A decentralized identity or identifier (DID) is nothing more than a scheme with several attributes that uniquely defines a person, object, or organization. Conventional identity management systems are based on centralized authorities, such as corporate directory services or certificate authorities. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority.
The emergence of blockchain technology provides the opportunity to implement fully decentralized identity management (DIDM). In DIDM, all identity owners share a common root of trust in the form of a globally distributed ledger.
Each DID record is cryptographically secured by private keys under the identity owner’s control. It is believed to be the missing link to redefine the security values of the Internet, as it can become the identity layer of the Internet. The specification for DIDs is being created by the World Wide Web Consortium (W3C).
Markus Sabadello, co-author of the DID spec and CEO of Danube Tech, explained the general benefits of using DIDs:
DIDs are controlled exclusively by the entity they refer to and therefore are a fundamental building block for what is generally known as "self-sovereign identity" or "decentralized identity".
Imagine having a phone number that is not assigned to you by your mobile operator, but instead, you choose it yourself. Anyone in the world can still call you, and no one could ever take that phone number away from you - DIDs are similar to this situation.
Technically, DIDs are valid Uniform Resource Identifiers (URIs), therefore they are compatible with many general-purpose web technologies. They are not limited to a single use case or protocol.
Another benefit is that DIDs are designed to work with different blockchains and other target systems, therefore providing interoperability.
DIDs can be used to identify any digital or real-life resource, such as a document, an individual, a company, or a physical object. Generally, a DID by itself doesn't prove uniqueness, or anything else about its owner. A DID is merely an identifier. You can, and in many cases should, have multiple DIDs for different purposes, relationships, and transactions.
However, even though a DID by itself doesn't provide much information about the owner, you can use protocols on top of DIDs to verify a number of things. To simply prove that you control a certain DID, and to use it (e.g., to log in to a website), you can use a challenge/response protocol called DID Auth. This fulfills a similar function for "decentralized identity" as OpenID Connect and others do for "federated identity".
In order to prove more complex facts about a DID's owner, such as one's age, possession of a valid driver's license, or membership in an organization, you can use Verifiable Credentials, which are being standardized by the W3C.
Verifiable Credentials are claims attested to by an issuer about a DID. They can then be used as a proof by the DID's owner during a transaction. There is no limit to the scope and semantics of claims that can be associated with a DID; they can be as rich as all of our real-life human and organizational identities that make up our societies.
Many variants are possible for a DID. The complete specifications file can be found at W3C. Below is one possible way to define a DID. What we see here is a simple definition of a DID with the creation date, the date on which document has been updated for the last time, signature field (optional), and “authorizationCapability”. This last field contains objects referring to other DIDs who get a specific permission over this DID. For example, DID with ID 215cb1dc-1f44-4695-a07f-97649cad9938 receives the permission to update this DID.
Source: W3C - https://w3c-ccg.github.io/did-spec/#requirements-of-did-method-specifications
The “signature” field is often misunderstood. The "signature" field only proves that the DID Document has not been tampered with and that the signer controlled a certain private key at the time it was signed. However, the signature does not prove that the signer is the actual DID owner. So, while it can be an additional security feature, it cannot be relied on by itself when working with DIDs. It’s similar to the process of staking a PGP key publicly on the Bitcointalk.com forum to prove you owned that key linked to your Bitcointalk account.
Markus Sabadello has stated that the “permission” field is the unstable element in the DID spec and will probably be removed. Its intention is to express permissions regarding who can update the DID Document. However, there are a few problems with this:
Source: W3C - https://w3c-ccg.github.io/ld-ocap/
The simplest example is logging into websites. You would have a digital wallet that stores your DIDs and associated keys, and you could use a browser plugin or app that pops up and asks for confirmation when you are logging in. The idea is a bit comparable with the MetaMask plugin, but less advanced.
Another example is "Bring Your Own Identity" when shopping online. You could buy a book at an online store and when checking out, you just supply your DID (again using a plugin or app). This way you would be able to share your shipping address and payment information without even having to create an account with the store's website. We can even draw the line to the physical world where we link a customer loyalty card, which we get in every store to obtain a small discount, to the ID field of our Decentralized Identifier.
Finally, a more advanced example is a distributed address book. You could stay connected to your friends, as well as businesses you care about, and share your personal address and other profile information with them, with full control, transparency, and data portability. Every time your profile information changes, your connections can be automatically notified. DIDs enable lifelong connections between DID owners that no one can take away from you.
To understand how DIDs enhance security, we first need to get familiar with what a Public Key Infrastructure (PKI) is. A PKI is used primarily for encrypting and/or signing data. Encrypting data refers to scrambling it in a way that makes it unreadable except to authorized persons. The PKI is based on a mechanism called a digital certificate, also referred to as X.509 certificates. Think of a certificate as a virtual ID card. A PKI is also referred to as a certificate authority (CA). For example, VeriSign is a well-known CA for creating a web of trust by offering SSL/TLS certificates signed by them.
As a PKI uses a centralized database for storing this info, we can then think of DIDs as a decentralized variant of PKIs. DIDs form the basis for a Decentralized Public Key Infrastructure (DPKI).
This means that all data sharing and messaging between DIDs is authenticated and encrypted using cryptographic keys associated with a DID, similar to traditional PKIs, but without the drawbacks of traditional certificate authorities.
There are numerous examples where, in the past, the existing TLS certificate architecture used by web servers has turned out to be vulnerable to censorship and manipulation. With DIDs, this threat of intermediaries can be eliminated, as every DID represents its own "root of trust". This means that they don't have to be controlled and issued by central authorities in order to be trusted.
Another important security feature is that DIDs are persistent. This means that the cryptographic keys associated with a DID can be securely rotated and revoked through various mechanisms, without having to create a new DID. We will delve more into this “revoking” aspect under the next subheading.
The latest version (v0.7) of the W3C spec on Decentralized Identifiers discusses the different DID operations under which we can find “Delete/Revoke”. This is pretty strange as decentralized ledger technologies (DLTs) are immutable by nature. Let’s explore this aspect further.
Once an initial transaction has been issued to create the DID, further transactions can update, and also "revoke" or "terminate", the DID. Even though the history of a DID may be append-only and exist infinitely, the current state of the DID is defined by the cumulative sum of all transactions.
If a special transaction is added to that history, then that marks the DID as "revoked". Also, note that while DLTs have useful properties that make them suitable for DID creation and storage, DLTs are not the only possible technology for DIDs. DIDs can also be created using decentralized hash tables (DHTs), distributed file systems (IPFs), databases (BigchainDB), or other decentralized networks.
There are still some open issues, but the W3C workgroup for DIDs expects to publish a relatively stable Implementer’s Draft by March or April of 2018. Arriving at a finished W3C standard is a much longer process that they cannot predict yet.
In addition, W3C are also developing tools, like the Universal Resolver, that acts as an identifier resolver and works with any decentralized identifier system. Implementations are available for Java and Python3 programming languages.
Markus Sabadello stated “Those of us who are working on DIDs are experiencing an incredible amount of interest in this technology from all over the world. We think of DIDs as nothing less than finally having the opportunity to realize the "missing identity layer" of the Internet." DIDs have the potential to replace much of the current Internet identity infrastructure, including things like usernames, domain names, certificate authorities, and centralized identity services like "Log in with Facebook". It may take some time to adapt to this "decentralized identity" paradigm, but it will become a better basis for how authentication, data sharing, and messaging will work.
The emergence of blockchain technology provides the opportunity to implement fully decentralized identity management (DIDM). In DIDM, all identity owners share a common root of trust in the form of a globally distributed ledger.
Each DID record is cryptographically secured by private keys under the identity owner’s control. It is believed to be the missing link to redefine the security values of the Internet, as it can become the identity layer of the Internet. The specification for DIDs is being created by the World Wide Web Consortium (W3C).
Advantages of DIDs
Markus Sabadello, co-author of the DID spec and CEO of Danube Tech, explained the general benefits of using DIDs:
“DIDs are an important innovation because they give us the ability to establish digital identifiers that are persistent, secure, and globally resolvable, yet their creation does not require a central authority or intermediary.”
DIDs are controlled exclusively by the entity they refer to and therefore are a fundamental building block for what is generally known as "self-sovereign identity" or "decentralized identity".
Imagine having a phone number that is not assigned to you by your mobile operator, but instead, you choose it yourself. Anyone in the world can still call you, and no one could ever take that phone number away from you - DIDs are similar to this situation.
Technically, DIDs are valid Uniform Resource Identifiers (URIs), therefore they are compatible with many general-purpose web technologies. They are not limited to a single use case or protocol.
Another benefit is that DIDs are designed to work with different blockchains and other target systems, therefore providing interoperability.
What are the uses of DIDs?
DIDs can be used to identify any digital or real-life resource, such as a document, an individual, a company, or a physical object. Generally, a DID by itself doesn't prove uniqueness, or anything else about its owner. A DID is merely an identifier. You can, and in many cases should, have multiple DIDs for different purposes, relationships, and transactions.
However, even though a DID by itself doesn't provide much information about the owner, you can use protocols on top of DIDs to verify a number of things. To simply prove that you control a certain DID, and to use it (e.g., to log in to a website), you can use a challenge/response protocol called DID Auth. This fulfills a similar function for "decentralized identity" as OpenID Connect and others do for "federated identity".
In order to prove more complex facts about a DID's owner, such as one's age, possession of a valid driver's license, or membership in an organization, you can use Verifiable Credentials, which are being standardized by the W3C.
Verifiable Credentials are claims attested to by an issuer about a DID. They can then be used as a proof by the DID's owner during a transaction. There is no limit to the scope and semantics of claims that can be associated with a DID; they can be as rich as all of our real-life human and organizational identities that make up our societies.
Example DID Structure
Many variants are possible for a DID. The complete specifications file can be found at W3C. Below is one possible way to define a DID. What we see here is a simple definition of a DID with the creation date, the date on which document has been updated for the last time, signature field (optional), and “authorizationCapability”. This last field contains objects referring to other DIDs who get a specific permission over this DID. For example, DID with ID 215cb1dc-1f44-4695-a07f-97649cad9938 receives the permission to update this DID.
Source: W3C - https://w3c-ccg.github.io/did-spec/#requirements-of-did-method-specifications
The “signature” field is often misunderstood. The "signature" field only proves that the DID Document has not been tampered with and that the signer controlled a certain private key at the time it was signed. However, the signature does not prove that the signer is the actual DID owner. So, while it can be an additional security feature, it cannot be relied on by itself when working with DIDs. It’s similar to the process of staking a PGP key publicly on the Bitcointalk.com forum to prove you owned that key linked to your Bitcointalk account.
Markus Sabadello has stated that the “permission” field is the unstable element in the DID spec and will probably be removed. Its intention is to express permissions regarding who can update the DID Document. However, there are a few problems with this:
- Different kinds of DIDs (DID methods) have very different ideas and possibilities regarding how to manage updates. Any authorization information about DID updates should be specified by those specific DID methods, rather than mandating this in a universal way for all DIDs.
- Instead of traditional access control lists for expressing permissions, we have been looking at an alternative model called object capabilities. This is an example of this specification which is very similar to DIDs.
Source: W3C - https://w3c-ccg.github.io/ld-ocap/
Use cases
The simplest example is logging into websites. You would have a digital wallet that stores your DIDs and associated keys, and you could use a browser plugin or app that pops up and asks for confirmation when you are logging in. The idea is a bit comparable with the MetaMask plugin, but less advanced.
Another example is "Bring Your Own Identity" when shopping online. You could buy a book at an online store and when checking out, you just supply your DID (again using a plugin or app). This way you would be able to share your shipping address and payment information without even having to create an account with the store's website. We can even draw the line to the physical world where we link a customer loyalty card, which we get in every store to obtain a small discount, to the ID field of our Decentralized Identifier.
Finally, a more advanced example is a distributed address book. You could stay connected to your friends, as well as businesses you care about, and share your personal address and other profile information with them, with full control, transparency, and data portability. Every time your profile information changes, your connections can be automatically notified. DIDs enable lifelong connections between DID owners that no one can take away from you.
DIDs enhance security
To understand how DIDs enhance security, we first need to get familiar with what a Public Key Infrastructure (PKI) is. A PKI is used primarily for encrypting and/or signing data. Encrypting data refers to scrambling it in a way that makes it unreadable except to authorized persons. The PKI is based on a mechanism called a digital certificate, also referred to as X.509 certificates. Think of a certificate as a virtual ID card. A PKI is also referred to as a certificate authority (CA). For example, VeriSign is a well-known CA for creating a web of trust by offering SSL/TLS certificates signed by them.
As a PKI uses a centralized database for storing this info, we can then think of DIDs as a decentralized variant of PKIs. DIDs form the basis for a Decentralized Public Key Infrastructure (DPKI).
This means that all data sharing and messaging between DIDs is authenticated and encrypted using cryptographic keys associated with a DID, similar to traditional PKIs, but without the drawbacks of traditional certificate authorities.
There are numerous examples where, in the past, the existing TLS certificate architecture used by web servers has turned out to be vulnerable to censorship and manipulation. With DIDs, this threat of intermediaries can be eliminated, as every DID represents its own "root of trust". This means that they don't have to be controlled and issued by central authorities in order to be trusted.
Another important security feature is that DIDs are persistent. This means that the cryptographic keys associated with a DID can be securely rotated and revoked through various mechanisms, without having to create a new DID. We will delve more into this “revoking” aspect under the next subheading.
Delete or revoke DID
The latest version (v0.7) of the W3C spec on Decentralized Identifiers discusses the different DID operations under which we can find “Delete/Revoke”. This is pretty strange as decentralized ledger technologies (DLTs) are immutable by nature. Let’s explore this aspect further.
Once an initial transaction has been issued to create the DID, further transactions can update, and also "revoke" or "terminate", the DID. Even though the history of a DID may be append-only and exist infinitely, the current state of the DID is defined by the cumulative sum of all transactions.
If a special transaction is added to that history, then that marks the DID as "revoked". Also, note that while DLTs have useful properties that make them suitable for DID creation and storage, DLTs are not the only possible technology for DIDs. DIDs can also be created using decentralized hash tables (DHTs), distributed file systems (IPFs), databases (BigchainDB), or other decentralized networks.
Status of DID specification
There are still some open issues, but the W3C workgroup for DIDs expects to publish a relatively stable Implementer’s Draft by March or April of 2018. Arriving at a finished W3C standard is a much longer process that they cannot predict yet.
In addition, W3C are also developing tools, like the Universal Resolver, that acts as an identifier resolver and works with any decentralized identifier system. Implementations are available for Java and Python3 programming languages.
Future and final thoughts:
Markus Sabadello stated “Those of us who are working on DIDs are experiencing an incredible amount of interest in this technology from all over the world. We think of DIDs as nothing less than finally having the opportunity to realize the "missing identity layer" of the Internet." DIDs have the potential to replace much of the current Internet identity infrastructure, including things like usernames, domain names, certificate authorities, and centralized identity services like "Log in with Facebook". It may take some time to adapt to this "decentralized identity" paradigm, but it will become a better basis for how authentication, data sharing, and messaging will work.