did:web
did:web is a DID method that resolves a DID document from a well-known HTTPS location on a domain its owner controls, so it can be published and updated using ordinary web infrastructure without a blockchain or distributed ledger.
A did:web identifier such as did:web:example.com maps directly to a URL like https://example.com/.well-known/did.json, so any standard HTTPS client can fetch the DID document without running specialised resolver software. Extra colon-separated segments become path segments, so did:web:example.com:issuer:eu resolves to https://example.com/issuer/eu/did.json instead.
The document at that URL is what gives the identifier its meaning. It lists the public keys that may sign on behalf of the subject, says which of them may authenticate or assert claims, and names any service endpoints the subject publishes. Rotating a key is an edit to that one file.
Trust in the DID depends entirely on control of the domain and its TLS certificate, so an expired registration, a hijacked name server or a mis-issued certificate is enough to speak in the owner's name. There is no second signature underneath to fall back on.
The DID document also only reflects its current state: nothing in the method itself records or proves what the document looked like before the most recent edit, which is the gap did:webvh closes by adding a signed, append-only history on top of the same web hosting.
Read the full explanation
This page gives the short definition. Our explainer shows what it means in practice: who is involved, how it works and what changes for your organisation.
did:web explainedRelated terms
How is a did:web DID resolved?
The DID method identifier and domain map directly to an HTTPS URL under that domain, typically /.well-known/did.json, and fetching that URL returns the DID document. No blockchain, ledger, or specialised network is involved, only ordinary web hosting and TLS.