Decentralized Identifiers – the internet’s “missing identity layer”
DIDs represent 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.
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).
Advantages of DIDsMarkus 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 StructureMany 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.