Two Blockchain-based Recommended DID Methods

An update from our joint working group with the Trust-Over-IP Foundation in LFDT

The public-service work of vetting and curating a shortlist of DID systems for production-readiness and maturity continues with the announcement of two more recommendations. Since April of 2025, wge the DIF DID Methods Working Group first published 13 steps for becoming a DIF Recommended method. The volunteers have been vetting and documenting their work to recommend a wide variety of decentralized identity networks (based on W3C DIDs). The process was the outcome of a collaboration between DIF, Trust over IP (ToIP), and the W3C DID Working group, who signed a letter of intent in 2024 to work jointly towards DID standardization. Today, DIF officially announces it's recommendation of did:ethr and did:cid, have completed and passed the process.

What is a DIF Recommended DID Method?

DIF recommendation is not a certification, nor does it imply the superiority of one method over another. What it means is that the DID method has gone through the process of demonstrating technical viability in production systems over time, and that it can be implemented generally, not just in a specialized case. While DIF continues to remain agnostic to the technology stack, we see it as important to support easier paths to deployment, providing “strength in numbers” as a market develops around DID-based technologies.

Full-fledged certification is outside of DIF’s mandate as an organization that supports research, standards and specification development, but we hope this coarse-grained initial step will encourage organizations closer to specific technology markets to further vet and endorse specific DID-based implementations, registries, and ecosystems.

As such, DIF is proud to recommend two blockchain-based DID methods.

What exactly does "blockchain-based" mean?

The headlining capabilities and affordances of decentralized identifiers systems, permissionless certifiability (or even self-certifying data), anonymous public reads, and strong guarantees of direct user control are all downstream of what ToIP Drummond Reed, co-founder of the Trust-over-IP Foundation, dubbed the "Verifiable Data Registry": not a verifiable registry of data, but a registry of data that is always, easily, and publicly verifiable. From the very first discussions hosted by the Blockchain Commons, or even earlier at IIWs, the vision of DIDs has been intimately tied to blockchain data structures, distrubuted acyclical graphs, gossip networks, and other novel (decentralizing) data protocols, which are straightforwardly good fits for direct user-controlled public-key infrastructure and naming systems.

And yet, while blockchains indisputably lend themselves to being "back-ends" for user-controlled identity systems secured by cryptography, i.e. "VDRs", the front-end (and the business-sector rollout, and the integrations with incumbents) has proven increasingly elusive in the years since. Blockchains, often associated with private money systems which often tied their funding and maintainence with speculation and payment systems, have been a hard sell as tooling for securing personal data (and building independence from infrastructure providers).

Enthusiasm for blockchains and related permissionless data systems might be at a relative nadir in some corners of the software industry and general public, yet blockchains continue to support many kinds of emergent economics and novel data flows. Exactly because blockchain-based DID methods are unwelcome in some corners of the contemporary DID landscape, DIF is proud to support those communities that have stuck by the vision of decentralized identity bridging between different data worlds and software contexts.

In many ways, did:ethr has the longest and richest history at DIF of any blockchain-based method, while did:cid offers a new vision. In the rear-view mirror (having initiated its recommendation process a little later), did:hedera, one of the blockchain methods with most load-bearing and prominent deployments within its blockchain community, promises to round out this second batch of DID methods soon.

DID:Ethr, the veteran Blockchain DID Method

In many ways, did:ethr is the archetypical blockchain DID method, in that it integrates deeply and easily into the "native" identity/PKI system of Ethereum, and turns each Ethereum chain into a distinct VDR and witness, keeping reads public and writes as cheap as each chain's economics allow. The "native" actor model of Ethereum can be thought of as a straightforward Simple PKI ("spooky") system: in the early days of Ethereum usage and experimentation with direct key management (in CLIs and early "wallet" software), and eventually evolved into a complex landscape of multi-signature wallets, on-chain wallets, and on-chain logic emitting signed transactions interlocking into a complex virtual machine. What unifies all of these is that each ethereum "address" (payment endpoint) is a public key, and no transaction is valid unless its sender signs it with the appropriate key that proofs it. In that sense, there is no native "naming" system or namespace for actors, just public keys.

did:ethr extends this elegantly, by treating any valid ethereum address as a DID (like did:key with Ethereum-specific extra steps) with an automatic DID Document containing only that public key. A DID Document containing anything else is specific to a given chain, and is the end result of every valid DID Document update sent to that chain over time (i.e., signed by the corresponding key), meaning that any Ethereum wallet can emit events rotating the key of the DID that bears it [initial] address, witnessed by anyone who can read that chain which witnessed those rotations. A valid address that has never emited an event on a given chain can be referenced by its DID in any transaction, on-chain logic, or off-chain/web operation and remain valid even if that DID is later rotated, unlike referencing a bare Ethereum address which is, well, immutable by definition.

As the design goals were always to make a more robust PKI layer for actors, with rotation and tombstoning and service discovery capabilities (and the minimum of additional security or privacy risks), valid updates to an address' DID document on a given chain are tightly constrained to the adding and removing of keys and the adding and removing of serviceEndpoint entries (commonly called "services" in DID-speak) by the method's algorithms and all its known implementations. Unlike earlier extensions to the base Ethereum address system, arbitrary user-generated content is barred to prevent immutably on-chaining personal or toxic human-readable data.

As for deployment history, did:ethr is very widely deployed and used in many deployments of Ethereum software, KYC systems, multi-sig systems, etc. It is the flagship/native DID method of the Veramo codebase developed and maintained at DIF, which allows off-chain Verifiable Credentials, smart-contracts, "dapps", and on-chain Ethereum Attestation Service documents to interoperate, and for ethereum wallets to becomme full-featured "Identity Wallets" capable of holding and verifiably presenting off-chain Verifiable Credentials. It can even speak DIDComm!

For a self-guided deep-dive into the mechanics and properties of the OG blockchain DID method, check out method champion (and DIF veteran) Mircea Nistor's hello world website for did:ethr.

DID:CID, the multichain superset of DID Methods

The driving design goal of did:cid (formerly did:mdip) was to evade one of every previous blockchain's limitations: its fundamental dependency on a single blockchain network. While most blockchain methods name a witness (a specific chain, as in did:ethr, or a specific gossip "topic" or beacon, as in did:hedera) and never allow an actor to "migrate" to other witnesses while bringing their prior history with them, did:cid strives to make each DID's document history a verifiable event log across the adding and removing of witnesses.

The data model enabling this portability is that of IPFS, in that each valid state of each DID document is content-addressed, and links back to its previous state by that content-address, allowing each DID's history to be a verifiable, tamper-evident "microledger" comprised of sequential states leading back to a genesis document, whose IPFS hash is the globally-unique DID string. Across all of this history, blockchains are used just as witnesses to vouchsafe timestamps and aid in discovery/consumption, but strictly speaking, they are both multiple and optional, i.e, there can be 0 or more witnesses named in each DID document.

The architecture enabling this portability is a Gateway pattern, whereby every DID is hosted at any given time by a Gateway, which published each DID document to 0 or more of the supported blockchain witnesses (as well as bundling and abstracting the costs of writing to them). In this sense, it is a direct heir to the Sidetree family of DID methods, which also used IPFS to bundle DID operations into hosting "nodes" which gossip between them to synchronise and cache each other's state, and write to blockchains or other witnesses as additional security and discovery.

The did:cid highly portable and configurable approach bears much kinship with the self-certifying properties so central to the Trust-over-IP architectural tradition, and the verifiable-history and host-independence properties motivating did:webvh, did:webplus, and did:webs.

For further information on the did:cid protocol and its use-case context, see archetech.com.

The future of DIDs

As mentioned earlier, the queue of DID methods in-process for recommendation includes at least one more blockchain method, did:hedera, and possibly more before the year is out. If reading this piqued your interest in the design space, feel free to get involved and help kick tires and document deployments with us in the DID Methods WG.

As you may be aware, W3C will be launching a W3C DID Methods working group to curate its own registry. A DIF representative will be chairing that group, which will have different enough criteria to be complementary and different enough scope to only partly overlap. DIF's Recommended Methods WG will continue at pace, with the W3C WG going up for a vote at the upcoming TPAC Conference. DIF and W3C are closely aligned, and each WG will be addressing different needs within the industry.