did:webplus was designed from the concrete requirements of a regulated messaging community, then generalized. That origin is the best evidence of what it can carry.

When LedgerDomain began building identity infrastructure for the US pharmaceutical supply chain, the environment was unusual by decentralized identity standards. Hundreds of thousands of independent, publicly registered organizations exchange billions of sensitive, confidential, and regulated messages each year, under direct government oversight. Any one of those messages can become evidence in a regulatory investigation, sometimes many years after the original transaction.

The messaging problem set the identity requirements. Trading partners needed to communicate confidentially and at scale without leaking network metadata or trade terms, while preserving cryptographic proof that every interaction was legitimately authorized at the time it occurred. That proof had to survive vendor changes, employee churn, key and pseudonym rotation, infrastructure migrations, and companies exiting the ecosystem altogether.

The ecosystem adopted did:web early: web-native, easy to deploy, aligned with existing organizational boundaries. As the system matured toward production, the gap became clear. Resolving a DID to its current state was insufficient; verifiers had to determine which keys and policies were valid at a specific moment in time, and did:web’s optional, trustful historical resolution could not support long-term auditability and non-repudiation.

Rather than change deployment models or governance assumptions, did:webplus extended the did:web model directly: an append-only microledger per DID, explicit update rules, and incremental retrieval over plain HTTPS. The DID method and the messaging substrate evolved together, each reinforcing the other’s guarantees of durability, non-repudiation, and auditability at scale.

did:webplus is now being prepared for production use within the Open Credentialing Initiative (OCI) ecosystem. Adopters already operate did:web-based systems and extend them with verifiable history without redesigning workflows or architectures; that continuity is deliberate. The broader context shaped the design too: messaging standards stewarded by GS1, identity assurance processes aligned with NIST guidelines, and participation governed through a public-private partnership with the FDA. did:webplus encodes those realities on boring, compliant web rails rather than attempting to replace them.

Read the full member post at the Decentralized Identity Foundation: Case Study: Designing for a Regulated Messaging Community.

did:webplus is one of two DID methods DIF recommended in June 2026, and that recommendation is non-exclusive. Here is how it lines up against plain did:web, its sibling did:webvh, and ledger-anchored methods, so you can judge the fit for your own stack.

vs did:web

Everything did:web offers carries over: the hosting model, the URL mapping, the operational simplicity. did:webplus adds verifiable history, explicit update authorization, fork detection, and non-repudiation. Existing did:web deployments can adopt incrementally, which is precisely the OCI migration story. If you never need to prove past key states, did:web remains a fine choice.

vs did:webvh

Both methods extend did:web with a hash-linked, verifiable history, and both passed the DIF Recommended process in June 2026. Genuine differences in emphasis:

Update authorization: did:webplus updateRules compose any/all combinators and weighted thresholds (m-of-n with per-key weights, hidden pre-rotation keys) evaluated by every verifier. Gateway architecture: the Verifiable Data Gateway is a first-class, specified component with a defined HTTP API, giving Thin resolvers, constant-time resolution, and an explicit scope-of-agreement model for fork detection. Retrieval: one JSONL file per DID with HTTP range requests makes incremental sync a plain web primitive, CDN and static-host friendly. Signature pinning: fully qualified key identifiers commit each signature to the exact DID document version current at signing.

did:webvh has its own strengths, including specified DID portability between domains and its /whois convention. Read both specs; the methods are similar enough that ecosystem fit and tooling maturity in your stack may decide it.

vs ledger-anchored methods

Ledger-anchored methods obtain history integrity from a blockchain; did:webplus obtains it from self-hashed chains plus witnessing, with equivalent practical assurances for this class of use case. What you give up: a single global consensus. What you gain: no live blockchain dependency in the resolution path, no token economics, no SaaS intermediary, and hosting plus governance models that regulated industries have already accepted.