Re-framing DIDs - Pointers with a Purpose

Originally published on LinkedIn

I recently came across a LinkedIn article: “Are DIDs a DUD ?”. The article raises some long-standing concerns about the DID ecosystem, particularly around fragmentation, practicality, and real-world interoperability. But some of these points are made in a way that misrepresents the goal and scope of DIDs. DIDs are just a pointer

Yes, they are. The interesting part is why they are. DIDs allow their owner to list keys and related services, as well as change them: 1. without changing the identity reference, 2. without relying on a central authority to be able to do so.

They are pointers that enable continuity in digital relationships. Pointing to did:key and did:jwk saying they are a solved problem also misses the point of both these specs: they are adapters and use case-specific variants of the whole ecosystem. Divergence, convergence - compromises

It is true that the DID ecosystem is very fragmented and the list of existing methods long enough to give heartburn to potential adopters. It is also true that not every company needs their DID method. But vanity methods aside, the list shows the multitude of ways DIDs can be implemented and operated. It shows flexibility. It shows adaptability to industry-specific requirements.

Some of these methods are an exercise in creativity and some just demonstrate how the specification is generic enough to allow bridging back in a lot of existing systems (e.g., did:snail). Some are compromises. did:web

Criticizing did:web for just adding a layer of indirection on top of the X509 infrastructure is a valid point, but it also misses the target. did:web does not exist to augment the existing PKI infrastructure and claim decentralization. It exists as a pragmatic bridge from existing trust infrastructure to a more flexible model. did:web is a path forward instead of a goal in itself.

I must admit, however, that I’m afraid did:web is going to be a new status quo, an intermediate solution that becomes entrenched and overstays its welcome. Costs and interoperability

The article claims that DIDs bring higher cost and lower interoperability.

It is unclear to me how easy we can compare the cost of operating on DIDs or certificate; what is certain is that managing certificates at scale is not cheap. I encourage people to read this analysis of X.509 in the scope of organizational identity by Daniel Hardman. Notably, this analysis extends to DID methods that rely on X.509 as their root of trust.

Interoperability criticism - while rooted in some level of truth - also makes the unfair comparison of a specification for “just pointers” with the entire technical and legal ecosystem of which X.509 certificates are a tiny component. Interoperability emerges from real-world uses and needs, a specification merely tries to foster it by designing for it. Conclusion

I acknowledge that these arguments might paint me as some kind of evangelist. I’m not religiously convinced that DIDs or any other piece of technology are here to save the internet. I realize there are numerous layers of intricacies and trade-offs to consider

The author makes some valid points on which I agree. DIDs certainly have shortcomings and create new problems that need solving. This answer is mostly meant as a reframing of the problem in what I believe is a fairer picture so that readers can form an opinion knowing more about DIDs than did:key, did:jwk, and did:web might show.

DIDs are not a drop-in replacement for PKI, but a tool that shifts some of the assumptions and responsibilities around trust and representation in the digital space.