did:web
Identity Protocol
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
Owner - List
- Decentralized Identity Foundation
- World Wide Web Consortium
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 31, 2026
Identity Protocol Attributes
Owner - List
- Decentralized Identity Foundation
- World Wide Web Consortium
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
Identity Standards - List
DID Methods Supported did:web (defines this method). did:webvh is a backwards-compatible extension that adds verifiable history and self-certification
DID Methods Supported - List
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
Credential Types - List
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
Credential Exchange Protocols - List
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
Relationships
How this tool connects to other tools and organizations, from relationships reviewed by the OpenHaven data steward. They describe how projects connect, not how good they are.