- What are Decentralized Identifiers (DID)?
- Special features of Decentralized Identifiers (DID)
- How is a Decentralized Identifier (DID) formed?
- Introduction to the architecture of Decentralized Identifiers (DID)
In this third guide, we will explain how one of the pillars of Self-Sovereign Identity, the Decentralized Identifiers (i.e. DID), works. We will just review what we have introduced in previous guides.
We have seen that there are three existing Identity Management models.
The first is called the “Silos Model”, which is completely centralized and fragments our digital identity between the different organisations with which we interact. This model uses security standards such as https, SSL and TSL. The second model is called “Federated or Third Party IDP”, which is based on Identity Providers, such as Facebook or Twitter, which guarantee the identity of the user. This model in turn uses security standards such as SAML, OAuth and OpenID Connect.
We have seen how the models mentioned can have potential risks and weaknesses in terms of security, privacy and control.
The third model is defined as ‘Self-Sovereign Identity’ (SSI), which is based on distributed ledger (i.e. blockchain) and other more traditional techniques to create a system in which a user is completely ‘in control’ of their data. Compared to the two approaches listed above, SSI is based on the idea of peer-to-peer and non-account-based connections. The tool that allows such connections is the cryptographic wallet. This model also has standards in order to function and be secure: the first of these is decentralized identifiers (DID), a new type of ‘identifier’.
Just to get the general picture right, the other standards used are Verifiable Credentials, DKMS and DID Auth. The other three standards will be addressed in the next guides.
What are Decentralized Identifiers?
A DID is a constituent element of a new level of decentralized identity that has four properties:
But let’s go by order.
According to the W3C definition, a DID is a new type of identifier: i.e. no more than an alphanumeric string that identifies a resource. By resource we mean any object that can be identified, from a web page to a person to a planet. This string looks very much like any other Web address, except that it starts with “did:” and not “https:” or “http.
If we want to be more technical, a DID is a type of URI (Uniform Resource Identifier) .
A URI is a string of characters that identifies an abstract or concrete resource in a specific and unique format. Each resource has one and only one URI, each URI has one and only one resource. Within the set of URIs are URLs (Uniform Resource Locators) and URNs (Uniform Resource Names).
A URL is a subclass of URI that is used to locate a resource by its location on the Web. For example, the page you are reading right now is a resource that is a specific page on the selfsovereignidentity.it website. Every Web page, file, image, video, has its own URL. It is not “on the Web” if it does not have a URL and is often called a ” representation”. The addresses displayed in the browser’s address bar are generally URLs. The important factor is that these identifiers can change.
Meanwhile the second subclass of identifiers are defined as URNs and are used to identify a resource by its ‘name’. An example of URN is the ISBN: this uniquely identifies a book, but does not give us any information about the location of the book or where it is located on the network. The main factor is that this identifier cannot change over time.
Having described URI, URL and URN, we can be more precise about the definition of DID.
If we want to be more technical, a DID is a type of URI (Uniform Resource Identifier) .
A DID is a URN that can be ‘searched’ (technically defined as resolved) to obtain a standardized set of information about the resource that is identified by the DID. By resource, we can think of a person, an association/collective body or an object. So the information related to the DID is information related to persons, associations/collective bodies or objects. Clear, isn’t it?
The particularity of Decentralised Identifiers
However, this definition captures only two of the four properties of a DID, namely persistence and resolvability. For the third property – cryptography -, a DID is associated with a pair of cryptographic keys (public key and private key) and the holder of the private key can prove to be the controller of the DID. If you have already had some experience with bitcoins or cryptocurrency wallets, you will know that the private key is the secret that allows you to spend your bitcoins, while the public key is the alphanumeric code that you show to third parties in order to receive new bitcoins.
Finally, these private and public keys use the blockchain as a ledger or shared source of truth to demonstrate to third parties your control, without relying on centralized ledgers. This is the same process by which the wallets for bitcoin or other cryptocurrencies are created, and it is how it all works without a centralized counterpart.
How is a Decentralised Identifier formed?
At this stage, we have understood that a DID is nothing more than an alphanumeric code representing a generic resource. I will have a DID and you will have a DID that is different from mine. This code has a very specific scheme and is made up of three parts, namely “Method”, “DID Method” and “Method Specific-Identifier”.
- The first part is called Scheme and is nothing more than the prefix “did:”
- The second part is defined as DID Method. This second part is very important because it identifies on which decentralized ledger or blockchain this DID was resolved. For example, if it is resolved on the Bitcoin blockchain it will be expressed as “did:btcr”.
- The third part is defined as the Method Specific-Identifier and is the extension that characterises the DID for the specific resource (my DID, your DID). For example, my specific DID for bitcoin might be the following did:btcr:13n29cn30cn3ncr84dc.
A completely generic DID is reported as:
Each DID is registered autonomously, directly by the owner within permissionless and/or permissioned blockchains. There are no intermediaries, which is why it is called Self-Sovereign Identity. Each user is completely sovereign of himself and his own identity.
The Decentralized Identifier Architecture
We have therefore understood that a DID has a very specific form and that the creation process is completely autonomous and does not require a centralized counterpart. But actually, how does it enable the concept of Self-Sovereign Identity?
Let us imagine the DID as the identification code of our driving licence. The big difference is that this code is not provided by the DMV, but it will be us who tell the DMV that the DID “example” will belong to a particular person (myself). This has to do with the concept of connection and being able to decide how to connect. The SSI is based on the idea that an individual can open several channels of private communication with third parties such as people, collective entities and objects. This is the fundamental mechanism to be understood and brought home to us.
Lastly, we must specify that there are different types of DID, precisely because, as we have seen above, the latter is a generic identifier.
For example, there is a DID that is defined as “DID Subject” and a DID that is defined as “DID Controller”. An example to explain the difference could be the following: when a parent checks a DID that identifies his or her own children,: the “DID Subject” is the child but the “DID Controller” (at least until the child has reached the age of majority) is the parent. However, when the child comes of age he/she will become both “DID Subject” and “DID Controller”. In addition, this information (i.e. who controls or who is the subject) is included in a particular document which is called a “DID Document”. Each DID has its own “DID Document” where there is a standardised data structure that provides specifications and metadata associated with the DID. There is also the “DID Resolver” which is a software and/or hardware component that takes a DID (and associated options) as input and produces a compliant “DID Document” (and associated metadata) as output. This process is called “DID Resolution”. Finally, there are also “DID URLs” which take the syntax of DIDs and associate a URL in the “Method Specific Identifier” from which information can be extracted from the Web regarding the DID itself.
It should also be noted that a generic user may potentially have several DIDs, depending on the number and confidentiality of the links they wish to make.
We conclude this guide by reminding the reader that a DID is a unique and persistent identifier, which, unlike a URI, uses cryptography and decentralisation (via blockchain) to generate itself and to make the process completely autonomous and ‘sovereign’. Finally, let us remember that a DID can also identify objects, companies or collective entities. In the next guide, we will explain the second fundamental pillar of Self-Sovereign Identity, namely Verifiable Credentials.