Skip to main content

Decentralized Identifiers (DIDs)

This page introduces the concept of Self-Sovereign identity (SSI), the components of Decentralized Identifiers (DIDs) and verifiable credentials (VCs), and how they provide the mechanisms for identity access and management for the Elastos protocol.

Self-Sovereign Identity (SSI)

'Self-Sovereign Identity’ is a growing paradigm that promotes an individual’s control over their identity and their data. This is in contrast to the current paradigm where most of our official identifiers (driver’s license, birth certificate, usernames, etc.) are given to us and maintained by a central authority, and where our data can be shared without our knowledge or consent.

The SSI movement catalyzes the shift away from stratified, centralized authorities as the distributors and overseers of identity, and toward a system where individuals can maintain their own identity and where verification and data-sharing can occur via secure, digital consent.


Self-sovereign identity (SSI) is a term used to describe the digital movement that recognizes an individual should own and control their identity without the intervening administrative authorities. SSI allows people to interact in the digital world with the same freedom and capacity for trust as they do in the offline world.

Components of SSI

Decentralized identifiers (DIDs) and Verifiable Credentials (VCs) are two of the most important components of SSI.

A DID is an identifier that can be generated and controlled by individuals or organizations without an external authority. It can be used to identify any subject, such as a non-tangible asset, a customer, or an organization.

A Verifiable Credential is a secure and machine-verifiable digital credential which respects a standard data model. Together they allow users and organizations to have control over their identities. Instead of an external authority maintaining control over an identifier and its associated identity data, any individual or asset can create an identity, and then establish credentials over time through interactions with peers or authorities on a trusted, decentralized network.

Both DIDs and VCs are specifications of the W3C. The W3C is an organization which provides core technical specifications to establish guidelines and best practices for an open, inclusive and trustworthy web. Energy Web’s approach to DIDs and VCs is sufficiently abstract and flexible that it can be used with the Energy Web Chain, another blockchain, or no chain at all.

Decentralized Identifiers (DIDs)

A DID is an identifier that is user-generated and not coupled to any centralized authority. It can be used to identify any subject, such as a non-tangible asset, a customer, or an organization.

Unlike traditional forms of identification, DIDs are not generated by a central authority, such as a government-issued driver’s license, or a bank-issued account number, and they are not stored in a centralized database. A user can create a DID for themselves or an asset using cryptographic or other means.

A DID for a given system resides in a decentralized DID registry. DID Registries, like VCs and DIDs themselves, are developed according to W3C standards. Most DID registries live on a decentralized ledger, or a blockchain. In the case of Elastos, the DID registry is on the Elastos Identity Chain (EID).

How are DIDs created?

A DID is derived from a public-private key pair that is generated programmatically through a cryptographic algorithm. The algorithm produces a private key and a corresponding public key. Crypto wallets such as MetaMask will generate these keys for you on creation of an account. The public key can be exposed and shared with others, but the private key should not be shared with anyone. The algorithm used to generate the key-pair makes it virtually impossible for any outsider to guess your private key.

Your public key serves as your address on the blockchain, and your private key serves as your private identifier, similar to a password, and is used to sign transactions on the blockchain. The signature is proof that you initiated that transaction.

DID Format

DIDs are made up of a scheme, a method and a unique method identifier. There are many DID methods that are supported by different blockchain networks. You can see a full list here. DID methods define operations to create, resolve, update and deactivate DIDs and their associated DID Documents, which are discussed below. DID Methods are often associated with a verifiable data registry, which are registries with store DIDs and their data. If the registry is implemented on a blockchain, smart contracts usually serve as the data registry. An example of this is the did:ethr registry.


DID Document

DID Documents Every DID resolves to a corresponding DID document, which contains metadata about the subject's authentication mechanisms and attributes, like its public key.

Below is a sample JSON document that was created by the EW-DOS DID library. For a list of required and possible DID Document properties, see the W3C documentation on DID Document Properties.


Verifiable Credentials

Above we discussed the role of identity. Once an identity is established, it exists in a DID registry, but nothing is known about the subject through a digital identity alone. That is where Verifiable Credentials come into play.

A credential is something that we can prove about a subject or individual. Common examples of credentials include a driver's license, that proves that one has passed a test and can drive a particular class of vehicle, or a passport, that proves one is approved to travel internationally until a specified date in the future. These traditional credentials are authorized and issued by a central authority, such as a government bureau or a bank. They are distinct and not interchangeable. For example, you cannot use your passport to show that you can drive a car, and you cannot show your driver's license to prove that you can travel.

What is a Verifiable Credential?

Like traditional credentials, VCs are statements or claims made about an identity, which is referred to as the credential subject. If a battery was the credential subject, it could have a verifiable claim that it originated in a particular manufacturing plant, or that it has a specific discharge rate at the time of manufacturing.


Verifiable Credentials are a Web3 standard for digital credentials in a decentralized ecosystem, meaning a system with no central issuer or authority.

Issuers, Holders, Verifiers

There are three primary actors in the facilitation of Verifiable Credentials.

  • Issuer: makes a claim about a credential subject and correspondingly creates and issues credentials asserting the claim.
  • Holder: receives, holds and shares credentials
  • Verifier: receives and verifies proofs (proofs can be the entire credential or a piece of info from the credential)

Credential Verification

The main difference between traditional, non-digital credentials and verifiable credentials are the way they are verified.

Traditional credentials require manual verification, such as a signature or a stamp. Verifiable Credentials are verified completely through cryptographic means using a digital proof mechanism, such as a digital signature or a JSON Web Token, through a digital trust mechanism, such as a blockchain.

In the context of EW-DOS, a digital cryptocurrency wallet such as MetaMask, which holds a user’s public and private keys, is used to facilitate a digital signature. This eliminates the need for any interaction between the issuer and the verifier. The blockchain provides the platform and mechanisms of trust.

Once an authority verifies a claim, a VC can then be used as an official record to assure others of the truth of the statements. These credentials are linked back to the credential subject’s digital identity. In the case of EW-DOS, credentials are linked back to the user's DID document. A DID Document can amass a rich set of Verifiable Credentials that provide a full picture of its origin, attributes and capabilities.


To see a more exhaustive list of possible interactions and use cases for issuers, holders and verifiers, see w3’s list of Verifiable Credential use cases.