Introduction to Self-Sovereign Identity Components – Part 2

Introduction to Self-Sovereign Identity Components – Part 2

by | 24 April 2020 | Blockchain, SSI

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. 

If you have any questions about SSI or want to leave feedback, feel free to contact me.

The New Digital ID: Self-Sovereign Identity

The New Digital ID: Self-Sovereign Identity

by | 15 October 2019 | Blockchain, SSI

We from Datarella are always encouraged to be experts in the field of blockchain-related concepts and technologies and also to share our knowledge with the blockchain community. This blogpost should raise awareness about Self-Sovereign Identity (SSI), a fundamentally new approach of digital ID enabling users to have autonomy about their decentralized identifiers (DIDs) on the internet. 

Managing identities on the internet is a problem since its early days as it doesn’t have an integrated identity layer. Conventional identities are represented by identifiers provided by identity providers, such as an e-mail or a social media account like Facebook. The problem with these is that the identifier is not owned but only borrowed. The identity provider remains in control of the identifier and not the actual user. Although registration at new services is an annoying process already, the major problem is that websites store this personal information on their servers to determine who their users are. Based on the user information, data is generated and passed on to third parties without the explicit knowledge of the user. Besides, it often happens that this information is not sufficiently protected against criminal attacks.

DIDs as the fundamental component in Self-Sovereign Identity

The new digital ID concept “Self-Sovereign Identity” should allow users to have full autonomy about their identifier and control over how related personal information is shared and used and with whom. The fundamental component which makes it possible is the so-called decentralized identifier (DID). A DID represents the user in a pseudo-anonymous way and is derived from a public key generated on a blockchain or other distributed ledger technologies. Users can create and register their DIDs without the need for a central authority. 

DIDs serve to create lifetime relationships with others in a decentralized and privacy-preserving manner. Only the information that is needed should be disclosed. A popular example is that a verifier doesn’t care about the actual date of birth but only if the user is old enough to use or access a service. By using zero-knowledge proofs, the verifier only sees this information, derived from the date of birth. 

Self-Sovereign Identity further faces the challenge to merge the real-world identity closer to the offline world. This should be achieved by integrating verifiable credentials that can be issued to assert personal information to the DID. Credentials could contain any information, depending on the issuer, such as a valid digital ID, an attestation about a relationship like a club membership, or a digital diploma. By gathering such credentials, a user could integrate real-world identity characteristics to the online identity. 

Still a long way to go for SSI

Even though the concept of SSI is very promising, and standardized formats, such as DID, exist, there are still big hurdles to take. 

One challenge will be how this concept should be integrated on the internet. The usability has to be intuitive, so users tend to use their DIDs instead of a username and password combination. Then all actors have to be on-boarded. This is the typical chicken and egg problem. It requires a significant amount of services and authorities to accept or issue credentials but it also needs enough users to incentivize authorities to offer credentials first. 

However, there are already several projects running that provide this technology. The Sovrin Network, for instance, provides an advanced identity ecosystem that allows users or authorities to form relationships with others and issue or receive credentials. The uPort project also provides a full SDK to implement Self-Sovereign Identity solutions on the Ethereum blockchain. 

 

If you are interested in more information about Self-Sovereign Identity feel free to contact me via E-Mail or read into already existing documentation, such as the DID primer.