Decentralized Identifiers (DIDs)

Definition of Decentralized Identifiers

Identifiers (IDs) are everywhere. Identified objects include: Persons (passport number…), companies (VAT number…), retail items (GTIN…), books (ISBN number…), vehicles (VIN…), airplanes (‚tail number‘…), network devices (MAC address…), IoT devices, proteins, viruses, galaxies, and so forth.

Decentralized Identifiers (DID) is a proposed recommendation by the World Wide Web Consortium (proposed W3C standard) with these key characteristics:

• It allows to specify decentralized identifiers, called DID, for everything, so without any semantic limitation.
• DIDs come with DID Documents. These are in essence sets of key-value pairs. For a book, they might specify properties like title, author, and publication date.
• DID methods are the mechanism by which a particular type of DID and its associated DID document are created, updated, deactivated, etc. The method also defines the syntax of the DID itself. DID methods are defined using separate DID method specifications. Multiple methods will exist; the standard is not strict with regard to the specification and implementation of the DID methods.
• Technically, the DID is a specific kind of Uniform Resource Identifier (URI). This facilitates easy handling of DIDs on the web. The syntax is of a DID is did:<did_method>:<method-specific_identifier> . For example, the ‘iota’ method (built on the IOTA ledger) uses 44-character identifiers, with DIDs like did:iota:H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV. The URI standard does not include or enforce using the HTTP protocol.
• The DID resolver resolves the DID, that means for a given DID it retrieves the DID document. It invokes the DID method for reading the DID document and potentially performs additional steps. In practice, DID resolvers might provide a REST API and serve browser and App user interfaces.
• The entity that is identified by a DID is called the DID subject. The DID controller is the entity responsible for creating and updating the DID. The DID controller can be identical to the DID subject, e.g., in case of identifiers for a person. The DID controller can grant access to a verification method (e.g. for authentication purposes) to a third party called the DID delegate.
• In addition to holding properties, DID documents are specifically intended to hold cryptographic information, such as public keys, and verification methods. An essential capability based on that is that the DID subject (or DID delegate) can authenticate itself and prove its association with the DID. Another prominent use case is verification (‚verifiable credential‘, see also the corresponding W3C recommendation). For example, if an university creates a DID for a university degree, then the degree holder can cryptographically prove that he/she holds the degree.
• The verifiable data registry is the system that facilitates the „creation, verification, updating, and/or deactivation of DIDs and DID documents.“ So it not only stores (persists) the information, but also implements the DID methods associated with it.

Core DID Components (illustrative, simplified)

Technology Evaluation

Advantages

The standard empowers the DID controller and eliminates a third party managing the ID, fostering data sovereignty. With the words of Ivan Herman, the DID standard‘s ‚Staff contact‘: „A DID is a self-sovereign identity, i.e. lifetime, portable, and verifiable digital entity that does not depend on any centralized authority.“

Eliminating a third-party ID provider specifically means independence from that third party’s very existence (e.g., usage of email as identifier with the risk of the email provider no longer being available), its cost (e.g. using web domains as IDs, with registration cost), its jurisdiction, and other dependencies.

DIDs can heavily reduce the number of redundant IDs. People have hundreds of IDs on the internet today, continuously re-creating new IDs for themselves in their partner’s systems. DIDs can be the foundation to reverse that by people bringing their identity (BYOI) to a new partner, proving who they are, and exposing the exact right amount of data (‚data minimization‘). This is opposed to, say, showing an ID card at a bar entrance, which reveals much more than the required information: whether the person is of legal drinking age.

DIDs support existing and new use cases where strong verifiability is of the essence. During a job application, cryptographically proving that the applicant holds a university degree is a world apart from attaching a PDF.

Disadvantages

Most DIDs cannot be memorized by humans; they are internet friendly but not human friendly. Domain names like ‘www.softwareag.com’ were invented as they are much easier to memorize than IP addresses. There are no similar provisions for DIDs. Many people memorize their social security number. There is no standardized way to turn such ‘human-manageable’ IDs to DIDs. (However, digital ‘wallets’ can to some degree alleviate the problem.)

DID is still in the ‘proposed recommendation’ status. During the review period in fall 2021, a formal objection to releasing the standard was submitted. Main objections are:

1. The documented design goal for decentralization is to ‘eliminate the requirement for centralized authorities or single point failure [sic] in identifier management’ (emphasis added). Distributed ledger technology (DLT, like a blockchain) is the best technology for this purpose, providing superior levels of distribution, programmability, resilience etc. According to the DID standard, examples for the verifiable data registry include ‘distributed ledgers, decentralized file systems, databases of any kind […] and other forms of trusted data storage.’ So, the standard itself does not enforce decentralization on the verifiable data registry. The objection is that this violates stated design goals.
2. DID methods can be specified differently and implemented on various systems, (a list of current method specs under development is found here), so they are not interoperable. Standardization of the methods was taken out of scope for version 1.0 of the recommendation. The objection is that the proliferation of non-interoperable method specifications could drastically limit the practical use and adoption.
3. Blockchains can be environmentally harmful (not all are), which is against stated W3C principles. The objection is that the standard is not actively dealing with this issue.

The current status of the debate is found here. The consensus process stalled and progress is slow.

Market – Current Adoption

The delays do not seem to significantly slow down the adoption of the proposed standard. A significant number of players are active, as illustrated by the number of DID method specifications currently under development. Notable developments include:

• Developments cover verifiable data registries on many distributed ledgers, including but not limited to Ethereum, including also Layer 2 solutions like Polygon.
• The Hyperledger Foundation is an open source community developing frameworks for blockchain deployments. Among them is Hyperledger Indy, providing ‚tools, libraries, and reusable components for providing digital identities rooted on blockchains‘. A related project with focus on interoperability (DLT agnostic) is Hyperledger Aries. Various DID methods based on Hyperledger are developed.
• Both the IOTA Foundation and the IoTeX Foundation create DID methods, illustrating the interest of the IoT community in the topic. IOTA's Identity framework, somewhat similar to Aries, provides a DLT-agnostic framework.

Market – Outlook

The time is ripe for decentralized identifiers; the problems with today’s ID management are apparent even to non-technical people. The technology is available, in particular distributed ledgers as an ideal foundation. A large number of companies are trying to address the market. A basic standard from an authority like the W3C is way overdue.

Historically, however, the progress in this area has been painfully slow. It could even be argued that looking at the maturity of many IT systems today, topics around identification, authentication, and personal information management are among the least developed of all.

Right now, there is a lot of momentum despite the challenges around the successful conclusion of the standardization process. With or without the DID standard, decentral identifier management is a main use case for distributed ledgers and will without doubt find wide adoption in the near future. It will be interesting to see how the standardization of the DID methods turns out; possibly by an informal, de-facto standard emerging on top of the official recommendation.