Earlier this year, the Decentralized Identifiers (DID) v1.0 core specification advanced from a draft to a W3C Recommendation. The specification solidifies the official Web standard, but the community has already experimented with DIDs for a while.

If you have not read up on decentralized identifiers yet, now is the time. In this blog post, I will straighten up some misconceptions and provide some basic understanding concerning DIDs.

Myth: DIDs Require Blockchain

When browsing about DIDs, many explanations mention blockchains. People often assume DIDs are meant to be implemented on blockchains. However, DIDs are not designed to rely on any blockchain or distributed ledger technology but to be decentral and resolvable. To fulfill this requirement, some variants of DIDs (called DID methods) do not need any (verifiable) data registry at all. For example, did:jwk and did:key are both valid DID methods and are self-contained.

I like to think of a blockchain as a decentralized, verifiable transaction log with consensus rules. And as such, it can be an applicable storage for DIDs and related data. Yet, neither the DID standard nor technology requires using blockchains or distributed ledgers. Other examples of verifiable data registries are decentralized file systems, databases, or peer-to-peer networks.

Since blockchains keep records of all transactions, they maintain a DID history and thus provide traceability. That said, do not put any personal data on the blockchain, whether you use plain, encrypted, or hashed values.

Myth: DIDs Should Contain Personal Data

A DID is just a structured ID, and, as such, it commonly contains more or less random strings and no personal data per se. However, a DID resolves to a so-called DID document. A DID-document describes the DID subject, which is the entity that the DID refers to. Consequently, it is easy to believe that the DID document should contain personal attributes. Thus, some identity architects may be tempted to add personal data to the DID document to describe the subject in more detail (as indicated above). That approach, however, violates one of the design goals of the DID specification: privacy.

The DID specification advises against putting any identifiable data into the DID document. This is especially true when the document is stored on an immutable or public-facing registry, like a blockchain, where it cannot be removed. An implementation that puts personal data on a blockchain can hardly argue to comply with the "right to be forgotten." Even encrypted values should be considered unsafe as they will be exposed at some point with cryptography and computing power advancing over time. Therefore, keep private data private.

A DID document should only contain one or more public keys used for proof-of-possession verifications. Services listed in the DID document and verifiable credentials (VCs) are then suitable methods for retrieving descriptive claims about the subject.

Myth: DIDs Are Self-Controlled Identities

I briefly mentioned two design goals of DIDs in the previous sections: decentralization and privacy. Another important aspect of DIDs is the ability to control one's identifiers directly, without involving external authorities. This does not necessarily mean that the controller is also the DID subject, although it can be. It means that DIDs are identifiers that can be controlled by an entity other than an authority. Note, that DIDs are just one building block in a bigger ecosystem and on their own are insufficient to create a self-controlled identity system.

Undoubtedly, that design makes DIDs an enabler for self-controlled identities or what is commonly referred to as self-sovereign identities. DIDs lend themselves well to verifiable credentials. Verifiable credentials are similar to certificates: They are documents containing an assertion of authority that a key identified via the DID possesses certain attributes. The authority is identified by another DID that is part of the trust structure. The holder of a verifiable credential can then use the same and present it to various parties using proof-of-holder mechanisms. As all keys are identified via DIDs, credentials and their presentations can be verified without contacting an authority, issuer, or any other central system. An environment where users can control how they want to be identified (which identifier to use) and what part of their identity to share with whom, is not one solution but the carefully designed orchestration of several building blocks where DIDs form the foundation.

Truth: DIDs Do Not Solve All Problems

Some identity providers today have tremendous control over their users' data. Yet, it's problematic and even dangerous when a single player has so much power that it (or others) can eventually abuse. Therefore I like the idea of a self-controlled identity, where individuals don't rely on an authentication authority. DIDs play a vital role in that movement, and it is fascinating to follow all the ideas and experiments people come up with using DIDs. However, DIDs do not solve all problems. The industry will require harmonization with best-in-class solutions if DIDs are to become sustainable.

DIDs still do not solve the big question: How do we establish trust in a self-controlled identity ecosystem? Even with a decentralized approach, one or more authorities still issue verifiable credentials or similar attestations. Holders and verifiers need to be able to verify the authority and that the authority is indeed authoritative for a given attestation. A trusted issuer registry could be a solution, yet, who would maintain such a registry? Can you maintain it in a decentralized manner?

If something goes wrong in issuing the verifiable credential, the system will break. How do we ensure the process is secure and provide a fallback method, such as revoking a verifiable credential or DID? Is there a pure decentralized way to achieve that? Are DIDs really as innovative as we believe them to be, or will we end up with a PKI-similar system, only decentralized using new data formats and protocols?

Even with decentralized identifiers, authorities will likely still play an essential role in self-controlled identities as they will be central to establishing trust. Today, we preach using a central identity and access management system to secure your business. This recommendation won't change in the near future because although trust is centralized, identifiers don't necessarily have to be.