Understanding federated identity and how it compares to self-sovereign identity (SSI) requires a basic understanding of when, where, and how digital identities are used online today. There is no “one size fits all,” though passionate proponents of various technologies may beg to differ. Alas, the world is not that simple: Different use cases drive different architectures and prioritize different technologies. That makes for quite a bit of confusion and a rather long blog post.
Why the confusion?
One question you might ask is, why is there so much confusion, anyway? The terms don’t look anything alike, so surely they must be entirely different things! Well, no, not at a functional level. (The technology stacks used to support that functionality differ, but we’ll discuss that later.)
First, let’s recognize that not everyone even likes the term SSI. It’s unclear whether digital wallet technologies fall under this category; some people say they do, others don’t. Other people are immediately turned off by how early proponents of SSI focused almost exclusively on blockchain technology. For the sake of this post, know that I’m coming at this from the perspective of SSI as an architecture that encompasses a user-centric focus for digital identity credentials. YMMV.
Both Federated Identity and SSI models support similar (but not wholly overlapping) use cases. For example, both models can support remote identification, authentication, and/or authorization to online services. Both require an entity that holds the source records, issues credentials, and supports the possibility of a third party using those credentials. It’s also possible (but rarely implemented in the Federated Identity model) that the person engaged in the transaction has some control over what exactly is shared with the third party requesting the data.
But wait, there’s more!
Discovery
In both models, there is also the requirement that an individual be able to make some choices about what credential they want to use. Within Federated Identity, that means being able to pick the identity provider (IdP) from a list or type an identifier for it into a dialog box. In the SSI model, that means being able to pick from a list of locally stored credentials OR picking the correct container (aka, the digital wallet) used to store the appropriate credentials.
If this sounds like a UX nightmare, it is. Federated identity has been used in production environments for decades, and they still haven’t definitively solved what’s referred to as “the discovery problem.” In the research and education sector, for example, a single relying party (RP) might need to offer a choice of nearly 6,000 IdPs for the user to select from. The SSI model is realizing the same pain now, exacerbated by the desire not to let any third party know more information than they absolutely have to.
So, there is just enough functional similarity to make things interesting when talking about these two architectures. Some might even say that SSI is just another flavor of Federated Identity (note: that way lies madness). Now, let’s talk about some of the differences.
Federated Identity
What use cases drive decisions toward one model and not the other? Well, for one thing, it provides the company that operates the IdP control over the authentication process and the information shared during the transaction. In the case of an enterprise organization, that makes a lot of sense. Authentication and authorization in this use case is by, for, and about an individual as they relate to a company. It’s not about the individual’s private information; it’s the data about them as associated with and owned by the enterprise.
That’s all a question of functional requirements. The technology stacks, however, are quite different. When talking about federated identity models, protocols like the Security Assertion Markup Language (SAML), OAuth, and OpenID Connect are what describe (and constrain) everything including the claims, the assertions used, the structure of the attributes shared, the way identity provider discovery is handled, and more. A great deal of control is given to both the RP and the IdP, and there is a coarse level of control for the individual (generally in the form of “you can either choose to log in or not, but you aren’t guaranteed control over what information is shared as a result”).
SSI
The SSI model is a very different beast in the underlying assumptions, protocols, and architecture used. The most important entity involved in any transaction is the individual, aka the user (not my favorite term, but it’s pretty common in the documentation). The individual decides what information is shared and with whom. In a typical use case, when an individual uses a credential in an SSI model, nothing reports back to the issuing authority that lets them track what the individual is doing with their credentials.
Ideally, the individual has discrete control over every bit of information in their credential. In fact, the protocols are being designed to ensure a minimum of information is shared in an identity transaction. For example, when a third party asks for verification that the individual is over 55, all they should get in return is a ‘yes’ or ‘no.’ They should not get the date of birth, home address, a photo, and whether the individual has chosen to donate organs upon death: the information shared when presenting a physical US driver’s license to verify age. Another name for this is selective disclosure.
When considering the protocols, SAML (as far as I know) will never properly fit in an SSI world. OAuth and OpenID Connect may, and there’s work in progress to make that happen (check out OpenID for Verifiable Credentials if you want to know more). Work is also underway regarding the credential itself, most notably the W3C’s Verifiable Credential efforts, the IETF’s SD-JWT specification, and ISO’s mdocs.
New Solutions
The good news is that, as one likes to see when it comes to evolving technologies, SSI is helping solve some of the challenges that traditional Federated Identity models weren’t able (or chose not to for reasons that made sense at the time) to support. I already mentioned selective disclosure. SSI models have this as a fundamental requirement of the technology, not just something that an IdP might implement on behalf of its users but rarely under the control of its users. Big privacy win here!
Another possibility in this brave new world is cross-device support. Rather than a password that has to be memorized and/or copied over to multiple devices (for example), a credential that lives on one mobile device can be used in an authentication or authorization process on another device, like a desktop or tablet. (I will note that this may fall under the category of “just because you can, doesn’t mean you should.” There will be a LOT of different types of credentials, even identity-focused ones, available to the individual. They are not all designed with authentication in mind.)
That said, when a credential is designed for authentication and authorization AND moves us away from relying on passwords, it is really a Very Good Thing.
New Problems
Sign me up! Let’s do it! Rah Rah, go, team!
Or, maybe not quite yet, because new challenges must be addressed before people decide to jump on the SSI bandwagon.
For one thing, the UX challenges are pretty significant. The technologies under development to move ahead in an SSI model support more than just identity. They also support payment systems, transportation tickets, library cards, insurance cards, hotel keys, car keys – the list goes on. It’s one thing to compare this model as similar to having all these cards in a physical wallet, but there comes the point where there are too many cards for me to find the right one when I need it. Surely, a computer can search for the one I need, right? Right?
Well, not yet. This is where the privacy considerations make usability that much harder. Credentials are often stored in a digital wallet, and that wallet protects the credentials from any random request. Arguably, the wallet shouldn’t have anything to do with the credentials it holds any more than a physical wallet has anything to do with the cards it holds. Just to make sure we’re maxing out on the potential for complexity here, there may be more than one wallet holding various credentials!
More New Problems
Not everyone wants to live in a paternalistic nation-state that assumes people are unlikely to make good choices and protects their population by restricting various freedoms and technical innovations. That said, not everyone wants to live in a completely libertarian environment that leaves individuals responsible for their actions, whether or not the ramifications of those actions are clear. Trying to find the compromise in the middle usually involves some level of transparency and accountability so that it’s possible to verify all parties did the right thing as defined by contract or law.
That’s not too hard in a traditional Federated Identity system. The IdP has logs of transactions. The RP has logs, too. The only entity that (probably) doesn’t have logs is the individual (although the IdP and the RP sometimes make their logs visible to the user). With two out of three parties having info on what happened, cross-checking becomes possible if something goes to court.
However, In an SSI model, the entity that issues the credential knows that it issued it. When it comes to the credentials being used, however, they (in some implementations) don’t know anything – on purpose. The RP (aka, the Verifier) may only know a potentially small subset of information that doesn’t identify the individual at all. Whether the individual (or the device or application holding their credential) has a transaction log is still under debate and may be an implementation detail. Some developers may implement one (and get yelled at regarding the privacy implications), and some may not (and get yelled at for not supporting accountability and transparency).
Wrap Up
The functionality of Federated Identity and SSI architectures is similar if you tilt your head just right. Both serve to support remote authentication and authorization. Both have one party responsible for creating the digital identity credential, another party expected to consume it, and an individual (and their devices) instigating the transaction in the first place.
The technical decisions that inform the protocols and subsequent implementations, however, are where the designs quickly divide. While no one wants to support more identity systems than is necessary; the traditional Federated Identity model and the newer SSI architecture are not mutually exclusive. They just focus on solving different problems.
It doesn’t help that SSI technologies are very young and under active debate and development. The technology you see right now is not fully baked, and it still needs to grow to solve everything technologists hope it will. Of course, you can wait for that and ask someone to let you know when it’s all resolved. Or, as always, my preferred option: you can get involved in the discussions to ensure you help guide these technologies’ development and deployment.
Thank you for reading my post! Please leave a comment if you found it useful. If you’re interested in starting your own blog or improving your writing, check out The Writer’s Comfort Zone.
If you’d like to have me on a podcast or webinar, my media kit is available for your reference.
