Decentralized Identifier (DID)

Decentralized Identifiers (DIDs) are globally unique identifiers for verifiable, self-sovereign digital identities. Unlike traditional identities managed by governments, banks, or platforms, DIDs are designed to give individuals control over their digital identity through independent verification of digital signatures or encrypted communications without a central authority. However, the actual level of decentralization and control depends heavily on the chosen DID method: some (like did:key) are truly self-sovereign, while others (like did:web) rely on existing centralized infrastructure like DNS.

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. This is what makes it possible to verify 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 interface (defined by the W3C DID Resolution specification) 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 resolverHolderIdentity walletIssuerVerifierVerifiable data registry a DIDmethod rulescontrolsissuespresentspublishes keys
A DID is a stable reference, and what it resolves to — a document holding public keys, not personal data — is what lets a verifier check a signature without asking the issuer.
VerifierDID resolverDID DocumentReads over HTTPSDerived from the keyQueries a ledger a DIDdid:webdid:keydid:ionpublic keys
One resolver interface, behind which every method does something different: did:web reads a file over HTTPS, did:key derives the document from the identifier itself, and did:ion queries a ledger — which is why the method rather than the standard decides how decentralized a deployment is.

DID Methods and Technology Choices

While DIDs can use 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 (uses 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), and interoperability (work across platforms). Selective disclosure, sharing only the necessary information, is a property of the credential format rather than of the DID.

Relationship to Verifiable Credentials

DIDs and Verifiable Credentials (VCs) have three points of contact: 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 detailed 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. Verifiers increasingly need an identifier and signing key of their own as well, because a wallet asked for a presentation through the W3C Digital Credentials API authenticates the requesting party before releasing attributes.
  • 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.