Engineering · 2026-04-15

DID Method Proliferation: did:web and Enterprise Adoption

By J. W. Bouckaert

The proliferation problem

The W3C DID Core 1.0 specification, ratified as a Recommendation in July 2022, was deliberately method-agnostic. It defined the data model—what a Decentralized Identifier is and what a DID Document contains—but left the mechanics of creation, resolution, and key management to individual DID methods.

This design choice was philosophically sound and practically catastrophic.

By mid-2026, the W3C DID Extensions Methods registry catalogs more than 200 known DID methods (225 in the companion catalogue as of the latest Group Note). Two hundred different ways to create an identifier. Two hundred different resolution protocols. Two hundred different trust models, infrastructure requirements, and operational characteristics.

For enterprises evaluating decentralized identity, this proliferation was a barrier.

The DID specification gave us a universal data model and 200 incompatible ways to use it. Enterprise procurement teams do not evaluate 200 options. They evaluate three, pick one, and move on.

The four methods that mattered

Despite the registry's sprawl, enterprise adoption consolidated around four DID methods by mid-2025. Each represents a distinct architectural philosophy:

Each method optimizes for a different point on the decentralization-operability spectrum. The market's verdict is now clear: enterprises chose operability.

Reasons did:web won

1. DNS is the enterprise's existing trust anchor

Every enterprise already operates DNS infrastructure. They have domain registrars, DNSSEC policies, certificate authorities, and operations teams that understand zone files. did:web maps a DID directly to a domain name:

did:web:example.com → https://example.com/.well-known/did.json
did:web:example.com:department:engineering → https://example.com/department/engineering/did.json

This is the existing web PKI trust model, not a new one—the same model that secures every TLS connection, every SAML assertion, and every OAuth token exchange in the enterprise today. IT teams do not need to learn new infrastructure. They need to serve a JSON file.

Compare this to did:ion, which requires operating Bitcoin Core full nodes, Sidetree processing nodes, and IPFS content storage. For a Fortune 500 CISO, the conversation with the infrastructure team is the difference between "add a JSON file to our CDN" and "we need to run Bitcoin nodes in production."

The first conversation takes a day. The second never gets past procurement.

2. Resolution latency matches enterprise SLAs

did:web resolution is an HTTPS GET request. On a CDN-backed domain, resolution completes in tens of milliseconds from most global points of presence. With proper Cache-Control headers, repeat resolutions hit edge cache and return in single-digit milliseconds.

did:ion resolution requires querying the Bitcoin blockchain, processing Sidetree operations, and resolving IPFS content. Even with optimized resolvers like Microsoft's ION resolver, resolution latency is measured in seconds—acceptable for background verification, but incompatible with real-time authentication flows where an in-request verdict is the expectation.

For identity verification pipelines that process thousands of credential presentations per second, the difference between 50ms and 5,000ms is the difference between a viable architecture and a bottleneck.

3. Microsoft's migration set the market direction

When Microsoft launched Entra Verified ID, it initially anchored on did:ion—its own Bitcoin-based DID method. The technical ambition was significant: an enterprise identity layer backed by the most resilient public ledger on the planet.

The operational reality was different. Running ION infrastructure at enterprise scale required specialized DevOps expertise that most organizations did not have. Resolution latency complicated real-time verification flows. And the Bitcoin association created boardroom anxiety in regulated industries where cryptocurrency-adjacent technology faced heightened scrutiny.

Microsoft's subsequent addition of did:web support in Entra Verified ID was the inflection point. When the largest enterprise identity provider in the world offered a simpler, faster, DNS-based alternative to its own blockchain method, the market signal was unambiguous: operational simplicity wins.

4. It reuses the Web PKI you already run

did:web DID Documents are served over HTTPS, which means they are protected by the same TLS certificates that protect every other enterprise endpoint. Certificate lifecycle management, revocation checking, and transparency logging all apply automatically.

This is a significant operational advantage. Enterprises do not need to build a parallel key management infrastructure for their DIDs. The domain's TLS certificate, managed by their existing certificate authority and monitored through Certificate Transparency logs, provides the transport-layer security. The DID Document's verification methods provide the identity-layer cryptography. Both layers use standards the enterprise already operates.

Compare this to did:ion, where key management happens entirely outside the web PKI. Keys are anchored to blockchain transactions. Rotation requires publishing new Sidetree operations. Recovery requires pre-committed recovery keys that must be stored and managed independently. This is a second key management system layered on top of the first—exactly the kind of operational duplication that enterprise architects are trained to eliminate.

The trade-offs enterprise accepted

did:web's victory was not without compromise. The enterprise market made a deliberate trade: it accepted did:web's known limitations in exchange for operational simplicity.

DNS dependency

did:web's most cited weakness is its dependency on DNS. If an attacker compromises a domain's DNS records or the web server hosting the DID Document, they can serve a fraudulent document. This is a real risk, and an old one: the same risk that applies to every TLS-protected service on the domain.

Enterprises mitigate this with layers they already operate:

• DNSSEC—Cryptographic validation of DNS responses prevents cache poisoning and spoofing
• Certificate Transparency—Public logging of all certificates issued for a domain detects unauthorized issuance within hours
• Web Application Firewalls—Rate limiting and access control on the DID Document endpoint prevent bulk enumeration
• DID Document versioning—Cryptographic hashes of previous document versions enable tamper detection

The did:webs specification, proposed by the Trust Over IP Foundation, adds a self-certifying identifier layer on top of did:web that provides cryptographic proof of document integrity independent of DNS. For organizations that need belt-and-suspenders assurance, did:webs offers a migration path without abandoning the DNS-based resolution model.

No censorship resistance

did:web identifiers can be censored. A domain registrar can seize a domain. A hosting provider can take down a server. A government can order DNS blocking. For organizations operating in adversarial jurisdictions, this is a meaningful limitation.

But for the Fortune 5000 operating in regulated markets with established legal frameworks, censorship resistance is not a procurement criterion. These organizations want their identifiers to be discoverable, auditable, and revocable—properties that align with regulatory expectations.

Centralized trust root

did:web's trust model ultimately roots in the DNS registrar and the certificate authority. This is a centralized trust model decorated with decentralized identifiers. Purists object. Pragmatists ship.

The philosophical argument for blockchain-anchored identifiers—that no single entity should control an identifier's lifecycle—is compelling in theory. In practice, enterprises already trust centralized authorities for their most critical identity infrastructure. Active Directory trusts Microsoft. SAML federations trust certificate authorities. OAuth flows trust authorization servers. Adding did:web does not introduce a new trust assumption. It operates within the trust relationships the enterprise already has.

The other methods

did:web's enterprise dominance does not make other methods irrelevant. Each occupies a distinct architectural niche.

did:key: The ephemeral workhorse

did:key encodes a public key directly in the identifier. did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK is both a DID and a public key—no resolution required. This makes did:key ideal for scenarios where infrastructure is unavailable or unnecessary:

• Agent-to-agent handshakes—When two AI agents need to establish a temporary authenticated channel, did:key provides instant, zero-infrastructure identity. PasskeyBridge uses did:key in its A2A trust negotiation protocol for the initial handshake before upgrading to persistent did:web-backed identities.
• Offline verification—Cached proofs that must be verifiable without network access embed did:key identifiers that can be resolved locally.
• Test and development—Developers generating test credentials do not need a domain and a web server. did:key works immediately.

The limitation is permanent: did:key identifiers cannot be updated. There is no mechanism for key rotation. If the key is compromised, the DID is dead. For ephemeral use cases, this is acceptable. For organizational identity, it is not.

did:peer: The private channel

did:peer identifiers are exchanged directly between two parties and are never published to any shared infrastructure. This makes them invisible to third parties—ideal for privacy-preserving bilateral relationships.

Enterprise use cases include:

• Confidential supplier verification—Two organizations verify each other's credentials without publishing the relationship
• DIDComm messaging—End-to-end encrypted organizational communication channels backed by pairwise DIDs
• Regulated data exchange—HIPAA-covered entities sharing protected health information through channels that cannot be enumerated by third parties

did:peer's strength—invisibility—is also its limitation. These identifiers are not discoverable. They cannot be used for public-facing organizational identity. They serve a fundamentally different purpose than did:web.

The PasskeyBridge did:web implementation

PasskeyBridge's DID resolution infrastructure uses did:web as its primary method for organizational identity, with did:key for ephemeral agent interactions.

Platform-level DID document

The platform DID did:web:passkeybridge.io resolves to a DID Document that anchors the entire credential issuance infrastructure:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:web:passkeybridge.io",
  "verificationMethod": [{
    "id": "did:web:passkeybridge.io#key-1",
    "type": "JsonWebKey2020",
    "controller": "did:web:passkeybridge.io",
    "publicKeyJwk": { "kty": "OKP", "crv": "Ed25519", "use": "sig" }
  }],
  "authentication": ["did:web:passkeybridge.io#key-1"],
  "assertionMethod": ["did:web:passkeybridge.io#key-1"],
  "service": [
    { "id": "did:web:passkeybridge.io#vc-issue", "type": "CredentialIssuer" },
    { "id": "did:web:passkeybridge.io#vc-verify", "type": "CredentialVerifier" }
  ]
}

Per-tenant DID documents

Each tenant receives a scoped DID under the platform namespace:

did:web:passkeybridge.io:tenants:acme-corp
→ https://passkeybridge.io/tenants/acme-corp/did.json

Tenant DID Documents include the tenant's own verification methods (if they have provisioned per-tenant keys) and conditional service endpoints based on their subscription tier. Tenants with Verifiable Credentials enabled receive CredentialIssuer and CredentialVerifier service entries. Tenants on the Starter plan receive a minimal document sufficient for identity verification.

Resolution architecture

PasskeyBridge's DID resolution endpoint supports three resolution paths:

1. Tenant resolution—GET /shield-did-resolve/{slug} returns the tenant's DID Document with application/did+json content type and 5-minute cache headers
2. Generic did:key resolution—GET /shield-did-resolve?did=did:key:z6M... resolves any did:key identifier to its DID Document envelope per the DID Resolution specification
3. Platform resolution—GET /shield-did-resolve/.well-known returns the platform-level DID Document

All responses conform to the DID Resolution Result envelope format. did:web resolution for external domains is restricted to the passkeybridge.io apex to prevent open redirect vulnerabilities.

The did:web maturity curve

The W3C published a Candidate Recommendation Snapshot of DID Core v1.1 in early 2026, signaling continued standards evolution. The DID Resolution specification reached Working Draft status in January 2026, formalizing the resolution algorithms that implementations like PasskeyBridge already follow.

The did:web method specification itself remains a W3C Community Group document—not a full W3C Recommendation. This is a legitimate governance concern that the DID Methods Working Group at the Decentralized Identity Foundation is working to address. The practical reality is that did:web's adoption has outpaced its standardization, creating a de facto standard that the standards body is now catching up to formalize.

For enterprises making DID method decisions today, the calculus is straightforward:

• did:web for persistent organizational identity—discoverable, rotatable, CDN-cacheable, manageable by existing IT teams
• did:key for ephemeral interactions—zero infrastructure, instant resolution, acceptable key-compromise trade-off for short-lived use
• did:peer for private bilateral channels—invisible to third parties, ideal for confidential relationships
• did:ion for immutability-critical anchoring—blockchain-backed permanence when regulatory or contractual requirements demand it

The market has spoken. did:web won because it met enterprises where they already were: on the web, with DNS, behind TLS, managed by IT teams who already know how to serve a JSON file over HTTPS.

The question was never which DID method is most decentralized. The question was which DID method ships.

Explore PasskeyBridge's DID resolution → | Read the Verifiable Credentials deep-dive → | Get started free →

Start free · Test the API