What are Decentralized Identifiers:All You Need to Know
The Decentralized Identifiers protocol is one of the three pillars of Self-Sovereign Identity, together with the Verifiable Credentials protocol and Blockchain. DIDs allow individuals to manage their identity-related information. So you can create identifiers and claim and hold your attestations without relying on central authorities, like governments or service providers. Let’s dive in to find out precisely what Decentralized Identifiers are, the difference between Private DIDs and Public DIDs, how they are used, and more.
Table of Contents
What are Decentralized Identifiers?
Decentralized Identifiers or DIDs are a new type of globally unique identifier that is cryptographically verifiable and don’t need a centralized registration authority. DIDs can identify a person, abstract entities, organizations, data models, and Internet of Things (IoT) devices.
DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. While other parties may be used to help discover information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from another party.
In our digital world, we need to provide critical information to access websites, apps, services, and devices. The technology of universally unique identifiers (UUID) and unicorn resource names (URN) requires a centralized registration authority and isn’t equipped to cryptographically verify ownership of the identifier. As a result, we are often subject to data theft, privacy loss, and other related problems.
This is what a DID looks like:
A DID is a text string that consists of three parts:
- Scheme
In the first part, all DIDs start with “did,” the URI scheme identifier. It is just like how all website addresses begin with http://. The URI doesn’t change, regardless of implementation.
- Method
The second part, called “example”, is the DID method. It is the protocol that determines where to go to find the DID. They are often stored in a digital wallet or a blockchain, but at the same time, they can be stored anywhere. Most methods revolve around creation, updating, reading, and deleting. However, the implementation of each of these actions vary across the methods. By the way, the DID method is the critical building block of DIDs.
- Identifier
The long alphanumeric value in the third part is the DID resolution. It can be understood as a value or an algorithm that resolves the DID document. It is just like the DNS address that we use today.
What Problems Do Decentralized Identifiers Solve?
Today we rely on identifiers from intermediaries like Facebook and Google, email providers, or mobile network operators to connect us. This has serious implications for our privacy as the (meta) data collected by these parties from the interactions over those connections aren’t under our control.
Even when using a messaging service like WhatsApp, where your communication is encrypted, the intermediary (Facebook) can still see and connect your metadata. That alone could tell them who you messaged, for how long, at what time, in which intervals, from what location, while using which apps.
Then, by combining that data with other meta (data) from you and the friend you sent the message to, these intermediaries can create a much more accurate profile. For example, if your friend was talking to you about race bikes, you might also be getting targeted ads for race bikes, even if your conversation was fully encrypted, just because your friend was looking for race bikes around the time you talked.
While racing bikes ads are primarily harmless, these data correlation practices have also been used to interfere in elections. This is partly because power over these identifiers is in the hands of a few centralized groups with almost unlimited access to your private information.
The Relationship Between DIDs, Verifiable Credentials and Blockchain
An organization attaches their Public DID to the Verifiable Credential when they issue you that Credential. The Public DID is also stored on the blockchain, an immutable record of data. When someone wants to verify the validity/authenticity of the Credential, they could check the DID on the blockchain to see who issued it without contacting the issuing party.
So, the blockchain acts as a verifiable data registry. It is like a “phonebook” that anyone can consult to verify what organization a specific Public DID belongs to.
Types of Decentralized Identifiers (DIDs)
There are two types of DIDs: Private DIDs and Public DIDs ( sometimes called “pairwise,” “peer,” or “pseudonymous” DIDs).
- Private DIDs
Private DIDs can be exchanged between two parties to create a secure channel that no one else has access to. It simply means that no third party knows what happens across that channel. Parties can also use private DIDs as channels for communication or transmission of sensitive data without their use being monitored.
The best thing is that you can spin up as many separate DIDs for as many respective relationships as you see fit to prevent the correlation of your private information without relying on a single central authority.
- Public DIDs
Public DIDs are for when a subject wants to be publicly identifiable. They can also be used to kick off the exchange of private DIDs between two parties.
Public DIDs are when a DID is used to issue a verifiable credential like a passport. The credential and identifiers are stored on a public blockchain ledger; thus anyone can see and verify that the owner has a right to travel internationally.
There is a remarkable thing about verifiable credentials called zero-knowledge proof. It means that the publicly accessible proof of license to travel doesn’t show other information that would generally be on a physical passport, such as place and date of birth.
Benefits of Decentralized Identifiers (DIDs)
DIDs benefit organizations and institutions that issue or verify credentials.
The DIDs decentralized nature makes credentials always available for verification. As opposed to a system where the credentials are in a centralized database, which can become useless if it goes down for any reason (or, in the worst case, gets destroyed).
They allow two parties to create a secure channel for data exchange. A channel that someone else is privy to.
The ability to instantly verify credentials is helpful for various use cases, including speeding up the hiring process and reducing the risk of hiring someone without the proper credentials.
Many organizations worldwide must comply with regulations on collecting, storing, and using user data if they don’t follow those regulations. They may face penalties and sanctions for breaking the rules or data breaches.
How Do Decentralized Identifiers Work?
As one of the components of Self-Sovereign Identity (SSI), DIDs allow for controllable and cryptographically secure identification without going through a third party. Unlike Google, which passes through a verifying intermediary, DIDs are stored on an immutable blockchain.
Organizations and individuals can create as many DIDs as necessary and be used in different contexts whenever identity verification needs. There are a variety of other DID methods which can be used to create a DID. Moreover, each decentralized identifier is a code that consists of a scheme, a method, and a method-specific string.
When decentralized identifiers are created, parties can exchange them to create secure connectivity between them and confirming identification. With the help of verifiable credentials, DIDs produce a reliable way to display proof of license where applicable.
The Format of a DID
In 2016 the DID specification developers agreed with Christopher Allen’s suggestion that DIDs could be adapted to work with multiple blockchains, following the same basic pattern as the URN specification.
The key difference is that in the case of a DID, the namespace component identifies a DID method. In contrast, a DID method specification specifies the format of the method-specific identifier.
DID methods define how DIDs work with a particular blockchain. All DID method specifications must specify the format and generation of the method-specific identifier. It should be noted that the method-specific identifier string should be unique in the namespace of that DID method.
DID Documents
A DID document is a structure expressed, like JSON, and contains information about the identity. It can also include other claims or attributes describing the subject. These DID documents are graph-based data structures expressed using JSON-LD but might also be expressed using other compatible graph-based data formats.
A DID document’s purpose is to describe the public keys, authentication protocols, and service endpoints necessary to bootstrap cryptographically-verifiable interactions with the identified entity.
Thus, a DID document is a valid JSON-LD object which uses the DID contexts. It includes six components:
- the DID itself
- a timestamp of when it was created
- cryptographic proof of DID’s validity, like public keys that are used for authentication or interaction with the DID subject
- a list of cryptographic protocols for interacting with the DID subjects, like authentication and capability delegation
- a set of services where the DID can be used
- an optional JSON-LD signature to verify the integrity of the DID document
DID Methods
DID methods are the component with the help of which a DID resolves a DID document. The role of a DID method specification is to define how DID documents are created, fixed, updated, and managed on a specific blockchain.
DID documents can be adapted to any distributed ledger, modern blockchain, or decentralized network that can resolve a unique key into an exceptional value. The blockchain can be public, private, permissionless, or permission.
DID methods are also associated with a verifiable data registry. It is a system that combines DIDs, DID documents, and DID methods. Examples of verifiable data registries can be trusted databases, decentralized databases, distributed ledgers, and government ID databases like DigiLocker.
DID method specifications define the following operations for a particular target system:
✅Create
Some DID methods can generate a DID directly from a cryptographic key pair. Others might use the address of a transaction or a smart contract on the blockchain.
✅ Read
DID methods use blockchains that can store DID documents directly on the blockchain. Others can instruct DID resolvers to construct them dynamically based on the attributes of a blockchain record. However, others might store a pointer on the blockchain to a DID document stored in one or more parts on decentralized storage networks like IPFS or STORJ.
✅ Update
This operation is the most critical from a security standpoint since control of a DID document represents control of the public keys or proofs necessary to authenticate an entity.
As verification of DID document update permissions can be enforced by the target blockchain, the DID method specification has to define precisely how authorization and authentication are performed for any update operation
✅ Delete.
DID entries on a blockchain are immutable; that’s why they can’t be “deleted” in the conventional database sense. But it should be noted that they can be revoked in the cryptographic sense. A DID method specification has to specify how the termination is performed, for example, by writing a null DID document.
DIDs and Privacy by Design
Privacy is an essential component of any identity management solution. It’s especially critical for a global identity system using an immutable public blockchain. Fortunately, the DID architecture can incorporate Privacy by Design at the lowest levels of the infrastructure and thus becomes a powerful, new, privacy-preserving technology when deployed using best practices such as:
✅ Pairwise-pseudonymous DIDs
DIDs can be used not only as public identifiers but also as private ones issued on a per-relationship basis. Thus, instead of a person having a single DID, such as a cell phone number or national ID number, he may have thousands of pairwise-unique DIDs that can’t be correlated without his consent yet can be managed as quickly as an address book.
✅Off-chain private data
Storing Pll of any type on a public blockchain, even if encrypted is hashed, is dangerous for two reasons: 1) the encrypted or hashed data is a global correlation point when multiple parties, 2 use the data) if the encryption is eventually broken (for example, quantum computing), the data will always be available on an immutable public ledger. Therefore, storing all private data off-chain and exchanging it only over encrypted, private, peer-to-peer connections is better.
✅Selective disclosure
The decentralized PKI (DPKI) that DIDs make possible opens the door for people that gain more control over their personal data in two ways. First, it allows you to transfer it using encrypted digital credentials. Secondly, these credentials can use zero-knowledge proof cryptography for data minimization; for example, you can indicate that you are over a certain age without revealing your exact date of birth.
Economics of DIDs
Now let’s look at the ecosystem of DIDs from an economic perspective. It includes identifying the stakeholders involved in the production, distribution, and consumption of DIDs and their rational decisions.
The DID ecosystem consists of the following actors:
- Users are the owners of DIDs and the Holders and Subjects of Verifiable Claims.
- Service Providers: the platforms, websites, and mobile apps that act as Inspector-Validators of claims.
- Claim Issuers: the companies, government agencies, and organizations that provide Claims about any number of Subjects.
- Technology Providers: These companies would be required to build out the DID ecosystem on behalf of other actors.
These categories don’t differ in the real world. Companies like Facebook and Google are Service Providers, Issuers, and Technology Providers, and often government agencies like the DMV act as Service Providers and Issuers. However, this segmentation is still proper because the choices of one of these roles determine the overall decision-making.
DIDs and Verifiable Credentials
The verifiable credential is a term for a digitally signed electronic credential that conforms to the interoperability standards developed by the W3C Verifiable Claims Working Group.
The DID can identify various entities in the Verifiable Credentials ecosystem, like holders, issuers, subjects, and verifiers. In general, DIDs can be used as Identifiers for people, organizations, and devices.
Let’s see the three pieces involved in the use of Verifiable Credentials:
- Subject: a user, but it could also be a pet, company, or anything else that can be described.
- Issuer: an organization, like the DMV, a university, a bank, etc.
- Claim: any statement that could be descriptive. The examples are usually about people and include things like “has this name” or “ lives at this address…”.Therefore, a Verifiable Claim is when an Issuer makes a Claim about a Subject. The Verifiable Claims specification defines two more roles as well:
- Holder: someone who owns the credential and stores it in the digital wallet.
- Verifier: a service, like BevMO or Facebook, that receives Verifiable Claims to use as part of their service.
To clarify all these terms, let’s see an example. So imagine you would like to buy liquor from BevMo, and BevMO would like to know if you are 21 years or older. You will use a Verifiable Claim from the DVM ( the Issuer) that says that Adam Powers (the subject) is over 21 (the claim). You will download that Verifiable Claim document from the DMV ( Adam Powers is now the holder) and then upload it to BevMO (the Issuer-Verifier). BevMO will validate that claim and allow you to buy liquor.
How Decentralized Identifiers Differ From Other Globally Unique Identifiers
Globally unique identifiers don’t require a centralized registration authority. Thus the need for it is not new. Universally Unique Identifiers (UUIDs), also known as Globally Unique Identifiers (GUIDs), were developed for this purpose in the 1980s and standardized first by the Open Software Foundation and then by IETF RFC 4122.
The need for persistent identifiers is not new as, well. These identifiers can be assigned once to an entity and never change. The class of identifiers was standardized as URNs (Uniform Resource Names), first by IETF RFC 2142 and later by RFC 8141.
However, as a rule, UUIDs aren’t resolved globally, and URNs -if resolvable- require a centralized registration authority. Also, neither UUIDs nor URNs inherently consider a third characteristic, the ability to verify ownership of an identifier cryptographically.
For self-sovereign identity, also defined as a lifetime portable digital identity that doesn’t depend on any centralized authority, there is a need for a new class of identifier that fulfills all four requirements such as global resolvability, persistence, cryptographic verifiability, and decentralization.
Conclusion
We have covered all the information you need about the Decentralized Identifiers. Let’s wrap up the main points of this article once more:
- DIDs enable private and secure connections between two parties and can be verified anywhere at any time.
- Verifiable credentials also include DIDs to be used for multiple cases worldwide.
- Each party – an individual or organization – can create as many various DIDs as they wish.
- DIDs allow people to store, manage and submit verified claims easily.
To sum up, the interoperability of Decentralized Identifiers would allow individuals and organizations to prove their identity across all blockchains, software providers, and web apps.
Thus, DIDs have considerable potential and are already changing how we think about our digital identity.
