did:web

Identity Protocol

A DID method that resolves an identifier to a DID document hosted at a conventional HTTPS URL: did:web:example.com maps to https://example.com/.well-known/did.json. It requires no ledger, no new infrastructure and no cryptographic novelty — an organization that already controls a domain can publish a DID in minutes. That simplicity has made it the most widely deployed method by a wide margin; Microsoft migrated Entra Verified ID from did:ion to did:web and made it the only available trust system. The cost is that its trust anchor is DNS and the certificate authority system, so the identifier is only as sovereign as the domain registration behind it.

Community

Details

License Open specification (W3C CCG / DIF document licence); implemented in every significant DID resolver library under permissive licences
Dev Status 🟢 Active
Owner W3C Credentials Community Group / DIF — specification contacts listed in the W3C registry are Oliver Terbu, Mike Xu, Dmitri Zagidulin and Amy Guy
Governing Body W3C Community Group (Credentials Community Group) | DIF
Country International (W3C CCG and DIF participation; contributors across the USA, Europe and the UK)
Start Year 2019
Stack Language-agnostic specification; resolution is an HTTPS GET plus a path transformation, implementable in any language in a few lines
Funding N/A — no infrastructure or funding required beyond ordinary web hosting
Last Investigated Jul 1, 2026

Identity Protocol Attributes

Origins Self-sovereign identity / enterprise adoption — created to remove the infrastructure barrier to DID adoption by reusing the web PKI and DNS that organizations already operate
Database N/A — the DID document is a static JSON file served over HTTPS; storage is whatever the controller's web host provides
Query Language HTTPS GET — resolution is a deterministic transformation of the DID into a URL, followed by an ordinary web request
Data Formats W3C DID Document as JSON or JSON-LD, served at /.well-known/did.json or at a path derived from the DID's optional path components
Mobile Support Library-level — implemented inside resolver libraries and wallets; no standalone application
Web Support Yes — HTTPS is the entire resolution mechanism; the DID document is an ordinary web resource
Native Apps Library-level — embedded in resolver libraries; no standalone application
Terms Free at the specification level; real cost is domain registration and hosting, which the controller already bears
Funds N/A
Based On W3C DID Core 1.0; DNS; HTTPS and the web PKI (certificate authority trust); RFC 8615 well-known URIs
Permissions Web server access control — whoever can write to the hosting path controls the identifier
Authentication & Identity Domain-anchored — control of the identifier is control of the domain and its web server. There is no cryptographic binding between the identifier and any key; the keys are simply what the document at that URL says they are
Storage Model Web-hosted — a static JSON document on the controller's own server or CDN. No replication, no history, no verifiable log of changes
Interoperability Universal within the W3C DID ecosystem; the default assumption in most enterprise deployments. did:webvh (in this file) is backwards-compatible with did:web and can be resolved in legacy mode by dropping the SCID segment
Data Portability Poor — the domain is part of the identifier, so the DID cannot be moved to a different host without becoming a different DID. This is the specific limitation did:webvh and did:scid were designed to address
Governance & Decision Making W3C Credentials Community Group and DIF — open participation and public repository for the specification; each DID document is governed solely by whoever controls the domain
Protocol Maturity / Standardization Registered W3C DID method with the widest production deployment of any method, though the specification remains a community draft rather than a W3C Recommendation. Maturity here is adoption-driven
Identity Standards W3C DID Core 1.0; registered in the W3C DID Extensions methods registry
DID Methods Supported did:web (defines this method). did:webvh is a backwards-compatible extension that adds verifiable history and self-certification
Key Management Controller-managed with no verifiable history — keys can be changed at any time by editing the hosted document, but there is no signed log, so a relying party cannot distinguish a legitimate rotation from a compromise or a substitution by whoever controls the host
Credential Types N/A — a DID method specification; defines no credential types. Compatible with W3C Verifiable Credentials issued against identifiers of this method
Verification Method Whatever the retrieved document asserts — trust is transitive through HTTPS and the CA system rather than being cryptographically self-certifying. There is no proof that the document was authored by any particular key
Privacy Features Minimal — did:web identifiers are public by construction, human-readable, and tied to an organizational domain, making them inherently correlatable. Unsuitable for pairwise or pseudonymous use
Authentication Methods Cryptographic signature against keys listed in the hosted DID document
Revocation Mechanism Document edit or removal — the controller deletes or updates the hosted file. There is no cryptographic revocation record and no history, so past states cannot be verified
Agent Types Supported Any key-controlling entity — individuals, organizations, services and devices
Wallet/Client Types SDK / library integration — resolver implementations across the SSI tooling ecosystem; no method-specific wallet
Recovery Mechanisms Domain control — recovery means regaining control of the domain and the web server; there is no key-based recovery path
Compliance / Regulations Widely used in regulated enterprise deployments precisely because it maps onto existing organizational domain governance and audit practice. The specification itself addresses no regulation directly
Credential Exchange Protocols Compatible with DIDComm, OpenID4VC and any W3C DID-resolving protocol; the dominant issuer method in enterprise credential deployments
Trust Framework Web PKI — trust derives from DNS registration and certificate authorities, both of which are hierarchical and centrally administered. This is the method's defining structural property
Cost Model Domain registration plus hosting — recurring, and dependent on continued payment and registrar relationship. Lapse of the registration destroys the identifier
Censorship Resistance Low — the weakest on this tab. A registrar, certificate authority, hosting provider, court or state can each independently make the identifier unresolvable, and no fallback exists because the domain is embedded in the DID itself