DID Web Method

The DID Web Method is a Decentralized Identifier (DID) specification that uses a domain name as the foundation for a cryptographically verifiable digital identity. Defined by the W3C, its DID syntax is did:web:<domain-name>, where the domain acts as the persistent identifier's root. The associated DID Document—containing public keys and service endpoints—is hosted at a well-known location under that domain, typically /.well-known/did.json. This method leverages the existing Domain Name System (DNS) and HTTPS infrastructure for discovery and resolution, making it one of the most straightforward and immediately deployable DID methods.

A key advantage of the DID Web method is its simplicity and low barrier to entry for developers and organizations. Unlike blockchain-based methods, it does not require transaction fees or specialized node software. The entity controlling the domain (e.g., a company, developer, or individual) has full custodianship over the DID and its document, allowing for direct management and rapid updates. This makes it ideal for prototyping, enterprise use cases, and scenarios where a trusted domain authority is acceptable. However, this reliance on traditional web trust models means its decentralization is contingent on the security and availability of the domain and web server.

The technical resolution process is defined by the W3C DID Specification. A resolver converts the did:web:example.com identifier into an HTTPS GET request to https://example.com/.well-known/did.json. The returned JSON-LD document must conform to the DID Core data model. For more specific paths, like did:web:example.com:user:alice, the resolver would fetch https://example.com/user/alice/did.json. This predictable, HTTP-based lookup enables interoperability across any system that implements the standard DID Web resolution algorithm.

Common use cases for DID Web include securing communications with Verifiable Credentials, establishing trust in API authentication (e.g., using DID as an OAuth client ID), and creating self-sovereign identities for websites and services. It serves as an excellent entry point for understanding decentralized identity principles before exploring more complex, fully decentralized ledgers. Its design prioritizes practical deployment, allowing organizations to issue, hold, and verify credentials without initially integrating with a blockchain, though it can be used in conjunction with other methods for enhanced trust models.

When implementing DID Web, critical security considerations include maintaining the integrity and availability of the hosted DID Document, using HTTPS to prevent man-in-the-middle attacks, and properly managing the private keys corresponding to the public keys listed in the document. Best practices also involve implementing proper HTTP caching headers and considering the use of DID Configuration with serviceEndpoint entries like linkedDomains to cryptographically link the DID to the domain, further strengthening the trust assertion.

The DID Web Method, defined by the W3C, is a mechanism for creating Decentralized Identifiers (DIDs) where the identifier itself is a URL based on a domain name you control. A DID Web identifier takes the form did:web:example.com. This method leverages the existing Domain Name System (DNS) and HTTPS infrastructure to provide a simple, low-barrier entry point for decentralized identity. The controlling entity—be it an individual, organization, or service—publishes the corresponding DID Document at a well-known location under that domain, typically https://example.com/.well-known/did.json. This document contains the public keys, service endpoints, and other verification methods necessary to prove control of the DID.

The resolution process is straightforward and does not require a blockchain or a specialized decentralized registry. When a verifier needs to look up did:web:example.com, they perform an HTTPS GET request to the predictable URL. The returned DID Document is cryptographically signed, allowing the verifier to authenticate its origin and integrity. This design makes the Web Method highly practical for enterprise applications, self-sovereign identity wallets, and verifiable credentials ecosystems where participants already manage web domains. Its reliance on TLS/HTTPS also provides a foundational layer of security and authenticity for the document retrieval process.

A key advantage of the DID Web Method is its simplicity and deployability. Since it uses standard web protocols, it avoids the complexity of running a node on a blockchain or peer-to-peer network. However, this convenience comes with trade-offs. Control of the DID is contingent on control of the domain name and web server, making it dependent on traditional centralized authorities (domain registrars and hosting providers). For high-assurance, censorship-resistant identities, methods like did:ethr or did:ion may be more appropriate. The DID Web Method is thus ideal for organizational identities, API authentication, and scenarios where existing web trust models are sufficient.

The DID Web method is a Decentralized Identifier (DID) specification defined by the W3C that creates a DID from a domain name, using the familiar did:web method identifier. This method enables individuals and organizations to host their own DID documents on a web server they control, making it one of the most straightforward methods to implement without requiring a new blockchain or specialized registry. The DID itself is derived directly from the host component of a URL, such as did:web:example.com. Its resolution involves performing an HTTPS GET request to a well-known endpoint on that domain to retrieve the corresponding DID Document.

The syntax for a DID Web identifier follows a predictable pattern: did:web:<host>[:<path>]. The <host> is a fully qualified domain name, optionally followed by a <path> component for organizational purposes, like did:web:example.com:user:alice. This path structure allows a single domain to manage multiple DIDs. The corresponding DID Document is fetched by converting this DID into a URL: the did:web: prefix is replaced with https://, colons (:) are replaced with forward slashes (/), and the path /.well-known/did.json is appended. For example, did:web:example.com resolves to https://example.com/.well-known/did.json.

Resolution of a did:web identifier is an HTTPS-based process where a DID resolver performs a TLS-secured HTTP GET request to the constructed URL. The server must respond with the DID Document as a JSON-LD document with the correct application/did+ld+json content type. This document contains the public keys, service endpoints, and verification methods associated with the DID. A key advantage of this method is its simplicity and reliance on established web security models, including TLS certificates for server authentication. However, it also inherits the web's centralized trust model, as control of the DID is contingent upon control of the domain name and web server.

For key rotation and updates, the DID Web method relies on the entity controlling the web server to publish a new DID Document at the same URL. This is a simple file update but requires careful management to ensure continuity and prevent service disruption. Unlike blockchain-anchored methods, there is no immutable audit trail of changes, so implementers often pair the DID Document with cryptographic proofs, like signed verifiable credentials, to establish a history. The method is particularly suited for enterprise, academic, and institutional use cases where the organization already maintains a trusted web domain and wants to issue verifiable credentials to employees or members without deploying new infrastructure.

While powerful for prototyping and controlled environments, the DID Web method has distinct considerations. Its decentralization is relative, as it depends on the centralized Domain Name System (DNS) and certificate authorities. Security is tied to the security of the hosting web server and the strength of its TLS configuration. The W3C specification mandates the use of HTTPS to ensure communication integrity and recommends the publication of DID Documents with appropriate HTTP cache-control headers. For production systems requiring higher assurance of availability and censorship resistance, it is often used in conjunction with other, more persistent DID methods or through did:web-to-did:peer bridging techniques.