Demystifying Decentralized Identifiers (DIDs)

Decentralized Identifiers (DID) are unique identifiers that enable entities to generate and control their identifiers in the digital world.
Nov 15, 2021

All of us have many unique identifiers/credentials that identify us, such as our email addresses, social media handles, usernames and passwords for different sites, driver’s license ID, passport ID, and so on. In reality, we don’t control any of these identifiers and the way they are shared.

Often, these identifiers are stored by third-party companies in centralized locations that could be hacked. Also, they are closely tied to the organization storing it, so if the organization bans you or becomes non-existent, so do your identifiers. A good example can be the way Donald Trump was kicked out of Twitter that led him to lose his followers and public identity overnight!

A new digital identity framework called Self-Sovereign Identity (SSI) has emerged to overcome these challenges and to give users complete control over how their identifiers are generated, where they are stored, and how they are shared.

The last few years have seen a stronger push for self-sovereign identity and this has led to the development of standards and building blocks for their implementation. Many companies like Affinidi have been creating building blocks to enable SSI across different industries.

A basic building block of SSI is Decentralized Identifiers (DIDs). These are a type of unique identifiers (URI) that enable entities to generate and control their identifiers in the digital world.

These DIDs come with certain properties and they are:

  • Does not require a centralized registration authority
  • Many DIDs use the distributed ledger technology or any other decentralized network, though it is not mandatory
  • It is a permanent identifier because it does not depend on a single third-party or centralized registry for its existence.
  • Can be cryptographically verified
  • They connect a DID subject (the entity identified by the DID) with a DID document (a set of data that describes the DID subject) to enable the subject to have trustable interactions.
  • They are interoperable and portable, provided they conform to the existing standards laid down by W3C

So, this is how a DID looks like.



  • The first part, the “did”, is the URI to identify that the transaction pertains to decentralized identifiers. This URI does not change, regardless of the implementation.

  • The second part, “example” is the DID method. This value is the protocol that determines where or how you’re going to find the DID. There are about 97 methods available at the time of writing this piece and this is likely to increase. Fundamentally, most of these methods revolve around creation, reading, update, and delete, but the implementation of each of these actions vary across the methods.

  • The third part, the long alphanumeric value is the DID resolution that can be understood as an algorithm or value that resolves the DID to the DID document. It is similar to the DNS address that we use today.

A key building block of DIDs is the DID method.

What are DID Methods?

In a nutshell, DID methods are the component that helps a DID to resolve a DID document. It defines how DID documents are created, read, updated, and deleted on a network.

DID methods are often associated with a verifiable data registry, which is a system that brings together DIDs, DID documents, and DID methods. Some examples of verifiable data registries are trusted databases, decentralized databases, distributed ledger, and government ID databases like DigiLocker. Sometimes, more than one type of registry can be used in the same ecosystem.

In terms of implementation, a DID method is defined by its specification that precisely defines how DIDs and DID documents are created, updated, deactivated, and resolved.

Let’s understand this with an example.

DID: ELEM: jadjfa;j948madnfaupwmfm


  • DID is the schema
  • ELEM is the verifiable data registry. ELEM represents the implementation of sidetree protocol on the Ethernet network
  • Jadjfa;j948madnfaupwmfm is the method-specific identifier and is the public key on a distributed ledger.

Let’s now delve deeper into the world of DIDs and their working

How do DIDs Work?

Just like any other URI, DIDs are a unique identifier that associates a DID subject with a DID document.

Here, the DID subject can be an individual, entity, thing, etc, while the DID document is a JSON-LD object that contains a set of data that describes the DID subject including the cryptographic signatures, verification methods, or just about anything that will enable the DID subject to have trustable interactions with other entities on the network.

In essence, the DID contains a unique identifier that is used to lookup a DID document that relates to a DID subject. It is stored on one or more decentralized storage systems such as IPFS or STORJ.

Here, the DID resolves the DID document that in turn, describes the DID subject. To close the loop, the DID subject controls the DID and determines how and with whom it can be shared. In this sense, the DID subject is the DID controller in our example, but it merits to note that the DID controller and the DID subject don’t have to be the same entity at all times.

The key difference is that the DID controller has the right to change the DID document and this right is granted through the use of cryptographic keys. Due to this aspect, there can be more than one DID controller for the same DID document.

So, the workflow begins when a DID subject decides to create a DID for sharing with others. This connects to a DID document that could contain,

  • The DID itself
  • A timestamp of when it was created
  • Metadata related to its delegation and authorization
  • Cryptographic proof of its validity including the public keys that is used to authenticate the DID subject
  • A possible list of services where the DID can be used
  • A JSON-LD signature to verify the integrity of the DID document

Note that the DID document doesn’t contain personal information about the subject as these come through verifiable credentials. You can visualize DID as the base layer of the decentralized infrastructure and the verifiable credentials containing the PII of a subject as the next higher layer.

Yet, there are many differences between DIDs and DNS.


Now that we have a better understanding, here’s how a DID document could look like. { "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ] "id": "did:example:123456789abcdefghi", "authentication": [{ // used to authenticate as did:...fghi "id": "did:example:123456789abcdefghi#keys-1", "type": "Ed25519VerificationKey2020", "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }] }

Here, the DID document contains the cryptographic information needed to authenticate the DID controller.

There are a few key elements here.

  • Context — Denotes that this is a JSON-LD document
  • Id — Points to the DID in a DID document
  • Authentication — An optional property and represents one or more verification methods
  • Service — This is also optional and describes the means of communication with a DID subject

We hope this gives you an idea of what DIDs are and why you need them for relevant implementations. It can come in handy for anyone who is interested in the implementation of decentralized identity management and developers who want to use Affindi’s APIs to develop real-world applications that can address many of the pressing issues facing us, especially in the realm of digital identity.

You can check out some real-world use-cases here.

Affinidi provides building blocks for an open and interoperable Self-Sovereign Identity ecosystem. Check out our developer portal for more information.

Get an email whenever Affinidi Publishes!