← Back to packages

Package doirp_v3.v1

Service DoIrpService

Message DoidRecord

Message Ttl

Message Element

Message MessageHeader

Message Error

Message ResolveResult

Message ServiceReferral

Message ResolveRequest

Message ResolveResponse

Message AddElementRequest

Message AddElementResponse

Message RemoveElementRequest

Message RemoveElementResponse

Message ModifyElementRequest

Message ModifyElementResponse

Message CreateDoidRequest

Message CreateDoidResponse

Message DeleteDoidRequest

Message DeleteDoidResponse

Message ChallengeResponseRequest

Message ChallengeResponseResponse

Enum OpCode

Enum ResponseCode

Enum TtlType

Enum Permission

Enum Type

Enum AuthType

Services

service DoIrpService doirp_v3/v1/service.proto

Spec: 7.2 QUERY OPERATION (OC_RESOLUTION)

A query operation consists of a client sending a query request to the responsible server and the server returning the query result to the client. Query requests are used to retrieve identifier elements assigned to any given identifier.

Spec: 7.7.1 ADD ELEMENT(S) (OC_ADD_ELEMENT)

Clients add elements to existing identifier records by sending ADD_ELEMENT requests to the responsible server. The Message Header of the ADD_ELEMENT request must set its to OC_ADD_ELEMENT.

Spec: 7.7.2 REMOVE ELEMENT(S) (OC_REMOVE_ELEMENT)

Clients remove existing elements by sending REMOVE_ELEMENT requests to the responsible server. The Message Header of the REMOVE_ELEMENT request must set its to OC_REMOVE_ELEMENT.

Spec: 7.7.3 MODIFY ELEMENT(S) (OC_MODIFY_ELEMENT)

Clients can make modifications to an existing element by sending MODIFY_ELEMENT requests to the responsible server. The Message Header of the MODIFY_ELEMENT request must set its to OC_MODIFY_ELEMENT.

Spec: 7.7.4 CREATE IDENTIFIER (OC_CREATE_ID)

Clients can create new identifiers by sending CREATE_ID requests to the responsible server.

Spec: 7.7.5 DELETE IDENTIFIER (OC_DELETE_ID)

Clients delete existing identifiers by sending DELETE_ID requests to the responsible DO-IRP server. The Message Header of the DELETE_ID request must set its to OC_DELETE_ID.

Spec: 7.5 CLIENT AUTHENTICATION

Clients are asked to authenticate themselves as administrators when querying for any element with ADMIN_READ but no PUBLIC_READ permission. Client authentication is also required for any administration requests that require administrator privileges. This includes adding, removing, or modifying identifiers or elements.

Client authentication consists of multiple messages exchanged between the client and server. Such messages include the challenge from the server to the client to authenticate the client, the challenge-response from the client in response to the server's challenge, and the verification request and response message if secret key authentication takes place. Messages exchanged during the authentication are correlated via a unique assigned by the server. For each authentication session, the server needs to maintain the state information that includes the server's challenge, the challenge-response from the client, as well as the original client request.

The authentication starts with a response message from the server that contains a challenge to the client. The client must respond to the challenge with a challenge-response message. The server validates the challenge-response, either by verifying the digital signature inside the challenge- response, or by sending a verification request to another server (herein referred to as the verification server), that maintains the secret key for the administrator. The purpose of the challenge and the challenge-response is to prove to the server that the client possesses the private key (or the secret key) of the administrator. If the authentication fails, an error response will be sent back with the set to RC_AUTHEN_FAILED.

Upon successful client authentication, the server must also make sure that the administrator is authorized for the request. If the administrator has sufficient privileges, the server will process the request and send back the result. If the administrator does not have sufficient privileges, the server will return an error message with set to RC_INVALID_ADMIN.

Authentication is not about encryption (although encryption may be used in the process) and is accomplished by use of a Message Authentication Code or digital signature verification.

The following sections provide details of each message exchanged during the authentication process.

7.5.1 CHALLENGE FROM SERVER TO CLIENT

The Message Header of the CHALLENGE must keep the same as the original request and set the to RC_AUTH_NEEDED. If the message is not already part of an established session, the server must assign a non-zero unique in the Message Envelope to keep track of the authentication. It must also set the RD flag of the (see section 6.2.2.3) in the Message Header, regardless of whether the original request had the RD bit set or not. The Message Body of the server's CHALLENGE is defined as follows:

::=

where

Message Digest of the request message, as defined in section 6.2.3.

A 4-byte unsigned integer followed by a random string generated by the server via a secure random number generator. The integer specifies the number of octets in the random string. The size of the random string should be no less than 16 octets.

Note that the server will not sign the challenge if the client did not request the server to do so. If the client worries about whether it is speaking to the right server, it may ask the server to sign the . If the client requested the server to sign the but failed to validate the server's signature, the client should discard the server's response and reissue the request to the server.

7.5.2 CHALLENGE-RESPONSE FROM CLIENT TO SERVER

The Message Header of the CHALLENGE_RESPONSE must set its to OC_CHALLENGE_RESPONSE and its to 0.

Messages

message DoidRecord doirp_v3/v1/core.proto

Spec: 4 DATA MODEL

Each identifier may have a set of elements assigned to it, which are collectively known as the identifier's "Identifier Record". There is no inherent limit to the number of elements in each identifier record. Records can optionally contain an element which is a signature certifying the contents of the record; additionally, if requested by a client, messages used to transmit records shall be signed for security. Each such element has a specified "type" which is represented by a unique identifier of its own. DO-IRP servers maintain these Identifier Records and typically return an instance of each such requested Identifier Record in response to a request for resolution of that designated identifier. More tailored requests can result in specific elements of an identifier record being shown in a given returned identifier record.

4.1 IDENTIFIER RECORD

An identifier record thus consists of one or more elements, each of which contains multiple fields including its type, a value associated with that type, and a unique index number that distinguishes that element from other elements in the record, especially those with the same type. The specific type shown in an element may define the syntax, structure, possible semantics, or any other necessary descriptive characteristics of the element's value field. Each element also contains a set of administrative information such as a timestamp, Time to Live ("TTL") and certain associated permissions. Pre-defined types are discussed in section 4.3.

Figure 4.1 below shows the identifier "35.1234/abc" with a sample record with three elements with indexes 1,2 and 3; The element 1 is shown in detail below.

Identifier "35.1234/abc" | | V


| : 3 | ------------------------------------------------------------- | | : 2 | | ------------------------------------------------------------- | | | | | | | : 1 | | | | : 0.TYPE/URL | | | | : http://www.dlib.org/dlib... | | | | : {Relative: 24 hours} | | | | : PUBLIC_READ, ADMIN_WRITE | | | | : 927314334000 | |- | |-


Figure 4.1: Identifier "35.1234/abc" and its set of three elements

Figure 4.1 shows a single element whose index is set to 1. The type for this element is URL [5], which is represented in the system by the resolvable identifier 0.TYPE/URL. In general, a type is represented as a unique identifier and will either be a system type or a user created type. The URL data as stated in the field is "http://www.dlib.org/dlib... ". The TTL (time to live) entry suggests that the record should be cached no more than 24 hours before the source of the information should be consulted again. The field grants anyone permission to read; but only the administrator has permission to update that particular element.

Field Type Description
1 doid string

2 elements repeated doirp_v3.v1.Element

3 created_at uint32

The following two timestamp fields are not in the spec, added for convenience. Both are 4-byte unsigned integers representing the elapsed time since 00:00:00 UTC, January 1970 in seconds. the created time of the identifier

4 updated_at uint32

last time the identifier was updated at the server

message Ttl (Nested in doirp_v3.v1.Element ) doirp_v3/v1/core.proto

Spec: An octet followed by a 4-byte integer that specifies the Time-To-Live of the element. It is used to describe how long the element should be cached by clients before the source of the information (i.e., the corresponding DO-IRP server) should again be consulted. A zero value for a TTL indicates that the element should only be used for the transaction in progress and should not be cached. Any non-zero TTL is defined in terms of a TTL type (specified in the first octet), followed by the TTL value (the 32-bit integer that follows the TTL type). The TTL type indicates whether the TTL value is relative (octet 0x00) or absolute (octet 0x01). An absolute TTL value is an unsigned integer which defines the time to live as an expiration in terms of seconds since 00:00:00 UTC, January 1st 1970. A relative TTL specifies the time to live in terms of the number of seconds elapsed since the element was obtained by the client from any DO-IRP server. A relative TTL which would be negative if interpreted as a signed integer indicates that the element should not be cached.

Field Type Description
1 type doirp_v3.v1.Element.Ttl.TtlType
2 seconds uint32

interpreted as int32 when type is 1

message Element doirp_v3/v1/core.proto

Spec: 4.1 IDENTIFIER RECORD

Thus, an element may be thought of as group of fields which are defined below, along with the standard binary encoding of an element used by the DO-IRP protocol.

Field Type Description
1 index uint32

Spec: An unsigned 32-bit integer that uniquely differentiates an element from all the other elements in the identifier record. The index 0 is reserved. For maximum compatibility with existing implementations, indexes greater than or equal to 2^31 (which would represent negative values if interpreted as signed integers) should not be used.

2 type string

Spec: A UTF8-string that specifies the identifier for the type of the value field in the element.

The field is used to specify the identifier of the type that defines the syntax, format, and possible semantics of the data in the element's field. The identifier for a type can be specified by the creator of the element as desired, but this standard recommends that it be an identifier resolvable using DO-IRP to make it globally resolvable and accessible. See section 9 on Type Identifiers Consideration for more details.

The UTF8-string in the field shall not end with the "." character. However, for clarity, the "." character may appear in the end of the prefix used in an identifier query. This prefix string is used to query for all elements under a common type hierarchy. For example, one may query for all elements under the type hierarchy "a.b" (e.g., elements of "a.b.x", "a.b.y" and "a.b.z") by setting the parameter of the query to "a.b. ". Note here that the prefix in the query must specifically end with the "." character. Details of the query operation can be found in the protocol specification in section 7.2.

3 permission uint32

an eight-bit bit-mask for access control of the element, see Permission for details

4 ttl doirp_v3.v1.Element.Ttl

TTL of the element, see Ttl for details

5 created_at uint32

A 4-byte unsigned integer that records the created of the identifier. The field contains elapsed time since 00:00:00 UTC, January 1970 in seconds. This field is not in the spec, added for convenience.

6 updated_at uint32

Spec: A 4-byte unsigned integer that records the last time the element was updated at the server. The field contains elapsed time since 00:00:00 UTC, January 1970 in seconds.

7 value bytes

Spec: A sequence of octets (preceded by its length in a 4-byte unsigned integer). The syntax, format, and semantics of these octets are determined by the field.

This field is for custom element types defined by the IRS users. For standard types, use the dedicated typed fields defined below.

8 hs_admin doirp_v3.v1.element.HsAdmin

Spec: 4.3.1 IDENTIFIER ADMINISTRATOR: HS_ADMIN See element/hs_admin.proto for details

9 hs_site doirp_v3.v1.element.HsSite

Spec: 4.3.2 SERVICE SITE INFORMATION: HS_SITE 4.3.3 SERVICE SITE INFORMATION: HS_SITE.PREFIX See element/hs_site.proto for details

10 hs_serv doirp_v3.v1.element.HsServ

Spec: 4.3.4 SERVICE IDENTIFIER: HS_SERV 4.3.5 SERVICE IDENTIFIER: HS_SERV.PREFIX See element/hs_serv.proto for details

11 hs_pubkey doirp_v3.v1.element.HsPubkey

Spec: 4.3.6 IDENTITY: HS_PUBKEY See element/hs_pubkey.proto for details

12 hs_seckey bytes

require minimum length of 16 bytes for security

13 hs_vlist repeated doirp_v3.v1.common.ElementRef

Spec: 4.3.8 VALUE LIST: HS_VLIST

HS_VLIST allows referencing a list of elements in other identifiers, and allows the referenced elements to be updated without requiring an update of the referring identifier record. An HS_VLIST element is one whose is HS_VLIST and whose consists of a 4-byte unsigned integer followed by a list of references to other elements. The integer specifies the number of references in the list. The references may refer to elements under the same identifier or elements from other identifiers. Each reference is encoded as an UTF8-string followed by a 4-byte unsigned integer that identifies the referenced identifier and its index.

HS_VLIST elements may be used to define administrator groups for identifiers. Each administrator (as defined in 4.3.1) in the HS_VLIST includes is a member of the administrator group. Each element reference is defined in terms of an : pair. An administrator group may also contain other administrator groups as its members. This allows administrator groups to be defined in a hierarchical fashion. Care must be taken, however, to avoid a cyclic definition of administrators or administrator groups. Multiple levels of administrator groups should be avoided due to their lack of efficiency, but will not be signaled as an error. Client software should be prepared to detect any potential cyclic definition of administrators that refer to non-existent elements and treat them as errors.

14 hs_alias string

referenced DOID

message MessageHeader doirp_v3/v1/core.proto

Spec: 6.2.2 MESSAGE HEADER

The Message Header contains the common data elements among any protocol operation. It has a fixed size of 24 octets and consists of eight fields.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 .---------------------------------------------------------------. | OpCode | |---------------------------------------------------------------| | ResponseCode | |---------------------------------------------------------------| | OpFlag | |---------------------------------------------------------------| | SiteInfoSerialNumber | RecursionCount| | |---------------------------------------------------------------| | ExpirationTime | |---------------------------------------------------------------| | BodyLength | '---------------------------------------------------------------'

Figure 6.2.2: Message Header Fields

Every message that is not truncated must have a Message Header. If a message has to be truncated for its transmission, the Message Header must appear in the first truncated portion of the message.

This is different from the Message Envelope, which appears in each truncated portion of the message.

OpCode op_code = 1;

Field Type Description
2 response_code doirp_v3.v1.ResponseCode
3 op_flag uint32

Spec: 6.2.2.3

The is a 32-bit bit-mask that defines various control options for protocol operation. The following figure shows the location of each option flag in the field.

1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .---------------------------------------------------------------. |AT |CT |ENC|REC|CA |CN |KC |PO |RD |OWE|MNS|DNR| Reserved | |---------------------------------------------------------------| | Reserved | '---------------------------------------------------------------'

Figure 6.2.2.3: Option flags in the field

AT AuThoritative bit. A request with the AT bit set (to 1) indicates that the request should be directed to the primary service site (instead of any mirroring sites). A response message with the AT bit set (to 1) indicates that the message is returned from a primary server (within the primary service site)

CT CerTified bit. A request with the CT bit set (to 1) asks the server to sign its response with its digital signature by including a Message Credential (see section 6.2.4). A response with the CT bit set (to 1) indicates that the message is signed. The server must sign its response if the request has its CT bit set (to 1). If the server fails to provide a valid signature in its response, the client should discard the response and treat the request as failed.

ENC ENCryption bit. A request with the ENC bit set (to 1) requires the server to encrypt its response using the pre-established session key.

REC RECursive bit. A request with the REC bit set (to 1) asks the server to forward the query on behalf of the client if the request has to be processed by another DO-IRP server. The server may honor the request by forwarding the request to the appropriate server and passing on any result back to the client. The server may also deny any such request by sending a response with set to RC_SERVER_NOT_RESP.

CA Cache Authentication. This bit is reserved.

CN ContiNuous bit. A message with the CN bit set (to 1) tells the message recipient that more messages that are part of the same request (or response) will follow. This happens if a request (or response) has data that is sent as multiple messages. Unlike truncation at the level of the Message Envelope, which breaks down a single message into multiple for reasons of transport such as UDP message size, this indicates a request or response that is deliberately sent as multiple messages. This is used for example for the responses to requests to list identifiers.

KC Keep Connection bit. A message with the KC bit set requests that the message recipient keep the TCP connection open (after the response is sent back). This allows the same TCP connection to be used for multiple operations.

PO Public Only bit. Used by query operations only. A query request with the PO bit set (to 1) indicates that the client is only asking for elements that have the PUB_READ permission. A request with PO bit set to zero asks for all the elements regardless of their read permission. If any of the elements require ADMIN_READ permission, the server must authenticate the client as an administrator.

RD Request-Digest bit. A request with the RD bit set (to 1) asks the server to include in its response the message digest of the request. A response message with the RD bit set (to 1) indicates that the first field in the Message Body contains the message digest of the original request. The message digest can be used to check the integrity of the server response. Details of these are discussed in section 6.2.3.

OWE Overwrite when exists. When this bit is set on a request with OpCode OC_CREATE_ID or OC_ADD_ELEMENT, elements which already exist will be overwritten by the elements presented in the request. Otherwise the request will result in an error.

MNS Mint new suffix. When this bit is set on a request to create an identifier, the "identifier" field of the request will be considered the initial portion of the eventual identifier, which will be extended by the server to a new complete identifier. The initial portion should contain the slash.

DNR Do not refer. When this bit is set, a request which would normally result in a service referral or prefix referral response, will instead be applied on the server where the request is

4 site_info_serial_number uint32

Spec: 6.2.2.4

The is a two-byte unsigned integer. The in a request refers to the of the HS_SITE element used by the client (to access the server). Servers can check the in the request to find out if the client has up-to-date service information.

When possible, the server should fulfill a client's request even if the service information used by the client is out-of-date. However, the response message should specify the latest version of service information in the field. Clients with out-of-date service information can update the service information. If the server cannot fulfill a client's request due to expired service information, it should reject the request and return an error message with set to RC_EXPIRED_SITE_INFO.

5 recursion_count uint32

Spec: 6.2.2.5

The is a one-byte unsigned integer that specifies the number of service recursions. Service recursion happens if the server has to forward the client's request to another server. Any request directly from the client must have its set to 0. If the server has to send a recursive request on behalf of the client, it must increment the by 1. Any response from the server must maintain the same as the one in the request. To prevent an infinite loop of service recursion, the server should be configurable to stop sending a recursive request when the reaches a certain value.

6 expiration_time uint32

Spec: 6.2.2.6

The is a 4-byte unsigned integer that specifies the time when the message should be considered expired, relative to January 1st, 1970 GMT, in seconds. It is set to zero if no expiration is expected.

message Error doirp_v3/v1/service.proto

Spec: 7.3 ERROR RESPONSE FROM SERVER

A server will return an error message if it encounters an error when processing a request. Any error response from the server must maintain the same (in the message header) as the one in the original request. Each error condition is identified by a unique as defined in section 6.2.2.2 of this document. The Message Body of an error message may be empty. Otherwise it consists of the following data fields (unless otherwise specified):

::= [ ] [ ]

Field Type Description
1 message string

Spec: A UTF8-String that explains the error.

2 element_indexes repeated uint32

Spec: An optional field. Each index in the list is a 4-byte unsigned integer that refers to an element that contributed to the error.

An example would be a server that is asked to add three elements, with indexes 1, 2, and 3, and elements with indexes of 1 and 2 already in existence. In this case, the server could return an error message with set to RC_ELEMENT_ALREADY_EXIST and add index 1 and 2 to the . Note that the server is not obligated to return the complete list of indexes that may have caused the error.

message ResolveResult doirp_v3/v1/service.proto

Field Type Description
1 record doirp_v3.v1.DoidRecord

message ServiceReferral doirp_v3/v1/service.proto

Spec: 7.4 SERVICE REFERRAL AND PREFIX REFERRAL

A server may receive requests for identifiers that are managed by some other server or service. When this happens, the server has the option to either return a referral message that directs the client to the proper DO-IRP service, or simply return an error message with set to RC_SERVER_NOT_RESP. Service referral also happens when ownership of identifiers moves from one service to another. It may also be used by any DO-IRP service to indicate that some or all of its service may be performed by another DO-IRP service. Prefix referral in particular is used to indicate that a given prefix or prefixes may be resolvable and administered at a different service.

DO-IRP servers use the HS_SITE.PREFIX and HS_SERV.PREFIX element types in order to determine whether to send an RC_PREFIX_REFERRAL request. When a DO-IRP server is asked to resolve a prefix identifier 0.NA/., and the server does not have any information about 0.NA/. but does have 0.NA/ and the record for 0.NA/ includes HS_SITE.PREFIX and/or HS_SERV.PREFIX elements, those elements are returned to the client as a prefix referral response.

Since this behavior is purely in the server, server configuration can override this. This specification does not define under what conditions servers will send other prefix referral or service referral responses.

The Message Header of a service referral must maintain the same as the one in the original request and set its to RC_SERVICE_REFERRAL or RC_PREFIX_REFERRAL. The Message Body of any service referral or prefix referral is defined as follows:

::= [ ] [ ]

Field Type Description
1 referral_doid string

Spec: A UTF8-String that identifies the identifier (e.g., a service identifier) that maintains the referral information (i.e., the service information of the DO-IRP service to which it corresponds).

2 elements repeated doirp_v3.v1.Element

Spec: An optional field that must be empty if the is provided. When not empty, it consists a list of HS_SITE or HS_SERV elements, or, in the case of a prefix referral, HS_SITE.PREFIX or HS_SERV.PREFIX elements.

message ResolveRequest doirp_v3/v1/service.proto

Spec: 7.2.1 QUERY REQUEST (OC_RESOLUTION)

The Message Header of any query request must set its to OC_RESOLUTION (defined in section 6.2.2.1) and to 0.

The Message Body for any query request is defined as follows:

::=

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 doid string

Spec: A UTF8-String (as defined in section 6.1.4) that specifies the identifier to be resolved.

3 indexes repeated uint32

Spec: Each number in the integer array is an index and refers to an element to be retrieved. Set to an empty array to ask for all the elements regardless of their index.

4 types repeated string

Spec: Each UTF8-String in the list specifies a type. This tells the server to return all elements whose type is listed in the list. If a UTF8-String ends with the "." (0x2E) character, the server must return all elements whose type is under the type hierarchy specified in the UTF8-String. This means that the type is either exactly the supplied UTF8-String omitting the terminal "." character, or starts with the supplied UTF8- String including the "." character. The may be empty. In this case, the server must return all elements regardless of their type.

message ResolveResponse doirp_v3/v1/service.proto

Spec: 7.2.2 SUCCESSFUL QUERY RESPONSE

The Message Header of any query response must set its to OC_RESOLUTION. A successful query response must set its to RC_SUCCESS.

The message body of the successful query response is defined as follows:

::= [ ]

where

Optional field as defined in section 6.2.3.

A UTF8-String that specifies the identifier queried by the client.

A 4-byte unsigned integer followed by a list of elements. The integer specifies the number of elements in the list. The encoding of each element follows the specification given earlier (see section 4.1). The integer is set to zero if there is no element that satisfies the query.

7.2.3 UNSUCCESSFUL QUERY RESPONSE

If a server cannot fulfill a client's request, it must return an error message. The general format for any error message from the server is specified in section 7.3 of this document.

For example, a server must return an error message if the queried identifier does not exist in its database. The error message will have an empty message body and have its set to RC_ID_NOT_FOUND.

Note that a server should NOT return an RC_ID_NOT_FOUND message if the server is not responsible for the identifier being queried. It is possible that the queried identifier exists but is managed by another DO-IRP server (under some other DO-IRP service). When this happens, the server should either send a service referral (see section 7.4) or simply return an error message with set to RC_SERVER_NOT_RESP. See the requests for OC_HOME_PREFIX, OC_UNHOME_PREFIX, and OC_LIST_HOMED_PREFIXES for administering which prefixes for which a server considers itself responsible.

If the identifier exists, but there are no elements which match the client's query, then the server must return an RC_ELEMENT_NOT_FOUND message.

The server may return an error message with set to RC_SERVER_BUSY if the server is too busy to process the request. Like RC_ID_NOT_FOUND, an RC_SERVER_BUSY message also has an empty message body.

Servers should return an RC_ACCESS_DENIED message if the request does not have its PO flag set and asks for a specific element (via the index) that has neither PUBLIC_READ nor ADMIN_READ permission.

A server may ask its client to authenticate itself as the administrator during the resolution. This happens if the request does not have its PO flag set and any element in the query has ADMIN_READ permission, but no PUBLIC_READ permission. Details of client authentication are described in section 7.5

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 error doirp_v3.v1.Error
3 result doirp_v3.v1.ResolveResult

contains and

4 service_referral doirp_v3.v1.ServiceReferral

a service referral (see section 7.4)

message AddElementRequest doirp_v3/v1/service.proto

Spec: 7.7.1 ADD ELEMENT(S) (OC_ADD_ELEMENT)

Clients add elements to existing identifier records by sending ADD_ELEMENT requests to the responsible server. The Message Header of the ADD_ELEMENT request must set its to OC_ADD_ELEMENT.

The Message Body of the ADD_ELEMENT request is encoded as follows:

::=

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 doid string

Spec: A UTF8-String that specifies the identifier.

3 elements repeated doirp_v3.v1.Element

Spec: A 4-byte unsigned integer followed by a list of elements. The integer indicates the number of elements in the list.

message AddElementResponse doirp_v3/v1/service.proto

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 error doirp_v3.v1.Error

message RemoveElementRequest doirp_v3/v1/service.proto

Spec: 7.7.2 REMOVE ELEMENT(S) (OC_REMOVE_ELEMENT)

Clients remove existing elements by sending REMOVE_ELEMENT requests to the responsible server. The Message Header of the REMOVE_ELEMENT request must set its to OC_REMOVE_ELEMENT.

The Message Body of any REMOVE_ELEMENT request is encoded as follows:

::=

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 doid string

Spec: A UTF8-String that specifies the identifier whose element(s) needs to be removed.

3 indexes repeated uint32

Spec: A 4-byte unsigned integer followed by a list of indexes. Each index refers to an element to be removed from the . The integer specifies the number of indexes in the list. Each index is also encoded as a 4-byte unsigned integer.

message RemoveElementResponse doirp_v3/v1/service.proto

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 error doirp_v3.v1.Error

message ModifyElementRequest doirp_v3/v1/service.proto

Spec: 7.7.3 MODIFY ELEMENT(S) (OC_MODIFY_ELEMENT)

Clients can make modifications to an existing element by sending MODIFY_ELEMENT requests to the responsible server. The Message Header of the MODIFY_ELEMENT request must set its to OC_MODIFY_ELEMENT.

The Message Body of any MODIFY_ELEMENT request is defined as follows:

::=

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 doid string

Spec: A UTF8-String that specifies the identifier whose element(s) needs to be modified.

3 elements repeated doirp_v3.v1.Element

Spec: A 4-byte unsigned integer followed by a list of elements. The integer specifies the number of elements in the list. Each element in the specifies an element that will replace the existing element with the same index.

message ModifyElementResponse doirp_v3/v1/service.proto

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 error doirp_v3.v1.Error

message CreateDoidRequest doirp_v3/v1/service.proto

Spec: 7.7.4 CREATE IDENTIFIER (OC_CREATE_ID)

Clients can create new identifiers by sending CREATE_ID requests to the responsible server. The Message Header of any CREATE_ID request must set its to OC_CREATE_ID. The Message Body of any CREATE_ID request is defined as follows:

::=

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 record doirp_v3.v1.DoidRecord

contains and

message CreateDoidResponse doirp_v3/v1/service.proto

Spec: 7.7.4 CREATE IDENTIFIER

The Message Body of a successful Create Identifier Response is defined as follows:

::= []

The is the optional request digest of the Create Identifier Request, as defined in section 6.2.3. The is the UTF8-String of the identifier that was actually created, allowing the client to discover the created identifier when the MNS flag was set.

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 error doirp_v3.v1.Error
3 doid string

Spec:

message DeleteDoidRequest doirp_v3/v1/service.proto

Spec: 7.7.5 DELETE IDENTIFIER (OC_DELETE_ID)

Clients delete existing identifiers by sending DELETE_ID requests to the responsible DO-IRP server. The Message Header of the DELETE_ID request must set its to OC_DELETE_ID.

The Message Body of any DELETE_ID request is defined as follows:

::=

The server that receives the DELETE_ID request must first authenticate the client as the administrator with the DELETE_ID privilege. Upon successful authentication, the server will proceed to delete the identifier along with any elements assigned to the identifier. If successful, the server will return an RC_SUCCESS message to the client.

Each DELETE_ID request must be carried out as a transaction. If any part of the DELETE_ID process fails, the entire operation must be rolled back. For example, if the server fails to remove any elements assigned to the identifier (before deleting the identifier), it must return an error message without deleting the identifier. A DELETE_ID request that asks to delete a non-existing identifier will also be treated as an error. The server will return an error message with the set to RC_ID_NOT_EXIST.

DELETE_ID requests can also be used to delete prefix identifiers.

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 doid string

Spec: A UTF8-String that specifies the identifier.

message DeleteDoidResponse doirp_v3/v1/service.proto

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 error doirp_v3.v1.Error

message ChallengeResponseRequest doirp_v3/v1/service.proto

Spec: 7.5.2 CHALLENGE-RESPONSE FROM CLIENT TO SERVER

The Message Header of the CHALLENGE_RESPONSE must set its to OC_CHALLENGE_RESPONSE and its to 0. It must also keep the same (in the Message Envelope) as specified in the challenge from the server.

The Message Body of the CHALLENGE_RESPONSE request is defines as follows:

::=

Field Type Description
1 header doirp_v3.v1.MessageHeader
2 auth_type doirp_v3.v1.ChallengeResponseRequest.AuthType

Spec: A UTF8-String that identifies the type of authentication key used by the client. The field is set to "HS_SECKEY" if the client chooses to use a secret key for its authentication. The field is set to "HS_PUBKEY" if a public key is used instead.

3 key_ref doirp_v3.v1.common.ElementRef

Spec: A UTF8-String that identifies the identifier that holds the public or secret key of the administrator.

A 4-byte unsigned integer that specifies the index of the element (of the ) that holds the public or secret key of the administrator.

5 challenge_response bytes

Spec: A 4-byte unsigned integer indicating the length of the following byte array, which contains either the Message Authentication Code (MAC) or the digital signature over the challenge from the server. The used to produce the MAC or signature is the concatenation of the bytes of the from the CHALLENGE message, excluding the initial 4 length bytes, followed by the from the CHALLENGE message, excluding the initial byte.

message ChallengeResponseResponse doirp_v3/v1/service.proto

Field Type Description
1 header doirp_v3.v1.MessageHeader

Enums

enum OpCode doirp_v3/v1/core.proto

Spec: 6.2.2.1

The stands for operation code, which is a four-byte unsigned integer that specifies the intended operation.

A detailed description of each of these s can be found in section 7 of this document. In general, clients use the to tell the server what kind of operation they want to accomplish. Response from the server must maintain the same as the original request and use the to indicate the result.

Name Number Description
OP_CODE_RESERVED 0

Reserved

OP_CODE_RESOLUTION 1

Identifier query

OP_CODE_GET_SITEINFO 2

Get HS_SITE element

OP_CODE_CREATE_ID 100

Create new identifier

OP_CODE_DELETE_ID 101

Delete existing identifier

OP_CODE_ADD_ELEMENT 102

Add element(s)

OP_CODE_REMOVE_ELEMENT 103

Remove element(s)

OP_CODE_MODIFY_ELEMENT 104

Modify element(s)

OP_CODE_LIST_IDS 105

List identifiers

OP_CODE_LIST_DERIVED_PREFIXES 106

List derived prefixes

OP_CODE_CHALLENGE_RESPONSE 200

Response to challenge

OP_CODE_VERIFY_RESPONSE 201

Verify challenge response

OP_CODE_HOME_PREFIX 300

Home prefix (instruct server to consider itself responsible for the prefix)

OP_CODE_UNHOME_PREFIX 301

Unhome prefix

OP_CODE_LIST_HOMED_PREFIXES 302

List homed prefixes

OP_CODE_SESSION_SETUP 400

Session setup request

OP_CODE_SESSION_TERMINATE 401

Session termination request

enum ResponseCode doirp_v3/v1/core.proto

Spec: 6.2.2.2

The is a 4-byte unsigned integer that is given by a server to indicate the result of any service request.

Detailed descriptions of these s can be found in section 7 of this document. In general, any request from a client must have its set to 0. The response message from the server must have a non-zero to indicate the result. For example, a response message from a server with set to RC_SUCCESS indicates that the server has successfully fulfilled the client's request.

Name Number Description
RESPONSE_CODE_RESERVED 0

Reserved for request

RESPONSE_CODE_SUCCESS 1

Success response

RESPONSE_CODE_ERROR 2

General error

RESPONSE_CODE_SERVER_BUSY 3

Server too busy to respond

RESPONSE_CODE_PROTOCOL_ERROR 4

Corrupted or unrecognizable message

RESPONSE_CODE_OPERATION_DENIED 5

Unsupported operation

RESPONSE_CODE_RECUR_LIMIT_EXCEEDED 6

Too many recursions for the request

RESPONSE_CODE_SERVER_BACKUP 7

Server storage is temporarily read-only as for backup

RESPONSE_CODE_ID_NOT_FOUND 100

Identifier not found

RESPONSE_CODE_ID_ALREADY_EXIST 101

Identifier already exists

RESPONSE_CODE_INVALID_ID 102

Encoding (or syntax) error

RESPONSE_CODE_ELEMENT_NOT_FOUND 200

Element not found

RESPONSE_CODE_ELEMENT 201

ALREADY_EXIST Element already exists

RESPONSE_CODE_ELEMENT_INVALID 202

Invalid Element

RESPONSE_CODE_EXPIRED_SITE_INFO 300

SITE_INFO out of date

RESPONSE_CODE_SERVER_NOT_RESP 301

Server not responsible

RESPONSE_CODE_SERVICE_REFERRAL 302

Server referral

RESPONSE_CODE_PREFIX_REFERRAL 303

Prefix referral

RESPONSE_CODE_INVALID_ADMIN 400

Not an admin for operation

RESPONSE_CODE_ACCESS_DENIED 401

Insufficient permissions

RESPONSE_CODE_AUTHEN_NEEDED 402

Authentication required

RESPONSE_CODE_AUTHEN_FAILED 403

Failed to authenticate

RESPONSE_CODE_INVALID_CREDENTIAL 404

Invalid message credential

RESPONSE_CODE_AUTHEN_TIMEOUT 405

Authentication timed out

RESPONSE_CODE_UNABLE_TO_AUTHEN 406

Unexpected error authenticating

RESPONSE_CODE_SESSION_TIMEOUT 500

Session expired

RESPONSE_CODE_SESSION_FAILED 501

Unable to establish session

RESPONSE_CODE_SESSION_KEY_INVALID 502

Invalid session key or session authentication failure

RESPONSE_CODE_SESSION_MSG_REJECTED 505

Potential session replay attack

enum TtlType doirp_v3/v1/core.proto

Name Number Description
TTL_TYPE_RELATIVE 0
TTL_TYPE_ABSOLUTE 1

enum Permission doirp_v3/v1/core.proto

defines the permissions bit flags for elements

Name Number Description
PERMISSION_UNSPECIFIED 0
PERMISSION_PUBLIC_WRITE 1

Spec: PUBLIC_WRITE (0x01) permission that allows anyone to modify or delete the element.

PERMISSION_PUBLIC_READ 2

Spec: PUBLIC_READ (0x02) permission that allows anyone to read the element.

PERMISSION_ADMIN_WRITE 4

Spec: ADMIN_WRITE (0x04) permission that allows any authenticated administrator with Modify_Element Delete_Element privileges (see 4.3.1) to update or delete the element

PERMISSION_ADMIN_READ 8

Spec: ADMIN_READ (0x08) permission that allows any authenticated administrator with "Authorized_Read" privilege (see section 4.3.1 below) to read the element.

enum Type doirp_v3/v1/core.proto

This is for generating consts, won't be used directly in .proto files.

Name Number Description
TYPE_UNSPECIFIED 0
TYPE_HS_ADMIN 1

0.TYPE/HS_ADMIN

TYPE_HS_SITE 2

0.TYPE/HS_SITE

TYPE_HS_SITE_PREFIX 3

0.TYPE/HS_SITE.PREFIX

TYPE_HS_SERV 4

0.TYPE/HS_SERV

TYPE_HS_SERV_PREFIX 5

0.TYPE/HS_SERV.PREFIX

TYPE_HS_PUBKEY 6

0.TYPE/HS_PUBKEY

TYPE_HS_SECKEY 7

0.TYPE/HS_SECKEY

TYPE_HS_VLIST 8

0.TYPE/HS_VLIST

TYPE_HS_ALIAS 9

0.TYPE/HS_ALIAS

TYPE_HS_CERT 10

0.TYPE/HS_CERT

TYPE_HS_SIGNATURE 11

0.TYPE/HS_SIGNATURE

enum AuthType doirp_v3/v1/service.proto

Name Number Description
AUTH_TYPE_HS_SECKEY 0
AUTH_TYPE_HS_PUBKEY 1