The Decentralized Identifier specification, elevated to a W3C Recommendation in July 2022, represents the most ambitious attempt to re-architect the internet’s identity layer since the Domain Name System was deployed in 1983. Like DNS, DIDs provide a globally unique, resolvable identifier system. Unlike DNS, DIDs are designed to operate without centralized registries, to be controlled by their subjects rather than their registrars, and to provide cryptographic proof of control rather than administrative assertion of ownership. The comparison to DNS is not casual — DIDs are intended to be for identity what domain names are for network addressing: a universal, interoperable, resolution-based system that any application can use.
But the DID ecosystem, four years after standardization, remains fractured by a fundamental architectural tension that threatens to undermine its interoperability promise: the proliferation of DID methods. There are now over 150 registered DID methods, each defining a different mechanism for creating, resolving, updating, and deactivating DIDs. This diversity reflects the specification’s intentional extensibility, but it creates a practical interoperability crisis that the community must resolve if DIDs are to fulfill their potential as a universal identity layer.
Anatomy of a Decentralized Identifier
A DID is a URI — a Uniform Resource Identifier — with a specific syntax: did:method:method-specific-identifier. The three-part structure separates the DID scheme (did:), the method that defines how the DID is resolved (method:), and the identifier itself (method-specific-identifier). For example:
did:web:zuglogin.com— a DID resolved via the web (HTTP/HTTPS)did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK— a self-resolving DID derived from a public keydid:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a— a DID anchored on the Ethereum blockchaindid:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9JPhl_xLDI9Nfk38w5w— a DID anchored on Bitcoin via the ION network
Each DID resolves to a DID Document — a JSON-LD or JSON structure that contains the information necessary to interact with the DID subject. A typical DID Document includes:
- Verification Methods: Public keys or other cryptographic material that can be used to authenticate the DID subject, verify digital signatures, or establish encrypted communication channels.
- Authentication: References to verification methods authorized for authenticating as the DID subject.
- Assertion Method: References to verification methods authorized for issuing verifiable credentials or other signed assertions.
- Service Endpoints: URLs for services associated with the DID subject — messaging endpoints, credential issuance services, or personal data stores.
The DID Document is the bridge between the identifier and the entity it represents. It is, in essence, a self-describing identity record that contains everything a relying party needs to establish a cryptographically authenticated relationship with the DID subject.
The Method Proliferation Problem
The DID specification deliberately defines a meta-system — a framework for creating DID methods — rather than prescribing a single method. This design decision was intentional and, at the time, politically necessary: the DID community included blockchain maximalists who wanted DIDs anchored on specific chains, enterprise architects who wanted web-based resolution, and cryptography purists who wanted self-resolving identifiers with no external dependencies. The method abstraction accommodated all of these constituencies.
The consequence, however, is a fragmented ecosystem. With over 150 registered methods, a verifier that supports did:web resolution cannot verify credentials from a holder using did:ethr unless the verifier also implements did:ethr resolution. Each DID method is, in effect, a separate identity network, and cross-method interoperability requires either universal resolver implementations that support all methods or convergence on a smaller set of widely adopted methods.
In practice, the market is converging on a handful of methods that serve distinct use cases:
did:web — The Pragmatist’s Choice
did:web resolves DIDs by fetching a DID Document from a well-known URL path on a web server. The DID did:web:zuglogin.com resolves by making an HTTPS request to https://zuglogin.com/.well-known/did.json. This method requires no blockchain, no specialized infrastructure, and no new protocols — it piggybacks on the existing web infrastructure that every organization already operates.
The advantages of did:web are significant. Deployment is trivial: any organization with a web server can create a DID by publishing a JSON file. Resolution uses existing HTTP infrastructure, so performance is excellent and no specialized resolver software is needed. Organizations with established web domains can create DIDs that align with their existing online identity, making the transition from web-based trust to DID-based trust natural and incremental.
The disadvantages are equally significant. did:web inherits all the trust assumptions of the web PKI — the security of the DID depends on the security of the DNS system, the TLS certificate chain, and the web server hosting the DID Document. If an attacker compromises the web server, they can replace the DID Document and impersonate the DID subject. There is no historical record of DID Document changes, no protection against key rotation by compromised administrators, and no way for a verifier to determine whether the current DID Document is legitimate or the result of a compromise.
More fundamentally, did:web is not truly decentralized. The DID’s availability and integrity depend on a centralized web server operated by the DID controller. If the server goes offline, the DID cannot be resolved. If the domain expires, the DID becomes unresolvable and potentially hijackable by whoever acquires the expired domain. These dependencies are antithetical to the self-sovereign principles that motivated the DID specification.
Despite these limitations, did:web has emerged as the dominant method for organizational DIDs in enterprise contexts. Its pragmatism, ease of deployment, and alignment with existing web infrastructure outweigh its decentralization shortcomings for organizations that already operate web infrastructure and are comfortable with web-based trust models.
did:key — The Minimalist’s Identifier
did:key takes the opposite approach to did:web. A did:key DID is derived directly from a public key — the identifier itself encodes the key material, and the DID Document is generated deterministically from the identifier without any external resolution. No web server, no blockchain, no external infrastructure of any kind is needed. The DID is self-resolving, self-contained, and completely independent.
This makes did:key ideal for ephemeral identifiers, peer-to-peer interactions, and scenarios where the overhead of maintaining infrastructure is unwarranted. A mobile wallet can generate a did:key locally and use it to establish an authenticated channel with a verifier without any prior setup, registration, or infrastructure dependency.
The limitation of did:key is that it is static. Because the DID is derived from a key, the key cannot be rotated without changing the DID. There is no mechanism for adding service endpoints, updating verification methods, or managing the DID’s lifecycle. For long-lived identities that need key rotation — which is essential for security hygiene — did:key is insufficient.
Blockchain-Anchored Methods: did:ethr, did:ion, did:indy
Blockchain-anchored DID methods store DID Document metadata on a distributed ledger, providing a tamper-evident, historically auditable record of DID creation, updates, and deactivation. These methods offer the strongest decentralization guarantees: no single entity controls the DID’s resolution, the historical record of changes is immutable, and the DID remains resolvable as long as the underlying blockchain operates.
did:ethr anchors DIDs on Ethereum, using a smart contract registry that maps Ethereum addresses to DID Document metadata. DID Document updates are transactions on the Ethereum blockchain, providing a complete audit trail of every change. The method benefits from Ethereum’s extensive tooling ecosystem and large validator set.
did:ion uses Bitcoin as a settlement layer, anchoring DID operations in Bitcoin transactions through the Sidetree protocol. ION batches multiple DID operations into single Bitcoin transactions, achieving high throughput while inheriting Bitcoin’s unmatched security and decentralization properties.
did:indy, developed for the Hyperledger Indy ledger, is specifically designed for identity use cases and supports the AnonCreds verifiable credential format with built-in privacy features including zero-knowledge proof support and credential revocation through cryptographic accumulators.
The challenges with blockchain-anchored methods include transaction costs (particularly on Ethereum mainnet), latency (block confirmation times can introduce delays in DID updates), scalability concerns, and the environmental considerations associated with proof-of-work chains. Layer 2 solutions, alternative consensus mechanisms, and batching protocols (like Sidetree) address many of these concerns, but the fundamental trade-off between decentralization strength and operational simplicity remains.
Universal Resolution: The Interoperability Bridge
The DID method fragmentation problem has produced a pragmatic engineering response: the Universal Resolver. Originally developed by Markus Sabadello and the Decentralized Identity Foundation, the Universal Resolver is a service that accepts any DID regardless of method and returns the corresponding DID Document by dispatching the resolution request to the appropriate method-specific driver.
The Universal Resolver is architecturally analogous to a DNS resolver that supports multiple record types — it provides a single resolution interface that abstracts away the diversity of underlying methods. A verifier that integrates with a Universal Resolver can accept credentials from holders using any supported DID method without implementing method-specific resolution logic.
Several organizations operate public Universal Resolver instances, and the software is available as open-source for private deployment. The DIF Universal Resolver currently supports over 60 DID methods, covering the vast majority of DIDs in active use.
However, the Universal Resolver is a pragmatic workaround rather than an architectural solution. It introduces a service dependency (the resolver itself), does not address the trust model differences between methods (a did:web DID has fundamentally different security properties than a did:ion DID, even though both resolve through the same interface), and does not solve the governance question of which methods should be considered production-grade.
The Trust Registry Question
DID resolution tells a verifier what a DID’s cryptographic material is. It does not tell the verifier whether the DID should be trusted. A DID can be perfectly valid — properly formed, correctly resolved, cryptographically sound — and yet represent a fraudulent entity. The DID specification deliberately separates the resolution layer (infrastructure) from the trust layer (policy), but this separation creates a gap that must be filled by trust registries, trust frameworks, or verifier-side policy engines.
In the context of verifiable credentials, trust registries maintain lists of authorized issuers — DIDs that are recognized as legitimate credential issuers for specific credential types. A trust registry might specify that credentials of type “SwissMedicalLicense” are only accepted when issued by a DID appearing on the Swiss Medical Board’s issuer list. This allows verifiers to make trust decisions based on institutional authorization rather than mere cryptographic validity.
The architecture of trust registries is itself a subject of active debate. Centralized trust registries (maintained by governance bodies) are simple to implement but reintroduce the centralization that DIDs were designed to eliminate. Decentralized trust registries (maintained on distributed ledgers or through peer-to-peer governance protocols) preserve decentralization but introduce governance complexity. Federated trust registries (where multiple governance bodies maintain their own registries that interoperate through mutual recognition) offer a middle path that aligns with existing institutional structures.
The European Digital Identity Wallet framework has adopted a federated trust registry model, where each EU member state maintains a trust registry of authorized credential issuers, and mutual recognition agreements enable cross-border trust. Switzerland’s e-ID trust infrastructure follows a similar pattern, with a federal trust registry that is interoperable with the European framework.
Convergence or Continued Fragmentation?
The DID ecosystem stands at an inflection point. The specification is mature, implementations are production-ready, and regulatory frameworks are mandating verifiable credential ecosystems that depend on DID resolution. But the method proliferation problem and the trust registry fragmentation challenge remain unresolved.
The most likely trajectory is convergence around a small number of methods — perhaps three to five — that serve distinct architectural niches. did:web for organizational identifiers in enterprise contexts. A blockchain-anchored method (likely did:ion or a successor) for high-assurance, long-lived identifiers requiring maximum decentralization. did:key for ephemeral and peer-to-peer identifiers. And potentially a new method — perhaps did:tdw (Trust DID Web), which adds verifiable history and pre-rotation to did:web’s pragmatic foundation — that bridges the gap between web convenience and blockchain security.
The organizations and communities that drive this convergence — through standards work, regulatory adoption, and ecosystem investment — will shape the identity infrastructure of the next generation of the internet. The DID specification created the possibility of a universal, decentralized identity layer. The hard work of making that possibility real is now a matter of engineering, governance, and institutional will.