Federation Bubbles - Dynamic Trust Moves Beyond The Commons

Hi everybody and good afternoon. My name as, as you said, is Justin Richer. I'm an independent consultant based outta Boston in the US and today I'm here to talk about this weirdly named topic called Federation Bubbles. The reason for this is that I've been thinking a lot lately about accounts, about federation, about how we approach this identity problem, which has led me to thinking about bubbles. Now that might seem a little bit strange, so let's back this up a little bit. Authentication is a pretty simple process, right? You've got a user, they present an authenticator, we verify that authenticator, they get a session and everybody's happy, they're able to access the service. And this works. In fact, this has been working really well for a really long time. Direct authentication works great, but it really doesn't scale does it, right? You've got a user with an account on the system and then when you go to use a different system, you have to go create a different account with and buying different authenticators and do all of this other stuff. And even if you are doing something like a reusable authenticator, like a phyto token or whatnot, well then you have the problem of all of the attributes and everything associated with that user, not really scaling in the same way. Federation on the other hand, allows us to scale this authentication and account and Federation allows us to do that by bouncing the user out to their IDP and bouncing them back.
AV folks, could I actually get a, get a timer so I know how I'm doing? Thank you so much. Otherwise, I'm just gonna keep talking all day. Federation works by allowing us to bounce users out to their IDP and back. And that allows us to take a look at things in a way that we can actually scale out that authenticator. We can use that one account to not only go and talk to one system, but many different systems. And that's a really, really powerful pattern, right? We like, we like this, we use this all the time and that scales the accounts. But I'm gonna ask you, how do we scale out the trust? I need to make the decision of this account comes from this identity provider and I trust it for a certain amount of privileges and access rights and things like that. Like who is allowed to say that this is Mathias, right?
Like who, who, who gets to say that? Can I stand up an identity provider that can just claim that? Why would you trust that? You probably shouldn't. So we need to be able to scale trust independently and in parallel to the way that we scale how we pre present information in accounts. And I think that in a lot of times we sort of conflate these two, we wrap these two things up together in ways that is, is limiting. But there are patterns for scaling the trust out there. And one of the most viable ones is the use of a federation authority. So the Federation Authority doesn't log users in, the Federation Authority doesn't actually proof accounts or anything like that, but the Federation Authority says who's allowed to do that? In other words, we've abstracted this relationship between the IDP and the RP and any attribute providers and account providers and things like that up a level.
So we can use these constructs in order to scale the trust of a larger system and put it all together and it looks like this. Alright? Everybody understands absolutely every part of that diagram, right? Good. There'll be a quiz later. However, one of the problems with that, with diagrams like that that just flash by is that traditional federation systems are really designed for a connected world. The user shows up in order for them to log into your system, they need to reach their IDP wherever that IDP is that IDP needs to be online. It needs to be reachable from your environment in order for you to evaluate and trust everything. And yeah, you can do some tricks with bouncing through devices and you know, front channel presentations and things like that of course. But ultimately it's designed for this online system and these federation agreements, they're really designed for a growing system.
You look at the research and education space and federations like, you know, educating and in common stuff are all about like, oh, we are getting new accounts, we've got new students coming in, we got new universities coming in. But what happens when I need to stop trusting one of those? That's a lot harder to propagate in systems like this. They're really not designed for that type of, that type of engagement. And they also assume that once you're up and running than you're, you're online, you're up and running and everybody that needs to reach you can reach you and the authority gets out of the way. However, the real world doesn't always fit that assumption. And I've been working with a client recently on a lot of spaces where that starts to fall apart. For example, you've got a bunch of people that are about to get on a boat.
You may have a list of people that are supposed to be on that boat when the boat leaves dock, but after you're going on, maybe you rescue a bunch of people from a ship and they need access a sinking ship and they need access to stuff in order to just move around the ship as you're out there and you're not gonna be connected back into the home networks in order to propagate those policies down from the top. Or say you're doing a disaster recovery, you've got a bunch of computers out in a tent somewhere with spotty connection at best in order to to get stuff back. Not only, you're not gonna be able to make these connections back to some home hub. You're not gonna know who shows up to help with the disaster until they show up to help with the disaster and you're not gonna know what they're coming with until they show up with it, right? It could be a bunch of people with shovels that you still need to keep track of. And that is something that these sort of traditional federation authority type systems don't really do well, right? So I'm saying maybe it's time, maybe it's time that we as an industry start to rethink what we use federation for and maybe it's time to really rethink what we mean by an account and how we use an account. So how about bubbles?
So what do I mean here? Let's take that identity provider with all of the RPSs. There's a lot of really great aspects to that. Let's package that. Let's package that into a network that we can, we can have more assurances that this piece is gonna stay online with itself, but then this can now be separated from the rest of the network, right? So I've got users and accounts and authenticators in here and I've got a local authenticator to this IDP. So the user can log in and use all of those different services. All of my access rights are localized, all of my accounts are localized. All of my attributes are localized to this bubble itself.
Now, how did the user accounts get there? In a lot of cases, like the boat leaving the dock, we have a list of people that at least at the start of the journey, we expect to be on the boat. So we can prepackage a lot of that stuff from an authority and that carries some weight to it within the local systems because we know where those came from. Those people show up with a certain set of attributes that's preset authenticators that we can trust because we literally handed it to them. But then we go fish someone out of the water and be like, you know what? We have no idea who you are, but you can help us out in the kitchen from a couple of hours as long as somebody else is in there and we need to give you an account to do this.
Or we're out in the field and you know, a bunch of folks show up and they really want help and they claim to be a whole bunch of, you know, electrical workers from out west somewhere. Okay, fine. They, you know, grab, grab some tools and and get out there and help. 'cause we need every hand that we can get. What do we do today? With stuff like that? Quite honestly what we do is we hand somebody a username and password on a sticky note and say, please don't lose your sticky note because then we're gonna have to hand you a new sticky note. We do local provisioning on these kinds of systems all the time. So this whole idea of a local account is not new by any stretch, but that's not the whole story.
This bubble gives us a well-defined boundary and it gives us all of this local processing, but there's more to it than that because we can take that and we can repeat that pattern of packaging up these little systems, but they're not all gonna be the same out there. Every bubble's gonna have different attributes, different users, different applications, different things that it's concerned about, different things that it cares about, and they're gonna be living in this space together. So these are not simple copies or shards of a larger global correct view of the world, not by any stretch. All of these are different, separate independent worlds that now need to live together because we've got a lot of bubbles. And what happens when you have a lot of bubbles together, they're not really just bubbles anymore. They turn into a foam, it's its own entity. Those bubbles touch each other, they move, they connect.
And this happens with these systems that are out in the field as well. So let's say that electrical workers' union shows up and they've got their own bubble that has their credentials and everything in it that says, yeah, we are actually an electrical workers' union with workers that have passed these tests that can go and help us out. Alright, let's connect our bubbles together so that I can get you into my systems and I can get into your systems however I need to and let's get out there and actually start doing stuff. But the important thing here is that we're not just connecting these two bubbles as if they're a single bubble. Those users are showing up and we are actually gonna federate in. Or one way we can do that is we can federate in from the IDP of that orange bubble into the blue bubble, which means that once that user is in there, well, what did we say before?
When a new user shows up at the edge of our bubble, what are we're doing? We're creating a local account, we're binding them to a locally recognizable authenticator. Now in this case, it could be that they show up, they federate and they pop in a a phyto token and we're like, yep, okay, good. Get out there and go fix a light pole or whatever you gotta do. But at this point, at that point, they don't need to go back to their home bubble anymore like this only needs to be there for the touchpoints, for that introduction to pass the attributes, to pass the trust between those systems. Once we disconnect from each other, all of the logins and everything still works. All of the attributes that I have in my system about that person still works. Everything about that account is localized to my bubble and that gives me a lot of power around what I say it can do.
And what I say about it that is not directly dependent on connection to the outside world. So in other words, we're using things like federation as a provisioning system and not as an authentication system. And herein I think that there is actually a really, really interesting power with things like verifiable credentials, MOCs and things like that. Because here we have a technology that is really, really well designed for a proofing and provisioning type of transaction. You show up, you present at once, check the attributes and you're good to go. We shouldn't be leaning on that same tech to do, to handle all of our authentication problems as well, right? Because it's it, they're addressing different things. And I think that all too often we conflate this stuff. So once I have that user in my bubble, well guess what? I can now act as a trust authority to somebody else downstream.
That user from the orange bubble showed up. I made a local account and I can, if I decide, make that account available to somebody else. So somebody coming up and, and this user, you know, with their own bubble and this user connecting into that, they're gonna get this record that says, yes, this is a user from the blue bubble, which by the way, they came originally from the orange bubble, but I checked it at the time and I can sign that as the blue bubble and say that everything is good to go. So if you trust me as the blue bubble to be able to make that statement, then that can actually factor into your logic of whether or not and how much you trust this particular user and account. Then when we get reconnected, we can actually start sending information back to the other streams if we need to.
So for example, that user that did a bunch of stuff inside of my bubble, well now I see their home IDP again, it's like, hey, they did some kind of fishy stuff over here, just FYI maybe, maybe you want to know about that. Maybe you want to do something about that. You know, I can start auditing this stuff when I start talking to my authority and I can say like, Hey, I made this local account, I connected this external user that we didn't know about before. Does this look okay? Like help me process this. And it's not even gonna be a single authority. Like this is not a hierarchical relationship. This is a network, a web of relationships. So there's a lot of technology that's gonna help us solve this. But the most important thing about this bit is that I'm really envisioning every one of these to have an inbound side and an outbound side, right?
You've got all of the stuff in the middle to actually get your applications running. That part's relatively easy to package up. We know how to do that. We call this a corporate network in a lot of cases. But the really interesting problems to me are the stuff that goes on either side of it. How do we get new users in? How do we project new users out? How do we get access, rights and information on both ends? At the end of the day though, there's not a single protocol stack that's gonna solve this. And if anybody here at this con conference tries to sell you a protocol stack to solve this, they are lying to you because it does not exist. I believe that fundamentally it cannot exist because the future is gonna be heterogeneous. Each of these bubbles is just gonna be one element in an ever-growing, ever-changing, ever fluctuating network of different systems.
We need to be able to connect to them, but we need to assume that they're not all gonna be the same. Some of them are gonna speak open id, some of them are gonna speak verifiable credentials, and all of these standards allow us to connect those points, but we're not always going to connect in the same way. We need to build our systems with this type of connectability in mind in order to enable this type of local systems and embrace the diversity of all of this software and all of these models in order to survive in this dynamic world. So in my opinion, the future is in bubbles. Thank you.