What is the role of Did Auth and Decentralised Key Management Systems?

• What is an Auth DID?
• What is a DKMS?
• The workflow for identity verification on SSI
• Why are they essential for SSI?

We are back with our fifth guide on Self Sovereign Identity where we will explain how DID Auth and Decentralized Key Management System (DKMS) work, the two additional technology pillars that, along with Decentralized Identifiers and Verifiable Credentials, are critical to the implementation of this new digital identity standard.

What is a DID Auth?

In the world of Self Sovereign Identity, one of the first questions users have to ask themselves is: but if there is no one to provide me with my identity, how do I prove to third parties that I exist? 

We have explained in previous guides that my digital identity is given by what other users say about me within a virtual world, where personal identity is characterised by decentralised identifiers (DID). A world of DIDs that connect to each other. More technically, we can imagine our identity as a functional identity that is determined by the verifiable credentials that third parties provide us with and the connections that our DID has created with other peers. However, the problem shifts. If I myself control and generate my own DID, how do I prove that this DID is controlled by myself and represents me? 

This is where the role of DID Auth comes in. 

The term DID Auth has been used in a number of different ways and currently has no specific definition. However, we can define DID Auth as a virtual ceremony in which an owner of a digital identity, with the help of various components such as web browsers and mobile devices demonstrates to a counterpart that has full control of a specific DID at that precise moment. Clearly, when talking about Auth DID, this includes the ability to establish mutually authenticated communication channels and/or the ability to authenticate via one’s DID via websites and/or digital applications. 

More technically, in order to demonstrate control of a DID towards a counterpart, a mechanism is used which is described and specified within what we defined in the last guide as DID documents. 

DID documents can be thought of as instruction booklets that accompany DIDs, within which there is various metadata that help counterparties to identify the counterparty during a connection. However, some of the information relating to identification methods involves Decentralised Key Management Systems (DKMS), so let’s go in order.   

What is a DKMS?

In the offline world, we manage our credentials inside a physical wallet: this is because it helps us not to lose them, protects them by keeping them close to our body and makes them easy to carry and access when we need them. The job of a digital wallet should be no different: it should store your credentials, keep them safe from potential hackers or cyber-attacks and finally, they should be convenient to display across all of your devices, but at the same time, easy to hide from prying eyes.

Unfortunately, during the 1990s and 00s there were so many misguided attempts at digital wallets that many developers stopped using the term. However, with the emergence of cryptocurrencies, research and development of the famous crypto wallets has finally given these digital applications a new lease of life. 

These types of wallets are based on a branch of mathematics, more precisely cryptography, referred to as public key cryptography or asymmetric cryptography. The idea is as follows: a user has a private key, which must be kept safe and not shown to anyone, and a public key, which he can show and which enables the user to identify himself to his counterparts. No information is obtained from the public key with respect to the private key, but the latter is generated uniquely from the private key. 

Through the use of the private key, the user can operate and ‘unlock’ transactions and the public key will be used to prove to third parties that these transactions have been performed by him. For example, in the case of Bitcoin, the private key enables the user to spend bitcoins while the public key (more precisely a reduced representation of it, defined as the public address) is shown to receive other bitcoins from third parties.

But what is the relationship between these keys and the elements of Self Sovereign Identity? Simple, each DID is conceivable as a public address generated by a public key which in turn has been generated by a private key. I would also remind you that the direction of the generations is unidirectional, i.e. from the DID I can never go back to the private key, but on the contrary from the private key can go back to my DID. Therefore, a wallet for SSI will have to be a container for these 3 fundamental elements and is the proprietary tool that enables the user to carry out operations and connections with other users. 

Also, unlike a traditional crypto wallet (for those of you who already have some experience with Bitcoin etc) a DKMS will also have these functions:

• It will have to comply with open standards of Self Sovereign Identity;
• It should allow connections to perform verifiable credential exchange (VCs) between agents during identifications;
• It should be easily connected to other systems via APIs or other computer communication protocols;
• It should accept and resolve any type of verifiable credential (VC) according to its extension;
• It should be installable on any device;
• It should be possible to easily back up and move keys and credentials from one wallet to another;

By the way, if you think about it, all of these features are designed to create a digital copy, or as we often use a “digital twin” of our old leather wallet that we use on a daily basis: easy to use, carry around, fill and empty.

The workflow for identity verification on the SSI

Let us now try to understand how the relationship between DID Auth and DKMS works with regard to the verification of an identity on SSI.

We have said that DID Auth is a mechanism that allows a user to prove to a third party that they have a decentralised identifier (DID). On the other hand, DKMSs are containers that contain DIDs and cryptographic keys. Furthermore, we mentioned earlier how DID documents are used to help the user prove that he or she possesses a particular DID. But what does this actually mean?

Within a generic DID document, it is possible to find various fields, among which we are interested in the one defined as “authentication”. Authentication involves the use of one’s own cryptographic keys, i.e. the public and private keys associated with the DID.

Thanks to the private key, the user can solve a challenge created by the Auth DID and thanks to his public key he can show that he has solved this challenge. This resolution is called a cryptographic proof.

The cryptographic proof is an alphanumeric value that is reported within the DID document, so as to be public for all parties involved in the verification process.

This mechanism of proof will be carried out by the user through his DKMS, which will communicate with the DID Auth of the other party, imaginable as a button “Sign in with DID Auth” within a website or application. Through this method, the user will be able to identify himself to a third party and prove that he possesses that DID.

Why are they crucial for the SSI?

There are several reasons: the first, however, is one of the most important. 

One of the great benefits of Self Sovereign Identity is the possibility of being able to create hundreds and hundreds of one’s own identities based on the relationships and connections a user wants to create. More technically, it means that a user could create a new DID for each new relationship they are creating. This, however, would mean storing hundreds and hundreds of alphanumeric codes, which I challenge anyone to do without going crazy. DKMS are precisely for the purpose of having easy-to-use containers within which a general user can easily find and manage all his identities.

Secondly, thanks to the DID Auth, Self Sovereign Identity will be able to compete with other modes of digital recognition in a similar way to “Login With Facebook” etc. We always remember that user experience and ease of use are the main stumbling blocks when it comes to adoption.

Thirdly, the Auth DID challenge can be considered as a “special” verifiable credential. Special because only after the resolution of the DID Auth challenge, the other verifiable credentials can be exchanged (during any other verification), and therefore the DID Auth test is an integral part of the identity check.

With this guide, we have a better understanding of all the fundamental elements for the implementation of Self Sovereign Identity. Furthermore, in the next guide we will finally see the real use of blockchain within this new identity management mechanism.