Decentralized Identifiers (DID)

What it is

A Decentralized Identifier (DID) is a globally unique identifier that its subject controls directly, without a central registration authority. It is the addressing layer of decentralized identity: where a URL points to a web page, a DID points to a DID document holding the public keys and service endpoints needed to interact with the subject, whether a person, an organization or a device.

A DID looks like did:method:identifier, for example did:web:example.com or did:key:z6Mk.... It is standardized by W3C DID Core 1.0. In practice, DIDs matter most as issuer identifiers: they let a verifier find the key that signed a verifiable credential without a central directory.

Status (November 2026)

The DID Working Group is chartered until 31 January 2027. DID 1.1 states it cannot exit Candidate Recommendation until DID Resolution meets its own exit criteria, so the two are coupled. Per its revision history, DID 1.1 refactors the spec onto Controlled Identifiers, moves resolution out, consolidates media types into application/did, and adds a v1.1 JSON-LD context. For implementers, 1.0 DID documents remain the baseline; 1.1 mainly changes how the spec is layered.

How it works

A verifier receives a credential signed by did:web:university.example:

1. Parse. The method is web, so the identifier maps to https://university.example/.well-known/did.json.
2. Resolve. A resolver applies the method's rules and returns the DID document plus resolution metadata. DID Resolution standardizes that interface.
3. Select a key. The credential's proof names a verification method such as did:web:university.example#key-1. Fragment dereferencing finds it in the document.
4. Check the relationship. The key must be listed under the right verification relationship (for credentials, assertionMethod), not just present.
5. Verify. The verifier checks the signature, then decides whether it trusts that DID as an issuer, typically through a trust registry or allowlist.

Step 5 is the one teams skip. A valid signature from a DID only proves control of a key, not that the controller is a real university.

DID methods

The method determines how a DID is created, updated and resolved. The W3C DID Extensions registry listed 275 methods on 5 November 2026 (272 registered, 3 deprecated). New entries are a JSON file in a pull request that passes automated validation, an AI-based preliminary spec review, and at least two maintainer reviews. That is a listing process, not a security audit. Our DID methods compared guide covers the trade-offs in depth.

See also the DID method glossary entry.

Who implements it

• Microsoft Entra Verified ID: its standards page lists did:web as the only entity identifier method, with DIF Well Known DID Configuration to tie a DID to a domain.
• Procivis: supports did:key, did:web, did:jwk and did:webvh.
• cheqd: did:cheqd is in the registry, pointing to cheqd's method spec.
• Hyperledger Indy, Aries and AnonCreds: did:indy is registered for "any Hyperledger Indy ledger".

Compare platforms in best decentralized identity platforms.

Security and privacy pitfalls

DID 1.1 and the did:web spec spell out the risks:

• Key loss and compromise. DID 1.1 says cryptography alone cannot show whether a key is compromised, so relying systems should periodically confirm the controller still has control. Plan rotation and recovery before launch, and never reuse recovery keys for other purposes.
• did:web inherits the web's weaknesses. Without DNSSEC or DNS over HTTPS, an attacker can serve a fake DID document. A compromised web server can rewrite did.json. There is no built-in history, so keep the document in version control.
• Resolution leaks. The DNS provider and web host can see who resolves a did:web, which tells them who is verifying whose credentials. Cache documents or use a trusted resolver.
• Correlation. A long-lived public DID for a person is a global tracking identifier. DID 1.1 warns against correlatable identifiers and data in DID documents. Use pairwise or ephemeral identifiers for holders.
• Method sprawl. Supporting many methods means trusting many resolvers. Pick two or three.
• Mistaking identifiers for trust. A DID is not an identity claim. Trust still comes from the credentials issued and the trust registries that vouch for issuers.

How it fits with the other standards

VC Data Model 2.0 credentials commonly name a DID as issuer, and Data Integrity proofs reference DID verification methods. OpenID4VP defines a decentralized_identifier client identifier prefix and OpenID4VCI's proofs can bind a credential to a holder key. The two largest government deployments use certificates instead: mDL chains to IACA roots, and HAIP and the EUDI Wallet use X.509 chains and trusted lists. If you need EU interoperability, plan for X.509 alongside DIDs.

Related

Guides: what is decentralized identity, what is self-sovereign identity, DID methods compared, decentralized identity vs federated identity. Standards: Verifiable Credentials, OpenID4VC, eIDAS 2 / EUDI Wallet, mDL. Glossary: DID, DID document, DID method, self-sovereign identity. Vendors: decentralized identity. Directory: digital IDs by country.

Who wrote it

The DID 1.0 specification was co-edited by Drummond Reed, Manu Sporny, and Christopher Allen, who also co-authored TLS 1.0 and named self-sovereign identity. Samuel M. Smith argues the ledger-less case with KERI. More in the experts directory.