Engineering · 2026-04-15
DID Method Proliferation: did:web and Enterprise Adoption
By J. W. Bouckaert
Many methods, one data model
The W3C DID Core 1.0 specification became a Recommendation on 19 July 2022. It defines what a Decentralized Identifier (DID) is and what a DID document contains, and leaves creation, resolution and key management to separate DID methods.
Anyone can define a method. The W3C DID Methods registry, a Group Note last published on 1 October 2026, now lists more than 270 of them. An enterprise that wants to issue or verify credentials has to choose among them, and in practice most enterprise deployments use a small set. This article compares four common methods, explains why did:web is the usual choice for organizations, and describes how PasskeyBridge uses it.
Four common methods
| Method | How it resolves | Infrastructure | Key rotation | Discoverable | Typical use |
|---|---|---|---|---|---|
| did:web | HTTPS request to the domain | Web server or CDN | Yes | Yes, through DNS | Organizational identity |
| did:ion | Sidetree operations anchored in Bitcoin | Bitcoin, Sidetree and IPFS nodes | Yes | Yes | Ledger-anchored identifiers |
| did:key | Computed from the identifier | None | No | No | Short-lived or offline use |
| did:peer | Exchanged between the two parties | None | Yes | No | Pairwise relationships |
Reasons organizations choose did:web
It uses DNS and HTTPS
A did:web identifier maps to a URL on the organization's own domain:
did:web:example.com → https://example.com/.well-known/did.json
did:web:example.com:department:engineering → https://example.com/department/engineering/did.jsonPublishing a DID document means serving a JSON file over HTTPS. The domain, certificates and web servers are ones the organization already runs, and the people who manage them do not need new skills.
did:ion, by contrast, needs Bitcoin Core, Sidetree and IPFS infrastructure, run by the organization or by a resolver it trusts.
Resolution is an HTTP request
Resolving did:web is a single HTTPS GET that can be cached at a CDN with standard Cache-Control headers. Resolving did:ion means processing Sidetree operations from the ledger and fetching content from IPFS, usually through a hosted resolver. did:key and did:peer need no network request at all.
Microsoft moved Entra Verified ID to did:web
Microsoft's Entra Verified ID originally used did:ion, the Bitcoin-anchored method Microsoft helped build. It later added did:web, and in December 2023 Microsoft removed did:ion as a choice for the service's trust system, leaving did:web.
Keys and transport are separate
A did:web document is served over HTTPS, so the TLS certificate protects the transport, and Certificate Transparency logs show which certificates were issued for the domain. The verification keys in the document are separate keys used to sign credentials. Rotating a credential key means publishing a new document.
With did:ion, key changes are Sidetree operations, and recovery depends on recovery keys committed in advance, which the organization manages outside its web infrastructure.
Trade-offs of did:web
DNS and hosting are the trust root
Whoever controls the domain's DNS or the web server can publish a different DID document. The risk is the same one that applies to every other service on the domain, and the same controls reduce it:
- DNSSEC to authenticate DNS answers.
- Certificate Transparency monitoring to detect certificates issued without authorization.
- Change control on the server and path that serve the DID document.
Two newer methods address this. did:webs, from the Trust Over IP Foundation, adds self-certifying identifiers and a verifiable key event history while still resolving over the web. did:webvh, from the Decentralized Identity Foundation, adds a verifiable history of DID document versions.
A domain can be taken away
A registrar can suspend a domain, a host can remove a server, and a government can order DNS blocking. For most regulated organizations this is acceptable, because they want identifiers that are tied to a known legal entity and can be revoked. For groups that need identifiers no single party can remove, a ledger-based method fits better.
Uses for the other methods
did:key
A did:key identifier encodes the public key itself, such as did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK, so it resolves without a network request. It suits test credentials, short-lived sessions and offline checks. The key cannot be rotated: if it is compromised, the identifier has to be abandoned.
did:peer
did:peer identifiers are exchanged directly between two parties and never published. They are used with DIDComm messaging and other pairwise relationships where neither party wants the relationship to be discoverable. They cannot serve as a public organizational identity.
PasskeyBridge's did:web setup
Platform DID
The platform DID did:web:passkeybridge.io resolves to https://passkeybridge.io/.well-known/did.json. The document lists PasskeyBridge's verification methods, including the ML-DSA-65 public key that verifies the signatures on audit-log checkpoints, and service endpoints for credential issuance, verification and status.
Tenant DIDs
Each tenant has a DID under the platform namespace:
did:web:passkeybridge.io:tenants:acme-corp
→ https://passkeybridge.io/tenants/acme-corp/did.jsonA tenant's document lists its active signing key, once one is provisioned, and its ML-DSA public key, so a relying party can verify the post-quantum signature on a credential the tenant issued without any PasskeyBridge secret. Tenants with verifiable credentials enabled also get issuance, verification and status service endpoints.
Resolver
PasskeyBridge's public resolver endpoint returns tenant documents, the platform document and did:key documents, with the application/did+json content type and a five-minute cache lifetime. It resolves did:web only for passkeybridge.io, to prevent it from being used to fetch arbitrary URLs. Other did:web identifiers should go to a general-purpose resolver.
Standards status
- DID Core 1.0 has been a W3C Recommendation since July 2022. DID 1.1 reached Candidate Recommendation Snapshot on 5 March 2026.
- The DID Resolution specification is a W3C Candidate Recommendation Draft, last published on 1 October 2026.
- The did:web method specification is a W3C Credentials Community Group document, not a W3C Recommendation. The DID Methods Working Group at the Decentralized Identity Foundation works on method standardization.
Choosing a method
- did:web for an organization's public identity, when the organization controls a domain.
- did:webs or did:webvh when you want did:web's hosting model with a verifiable history.
- did:key for short-lived or offline use where rotation is not needed.
- did:peer for private pairwise relationships.
- did:ion or another ledger-based method when no single party should be able to remove the identifier.
Read the verifiable credentials article or create an account.