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 post Introduction to Self-Sovereign Identity Components – Part 2 appeared first on DATARELLA.

As already described in detail in the first blog post, Self-Sovereign Identity offers the user the possibility to manage their own digital identities completely autonomously. There is no platform or provider, such as an email address provider or a social network that controls identity. This is achieved using an underlying blockchain or a DLT on which key pairs can easily be generated that serve as identity representation.

Decentralized Identifiers

Now we come to the first component – the Decentralized Identifiers (DIDs). Their purpose is to act as a unique identifier of the person or object. These are derived from the public keys and can be identified over various blockchains. An example DID is shown below.

DIDs follow a general syntax: the schema (did:), the method (sov:) and the method-specific identifier (WRfXPg8dantKVubE3HX8pw). While the scheme is always the same, the method that describes how a DID is derived from a blockchain (here: Sovrin) and the method-specific identifier bo depend on the underlying blockchain. However, DIDs alone don’t bring any value.

DID Document

What fills a DID with life is the DID Document. This piece of data describes the DID object and its properties. By default, it contains the associated public key to a DID. However, it is also possible to add more public keys to the DID document that are authorized to perform actions in the name of a DID. Moreover, a DID can contain different types of attributes and service endpoints that allow the actual interaction with a DID. Changes to a DID Document can only be made by authorized public keys defined in the DID Document. An example DID Document with authorized public keys.

Verifiable Credentials

Now, that it is possible to identify an entity and to interact with it, is possible to attach information to the digital identity. This can be done with Verifiable Credentials (VCs) that act as an attestation or a digital representation of a credential such as an ID, a driver’s license or a club membership card. A VC consists of three main values:

1. 1. The issuer’s DID and signature
   2. The entity’s DID
   3. The information that is attached

Based on these three fragments, third-party verifiers can immediately determine the authenticity of the object by looking up the issuer’s DID. Verifiable Credentials are in possession of the DID owner that it was issued to and can be stored in a wallet. However, the issuer can always revoke the VC and adding it to the revocation registry that should be publicly visible.

These three components serve as the basis for a decentralized, trustless identity ecosystem that doesn’t rely on centralized authorities. DIDs identify an identity over, the DID Document describes the DID and a Verifiable Credential attaches verifiable information to a DID. Users are in sole control of their identity and can decide how information is shared and with whom.

However, this was only a small part of the entire SSI infrastructure. Part 2 of the Introduction to Self-Sovereign Identity components is about DID resolution, the process of resolving a DID Document from the DID, and DID authentication.

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

The post Introduction to Self-Sovereign Identity Components – Part 1 appeared first on DATARELLA.

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.

The post The New Digital ID: Self-Sovereign Identity appeared first on DATARELLA.