Last week we started a series of articles for an introduction to Self-Sovereign Identity components. In the first article, we have taken a look at some of the fundamental elements of SSI – Decentralized Identifiers (DIDs), their corresponding DID Documents and Verifiable Credentials. We now understand that DIDs are the digital and sovereign representation of an identity, that is further described in the DID Document and from and to which we can issue Verifiable Credentials. Part 2 of the series, we face the question of how DID Documents are technically associated with a DID and how we can authenticate using DIDs.

If you want to know what SSI is in general and how it could affect our online environment and behavior, take a look at the introduction article to SSI.

DID Resolution

DID resolution describes the process of getting from the DID to its associated DID Document. It is the basis for creating connections, initiating interactions, and proving ownership via DID Auth (see below). DIDs should be globally resolvable, allowing others to look up the DID document, for example, to start an interaction. Since every DID method works somehow differently and has different ways of creating and storing a DID document, resolving them works differently for each DID method. 

There are three main ways of how DID Methods, which define how to create a DID, and manage DID Documents. They could either be publicly stored somewhere and referenced in the transaction itself – like in Bitcoin Reference (did:btcr:) or generated by gathering events of a transaction to an authorized account – like in uPort’s ETHR DID Method (did:ethr:). The third way is to automatically generate the DID Document by the ledger itself like in Sovrin (did:sov:).

To create an interoperable SSI ecosystem, it would be useful to dynamically resolve the DIDs of any DID method. By doing so, DIDs from different blockchains could interact with each other. One system that does this is the “Universal Resolver”, which is illustrated in the following figure. Here, Webservices, Apps, or other services can resolve any DID Document that has a driver implemented in the Universal Resolver.

Model of the Universal Resolver

DID Auth

Cryptographically authenticating an identity owner, is a central goal in the SSI ecosystem. To establish trusted connections, proving control over a specific DID as long as the DID exists. In SSI, this specification is called DID Auth and relies on a challenge-response authentication protocol where the identity owner signs the response to authenticate. DID Auth uses the authorized public keys listed in the DID Document for authentication. 

The challenge-response cycle can be implemented with multiple protocols. One of the preferred ones is using a JSON Web Token. However, it also works with other protocols such as the TLS handshake protocol, OpenID Connect, or even HTTP. 

The following figure shows a simplified process of DID Auth.

Source: Introduction to DID Auth (Sabadello, et al.)

At first, the Web-Site of a relying party displays a QR on the Identity Owner’s Web browser that contains the DID-Auth Challenge. In the next step, the Identity Owner scans the QR Code and sends a DID-Auth Response with the signature of the Identity Owner’s private key to the Relying Party’s web server. Based on this private key signature, the creation of an proof signature indicates control over a DID. The web server receives the response and can validate that the identity owner controls the DID by resolving the DID document and validate the public key. After the successful authentication, the relying party’s web page polls this information and displays its content. For a more detailed description of DID Auth, I recommend taking a look at this document. 

Conclusion

In this second article about the introduction to Self-Sovereign Identity components, we got to know DID Resolution and DID Auth. 

To summarize, DID Resolution describes the process of getting from a DID to a DID Document. This process is essential as the DID Document contains important information about the DID, such as authorized public keys or service endpoints. This information is crucial to start an interaction like proving ownership or control over a DID, which describes the process of DID Auth. By implementing a challenge-response cycle, an identity owner can prove ownership or control over a DID and therefore creates trust between both parties. It’s worth mentioning that, in this case, only requires these two parties, and no additional identity provider needs to be involved. As a result, DID Auth creates a trusted fundament for further interactions, such as issuing credentials or other data exchange. 

In the third part of this series, we will take a more in-depth look at Verifiable Credentials. How can these be issued, how can they be trusted, or how can they be managed will be questions we are going to face and answer. 

This post was originally published on Datarella by Martin Schäffner