Decentralized Identities

Identities, DIDs, DID Documents and Verifiable Credentials

This article should sharpen the understanding for what an identity is and how the representation of it on a decentralized platform can be of use.

What is an identity?

One possibility is to represent the smallest set of properties which enables to distinguish every person from another. That is the way an identity is represented on a german identity card. Does an identity card like the german identity card for example reflect your complete identity, a part of your identity or not your identity at all? When one does think about that, a question like this is usually raised: What is about the other values that also define a person, like hobbies, favorite drinks or food, dreams, qualifications, etc.?

Most times what we tell about our identity differs depending on the context: At a job, professional qualifications are presented as a part of the own identity, off the job one usually does present this part of the identity rarely. Depending on the situation and people we meet, our identity is perceived differently because distinct information were shared.

Something like a static identity does not exist, since we human people change continuously and define ourselves differently. Think about favorite food and drinks, which change during the lifetime of most people. Further, our identity also depends on the social context we live in and stay in at that time.

How does one get an identity?

Germany defined a couple of legal ways for citizens to retrieve an identity card. As shown in the last section, such an identity card does not represent a final and complete identity of the person, but it describes a set of properties that allows to differentiate the person from any other person.

Example: Legally approved issuance of an identity card after birth in Germany

After birth the birthplace hands over a certificate of birth to the parents of the newborn child. The certificate of birth can be used to request an identity card from the state after the child aged a bit. The identity card contains properties that allow to differentiate the person from any other person. Those properties include immutable properties (e.g. date of birth) and mutable properties (e.g. height). The identity card also contains a unique identifier, which allows to refer to it.

Example: Legally unapproved issuance of an identity card after birth in Germany

After birth the parents take a card and write properties of their child on it. Those properties are identical to the properties on an identity card. To create an unique identifier they can concatenate the properties or alternatively flip a coin 256 times (for each bit on time).

Comparison of both procedures of issuing an identity card

Whether the document was created compliant to the law or whether the parents created the document mirroring the legal counterpart is irrelevant regarding the information about the person contained on the document. Both documents contain the same information. However, there is significant difference: German citizen agree about that a central authority does issue an identity card containing true information. This assumption is supported by the fact, that the civil servants who issue an identity card have obligated themselves to act according to the law. The identity card does supply a signature from the state, which is relatively difficult to imitate. Thus, the legally unapproved identity card described above does only differ from the legally approved identity card by a signature from an instance that we trust. A trustworthy signature transforms the identity card into a certificate.

Advantages of the current process of issuance

• The parts of the identity are usually correctly represented on the identity card.

Disadvantages of the current process of issuance

• The whole power of deciding which identity a person does embody is located exclusively at a central authority (disproportionateness of power).
• Not everybody has the chance to receive an attested identity card, since not every country does issue an attested identity card.

Decentralized Identity

The World Wide Web Consortium (W3C) is an organization that supports open standards [1]. All concepts defined in the following sections were proposed by W3C.

Definition: DID
A decentralized identifier is a sequence of characters, which is worldwide unique and cryptographically verifiable [2].

A decentralized identifier is comparable to an identification number of an identity card, differing in the property that it is unique worldwide (emphasis on “worldwide”) and cryptographically verifiable. The owner of the identity card can use the signature, which had to be attached to the registration for an identity card, to authenticate and engage in legally valid contracts. The signature should be unique for each person. The owner of a DID can authenticate as such as well by using a signature, however, the signature is based on a digital secret and cryptography instead of physical drawings. While the identification number of an identity card references the identity card, a DID references the so called “DID Document”:

Definition: DID Document
A DID Document is a resource which is associated with a decentralized identifier. The DID Document usually phrases methods of verification and services, which are offered by the entity represented by the DID Document [3].

The layout of an DID Document offers much flexibility. For example, a DID Document can contain multiple agents (persons and machines), who are permissioned to act in specific cases in the name of the identity behind the DID Document (for example an organization). Additionally, addresses to services like communication, certificate submission and contracting can be supplied, which can be used to further interact with permissioned agents.

First principles

DID Documents have been developed simultaneously with cryptocurrencies. Cryptocurrencies like Ethereum, which represent a decentralized computer by facilitating the decentralized execution of turing-complete code, allowed to implement a decentralized identity registry. Such a registry is used to map an address (should be unique per agent) to a DID which is ultimately mapped to a DID document. This information is stored publicly available in a distributed, decentralized and immutable blockchain. The simultaneous development was no coincidence, since some core-properties of the cryptocurrencies supported the philosophy behind decentralized identities:

1. Decentralized: Decentralized identities are worldwide redundantly distributed in storage media in a decentralized manner.
2. Immutable: A decentralized identity cannot be deleted or modified, the only way to change the information associated with it (within the DID Document) is to register an updated variant of the DID Document which becomes valid by a signature from an (group of) authorized agent(s). The complete history of the DID Document is permanent.
3. Open: Anybody with access to a computer and to the internet can create a decentralized identity.
4. Censorship-resistant: Nobody, expect the owner or an (group of) agent(s) which were authorized by the owner, can change the DID Document associated with the DID of the owner.

In summary, every agent has the right to create any number of decentralized identities (Open). The DID Documents, which represent the identity, are redundantly distributed in storage media in a decentralized manner (Decentralized). This (and some cryptography) is required to ensure that only the authorized agents can change their DID Document (Censorship-resistant). The changelog of a DID Document is preserved, therefore all changes made to the identity are traceable in the future (Immutable).

Note: The scenario during which one can create decentralized identities at will, whereas the ownership and the power of publication of (signed) information regarding the identity completely belongs to the owner of the identity, is called “Self-Sovereign Identity”.

Applying the first principles to the example presented in the last section, we come to following conclusion: In a state that uses such as system, everybody is able to create an identity card represented by a DID Document, whereas the (trustworthy) signature of the state is missing. So far, such a DID Document is about as credible as an identity card that was created by the parents of a child after its birth.

Everyone already creates identities for themselves

When we meet another person, we often share our name with them and therefore divulge a part of our identity (or to be more precise, a part of one of our identities). In a private setting this is usually trustworthy enough, the person believes that you supplied your real name. To support this claim, think about how often somebody you met in a private setting asked you to proof what your name is, for example by showing him a trustworthy certificate like an identity card. Another example takes place in the digital world: Many times, when you register for a service on the internet, you can freely choose under which identity you register, without being forced to prove your claims. Extrapolating the idea of freely registering an identity leads us to social media. In social media many people create an image of themselves that presents them as they like to be perceived. In many cases the presented identity is not completely in accordance with the real person behind it. As you can see, we already often (not explicitly knowingly) create (digital) identities and on many occasions this approach is enough.

When self-created identities are insufficient

Scenarios that require an identification and where self-created identities are insufficient to identify oneself are known to most people. Those scenarios arise, when a transaction (interaction based on a contract) with a legal entity is executed: Check the bus ticket, buy an article that has an age rating, conclude a contract. In such cases the legal entities involved in the transaction (often both) must show a certification for each aspect of the identity they use in that transaction. This way the validity of the presented identity (and therefore implicitly the rights and duties) can be verified. Example: A ticket inspector asks for your ticket in the bus (the transaction is “check bus ticket”). You verify that the ticket inspector is authorized to check your ticked by looking at his openly visible “ticket inspector ID” that was signed by the transport association. To prove that you are currently legally using the “bus riding” service of the transport association, you show your valid ticket that was signed by the transport association and if necessary additionally your identity card that was signed by the state. W3C also works on the concept of verifiable certificates in the digital and decentralized context. It is elucidated in the next subsection.

Establish Credibility: Verifiable Credentials

Definition: Verifiable Credential

A Verifiable Credential (VC) is a verifiable collection of claims from one identity (issuer) about another identity (subject). Verifiable Credentials must include metadata, which must in turn include at least a context (standard that the VC conforms to) and additional metadata that the selected context demands for. At least one cryptographic proof must be supplied, which can be used to verify the authenticity of the data within the VC [4].

Figure 1 shows the essential components of a Verifiable Credential.

Definition: Verifiable Presentation
A Verifiable Presentation (VP) expresses data from one or more VCs, and is packaged in such a way that the authorship of the data is verifiable [5].

For example, some identities issued Verifiable Credentials to you, which each proof that you are the owner of a specific domicile. If somebody wants you to proof to him that you are the owner of a specific domicile, you send him the Verifiable Credential, which turns into a Verifiable Presentation that he can finally use to verify that you are the owner of the domicile. Just as a side note, in a real scenario some information is added to the Verifiable Presentation to protect the subject against some attack scenarios. If an institution, for example the finance office, wants to know all the domiciles you own in a specific country, you would create a VP containing all the VCs of domiciles you own in that country.

The following subsections elaborate on the contents of a VC.

Credential Metadata

The metadata includes information that not directly concerns the subject of the VC. Instead, this information refers to the VC itself and often to the issuer. For Example: Which standard does the VC use? Who (human-readable name) has issued the VC? When was the VC issued? What is the type of the VC (e.g. domicile VC)?

Claims

Definition: Claim
A claim contains exactly one statement. The statement is of the following form: The property x of the entity y has the value z [6].

Claims can look like those for example (Each row is a claim):

Note: A value can also be a complex object (a whole new table), however in some situations it might be more practical to keep the values as simple as possible and to source the object out into a new VC. This way, more freedom is given in creating VPs (deciding which information you want to share).

Proofs

The proofs contain information, which are essential to verify the authenticity of the metadata and the claims. The most commonly used proofs include a date, a signature, the signature algorithm and a public key. This method is significantly more secure than its physical analog (e.g. a signature of a state). A VC contains at least one proof that can be used to verify the authenticity of all the metadata and the claims. Additional proofs that can be used to verify a subset of the metadata and claims can be added. Using such additional proofs within a domicile VC, the subject would potentially be able to create a VP which only shows the data in question, for example only the zip code. Since the issuer of the VC can freely select the proof algorithm, different proof scenarios can be covered. By using a zero-knowledge proof, one could proof that the value assigned to a property does fulfill specific (mathematical) conditions. Using such a proof in an identity VC, the subject would be potentially able to proof that he/she has reached a specific age, without revealing the exact age.

Example: Digital Identity Card

After the birth of a child a DID-Document will be created by the parents, which only contains an ID and public keys for cryptographic procedures (authentication, signing, encryption and decryption, etc.). The familiy does select the keys on their own, one key of the child as the owner and two keys of the parents as authorized agents. The responsible birthplace does own a temporarily valid VC from the state, which empowers them to issue valid birth certificates as a VC (let’s call it “birth-VC”). Sometime in the future the child is old enough to own an identity card. At this point the child can request an identity card in the form of a VC from the state. To do so, a valid application including the birth-VC and a valid signature by the childs key must be supplied. The state checks the application and after verification of the data and signatures decides to issue an identity card VC, which does contain the same information about the person on it like the previous physical identity card. The child can now use its identity card VC to show a certified view on part of his identity. For example, he/she can proof his/her age. Since the childs DID is associated with the identity card VC, and further the child owns the private key to the public key associated with the DID, it can digitally proof that it is the righteous owner of the identity card VC.

Example: Digital employee Smart Card

A person applies for a job at MaibornWolff. The application papers additionally contain the DID Document, an identity card VC, a proof that the person is the owner of the DID and lastly VCs from all organizations where the person enjoyed education or did work (qualifications). MaibornWolff accepts the application, invites the person to a job interview and finally signs a working contract. MaibornWolff issues a VC (let’s call it “MaibornWolff-Employee-VC”) for the (DID of the) new co-worker, which contains all relevant information (picture, department, room, job title, permissions, etc.). Using this MaibornWolff-Employee-VC, the new employee can authenticate as an employee at MaibornWolff. MaibornWolff flashes a SmartCard with the MaibornWolff-Employee-VC, which is handed out to the new employee afterwards. This SmartCard authorizes the employee to use internal services of MaibornWolff, like writing signed and encrypted E-Mails, opening freed doors, etc.

Sources

[1] Web3D Consortium, https://www.w3.org/
[2] W3C Standard, Decentralized Identifier (DID), https://www.w3.org/TR/did-core/#identifier
[3] W3C Standard, DID Document, https://www.w3.org/TR/did-core/#did-document
[4] W3C Standard, Verifiable Credential, https://www.w3.org/TR/vc-data-model/#credentials
[5] W3C Standard, Verifiable Presentation, https://www.w3.org/TR/vc-data-model/#presentations
[6] W3C Standard, Claim, https://www.w3.org/TR/vc-data-model/#claims

Thanks

Thanks goes to my co-workers at the DLT department of MaibornWolff GmbH for reading the article and giving me some feedback. Special thanks goes to Frank Polster for calling my attention on the DID and Verifiable Credential solution. Special thanks goes to Michael Olah and Frank Polster for their elaborate feedback.

---

About the author