DO-IRP v3.0 Protocol Overview

1. Protocol Overview

The Digital Object Identifier Resolution Protocol (DO-IRP) is a core component of the Digital Object Architecture (DOA). It is an application-layer network protocol designed to manage and resolve unique, persistent identifiers in distributed network environments.

DO-IRP establishes a secure and reliable binding between an identifier and its state information, represented by an identifier record. Given an abstract identifier such as 86.1000/123, a client can locate and retrieve associated metadata, access locations, fingerprint information, or authorization policies.

The DO-IRP v3.0 specification discussed here was released by the DONA Foundation on June 30, 2022. It is intended to supersede the earlier Handle System Protocol (RFC 3650-3652) and provide a more neutral, general-purpose identifier resolution service.

2. Core Design Principles

DO-IRP differs from conventional DNS and URL-redirection protocols by emphasizing three core properties.

2.1 Decoupling Identifiers from Locations

DO-IRP does not directly transfer files or data streams. Instead, it resolves an Identifier Record. The identifier remains persistent while the underlying data location, such as a URL, IP address, or cloud-storage path, may change. Resolving the identifier record decouples the logical identifier from its physical location and preserves long-term identity.

2.2 Fine-Grained Administrative Authority

Unlike DNS, where administration is generally scoped to a zone, DO-IRP supports highly granular administrative control.

• Independence: each identifier can have its own administrator.
• Access control: the protocol includes PKI-based access control. Read and write permissions can be defined independently for each record element. For example, an element may be publicly readable while modifications require an administrator holding a specific private key.

2.3 Distributed and Federated Architecture

DO-IRP is designed for distributed deployment.

• Two-level resolution architecture: a client first contacts a Prefix Registration Service (PRS), which is analogous to a root service, to discover the Local Identifier Service (LIS) responsible for the identifier. The client then contacts the LIS directly to retrieve the data.
• Service autonomy: organizations can operate their own Local Identifier Services and independently manage identifiers in their namespaces while remaining interconnected through the global root service.

3. Key Capabilities

DO-IRP defines two primary classes of service operations:

1. Resolution services:
   • Retrieval: a client submits an identifier and receives a structured identifier record containing elements such as URLs, public keys, fingerprints, and metadata.
   • Type filtering: a client can request only selected data, such as the URL or public key associated with an identifier.
2. Administration services:
   • Lifecycle management: create and delete identifiers.
   • State maintenance: add, modify, and remove individual information elements in an identifier record.
   • Authority management: update administrative permissions and authentication keys online.

4. Application Scenarios

DO-IRP is applicable where data interoperability and resource management must span systems and organizations.

4.1 Persistent Identifier Systems

This is the canonical DO-IRP use case, as seen in systems such as DOI.

• Scenario: scholarly papers, datasets, standards, and similar resources require permanent references that remain valid even when the hosting server or domain changes.
• Role of DO-IRP: resolving the identifier dynamically returns the resource’s current URL or metadata, preserving the durability of the reference.

4.2 Cross-Domain Data Sharing and Data Networking

• Scenario: in data-networking or industrial-internet environments, data is distributed across private organizational domains. A unified identifier system connects these isolated data assets.
• Role of DO-IRP: each organization runs its own DO-IRP service, or LIS, and registers identifiers for its data assets. External systems resolve those identifiers to obtain access endpoints, such as API addresses, schema descriptions, and authorization policies. The data remains in place while identifiers provide interoperability.

4.3 Digital Object Lifecycle Management

• Scenario: the properties of digital assets, such as copyrighted files or medical records, change as the assets are created, transferred, and archived.
• Role of DO-IRP: applications use administration operations to update state fields such as Timestamp and Status in real time, allowing the identifier record to serve as a dynamic identity record for the digital object.

4.4 Identity and Public-Key Infrastructure Management

• Scenario: entities in IoT and distributed systems require unique identities and authentication.
• Role of DO-IRP: an identifier serves as the unique device ID, while the identifier record stores the device public key in an HS_PUBKEY element. A system resolves the ID to retrieve the key, verify device signatures, or establish an encrypted channel. This can support decentralized authentication without relying on a conventional CA certificate chain.

4.5 Service Discovery and Routing

• Scenario: microservices and distributed-computing systems need to locate concrete service instances from logical names.
• Role of DO-IRP: the logical name is registered as an identifier, and service instance details such as IP address, port, and protocol version are stored in the record’s HS_SITE element. Resolving the identifier dynamically discovers available service nodes.

5. Protocol Advantages

DO-IRP addresses identifier-management limitations in existing Internet architecture. Compared with conventional network protocols, it offers the following advantages.

5.1 Built-In, Fine-Grained Security

• Self-contained security mechanisms: DO-IRP does not rely on external security facilities such as SSL/TLS certificate chains. Public keys can be stored directly as elements in identifier records, and the protocol defines a public/private-key challenge-response authentication flow, providing native security at the protocol layer.
• Fine-grained permissions: each Element in an identifier record can have independent read and write permissions, including Public Read, Admin Write, and Admin Read. Administrators can also receive different operation privileges, such as permission to add identifiers without permission to delete them.

5.2 High Availability and Performance

• Flexible deployment architecture: a service site can contain multiple primary or mirror nodes. Multiple servers within a site distribute load through a hashing algorithm and reduce single points of failure.
• Multi-level caching: TTL-based caching is defined for clients and servers, reducing network round trips and improving resolution efficiency.

5.3 Transport Independence

• DO-IRP is an application-layer protocol and is not bound to a single transport. Although the specification recommends TCP or UDP, the protocol can also be tunneled over HTTP or HTTPS. This allows it to traverse firewalls and integrate with existing Web architectures.

5.4 Internationalization

• The protocol requires UTF-8 encoding, so identifiers and associated metadata can contain characters from any language without additional transcoding or extension packages.

6. Technical Characteristics

This section summarizes the protocol’s technical architecture and operating model.

6.1 Flat and Structured Data Model

• Identifier structure: identifiers use a prefix/suffix structure. A global registration authority assigns prefixes to ensure uniqueness across organizations, while each organization independently manages its suffixes. Suffixes may contain arbitrary levels without imposing a tree structure.
• Identifier Record structure: unlike DNS responses that commonly return addresses, a DO-IRP resolution result is a structured record containing multiple Elements. Each Element has a Type, Value, Index, and TTL, allowing one identifier to reference heterogeneous data such as URLs, email addresses, public keys, and fingerprints.

6.2 Client-Server Interaction Model

• The protocol uses a conventional request-response model. A client sends a request containing an OpCode, and the server returns a result containing a ResponseCode.
• Session management allows peers to establish a shared key after one handshake. Subsequent requests can use encryption (ENC) or message authentication (MAC), improving the efficiency and security of repeated operations.

6.3 Two-Stage Resolution

• Resolution is logically divided into two stages. The client first queries the root service by Prefix to obtain the responsible local Service Info, then connects directly to that local service to retrieve the identifier record. This design supports horizontal scalability.

7. Comparison with Related Technologies

The following table compares DO-IRP with DNS and LDAP to clarify their respective roles.

Summary

• DNS acts like the Internet’s phone book. It quickly translates human-readable names into machine-readable addresses, but provides limited complex data description and no native security in its basic form.
• DO-IRP acts as an identity system for digital objects. It can locate an object, authenticate its identity, and carry important object attributes, making it suitable as a data-exchange layer between heterogeneous systems.

8. Data Model: Element Definition

In DO-IRP, resolving an Identifier returns an Identifier Record composed of multiple Elements.

8.1 Common Element Structure

Every Element follows the same encoding structure regardless of its type.

Permission Bit Definitions

Permission is an 8-bit bitmask with the following definitions:

8.2 Predefined System Types

DO-IRP defines system types with the implicit 0.TYPE/ prefix. Their <Value> fields have specific binary structures.

8.2.1 HS_ADMIN (Administrators and Permissions)

Purpose: identifies who may administer an identifier record and defines the corresponding administrative permissions.

AdminPermission bit definitions:

8.2.2 HS_SITE (Service Site Information)

Purpose: describes a DO-IRP service site’s configuration, server list, and access interfaces.

Top-level HS_SITE structure:

ServerRecord structure:

Interface structure:

8.2.3 HS_PUBKEY (Public Key) / HS_SECKEY (Private Key)

Purpose: stores authentication keys.

8.2.4 HS_VLIST (Value List / Administrator Group)

Purpose: defines a set of references, commonly used to create an administrator group.

8.2.5 HS_CERT (Certificate) / HS_SIGNATURE (Signature)

Purpose: supports offline data-integrity verification and trust-chain construction. The content is serialized as a JWT (JSON Web Token).

HS_CERT Claims (JSON fields):

HS_SIGNATURE Claims (JSON fields):

Other System Types

9 Protocol Message Structure

A DO-IRP message consists of four consecutive parts: Envelope, Header, Body, and Credential.

9.1 Message Envelope

The Envelope has a fixed length of 20 bytes. Figure 6.2.1 divides its first 4 bytes among the version, flag, and suggested-version fields; the remaining 16 bytes carry the session, request, sequence, and message-length fields.

9.2 Message Header

The Header has a fixed length of 24 bytes. Figure 6.2.2 states that it contains eight fields; the final byte after RecursionCount is unnamed in the diagram and has no separate semantics defined by the specification.

9.2.1 Common OpCode Values

9.2.2 Common ResponseCode Values

9.2.3 OpFlag Values

9.3 Message Body

The Body structure depends on OpCode. If the Header’s RD (Request Digest) flag is set, the Body begins with a digest.

Common Body structure:

RequestDigest structure:

9.4 Message Credential

The Credential carries a digital signature or session MAC.

SignedInfo structure:

Signature coverage:

1. Envelope fields (12 bytes): Major/Minor/SuggVersion + SessionId + RequestId.
2. Credential field (4 bytes): SessionCounter.
3. The complete Message Header.
4. The complete Message Body.