DID Document

The top-level id property defines the DID subject—the entity identified by the document. This value must exactly match the DID being resolved. The DID itself follows the W3C generic syntax: did:method:method-specific-identifier.

• Example: did:example:123456789abcdefghi
• The method component (e.g., example) defines the rules for CRUD operations on the document.
• The method-specific identifier is a globally unique string derived cryptographically or from a registry.

The verificationMethod array embeds cryptographic material used to authenticate the DID subject. Each entry includes a key ID, type, controller, and the public key material itself.

• Common types: Ed25519VerificationKey2020, JsonWebKey2020, Multikey.
• The controller field specifies which DID has authority over the key, enabling complex custodial relationships.
• Keys can be expressed as embedded objects or referenced by a URI fragment: #keys-1.

The authentication array specifies which verification methods are authorized to prove control of the DID. This is a verification relationship—a semantic link between a key and a specific capability.

• A DID controller uses an authentication key to sign a challenge during a login flow.
• The array can contain full verification method objects or URI references to entries in verificationMethod.
• This separation allows key rotation without altering the authentication logic.

The service array declares network addresses for interacting with the DID subject. These enable discoverability of the subject's agents, data hubs, or messaging relays.

• Common service types: DIDCommMessaging, LinkedDomains, CredentialRegistryService.
• Each entry includes a serviceEndpoint—a URI or array of URIs.
• Example: A DIDCommMessaging endpoint points to a mediator that routes encrypted messages to the subject's wallet.

Beyond authentication, DID Documents define other capability delegations and assertion methods:

• assertionMethod: Keys authorized to issue Verifiable Credentials on behalf of the DID subject.
• keyAgreement: Keys used for establishing encrypted communication channels (e.g., ECDH-ES).
• capabilityInvocation: Keys authorized to invoke specific actions, such as updating the DID Document itself.
• capabilityDelegation: Keys authorized to delegate a capability to another DID.

The @context property is mandatory and anchors the document's terms to globally understood vocabularies. This ensures semantic interoperability across different DID methods and implementations.

• The first entry is typically the W3C DID Core context: https://www.w3.org/ns/did/v1.
• Additional contexts extend the document with domain-specific terms (e.g., for financial credentials or supply chain events).
• Proper context definition prevents namespace collisions and enables automated JSON-LD processing.