Decentralized Identifier (DID)

DID Structure

A DID always follows a standardized structure defined by the W3C:

did:<method>:<method-specific-identifier>

For example:

• did:web:example.com (DID method using web infrastructure)
• did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK (DID method based on a cryptographic key)
• did:iota:0xe4edef97da1257e83cbeb49159cfdd2da6ac971ac447f233f8439cf29376ebfe (DID method using the IOTA blockchain)

The DID itself serves as a stable reference used to look up the cryptographic information needed to verify who controls it.

DID Documents

When a DID is resolved (similar to looking up a DNS record), it returns a DID Document containing technical metadata. A DID Document provides the public cryptographic material needed to verify signatures or interact with the DID owner, without exposing personal data or credentials.

A typical DID Document contains:

• Verification Methods (Public Keys): Public keys for signature verification
• Authentication Methods: Methods to authenticate as the DID subject
• Service Endpoints (optional): URLs for related services (e.g., messaging, credential repositories)
• Metadata (optional): Additional management information

DID Documents enable independent verification of digital signatures or encrypted communications without a central authority—crucial for verifying Verifiable Credentials (VCs), where the issuer's public key validates the credential's cryptographic signature.

DID Resolution

A DID Resolver is the component responsible for turning a DID into its corresponding DID Document. Because every DID method (e.g., did:web, did:key, did:ion) defines its own rules for how a DID is created, stored, and looked up, the resolver must implement the logic defined in each DID method specification. Without resolvers, DIDs would be unusable: you could read a DID string, but you would not be able to retrieve the public keys or service endpoints needed to verify signatures or interact with the identity. A resolver abstracts this complexity by exposing a simple, unified API (commonly DID Resolution [as per the DID Core spec]) while internally handling method-specific operations like reading a file from HTTPS (did:web), deriving a DID Document from a key (did:key), querying a blockchain (did:ion or did:ethr), or exchanging documents peer-to-peer (did:peer).

DID Methods and Technology Choices

While DIDs can utilize blockchain or distributed ledger technology, not all DID methods require blockchains. The DID standard is blockchain-agnostic. DID methods define how a DID is created, resolved, updated, and deactivated.

Common DID method categories include:

• Blockchain-based: did:ion, did:ethr, did:sov (use distributed ledgers)
• Web-based: did:web (leverages existing web infrastructure)
• Key-based: did:key (derived from a cryptographic public key)
• Peer methods: did:peer (for peer-to-peer relationships without a registry)

DIDs enable decentralization (no single controlling entity), self-ownership (you control the private key), independent verifiability (through cryptographic proofs), interoperability (work across platforms), and selective disclosure (share only necessary information).

Relationship to Verifiable Credentials

DIDs and Verifiable Credentials (VCs) work together in the decentralized identity ecosystem: A VC is issued by a DID (issuer), a VC is issued to a DID (subject), a VC is presented by a DID (holder). Verification of a VC uses the issuer's DID Document to obtain the public key needed to validate the credential's cryptographic signature. In essence, DIDs serve as identifiers, DID Documents provide cryptographic proof and endpoints, and VCs are signed claims about a DID. This separation ensures that personal data (in VCs) remains separate from the verification infrastructure (DID Documents).

Practical Applications

DIDs enable new approaches to digital identity across various domains. For comprehensive use cases in education, healthcare, finance, and other industries, see Verifiable Credentials and Self-Sovereign Identity (SSI).

Key DID-enabled capabilities include:

• Authentication: Instead of username/password combinations managed by each service provider, users authenticate with their DID and cryptographic proof of ownership, eliminating password databases and reducing breach risk.
• Credential Verification: When verifying credentials like university degrees, verifiers can check the issuer's signature against the issuer's DID Document rather than contacting the institution directly. See Verifiable Credentials for detailed credential use cases.
• Secure Messaging: Rather than relying on a messaging service to manage encryption keys, two parties can exchange encrypted messages using public keys from each other's DID Documents, enabling end-to-end encryption without a trusted intermediary.
• IoT Device Identity: Instead of manufacturers pre-programming device credentials that could be extracted, each IoT device gets a unique DID with rotation-capable keys, enabling secure device-to-device communication without centralized certificate authorities.