did:webvh

How did:webvh works

did:webvh is a web-based DID method that uses verifiable history to let resolvers check how a DID document changed over time, rather than trusting only the latest file. That makes document updates, key rotation, and deactivation auditable, which is the core difference from a simple static web document.

Because the method is published over the web, it still depends on standard web hosting and retrieval, but the trust model is stronger than ordinary hosting. A resolver is not just fetching content, it is validating whether the document history is internally consistent and whether the current state matches the recorded sequence of updates.

Why verifiable history matters for DID trust

Verifiable history is what lets a DID method answer questions such as “was this document changed in an expected way?” and “can this key update be justified by the published record?” That matters when the DID is used as a root of trust for credentials, authentication, or other verifier decisions, because the integrity of the history becomes part of the security boundary.

This also changes how disputes are handled. If a controller loses access to a publishing key, or if an update is questioned, the history can show whether the change followed the method rules. In practice, that helps reduce ambiguity around ownership transitions and key replacement.

For a broader DID grounding, see Decentralised identifiers (DIDs), which explains DID documents, resolution and controller key rotation in more depth.

Security properties and common failure modes

The security value of did:webvh comes from making update history tamper-evident, but it still inherits risk from the web layer, the publishing process, and the keys that control updates. If an attacker can replace hosted content, abuse a publishing key, or create confusion about which version is current, the resolver may be led to trust the wrong state unless the verifiable history is validated correctly.

Operationally, the method is only as strong as the integrity of the records that support it. Weak key management, stale documents, broken resolver logic, or inconsistent hosting paths can all undermine trust even when the DID syntax itself is valid.

For the wider identity-wallet and verifiable-credential context that often surrounds DID deployment, the Digital Identity, eID and Identity Wallets Guide is the most direct companion resource.

Where did:webvh fits in practice

did:webvh is useful when an organisation wants a DID that remains web-friendly while still supporting auditability and reproducible resolution. It is a good fit for environments that want to publish identifiers using familiar web infrastructure, but also need a stronger story for history, key updates, and verifier confidence than a plain hosted document can provide.

It is less about replacing all other DID methods and more about giving practitioners a publishable, auditable option for cases where change history matters. That makes it especially relevant when a DID is expected to survive key changes, controller changes, or long-lived verification relationships.

Practitioner Guidance

What to watch for: Treat did:webvh as an identity publishing method, not just a file format. The practical question is whether your team can protect the update keys, preserve a complete history, and operate resolution consistently across all relying parties.

Governance implication: The method only delivers its trust benefits when someone owns the lifecycle of the DID, the hosting process, and the key update process together. If those responsibilities are split across teams without clear control, the history can become formally verifiable but operationally unreliable.