Decentralized Identifiers: the easy guide

This is the first post in a series dedicated to Decentralized Identifiers (DIDs). I’ll explain, in an easy way, the main concepts and ideas behind DIDs.

The dominant identity management systems are based on centralized authorities who keep the decision power over who or what they refer to. With these systems, identifiers are recognized only by certain bodies, not of our choosing, and might become invalid if/when the controlling organization fails or disappears. Another issue of the existing identifiers is that they might disclose, unnecessarily, certain personal information. In addition, they are easily susceptible to identity theft.

An easy example of these identifiers in use is when you show your driver’s license to buy alcohol: the driver’s license is generated by a government and can prove you have the legal age to buy alcohol. BUT, when you show it to prove your age, the clerk will not only see your date of birth, but also your name, address, and other personal information displayed in your ID. In addition, being a piece of plastic, it is easily lost and can be used by another person to steal your identity.

Fortunately, advances in technology provide us with a better alternative, which is the focus of this article: Decentralized Identifiers (DIDs).

What are the Decentralized Identifiers?

According to the World Wide Web Consortium (w3c), a Decentralized Identifier, or DID, is “a globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. […] Many — but not all — DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network.”

DIDs are a type of URI (Uniform Resource Identifier) that associates a DID subject with a DID document, allowing trustable interactions with that subject. A DID is basically composed by three parts: 1) the DID URI scheme identifier, 2) the identifier for the DID method, and 3) the DID method-specific identifier:

The example above resolves to a DID document, which contains information associated with the DID, such as ways to cryptographically authenticate a DID controller.

I know what you are thinking… I just threw a bunch of other concepts at you. But don’t worry, let me explain each of them as briefly as possible:

• DID Subject: the entity identified by a DID, which can be anything: a person, organization, thing, concept, etc. The DID subject can also be the DID controller.
• DID Document: a set of data that describes the DID subject. They include mechanisms, like cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID.
• DID Controller: the entity (person, organization, or autonomous software) that has the capability, as defined by a DID method, to make changes to a DID document. A DID Subject can be a DID Controller and a DID can have more than one DID Controller.
• DID Method: the mechanism by which a DID and its associated DID Document are created, read, updated, and deactivated on a specific distributed ledger or network.
• DID Delegate: an entity to whom a DID controller has granted permission to use a verification method associated with a DID via a DID document.

As you can see in the image below, DIDs are only the first step to achieve decentralized identity management based on the Self- Sovereign Identity (SSI) concept. The next steps are formed by the descriptive properties that come through collecting and selectively using claims and verifiable credentials, which is the subject of the next post.

Source: World Wide Web Consortium