We are highly concerned about recent developments in the W3C Credentials Community Group discussion on Decentralized Identifiers (DIDs) . This is why Jolocom and Danube Tech decided to prepare this joint statement ahead of the upcoming Internet Identity Workshop held from April 30th to May 2nd 2019.
As long-term members of the decentralized identity space, we recognize how the recently proposed changes to the DID spec within the W3C group threaten to undermine the core values of our community.
Building a Universal Identity Layer
If we intend to build a universal identity layer for the web, we have to enable technical interoperability between identity systems of all sorts.
Several technical building blocks are currently being developed by groups such as DIF, W3C, and others, in order to establish the foundation for a universal, self-sovereign identity (SSI) layer. One core component of this identity layer is the Decentralized Identifier (DID). Even though the SSI ecosystem is still young, there is already broad consensus across many initiatives that DIDs are a useful concept.
While DIDs have proven to be highly attractive to achieve this effort, there is a conflict between the more recent goal to achieve interoperability with other identity systems and the initial goal of DIDs to empower identity subjects to be in full control of their identity.
To achieve both simultaneously, we have to ensure that the subject of an identity maintains control over its identity throughout the different layers of the stack. We are of the opinion that all efforts made towards interoperability have to respect that goal:It has to be clear at all times, whether an identity is under the sole control of its subject or whether it is dependent on a third party to function.
While we see the potential to enable interoperability with actors that do not put control in the hands of the subject of the digital identity, we must ensure that this interoperability on a technical level does not undermine the Design Goals that guided the creation of decentralized identifiers in the first place.
What’s at stake here is the integrity of our definition of DIDs — and, by extension, the future of the SSI ecosystem.
DID Design Challenges
In order to support the SSI/Web3 vision, DIDs have been designed with the following key properties:
Creating, updating, using, and deactivating the identifier can be done in a way that is independent from any central authority.
The identifier will always refer to the same real-world entity (the subject) and never get reassigned.
C. Cryptographically verifiable
It is possible to prove by cryptographic means that the identifier is under the exclusive control of the subject (or authorized delegate).
Metadata such as cryptographic keys and services can be discovered about the identifier to enable trustable interaction with the subject.
Historically, no type of digital identifier has had all four properties. For example, domain names or Facebook usernames have property D, but they do not have properties A, B, C. Obtaining each of these four properties in identifiers is essential for building an identity system that is not “only” user-centric, but definitely self-sovereign.
One challenge when developing technical specifications is how to come up with concrete, measurable definitions of terms. How do we define “decentralized”? When can we justifiably call an identifier a “Decentralized Identifier”? Perhaps it is not possible to come up with an objective technical definition, but there is certainly a shared narrative in the digital identity community that has emerged over the last few years and can be understood from the following sources, among others:
- Christopher Allen’s SSI principles (“independent existence”)
- Zooko’s triangle (“decentralized” property)
- RWoT#1 paper on DPKI (“decentralized public key infrastructure”)
However, while DIDs support the SSI/Web3 vision, we also need to recognize that other, non-decentralized identifiers will continue to exist. If people would like their identifiers to be managed by infrastructure that is centralized or hierarchical (e.g. usernames managed by Facebook, or domain names managed by ICANN), then that should be possible as well in an open and universal identity architecture.
To make this possible, one current community proposal is to expand the scope of the DID specification to apply the same syntax (namely, URIs starting with “did:”) and the same discovery format (DID Documents) to any kind of identifier, not just decentralized, and to therefore evolve the DID concept into a “bigger tent”. This would mean that we will see identifiers such as “did:web:mydomain.com” or “did:facebook:alice”.
The dilemma here is that on one hand, this approach would allow seamless interoperability, and architectures could be built in which everyone could choose freely whether they want their identifier to be registered in Ethereum, Bitcoin, Sovrin, Veres One, IPFS, DNS, Google, or Facebook. On the other hand, while all these identifiers would share a common syntax and discovery format, not all of them would fulfill the key properties A (Decentralized), B (Persistent) and C (Cryptographically Verifiable), which have so far all been considered essential for DID technology and the SSI/Web3 vision. We would start seeing identifiers that look like DIDs but do not satisfy the above-outlined criteria for what makes an identifier a DID.
Call to Action
What we must avoid at all cost is a development where business pressure leads us yet again down a road of “re-centralization”, and where for marketing reasons identifiers are called DIDs that are not really DIDs. We have witnessed this before with OpenID, which was designed as a decentralized identity technology but instead ended up being co-opted into centralized services that have brought us surveillance capitalism and violations of digital human rights on a massive scale.
With DIDs and SSI, we are now at an early stage in which small choices will affect the lives of many people in the future. We must therefore act responsibly to not compromise on our values.
We encourage you to share your thoughts on this blogpost and get involved in the ongoing GitHub discussion on the topic. We hope to come to a first shared proposal for resolving this during next week’s IIW in Mountain View.