This series of blogs focus on self-sovereign identity, SSI. This post explains where SSI originated from by giving a timeline of how digital identity has changed over the years. In the second blog, we focus on what SSI is exactly. In the third blog, give two examples of use cases (IRMA and Sovrin) where SSI plays an important role.
Every human being has an identity: an attribute or a lot of attributes which make a person identifiable [source: https://www.iso.org/obp/ui/#iso:std:iso-iec:24760:-1:ed-2:v1:en]: think about a social security number, your birthday or your e-mail address. These identities give access to specific facilities. A physical passport can be used to verify your identity when you travel or open an account. A college card proves that someone is a student or pupil, so that you can, for example, use a student discount.
Central identities
With the advent of computers and the internet, digital identities became the way to give people access to digital systems. It started with central identities, which are still widely used nowadays. For each website, each system and each company a different central identity exists. To prove your identity often password and username combinations are used. These can be activated via e-mail, post, or via a support desk.
A big disadvantage of this central identity is that you collect a lot of it, mainly due to the growth of the internet and social media. In addition, the information linked to an identity, such as address, e-mail, date of birth, dietary requirements, profile photo, etc., must be entered again and again. Not ideal, having to share the same data every time. In addition, people have to remember a lot of passwords and people reuse their password, which makes them vulnerable.
Federated identities
Federative identities were created to counteract these drawbacks. Federations are parties that sit between the user and third parties. We see this federated identity in various places in the contemporary internet: from social media federations "log in with Google / Facebook / Spotify" to government federations "log in with eIDAS". This means that as a user you can easily login in all kinds of places, via one federation, and share your data. The advantage of these types of systems is that users only remember the login methods of a limited number of federations. When you log in, federations share part of your data: such as e-mail address or profile picture, so that you as a user do not have to provide this data again.
Although this system sounds wonderful, it also has a disadvantage: You have no insight and control over what is shared from the federation with other websites and systems.
User-centric identity
People became more aware about their privacy, therefore user-centric identities were introduced. In user-centric identities users are in the centre and control what happens with their data and with whom it can be shared. Now a days, many federated identities took a step towards user-centric identities. They now explicitly ask users for their consent when sharing (part of) their data. For example, when you log in to LinkedIn with Google you can actually see which data Google sends to LinkedIn.
[Footnote: this openness is not flawless, however, for example, Facebook suffered some reputational damage with regard to their data sharing policy. I will not go into this further in this blog. https://www.bbc.com/news/technology-46618582].
This is for sure a step towards a more privacy-friendly way, especially taking the privacy law into account. However, the federations still had control over what happened and actually have a big brother role: they could see what every user did with his federated identity and which websites were visited. In addition, as a user, you could not check whether the federation did not share more information about you.
Self-sovereign identity
Self-sovereign identity (SSI) has been developed to solve these drawbacks in user-centric identity. In SSI, the user is not only symbolically central, but actually in the middle, between his data and the 3rd party that receives her data. With SSI, data no longer goes to a 3rd party with the permission of the user via the federation, which is currently the case where Google sends your data directly to LinkedIn. In SSI, the data goes directly to the user, the user stores it, and the user can send it to another party. In the same example, this would mean that the user receives her data from Google, stores it herself on her computer or mobile and then shares (part of) the data with LinkedIn when she wants to. With SSI, the federation (in this example Google) does not know which data, when and with which third party (in this example LinkedIn) the user shares data.
You may be wondering now: can I not mess things up if I use SSI by adjusting the DigiD data before I send them to the tax authorities? Fortunately, that is not possible, but more about that in the next blog in which we look at how self-sovereign identity works exactly.