DID Resolution

The DID Document is the JSON-LD object returned by resolution. It contains the public keys, service endpoints, and authentication mechanisms associated with the DID. This document is the core credential enabling interactions like signing and encryption.

• Public Keys: Used for verification and key agreement.
• Service Endpoints: URLs for interacting with the DID subject (e.g., a messaging service).
• Proof of Control: The document proves the controller can cryptographically prove ownership of the DID.

A Resolver is the software component that performs the resolution process. It takes a DID string as input and returns a DID Resolution Result containing the DID Document and metadata. Resolvers can be:

• Universal Resolvers: Handle multiple DID methods.
• Method-Specific Resolvers: Built for a single DID method (e.g., did:ethr, did:key).
• Client-Side or Server-Side: Can run in a browser, mobile app, or as a backend service.

A DID Method defines the specific syntax, operations, and underlying ledger or network for a DID scheme (e.g., did:ethr:..., did:web:...). The method specification dictates:

• CRUD Operations: How to Create, Read, Update, and Deactivate DIDs on that network.
• Resolution Algorithm: The precise steps the resolver must follow to fetch the DID Document.
• Verifiable Data Registry: The system (blockchain, database, etc.) where the DID's state is anchored.

The DID Resolution Result is the standardized JSON output of the resolution process, defined by the W3C. It contains more than just the DID Document.

Key components include:

• didDocument: The resolved DID Document (if successful).
• didDocumentMetadata: Timestamps, version info, and proof of ledger consistency.
• didResolutionMetadata: Resolution process details like content type, error messages, and resolver implementation data.

A Verifiable Data Registry is the trusted system where DIDs and their associated public keys are recorded. It provides the necessary data integrity and non-repudiation for the resolution process.

Common VDRs include:

• Public Blockchains (Ethereum, Bitcoin, Solana)
• Distributed Ledgers (Hyperledger Indy, IOTA)
• Decentralized Networks (IPFS, Git)
• Secure Databases (with verifiable logs)

The VDR is the source of truth the resolver queries.

A DID URL extends a basic DID string to point to specific components within a DID Document or request a particular representation. It enables precise, functional addressing.

Examples:

• Service Endpoint: did:example:123456#linked-domain
• Specific Key: did:example:123456#key-1
• Query Parameters: did:example:123456?service=agent&relativeRef=/path
• Versioning: did:example:123456?versionId=2

Resolution must correctly parse and process these URL components.

DID Resolution is the multi-step process of taking a DID string (e.g., did:ethr:0x...) and returning its corresponding DID Document. The process involves:

• Parsing the DID to extract its method and identifier.
• Resolving the identifier via the appropriate DID method.
• Validating the retrieved DID Document's integrity and authenticity.
• Returning the document, along with optional resolution metadata (e.g., timestamps, proof validity).

A DID method defines the precise rules for creating, resolving, updating, and deactivating DIDs on a specific verifiable data registry (e.g., a blockchain). Each method, like did:ethr (Ethereum) or did:sov (Sovrin), has its own specification detailing:

• The structure of its DID identifier.
• How the DID Document is anchored to its underlying system (e.g., via smart contracts or ledger transactions).
• The cryptographic operations supported for key management.

A Verifiable Data Registry is the decentralized system where DID Documents and their associated public keys are anchored. It is the trust root for the DID method. Common VDRs include:

• Blockchains (Ethereum, Bitcoin, Polygon) for did:ethr, did:btcr.
• Distributed Ledgers (Hyperledger Indy, Sovrin).
• Decentralized Storage Networks (IPFS) for did:web or did:key. The resolver interacts with the VDR to fetch the immutable, verifiable data.

These are distinct operations in the W3C specification:

• Resolution fetches the entire DID Document for a DID.
• Dereferencing fetches a specific component within a DID Document or a resource identified by a DID URL (e.g., did:example:123#key-1 to get just one public key). Dereferencing is often performed after resolution to extract a particular verification method or service endpoint.

The security of the resolution process depends on the trustworthiness of the DID method's resolution endpoint or the Universal Resolver. Key risks include:

• Man-in-the-Middle (MitM) Attacks: Interception of resolution requests/responses.
• Endpoint Compromise: A malicious or hijacked resolver returning fraudulent DID documents.
• Centralization Risk: Over-reliance on a single resolver service creates a single point of failure. Secure resolution requires authenticated channels (HTTPS, DIDs for resolvers) and decentralized resolver networks.

A resolved DID document must be cryptographically verifiable as the current, correct state for that DID. Threats include:

• Document Tampering: Altering public keys or service endpoints post-resolution.
• Replay Attacks: Substituting an old, valid document for the current one.
• Key Revocation Lag: Using a compromised key before the revocation is reflected on-chain. Mitigations rely on the DID method's underlying ledger (e.g., blockchain) for immutable proofs and digital signatures embedded in the document or its metadata.

A core security promise of DIDs is censorship-resistant identity. Resolution can be vulnerable if:

• The underlying blockchain (for blockchain-based DIDs) is susceptible to 51% attacks or transaction censorship.
• Resolver Governance is centralized, allowing operators to blacklist DIDs.
• Network Accessibility is limited, preventing certain users from querying the resolver. Security is measured by the liveness guarantee—the assurance that any honest party can resolve any DID without permission.

The resolution process itself can leak sensitive metadata, creating privacy risks:

• Resolver Correlation: A centralized resolver can log which DIDs a user is querying, building a profile.
• Network Surveillance: Observing resolution requests on a public network (e.g., P2P gossip).
• Document Content: DID documents may contain personal service endpoints (e.g., email, IP addresses). Privacy-enhancing techniques include onion routing for requests, blinded resolvers, and minimalist DID documents that avoid PII.

Attackers can target the availability and performance of the resolution system:

• Denial-of-Service (DoS): Flooding a resolver or its underlying infrastructure (e.g., RPC nodes for a blockchain DID method).
• Slow/Lazy Resolution: Malicious resolvers intentionally delaying responses to degrade user experience.
• Cache Poisoning: Injecting invalid DID documents into resolver caches. Defenses involve rate limiting, decentralized resolver architectures, efficient caching strategies, and service-level monitoring.

Security flaws often arise from incorrect implementation of the W3C DID Core specification or specific DID method specifications. Common issues include:

• Insecure Defaults: Lack of TLS, improper signature validation.
• Parsing Vulnerabilities: Malformed DID documents or DID URLs causing crashes or injection.
• Method-Specific Exploits: Flaws in the smart contract logic of an on-chain DID registry. Mitigation requires rigorous auditing of resolver code, conformance testing to specifications, and responsible vulnerability disclosure programs.