SSO vs SSI

• SSO : Single Sign-On
• SSI : Self Sovereign Identity

At IIW XXVI last week, there was much excitement about innovations in SSI. It’s tempting to hope that it’s the dawn of a new era, one in which people free themselves from the evil lords of federated identity. Finally, we can de-centralize! IDPs insert themselves between the person and the Internet, and SSI will save us! Or will it? SSO: federated identity, already decentralized? Using federated identity, I can use my browser (or an embedded browser in a mobile application), to surf the Internet, and websites can enable me to authorize the release of information from an HTTPS-accessible IDP. Federated identity is not limited to large consumer services like Google or Microsoft. Any domain can launch an OpenID Connect provider or a SAML IDP. It’s not that hard. At Gluu, we strive to make deploying a federated identity provider as easy as installing one package, and running one setup script. I could even launch my own personal IDP. For example, I could register the domain michael-schwartz.com, hold my own authentication credentials, and control what information I release about myself. I guess the top level domain (TLD) registrar, which controls the .com namespace could kick me off. But that’s a risk every domain on the Internet is living with today. The security for federated identity relies on “TLS”–meaning that when a website talks to the michael-schwartz.com IDP, it is trusting the validity of the X.509 certificate presented while making the HTTPS connection . IDPs may digitally sign assertions, but if the keys were acquired via HTTPS, then the security still boils down to TLS.

SSI

But what if your data is scattered at multiple IDPs? In a world where many organizations may publish information about you, requiring a website to gather data by making a bunch of TLS connections does not scale. In SSI, you can hold your own data, and you can reference a blockchain signature or a zero-knowledge proof to enable verification. Thus, SSI offers a secure alternative to gathering data via TLS.

Trust

In both federated and SSI models, what you are trusting is an assertion made by an issuer. But to what extent should I trust that assertion? Unfortunately, SSI doesn’t address this issue. Whether one domian trusts the assertions of another domain is up to them, and out of scope for both SSI and SAML/OpenID. Personally, I think this is where multi-party federations can help (as they have with SAML assertions), and that’s why I’m co-chair of the Kantara OTTO working group. But that’s a topic for another day.

Authentication

When I interact with a website, and provide verifiable claims, how does the website know they are dealing with the same person who is the subject of the claim? Ideally, I’d have to prove I’m me by presenting something I previously registered, like a FIDO authentication credential. While there are numerous feasible techniques for how to use distributed ledgers to prove identity (NuID, Showcard for example), it would be counter-productive to define a protocol to bind an identity to a browser. Our good old federated identity protocols are still the best way to do this.

Conclusion

It would be great if the Internet can adopt an SSI infrastructure. The current vocabulary for federated identity is limited. I can get first name, last name, and email using federated identity services, but rarely more. There are many different types of assertions: medical records, financial records, professional certifications… we need new vocabularies to represent these things, and more options to enable people and organizations to easily publish and consume this information. I fear that propagating the idea that SSI is a replacement for federated identity just confuses people. Organizations will continue to operate their own IDP–whether or not they store secrets like passwords, and whether or not they put up a registration form, or accept verifiable claims. IMHO, the most likely initial use cases for SSI will be as input for access control decisions for a transaction. If the user agent for that transaction is a website or mobile application, and if it is calling an API, verifiable claims can probably be sent via OAuth. Let’s make the case for how to use verifiable claims in the federated environment we already have–i.e. let’s walk before we run.