Member post from Ledger Domain, by Alex Coogan and Victor Dods
When LedgerDomain began building identity infrastructure for the U.S. pharmaceutical supply chain, we understood immediately that this was an atypical decentralized identity environment. Hundreds of thousands of independent, publicly-registered organizations exchange billions of sensitive, confidential and regulated messages each year, under direct and ongoing government oversight. Any one of those messages can later become evidence in a regulatory investigation, sometimes many years after the original transaction took place.
Our primary challenge was messaging: enabling trading partners 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 needed to remain verifiable even as companies changed vendors, churned employees, rotated keys and pseudonyms, migrated infrastructure, or exited the ecosystem altogether. We decided early to take an approach that paired cryptographic verifiability with standard web technologies in order to achieve a balance of security, scale, and performance. Additionally, we needed to achieve a measure of security parity with DID methods on a stronger cryptographic basis than did:web also in use within the messaging community.
Starting from Messaging Requirements
This messaging system had to support high-volume, point-to-point communication without broadcasting metadata or relying on centralized intermediaries. Participants needed strong assurances about counterparties, and regulators needed the ability to reconstruct chains of custody long after transactions were completed. Identity therefore had to support historical verification. It wasn’t sufficient to resolve a DID to its current state; verifiers had to be able to determine which keys and policies were valid at a specific moment in time.
We adopted did:web early because it aligned with the operational realities of the ecosystem. It was web-native, easy to deploy, and compatible with existing infrastructure and organizational boundaries. It allowed historical resolution as an optional affordance, albeit somewhat trustfully. As the system matured toward production use, however, it became clear that regulated environments require stronger guarantees than static web resolution alone can provide, and better handling of portability and other corner-cases. Without a verifiable history, long-term auditability and non-repudiation were difficult to support.
Rather than change deployment models or governance assumptions, we focused on addressing this gap directly and extending the did:web model.
Designing did:webplus from Operational Reality
did:webplus emerged as an implementation of did:web that extended the original by adds a cryptographically verifiable history to each DID. Every DID maintains an append-only microledger of DID documents; parallel efforts also led to roughly analogous microledger-based methods like did:webvh and did:oyd. A core goal of our microledger design was very expressive and explicit rulesets for updates: each update is self-hashed, linked to its predecessor, and authorized according to explicit rules defined in the prior state. This enables any verifier – now or in the future – to reconstruct the exact state (and exact current update policy) of a given DID at a specific point in time with cryptographic certainty.
This design was driven by the same guarantees our messaging system already required: durability, non-repudiation, and auditability at scale. Using standard web hosting and “incremental retrieval” patterns allowed these guarantees to be achieved efficiently and predictably over HTTPS. The DID method and the messaging substrate evolved together, reinforcing one another rather than being designed in isolation.
From a security perspective, this approach delivers the same assurances commonly associated with distributed-ledger-anchored identity systems, without every query having to be routed directly to a live blockchain node or indirectly through a SaaS middleman. From an operational perspective, it remains deployable using familiar web infrastructure and governance models already accepted in regulated industries.
Grounded in a Real Community
did:webplus is now being prepared for production use within the Open Credentialing Initiative (OCI) ecosystem. Adopters already operate did:web-based systems and expect to be able to extend them with verifiable history without redesigning their workflows or architectures. That continuity is intentional. did:webplus was designed for incremental adoption, respecting the timelines and boundaries under which regulated organizations operate.
The broader governance context also shaped the design. Messaging standards in the pharmaceutical supply chain are stewarded by GS1, a long-time member of the DID working group at W3C. OCI-harmonized identity assurance processes align with NIST guidelines, making secure pseudonymity easier to operationalize. Participation is governed through a public-private partnership with the FDA. did:webplus encodes these realities on boring and compliant web rails rather than attempting to replace them.
A Pattern for Requirements-Driven DID Design
This experience reinforced a lesson that we believe is broadly relevant to the decentralized identity community. Durable identity infrastructure emerges most effectively when it is designed from concrete ecosystem requirements outward. In our case, the demands of regulated, confidential, high-volume messaging shaped the DID method itself. We see this as a useful pattern for other high-assurance environments such as regulated finance, healthcare, and cross-border trade.
Of course, the design was not done in isolation from the broader decentralized identity community. Across GitHub issues and mailing messages, our Chief Software Architect Victor Dods investigated how other implementers understood the under-documented `?versionTime=` reserve word in the W3C DID specification, and how they had implemented it in blockchain-based systems. Victor presented an early draft of the design in the DIF Identifiers & Discovery Working Group for review, and has been grateful to receive extensive ergonomics and interoperability testing feedback from fellow DIF member Spherity in the OCI context.
LedgerDomain has also been a driving member of the DID Methods Working Group at DIF, which seeks to establish a common evaluation framework for maturity and market-readiness through structured peer-review and consolidation of various pre-existing self-documentation processes. In that context, LedgerDomain has sought to lobby for benchmarking production deployments and challenging other evaluators and evaluees to focus more on practical implementation and deployment experience, rather than simply the design process.
Join the conversation:
- In the spirit of open source, everything you need to evaluate, test, or analyze the did:webplus method is available on github.
- If you are interested in the design of DID methods, the Identifiers and Discovery Working Group is an open forum which Ledger Domain availed itself of early in the process
- If you are interested in productionization, benchmarking, and implementer experience, the DID Methods Working Group is steadily building up a registry of production-ready DID methods evaluated collectively and rigorously.
