Federation Bubbles

Perfect. Okay. Lately I've been thinking a lot about bubbles and the reason for this is that the world that we live in is increasingly mobile. We have people that are on their phones and laptops right now instead of listening to the presentation. But we're moving between different networks, from cell networks to wifi, to home networks, to all these different spaces. And that means that the identities that we use, the identities that we build, need to be resilient and flexible and work within those spaces, right? And the solutions that we build need to work in those contexts as they change.

They need to work for the space that I'm in right now and the space that I'm moving to as I'm going through the space, going, going out all through the world. So let's say we've got a group of people, right? They're out there together and they've got a bunch of applications that they want to be able to use.

Well, this is pretty easy. We let them log into those applications, right? This is a really simple problem, except that it probably means that they're gonna log into each of those applications differently. Now we have a whole stack of credentials that we need to manage, and this is kind of a mess. So it's 2024. We have a good way to solve this. We're gonna give them an identity provider and that identity provider, sorry, the slides keep jumping ahead. Could we make sure that they're not autoplay, please? Thank you. I'm not sure.

Yeah, they're something's autoplaying, so they should be here and not moving. I just don't know if the viewer was on auto play. Okay. Alright. So hopefully we'll make it work. Anyway. So we give these people an identity provider. This is where they can have all of their, all of their identities, all of their accounts. And that allows them to access all of these different applications. So what if these people were on a boat, all of those applications with them on that boat?

Well, we're probably gonna give them the ability to log into all of those applications on a boat, right? Well, except that, you know, we probably want to give them an IDP. Also a note, I am not changing these slides, so this is really disconcerting. Alright? So just a moment. We're going to give these people their own identity provider that's on that boat, that that controls all of their identities, all of their, all of their stuff, and allows them to access all of those applications.

This all works well and good, except that the person who probably put them on that boat said, you know what, one of the reasons that I wanted the IDP is that I wanted to be able to control and manage all of those identities, all of those accounts in a central location. So I'm gonna take that IDP and I'm gonna put it in a really safe place and I'm gonna make sure that that's accessible, that that's robust, that that's backed up. And this works really well when the boat is plugged in. But here's the thing about boats. They move.

And this might, you might start to think this is a pretty solvable problem. We're just gonna put that thing on a satellite link so that the boat will be able to reach the IDP and this works for a while. Latency might go up a little bit and it kind of works. You can still reach the IDP to get to the things until it doesn't. And now we are in a space, sorry, the slides are really fighting with me. I'm sorry about this guys.

The, yeah, So yeah, I'm, I'm not sure why it's auto advancing, but, so this works pretty well until it suddenly doesn't work anymore because you can't see your IDP anymore. And that was actually already the line in the presentation, believe it or not. And the thing is though, then that means that all of these people that have all of the rights and access have all of the accounts can no longer reach their applications even though they're all sitting right there. And so that means that we've got a lot of, a lot of trouble in this environment when that IDP goes away. Alright?

The reason for this is that our traditional model of federation systems is built for an online, always connected world. This is what we assume. We assume that if you have an IDP, you should be able to reach the IDP. If you're part of a multilateral federation, you can reach the federation authority to be able to check things.

Sure, you might be able to cash things and stuff like that, but ultimately you're not going to, you're not gonna expect that kind of thing to go away. And so my slides keep betraying me here, but a lot of things that what, when I've talked to people about this over the last year, most of the time what people say is, well, I know how to solve this. I'm just gonna take that IDP and I'm gonna make shards.

So I'm gonna take that IDP declare that this is the gold source of that IDP, and then I'm gonna make a whole bunch of copies of it and I hand those copies off to anybody that needs a copy so I can send it off into a field environment. I can send it off on a drone or on a boat. So the next time my boat is plugged in, we just download a copy of that IDP onto the boat and then we sail off and everything works pretty well. All of our people can access all of their applications. That all seems to be working pretty well, right?

And, and all of that is still managed by that central system. So now when they run into their peers out on the water, this actually works extra well because even though we might not be able to connect back to the home system, we can still talk to each other. So that means that we can actually go and federate across the, across the boundary here and they can log into each other's systems. We know who each other are. That's all well and good.

And then when we go back and we plug back in, we can actually get updates, which might say some policy decisions about various members of the crew that have been updated from a central authority. This seems really awesome. We should be doing this everywhere, right? So few funny things happen when you start building out a shards. The first thing is when you run into your peer out in the water, which of you has the, the authoritative copy? Which of you is it either of you? Is it the one who had it most recently downloaded? You know who, who has that gold star version?

Now you're probably thinking, oh this is a data synchronization problem, right? That's solvable until you actually come up to somebody who is not a direct peer. They have their own identity provider, they have their own trust framework. Now when we're next to each other like this, this works pretty well. We can actually federate, we can actually take somebody from their boat and as long as they can reach their IDP, they can log into all of the applications and that trust framework works just fine until their boat starts to sail away. Oh my word. What is going on here?

Yeah, that's, that's what I'm saying. Something is autoplaying this and I don't know, dunno why.

So anyway, when you run into that, that peer, they have their own trust framework, you might be able to be allowed to connect to them. You might even be able to physically federate to them because you can do a local network. All of that works really well except that when their, when their IDP goes away, oh you know what? If you do full screen instead of slideshow mode, maybe depending on what you're loading it in as You know what would it work better if I just plugged in my laptop? We can do. Okay. Okay. Yeah.

So I'm just gonna talk through this as I get my laptop and close all of the proprietary information that's on the screen right now. 'cause I wasn't planning on doing this.

So anywho, when you connect into the other, the other systems, you are working in different trust domains. But you might be able to deal with that in a way that makes a certain amount of sense. And that is all well and good. It's USBC should be plugged in. It should be HDII Don't see HDMI. There's A-U-S-B-C up here though.

Oh, you want me to go straight to HDMI If this works? You can, Yeah, we can try that. Did you find it?

Yeah, it is, it is plugged in. Now that's, that's not me.

So, oh man. Spoilers guys, come on. We don't understand it Yet.

Yeah, yeah. Neither do I. It's okay.

Excellent, excellent. Alright. Thank you. Sorry about this.

Alright, you guys know this part, right? You know, Do, do do Justin. I think what we need to be also to say on this moment is not everyone has the opportunity to get into trouble with the PowerPoint presentations that EI sees. It's only for very selected people. So is it though, Is it? Alright so hey we're back with our orange boat. Now here's the thing is that they have an IDP so we can actually talk across and so she can come over to our boat and because we can still reach her IDP, everything actually still works just fine. And this is pretty great until her IDP likewise goes away.

Well, so if you're taking this whole like sharding approach, what you're probably gonna say is like, this is a pretty easy to think. We're just gonna copy her entire IDP domain into our system so that she can keep working. This will be great. Believe it or not, I have actually had people suggest a doing exactly this. The fun thing is when you look at them and say like, okay, so now are you going to also copy your entire directory into your in into the other systems? They'll be like, no, that's crazy. Why would I do that? That's all like personal security information.

I would never give that up. So it speaks to a massive power imbalance that people are looking at when they're trying to solve these types of problems when they're trying to connect to people out in these fields, in these disadvantaged environments. Furthermore, the view of this account in her home IDP system has actually changed 'cause she's not on that boat anymore. So if that account gets used in that boat, that's actually an error. That's a security consideration, right?

We, so if we were actually keeping sync with the state of that account on that IDP, she wouldn't be able to log into our systems either. And that's not really, really not what we want. So the way that we usually solve this today, let's face it, we give her a local account, we just go in and log in as the local admin bang in a new account and say, you know what?

Fine, just you log in here, you're on the IDP, you can use all the stuff and that all works great. And then we go sailing along just fine. Then we meet somebody who's having a really bad day and we decide that you know what, we're gonna help them out and pull them up outta the water because quite frankly it's really not been a good day for them. But the thing is now they're on board. Now they can actually be useful, right? Part of the ship, part of the crew. The captain should be able to look at that person and say, Hey, you new guy, loop the conniption pins and make me a tuna fish sandwich.

And you should be able to do that, should be able to do the pieces of access that he needs to within this context because they've done enough local vetting on this person for the context that they're working in, right? So what are we gonna do? We're probably gonna make another local account for this person and that's all gonna work just fine. But now you can see our view of the world is changed a bit from when we last synchronized, but it's gonna get a little bit stranger because weird things happen when you're out on the open water.

And we might need to change the status of some of these accounts, some of these attributes as we're going along. And we now need to write down the fact that this account has been altered. And since that has happened, we now have this view of the world. But it's all based on our IDP. This view makes a lot of sense for us. But here's where things get real funny. I go plug the boat back in to the shard, to the gold source. It is now telling me that I have an aberrant copy of the view of the world, except that my view of the world is actually much more correct for me than it ever was before.

Because I have gone through a lot of experience that this home system could have never predicted, right? And that also gets even stranger when we run into our peers before we plug in, we now have a variant copy of the IDP shard. They probably have their own version. Whether or not they met the same ot, we don't even know, but we now have different copies that we now need to deal with. The problem here is that when you take a shard style approach, shards assume that there is a central source of truth, right? That is the whole idea. You have a central authority and you're just propagating it.

It's a data propagation problem at that point. So you need to always be able to ask the question, what is that central hierarchical source of truth? Where does all of that stem from? I think that we need to ask the question, is there a source of truth? Is there ever a single central source of truth across all of these different systems? Maybe there's not. And maybe it's time to start rethinking how we look at federation, how we look at account provisioning and how we look at access, especially in environments like this, right? And not just on boats, but boats make for a great metaphor.

So bubbles, what if we take that entire environment and we sort of wrap it up into a bubble? We treat everything inside there as a cohesive system. Everything in there, all of the accounts, the applications, the access rights, the attributes, the status, everything inside there is a cohesive system, which means that within that system we can use all of our great federation technologies. I can do VCs, OADC, I could even do SAML on a boat if I wanted to. I don't think that's probably good for the boat, but people have done stranger things.

What changes here is we now have different way to look at how we cross the boundaries of this bubble. It's an internally cohesive system. So we really start to ask the question of how we get across that boundary. So when I'm going and plugging into the doc, I am talking to an authoritative source for a given account. That account can be onboarded into my system. This is different from me downloading a copy of an account directory because now they're saying like, we have a record of this particular account or this set of accounts. Get them into your system in the way that makes sense.

It is no longer here is the copy of truth of the world override everything that you have. We now have a way to start to reason about all of the different stuff that we may have seen while we're out there, but still be able to keep synchronization. Because you know when, when the orange sailor came on board, do we really want to provision her account back up to our home system? Probably not the guy that we got off the sinking sailboat. We probably want to tell somebody about him. He might be great at tuna fish sandwiches.

But you know, it's probably a good idea to tell somebody that we pulled somebody on board. And of course we need to tell people about the account that got honored. This means that we can deal with all of these local changes and still do this synchronization, but we can also replicate this pattern all over the place. And we can do this across many different bubbles. Now wait a minute, didn't I just reinvent shards and give it a different name? I'm not that good at marketing. The key thing here is that every bubble is unique.

We treat every bubble not as a copy of some core environment, but as its own separate unique environment. So that means that those local accounts, when we onboard them, instead of saying this is an account that is provisioned from some known source of, of trustable data, we say, we just made this and it's here and it starts with us. And so we can actually become our own trust route functionally for a certain subset of the world.

And this is a really powerful construct because when we go to update attributes and artifacts as the world around us changes, we can do that within our system in a way that makes sense. So now we have a way to talk about the fact that we have changed the status of this account for a specific reason, that we can then go tell another authority maybe that propagates, maybe that doesn't, that's not really our direct problem. Our problem is dealing with the things inside of our system because there's this well-defined boundary. All of the decisions, all of the identities are local.

Since we can replicate this a lot, this means that we have a whole lot of different bubbles. And when you bring all these bubbles together, you make foam. Now foam is a fascinating construct because it's all of these individual things that are moving around, bumping around, touching, and passing information between each other. So that means that when we roll up to our peers, that were provisioned by the same thing and we have very different views of the world. We're looking at them not as a copy, potentially aberrant copy of some source of truth.

We're looking at them as another source of truth, another authority, a peer authority, something that I can evaluate within that smaller context. And the same thing, exact same thing happens when we come up against our peers that are not from that same authority. This also means that when we do get somebody in from one of our peer authorities, we can write them down in the exact same way that we did for everybody else.

This means that we have created a way to have a mutual limited decentralized trust across this foam, across all of these different bubbles, across all of these different environments. And it's a trust that works even when we disconnect. So unlike a traditional federation management system where you have to get back to the IDP or you have to get back to the Federation authority, everything works because the account that you get is local to the bubble with all kinds of local provenance that are associated with that.

So you know where it came from, you know how to associate it and you know what to do with it. But here's the important thing, when you reconnect, you can say, Hey, this sailor that you sent our way, she was getting into some weird stuff that she probably shouldn't be. You just might want to know about that. I can give you information, I can give you updates. I can carry that with all of the provenance information about the account that I'm talking about as we are discussing things.

And furthermore, since the error is not a single source of truth, there is not a single hierarchical thing that everything flows down from well. We are now our own source of truth, which means that all of the people in our bubble are now eligible to be expressed outbound into other bubbles, even people that came from external sources. So in this case, I'm saying like, oh, here's the sailor that came from the orange ship to us, and this is the statement that I can make about that. I might not be able to say anything beyond that, but I can tell you that I verified it.

And if that's good enough for you, then we're good to go. In other words, we're using federation and by extension, VCs and certificates and all sorts of trust authorities as a provisioning mechanism, not an authentication mechanism. And it is a really, really powerful construct for a disconnected environment like this. After the fact, we can audit things because we know where everything came from. And in fact, we can audit across multiple different authorities. And each of these different authorities might need to know about different accounts and different attributes of those accounts.

The stuff that I'm talking about is not unique to this space. This is not something that I've just gone and invented. We have the technology to build all of the pieces today. We have the ability to connect all of these bits and pieces, but I am 100% convinced that there is not one single protocol stack. There is not one single solution that's gonna solve this. I've talked to a lot of people over the last year as we've been building out these prototypes and building out this concept. A lot of people have solved little bits and pieces of this.

There is not a single protocol that's going to solve all of this because the world is heterogeneous and all of our solutions have to assume that heterogeneity when we're connecting. Now, standards are a massive help in this, but standards plural, there's not a single standard that's going to connect all of these because I might be able to connect with VCs to one system. I might be able to connect with OIDC federation to another system. And if the both of those make sense for me in different contexts, I need to be able to have that make sense.

There's fundamentally a concept here that all of this stuff can get built in layers to give us a new view of how we look at federation and accounts in the world. So in conclusion, shards might seem to be the really obvious solution to this, but they're sharp, they're stabby, you know, not really all that great. Bubbles. On the other hand, they're flexible, they protect. And so if you ask me the future, at least the future that I'd like to see is made of bubbles. Thank you.

So just Justin, thank you very much and, and I think it was very smart move that you said after I warned you about some of the people in the audience that you sent your presentation to motion so that we don't have time, don't have time, so that we don't have time for questions from Sebastian and Hutch and some of the others in the room. So it was a very cool, very insightful presentation and I liked that concept. I liked the the way you displayed it. So thank you very much again and applause for Justin. Thank you.