This series of blogs focusses on self-sovereign identity (SSI). This post explains what SSI is, what the basic architecture looks like and the advantages of SSI if implemented as PDM (personal data management). For more information on PDM, see our website. In the first blog, we focused on why SSI came to be. In the third blog, we give some examples of use cases where SSI plays an important role.
The SSI principles
A self-sovereign identity, as the name suggests, allows users to have the supreme control over their own personal data. The user, and she alone, can decide which data she shares and with whom. The definition of SSI cannot be completely described in just one sentence. However, there are some guidelines that help to describe what SSI is supposed to be.
Most famous are probably the ten SSI principles of Christopher Allen [source], they include:
- User control in sharing data
- Privacy
- Algorithm transparency
- Interoperability
- Portability of data
- Data minimalization
Based on these, and other, principles an SSI architecture arose that is currently implemented in different examples and versions of SSI. Please note that these SSI principles are strongly related to the Personal Data management (PDM) principles, which are for example implemented within MyData. SSI is an extension of PDM, the difference lays in how data is shared (more about that in a few paragraphs) and in blog 3 we will show that some PDM initiatives could be seen as SSI. In this blog we focus on this architecture to explain what SSI is.
The 3 main roles in the SSI architecture
There are three main roles in the SSI architecture: the issuer (data source), the verifier (sometimes called service provider or data receiver) and the user (holder). The user is in the centre of her data and has complete control over what happens with her data.
The issuer is the source of the user’s data and provides her with personal and non-personal information (which are often called credentials). The verifier will request credentials from the user, and if she wants to share it, the verifier will receive and verifies them. For the user (holders) point of view there can be multiple issuers, verifiers and registries.
The figure describes the basic SSI flow. Step 1) The user request her credentials from the issuer and the issuer sends the signed credentials to the user. Step 2) A verifier requests a certain credential from the user, the user can provider part of her credential which was signed by the issuer, to the verifier. Step 3) The verifier checks the signature of the credential using the registry. An important difference between SSI and PDM is shown in step 2: in the SSI architecture the credential will never go directly from issuer to verifier, but always via the holder, with this mechanism the issuer will never know with which verifiers the holder communicates. In PDM it might happen that, under the consent of the user, the issuer will send the credential directly to the verifier (this has more a user-centric federated identity, see blog 1.
Another advantage of SSI is that that it is possible for the holder to share only part of her credential, not the complete credential she received from the issuer, while it is still possible for the verifier to validate the credential.
Credential validation
Step 3, the validation of the data of the holder, is done using the public data of the issuer. This public data includes information like a public key, to check the digital signature of the credential. This public key of the issuer, or more general, the public-private key cryptography used, is a main part of the security of SSI. This public-private key encryption is used in more digital environments to create trust between users or organisations. Simply put, a public key, that everyone can know about, is used by verifier or holder to validate the signature from the issuer on the data. The private key, which can only be known by the issuer, is used to put a digital signature on the data by the issuer.
The registry, the extra roll
In most SSI environments the role of registry is introduced. The registry keeps a list of all (or some) known issuers and their public available data. An advantage of this method is that it allows verifiers to easier verify if a credential indeed belongs to that user and was issued by that issuer. Without the register, the verifier has to ask the issuer for its publics data, when it wants to verify a credential issued by that issuer. With a register, the verifier does not need to request this public data from every issuer but can use the registry.
However, the register also introduces more need for trust. The verifier has to trust that the register is true about the issuers public data and is not misusing its power to provide false data.
In this blog we had a quick look at the architecture of SSI and two important advantages of SSI: the possibility to share only part of a credential, while still being able to verify it and the cryptographical mechanism which allows to use SSI to share verifiable data, without the issuer having to deliver the data personally directly to the verifier. This contributes to more user control, more privacy and data minimalization.