Title photo: Luis Alberto Cardenas Otaya

Introduction

In late November the Mimoto team had a virtual ‘stand’ at Identity week 2020. Originally planned as a physical conference, it eventually migrated online due to the COVID-19 pandemic. As our first conference as exhibitors the virtual format made for a very different experience from meeting people in person.

The event featured a wide range of interactive talks from international experts in digital identity. One of the main themes of the event was Self-Sovereign Identity (SSI). Whilst watching some of the talks about SSI, I reflected that often when people ask me what I do, I end up having to explain the concept of federated identity as a kind of pre-requisite piece of knowledge. With this in mind, I thought it would be useful to write a beginner’s introduction to SSI and briefly cover how it differs from centrally managed identity and federated identity.

What is Self-Soverign Identity

The concept is still young and there is still a bit of discussion of what exactly is and isn’t SSI but broadly speaking it’s a authentication system where by a user can authenticate themselves to a service without having to rely on a central authority to enable that process. In this scenario the service doesn’t need prior knowledge of the user, it can establish a trust based on the information the user supplies. The user has control over their identity and isn’t reliant on a central authority to provide it on their behalf.

Identity architectures

It is helpful to look at Self-Soverign Identity in the context of other identity infrastructures.

Centralized

(Unfortunately) most login experiences we have are based on a centralized identity infrastructure. As an example, think of the experience you’ve had when you want to buy something from an online shop. You want to use this service, first you have to register your details and create a set of credentials that you’ll use to access the service. It’s easy for the service provider to setup but it has a lot of negative affects for everyone involved: the user has so many credentials, the service provider has a data security headache, and the whole approach fosters an environment where it is easy for a malicious attacker to win.

Open-trust

This is the Google and Facebook login model. A handful of large Identity Providers (IdPs) grant access to a vast range of services. The users identity information is hosted and controlled by these giant IdPs. Differences in protocol flavours mean that service providers (SPs) can end up creating multiple login handlers to allow access to their site from two or more of these huge IdPs. The IdPs have control over which SPs can use the authentication framework, and what happens to the users data. The user does have fewer credentials to remember however.

Federated Trust

With a federated login system, a user’s identity is hosted by an Identity Provider (IdP) at a logical home institution for the user. They use the IdP to authenticate to one or more service providers (SPs). The IdP also discloses an amount of data about the user to the SP, the level of disclosure is ultimately at the IdP owners discretion. To the point where access can be trusted to be both anonymous and authenticated at the same time. An interesting concept when you think about it.

With federated login systems the user doesn’t interact with the federation directly; they’re most likely not even aware of it. The federation is essentially a register of participating IdPs and SPs and trust data they need to be able to interact with each other. The IdPs and SPs download a copy of this register and use it to establish technical trusts between themselves whilst authenticating users. Within the federated identity sphere users typically have one identity they use across a range of services, they have control of their own data if their IdP delegates that to them. Here at Mimoto one of our products is Indiid, an IdP in the federated model where users have control of their identity.

Self Sovereign identity

Returning to self sovereign identity; in this model there is no IdP. The user has a digital identity, perhaps stored on a phone, which authenticates them to service providers. This can only work if the service provider has something they can put their trust in. With self sovereign identity the trust framework is provided by a de-centralized trust technology. Many are proposing blockchain as a way of providing this.

You may be aware of a old technology called Pretty Good Privacy (PGP) as a means of establishing the true identity of a email sender. In some ways it helps to think of PGP as something that is pretty close to a SSI. Users control a set of cryptographic keys they use to sign and/or encrypt data, and they also control which keys they trust. It’s a peer to peer model with no immediately apparent central authority that controls access to the technology. However, its strong link to email, and therefore the domain name system, means it can be seen as dependant on the ICANN authority which precludes it from being an SSI to many.

Conclusion

There is obviously a lot more to this topic than I can do justice to in a short introduction, so I thought I would end with some questions to ponder:

• How can we give the users control over their identity, whilst also making the technology simple enough for them to use in a secure way? Lots of users fall foul social engineering attacks even when the authentication model is simple.
• Who is responsible for the persistence and/or re-provisioning of the users identity? If it’s the user, how can this be made simple? If it’s an organisation how can we address the central authority issue?
• How will the decentralised trust fabric work? There is a lot of discussion about using blockchain but what are the costs of that and who bares them?
• How will a user’s access to their own identity be protected?

I would be interested to hear your thoughts. If you fancy a chat about digital identity, or if the Mimoto team can help you with your needs, please do get in touch.