DID Fragment

A DID Fragment is the part of a Decentralized Identifier (DID) that follows the hash (#) symbol, used to point to a specific key, service endpoint, or other component within the DID's associated DID Document. The full DID URI syntax is did:method:identifier#fragment. For example, in the DID did:example:123456789abcdefghi#key-1, the fragment key-1 references a specific public key listed in the corresponding DID document. This mechanism allows a single DID to manage multiple cryptographic keys, service endpoints, or verification methods, each addressable by its unique fragment.

The primary function of a DID fragment is internal referencing within the context of its parent DID. It is not a standalone identifier and has no meaning outside the DID document it points into. When a verifier or relying party resolves the full DID URI including the fragment, the process involves first fetching the complete DID document from its resolver, then using the fragment to locate the specific JSON object (like a verificationMethod or service entry) within that document. This enables precise, cryptographically verifiable references to specific capabilities, such as signing a particular type of credential or connecting to a specific messaging service.

From a technical perspective, the fragment is defined by the DID Core specification (W3C) and its behavior is analogous to the fragment identifier in a standard URL. The syntax and semantics of what a fragment can point to are defined by the specific DID method in use and the structure of its DID documents. Common uses include referencing different public keys for various purposes (authentication, assertion, key agreement), linking to service endpoints for communication, or pointing to specific Verifiable Credentials or presentations. Proper use of fragments is crucial for building complex, interoperable decentralized identity systems where a single entity manages multiple relationships and capabilities.

A DID Fragment is a string component appended to a Decentralized Identifier (DID) using a hash (#) symbol, forming a DID URL that references a specific part of the associated DID document. For example, the DID URL did:example:123456789abcdefghi#keys-1 uses the fragment keys-1 to point directly to a specific public key entry within the broader DID document. This mechanism enables fine-grained addressing, allowing applications to reference a particular verification method, service endpoint, or other JSON property without needing to parse the entire document.

The primary function of a fragment is to create an internal reference or anchor within the DID document's data structure. When a verifier or a relying party resolves the full DID URL, the resolver first fetches the complete DID document. It then uses the fragment identifier to locate the specific JSON object, typically by matching an id property. This is crucial for operations like digital signatures, where a proof must specify exactly which key from the document was used for signing, ensuring cryptographic precision and preventing ambiguity.

From an architectural perspective, fragments enable modularity and key rotation. A single DID document can contain multiple public keys for different purposes (e.g., authentication, assertion, key agreement). Each can be assigned a unique fragment identifier, such as #auth-key or #encryption-key. This allows services to be updated independently; a new signing key can be added with a new fragment without invalidating references to older, still-valid keys. It mirrors the functionality of URL fragments in web pages, providing direct, stable pointers to subsections of a structured document.

Implementing DID fragments requires strict adherence to the DID Core specification regarding URL syntax and document structure. The fragment itself is never sent over the network during the resolution process; it is a client-side directive for processing the retrieved document. This design ensures that the core DID resolution protocol remains simple and universal, while the fragment handling provides the necessary layer of specificity for advanced identity management and verifiable credential workflows, forming a foundational pattern for scalable decentralized identity systems.

A DID Fragment is the component of a Decentralized Identifier (DID) URL that follows the hash (#) character, serving as a pointer to a specific section or resource within the associated DID Document. The full syntax is did:method:identifier#fragment. For example, in the DID URL did:example:123456789abcdefghi#key-1, the fragment is key-1. This mechanism allows a single DID document, which can contain multiple public keys, service endpoints, and other data, to be referenced with surgical precision, enabling verifiers to identify the exact cryptographic material or service needed for an interaction without processing the entire document.

The primary function of a fragment is disambiguation and direct reference. A DID document is a JSON-LD structure that may list several verification methods (e.g., for authentication, assertion, or key agreement). By appending a fragment like #key-2 or #auth-key, the controller can specify which exact key should be used for a particular operation, such as signing a Verifiable Credential. This is crucial for key rotation and management, as different keys can be used for different purposes or time periods, all under the same persistent DID.

From a syntactic and parsing perspective, the fragment is not sent to the DID resolver. The resolver's job is to fetch the complete DID document using the portion of the URL before the hash (did:method:identifier). Once the document is retrieved, the consuming application uses the fragment to navigate within the JSON structure, typically by matching the fragment value against the id property of an object within the document. It is a client-side dereferencing mechanism. The W3C DID Core specification mandates that fragment identifiers must be interpreted in accordance with the DID document's data model and representation (e.g., JSON-LD).

In practice, fragments enable complex, real-world use cases. A DID document for a corporate entity might contain separate keys for the CEO, the legal department, and a robotic process automation (RPA) service. Using fragments like #ceo-sig-2025, #legal-approval, and #rpa-endpoint, the entity can issue and control credentials with clear authority chains. Similarly, in user-centric identity, a personal DID might use #master-key for recovery and #device-key-phone for daily authentication, all referenced cleanly from the same foundational identifier.

It is important to distinguish the DID fragment from the DID Query component, which precedes the fragment and uses a question mark (?) for parameterization (e.g., did:example:123?versionId=2#key-1). While query parameters might instruct the resolver how to fetch a specific version or representation of the document, the fragment instructs the client what to look for inside it. This separation of concerns is a key design pattern in decentralized identifier architecture, ensuring resolvers remain simple and universal while clients handle specific resource selection.

The resolution process with a fragment is the mechanism by which a DID resolver locates and returns a specific part of a DID Document, rather than the entire document. When a client submits a DID URL containing a fragment (e.g., did:example:123#key-1), the resolver first performs standard DID resolution to fetch the complete, verified DID Document. The fragment component (#key-1) is then used as an internal pointer, instructing the resolver to extract and return only the identified component, such as the specific verification method or service endpoint listed under that identifier within the document's data structure.

This process is crucial for enabling fine-grained interactions in decentralized systems. For instance, a verifier needing to check a signature only requires the specific public key used, not the identity holder's entire suite of keys or service listings. By resolving did:example:123#key-1, the resolver efficiently returns the JSON object for that single key. This targeted resolution supports use cases like selective disclosure, where different fragments can point to different cryptographic keys for distinct purposes (authentication, assertion, key agreement), or to specific service endpoints for communication or credential exchange.

The syntax and semantics of fragments are defined by the DID specification and the method governing the DID. The fragment identifier must correspond to the id property of an object within the DID Document. If the fragment does not resolve to a valid component, the resolution process fails for that specific dereferencing request. This architecture ensures that DIDs can function as compound URIs, where the base DID provides global, persistent identification, and the fragment enables precise, internal addressing within the decentralized identity's data set, separating the identifier from the identified data.