-Hi, everyone. I'm Mirela Ciobanu, Lead editor with The paypers, global financial publication, and we are live at the Cyberevolution. And I'm about to talk with Justin Richer, CTO of UberEther, Hi, Justin.
-Hello. Thank you for having me.
-It's so... Yeah, it's such an honor for me to have you here. Especially because after reading Justin's bio, I was so impressed. He is the, founder developer and hard, the hard working man behind so many protocols used in identity. And, I'm curious about what excites you to what excites you most about your job to have developed so many things in this space.
-So I think the thing that excites me the most is that there is always something new that's happening. We are either developing some new technology and applying it to the space, or figuring out a different way that, things can be looked at and applied in new circumstances. You know, so, for example, right now, you see a lot of stuff about workload and machine identity, and this is something that we didn't really think about very much, say ten, 20 years ago, because when you went and deployed a server, there was an actual computer sitting on a shelf somewhere, and we didn't really need to identify it more than just be able to address it. Now, with today's modern serverless and workload and, those types of systems and machines are coming up. And down, left and right, they might live only for a few microseconds to handle something and then disappear. And so how do we identify and manage that dynamic of an environment is a really big question that we as an industry are really just starting to wrap our heads around. And, I really love that, in this space, everything is always changing.
-Yeah. So now, because I mentioned in the beginning that you have developed some protocols and, those are related to, identity authentication and things related to... Yeah, digital identity. What challenges? What what problems did you think at that point that, those protocols will solve?
-So, first I want to say that I was part of developing all of these protocols and stuff like that, and none of these gets developed, you know, in a vacuum by a single person, for sure. There's a lot of people that were involved and, for for each type of thing that I've worked on over the years, we were really looking at, a specific set of use cases and circumstances. So for OAuth, for example, the original idea with OAuth was how do I connect one website to another website? And this is actually how I kind of got into the security space in the first place. Way back earlier in my career, I was actually a researcher in social computing platforms. So how do people actually work together? Well, we had two different sites that we had stood up and people had accounts on both. But how do we actually share data across them? It was right around this time that OAuth was being developed, and that's how I got involved in that community, was trying to solve that problem of how do I get software to act on behalf of a user without the user just chucking their password everywhere? That's fundamentally what OAuth was trying to solve. OpenID Connect came along as a way to carry identity information using sort of the same strata of the same constructs. And so at each stage, I think it's always been fascinating to me how you start off with the problem that you're trying to solve. You start off trying to define this is something that is missing in the technological space. And I need I need this computer to do something that it's not doing right now. So how can I do that in a repeatable way and interoperable way, among different systems?
-Yeah. And since you mentioned, starting analyzing what's missing in the technological space. And for the first question, you said that now you observed more on identity related to machines. So how have these challenges that you wanted to solve changed throughout the years?
-Oh, that's a great question. And I think it's actually more interesting to frame that in terms of what is also similar across the years, because even though now I'm doing a lot of work with, machine identification. So for these, you know, microservices and workloads and stuff like that, we still have a lot of the same underlying problems. Is this software allowed to make this request? Is this system allowed to call across different security domains when it does? How do I address that security domain? And ultimately, at the end of the day, this stuff is all working on behalf of a person, right? Computers aren't just computing for the sake of computing, they are working on behalf of somebody. Kicked off a request, somebody needed to get something done. And so you still have the human identity. You still have this notion of different pieces acting together. But what's changed is how we kind of think about how we address each of the parts of that. So a person is no longer just whoever has this password must be that person, right? Because we've moved beyond passwords for a lot of different systems. We've got delegation systems like OAuth now, we've got federated identity systems like SAML, open ID and this notion of who a person is and how you identify them across all of these different security domains, that has changed over the years. And that influences how that carries in to the underlying systems. I remember way back, early in my career, what you would do is you would just ask the user for their password, and then you would just replay their password to a bunch of systems, because everything just assumed that if you had the password, you must be the user. And so that's all that I care about. But our model has actually changed as to what those systems are and how they interconnect. And that is influenced largely by how we've changed our model of what represents a user, what represents a person, and what they're allowed to do within all of these systems.
-So it seems that many things I have started to yeah, complicated a bit and we started to analyze them more things related to how we, manage identities. And now I'm curious. Yeah. How can we orchestrate everything? Do we have, like, a solution, for example? Yeah. You talk about federated bubbles, maybe to present to a more in details. What are those? Where can they be applied? What are the benefits and challenges of, implementing these type of solutions?
-No. That's great. So, the concept of a federation bubble is really it's looking at an identity system as a cohesive unit that is sometimes connected to other systems, but sometimes not connected to other systems. If you look at classical identity federation, you assume that you're going to be online. So somebody comes in and you figure out who they are by sending them back to their IDP, they get a new message called an assertion that comes back over to me that I can validate in real time. And then every other time that I need to figure out who that person is, I just send them back to that IDP and they come back with a new assertion, because we assume that it's always online and that even though the federated network might grow over time, we don't expect it to really have a lot of churn. We expect people to kind of come in with the same account and be able to reach their IDP, do the updates and things like that over time. The concept of federation bubbles really came about when looking at networks and, systems that don't fit that more static, always online model. So we're looking at cases of things where sometimes you're disconnected, from, from the home system. So somebody comes in, I might be able to reach their IDP today, but, tomorrow I might be offline or their IDP might be offline. And I want them to still be able to access my system. Now, if you think about it from a policy perspective, this is somebody that I've already proofed. I've already brought them in. I've already decided that this person is okay. Nothing has really indicated to me other than I can't reach their IDP. Nothing is really directly changed. So if I'm pretty sure that it's the same person, then why wouldn't I let them in? Even though I can't reach their IDP now, two weeks down the line, I might be saying like, hey, it's been a while since I've checked that you still have that account that we based all of this trust off of. Maybe now I'll send you back. You know, I come back online, I see that your IDP is available. I'm going to say, hey, go log into your IDP right now just so that I can make sure that you're still there. And so this whole notion of the bubble is really taking this concept of a, you know, robust and resilient, independent system, but carefully defining what the connections are around the edges. So the people coming in and then of course, being able to send people from my system out into other networks in the same way, and that allows us to organically build a very dynamic, very robust network of different identity systems where people can move in between them all based on whatever hyper local policies and needs each of these individual systems has.
-And if I were to extract some use cases for financial services or benefits from this concept, what would those be? So for example, I'm thinking, yeah, the GDPR data privacy. Here you can select exactly what information you want to disclose or age verification or...
-Yeah. Exactly. And so what if, for example, you could do your identity proofing with one bank and then use that, leverage that to go talk to a different bank without having to restart the process all over. Right. So the second bank that you go to might want to ask some additional questions. They might want to verify some additional stuff. But if you could carry something with you that said no really, I have an account here and I can prove that I got it from over here right now. Then you can really start to think of it in terms of you've got two independent systems and I end up with two different accounts, but they both represent me and they're linked. They're linked in a way, that actually establishes trust across them. But they're not linked in a way that every time I go log in to the second bank, the first bank knows that I'm doing something over here. And that is a key difference in terms of, data privacy, because in a traditional federation network, when you go and log in, your IDP knows that you're logging in somewhere. And, in this model, once I have established that account, I'm going to be authenticating directly to that second system. Every time, instead of going back to my home system each time. I also think that there's a really interesting space in, the financial sector for this model to be applied in terms of resilience. So say you're a large bank and you've got a lot of little branches and stuff like that. You want each of those branches to be able to operate, even if they lose internet connectivity for a bit. We've actually seen this, at my company. We've talked to people working in the manufacturing sector. They have individual factories that they need to keep running, even if they can't connect back to the home office. Now, back 20, 30 years ago, that was no problem because each building would have its own stack of computers sitting in the back. And, the problem with that, of course, was that everything was just was just disconnected. It was very decentralized. But that meant that somebody could have a rogue account on one system, and you would never know, because it was over on this one building. And nobody ever really looked into that. We moved everything to cloud based systems so that we could have insight and control and management across all of these things, and we get online robustness from that, which is really, really great. But what we lost is the resilience to being disconnected. So in the bubbles model, each of these factories or each of these bank branches would have its own system, its own set of accounts that when it's online it can synchronize, it can connect, it can call back to the home systems for auditing purposes, for account management purposes and all of that other stuff. But in the day to day, it doesn't need to do that all the time. So I go to my local branch and I can just say “Hi, I’m me” authenticate, take care of whatever I need to and then I'm good to go. Same with the factory. People can come in, get on to the factory floor, authorize to the machines that they need to use in order to do their jobs. And it works without having to call back to the Home Office all the time.
-Yeah. And now I'm curious how this concept, because there have been some discussions that the events related to the European digital identity wallet and some, similar developments have been in the US with the mobile driving license. How can this concept or some ideas from, federated bubbles can be inserted within this wallet to make them work?
-So to me, the digital wallet concept is a is a really fascinating thing from a technological perspective because we've kind of almost accidentally reinvented certificates, X.509 style certificates, but with some different assumptions around how they're created and used. Because if you think about it, an X.509 Identity Certificate combines key presentation, attributes everything into something that you can carry with you. The certificate itself, it's got terrible usability. It's got all sorts of management problems and stuff like that. But fundamentally that's what it has at its core. Well, with a digital wallet, we've solved a lot of the usability problems. We've solved a lot of the attribute disclosure problems in a technological sense. So we've been able to carry some of the better aspects of the certificates in that I can issue something to a person that they can carry with them, and it doesn't have to call back home all the time, but we've managed to do so in a way that sort of assumes a more dynamic world, where sometimes you're online, you can be able to check things and whatnot. So to me, the whole notion of being able to carry a, credential in a wallet and present it to each of these different networks is, really a very powerful, enabling technology for the type of dynamic onboarding that we talk about when we talk about these federated bubble systems. Because when I approach a new bubble, a new, independent network, well, if I don't have to go back to my IDP, if I can just hand you something from my wallet that you can verify, even if we are offline, when that introduction takes place and you can verify that, cryptographicly that I am, at least at some point coming from that place that allows us to, do this onboarding process in a very rich way that, I wouldn't necessarily be able to if, if I was relying on an IDP and we were offline.
-There were so many, many benefits. And since, yeah, I mentioned, talks about, European digital identity wallet and cyber evolution, but what are some trends or some ideas that you take back home from, the event?
-You know, one of the biggest things that I've been taking, back from this event is the judicious application of, of AI in a way that actually sort of helps people in AI today. We mean the large language model, AI systems. I've been in the industry, in the tech industry long enough that AI has meant many things over the years, and it will continue to do so. But the, one of the biggest things that I've seen, and this is a part of my own talk this week as well, is that I make sense as part of sense making. I have a lot of inputs, and I need to, as a human, come up with some explanation, some course of direction that I can take based on that. And so for me, that is where it is. It can be most judiciously applied as a tool where I think things start to go awry, at least with today's systems, is that we start looking to AI to actually take action. We start looking at these systems and saying like, oh, we can give me an answer that looks like it's right. So I might as well just let it go, take the action and go do the automated pieces as well. So there and I think lies a lot of danger. And I think we've seen that a lot in talks this week of, systems where the AI will come up with something that an expert can verify, but an expert would say, we're not going to do exactly what that says, but this gives me the information I need to do in order to actually make the decision and take the action.
-Yeah. So it's more like a companion, a guiding, an organization, a mental organization of principles, than actually the thing that is doing the the action.
-Exactly. It still needs the human expertise, to create what the appropriate response to that is.
-As we saw, actually the humans won last evening.
-Oh, yeah. Yeah.
-It was a competition between the humans. So wanted to detect some, keywords behind some features, generated by AI. And. Yeah, it seems that we did better. Great. Thank you, Justin, for, for this interview. And I look forward to continue our discussion.
-Absolutely. Thank you so much for having me.
