Digital identity shapes every facet of our online interactions. The quest for a system that balances decentralization, scalability, security, and user experience has been relentless. Today, I'm thrilled to share that TBD has birthed a new solution: the DID DHT method. This leap forward is not just a technical achievement; it's a foundational component for the more inclusive and trust-based digital world we want for tomorrow.
The specification is nearing its first major version, and our team has produced client software in all of our open source SDKs in more than five languages. We have also built and deployed a publicly-available developer gateway, which has already registered hundreds of thousands of DIDs, with staging and production-ready gateways coming soon.
Some of you may already be familiar with DID DHT and why we’ve chosen to make it our default DID method, but if not, or if you’re curious to find out more, read on to learn more about how the method was created, and how we’ve ended up here today.
What Makes a Good DID Method?
Our vision for a superior DID method hinged on several critical features:
- Sufficient Decentralization — a foundational principle to mitigate censorship and enhance user autonomy.
- Scalability and Accessibility – making digital identity accessible to billions, without a prohibitive cost barrier.
- Comprehensive Feature Set — supporting multiple cryptographic key types, services, and other core DID properties.
- Reliable and Verifiable History — enabling trust through transparency historical data.
- Global Discoverability – facilitating easy access and independent verification of digital identifiers.
The Evolution of Our DID Strategy
Historically our software has supported did:key, did:web, and did:ion, and some other methods within certain segments of our stack. Recognizing the impracticality of a "one-size-fits-all" approach, we embraced a multi-method strategy. Today that strategy incorporates three key DID methods: did:jwk, did:web, and did:dht, each catering to specific scenarios with their unique strengths.
Within our SDKs, JWK replaces did:key, a simple and widely adopted method that uses standard JSON Web Keys (JWKs), limiting complexity over did:key’s approach to using multi-formats. DID Web is an obvious choice for entities with existing brands, as trust can be easily linked to existing domains without the use of any special or complex technology. DID DHT is a new method that we view as a replacement for ION, which has strong decentralization characteristics, a robust feature set, and a simpler architecture.
Leaping Beyond ION
The biggest change we’ve made is going from ION to DID DHT.
ION is a Sidetree-based DID method that is a L2 on the Bitcoin blockchain. ION is a fully-featured DID method, and one of the few that supports root key rotation and discoverability of all DIDs with complete historical state. However, there are three main reasons that led us to move away from using ION — architectural complexity, centralization risk, and a sub-optimal user experience.
While ION presented a robust DID method with admirable features, its complexity, centralization risks, and user experience challenges prompted us to explore alternatives. DID DHT stands out as our choice for a new direction, offering simplicity, enhanced decentralization, and a user-friendly approach without compromising on the core features essential for a comprehensive DID method.
Enter DID DHT
DID DHT is built upon Pkarr, a community-created project. Pkarr stands for Public Key Addressable Resource Records and acts as a bridge between our DID method and the Mainline Decentralized Hash Table, overlaying DNS record semantics and providing a space-efficient encoding mechanism for DID Documents. The choice of Mainline DHT, with its over 20 million active nodes and a 15-year successful run, guarantees exceptional decentralization out of mainline nodes, but can also leverage Pkarr nodes and DID DHT gateways for additional functionality.
DID DHT trades off use of a blockchain for immediate decentralization, fast publishing and resolution, and trustless verification. That’s right — the DID Document’s records are signed by its own key before entering the DHT — there’s no need to trust nodes, as you can verify payloads yourself client-side. Similar to ION, DID DHT documents support multiple keys, services, type indexing, and other DID Document properties.
DID DHT, however, is not without its limitations. The main three being: a need to republish records to nodes regularly to prevent them from expiring from the DHT and reliance on a non-rotatable Ed25519 key called the “identity key,” as is required by the DHT and BEP44, and historical DID state not being shared between nodes. Our ongoing development and community-driven enhancements aim to address these challenges, refining DID DHT's architecture for broader applicability and reliability.
DID DHT Opportunities
One of the most interesting opportunities we have identified for DID DHT is interoperability with existing single-key methods like did:key and did:jwk. Essentially, you can continue to use single-key methods as you do today, with an optional resolution step to the DHT to extend the functionality of these methods, like adding additional keys or service(s) to a DID Document. We have begun to define this interoperability in the method’s registry.
Another interesting opportunity for DID DHT is with the W3C DID working group, which is currently going through a rechartering effort to focus on interoperability and DID Resolution. Depending on how the charter ends up, there could be an opportunity to promote the DID DHT method as one that is broadly interoperable, decentralized, and does not necessitate the use of a blockchain — a common critique of DIDs by community members in the past.
We have additional ideas such as associating human-readable names with DIDs, tying DIDs into trust and discoverability services, and supporting gossip between DID DHT gateways. We encourage you to join us on GitHub to continue the discussion.
Looking Forward
The introduction of DID DHT represents a significant milestone in our journey toward a more decentralized, accessible, and secure digital identity landscape. We believe DID DHT has the characteristics to make it widely useful, and widely adopted. Try it out for yourself, and let us know what you think.
As we continue to refine and expand its capabilities, we invite the community to join us in this endeavor, contributing insights, feedback, and innovations to shepherd DID DHT toward becoming your default DID method.