Slides, that's useful, because apparently... Apparently I have a very important slide in the middle, I'm just wondering which one Katrina thinks it is, but fine. Hi everyone, I'm Andy, hello online people. I'm also Andy, for you online. I'm going to start with a disclaimer.
So, many of you will have seen me talk with my Identiverse conference chair on, my Authenticate conference chair on, and generally what I'm doing there is I'm providing an overview of industry direction, I'm providing summaries of best practice recommendations, I'm trying to help people leave essentially with more, I guess, more answers than they have questions, right? This is not that talk. This is not my usual talk. It's very much a thought experiment. You're not going to leave with a set of recommendations. You're going to leave with more questions than you had coming in.
That is absolutely my intention, and it is also not my intention to be the person who answers those questions, right? I'm deliberately throwing this out there to start a conversation. I should also say that experiments can go wrong. They do go wrong, it's part of the point of an experiment. It's entirely possible that some of what I'm suggesting here is impractical, is impossible, is implausible, but I think that the question that I'm about to ask and the direction that I'm about to paint, at minimum, needs significant and urgent conversation. At minimum.
And if all I managed to do today is start that conversation, that's good. So with that, let's ask a nice big question. It's a nice big question. Why do we have user accounts?
So, if we were in one of the wonderful kind of, you know, we've got half a day to do this, we'd get a whiteboard and we'd get everybody to shout out answers and we really can't do that in the 18 minutes that I get. But if we were to do that exercise, we'd probably end up with a big list of reasons and some of these things would probably be on that list and there's undoubtedly a whole bunch of others that would be on that list. I'm going to suggest to you that none of those reasons is correct. That's not why we have user accounts.
Those are things we do with user accounts, certainly, but it's not why we have user accounts. Why do we have user accounts?
So, the reason that we have user accounts is because of a thing called CTSS or the Compatible... I'm having to read this off the slide because I can't remember the acronym and in a minute you'll understand why. The Compatible Time Sharing System.
Arguably, this is where user accounts start. This is the dawn of modern multi-user computing back in 1962. It all started with this statement from John Backers in 1954. By time sharing, a big computer could be used as several small ones.
So, John Backers said that in 1954. For those of you that are about as good as me at mental arithmetic, I'll save you the effort. 1954 is 72 years ago. 72 years ago, John Backers proposed time sharing. A few years later, this thing called CTSS came along.
Now, CTSS is interesting because it does a whole bunch of things that are going to seem eerily familiar to people in the room. CTSS provided one of the first inter-user messaging implementations or email as we like to think of it. CTSS actually had one of the first implementations of instant messaging. CTSS ran Eliza. Chatbots are not new. Very excitingly, thank you CTSS for giving us the first password login. Very grateful to CTSS for that. Why did it give us the first password login? Because it also gave us time sharing via user accounts.
That, ladies and gentlemen, that is why we have user accounts. We have user accounts in order to do time sharing. Guess what? Computing has progressed somewhat in 72 years. We had local area networks and wide area networks and the internet came along and we had the web and we've got APIs and we've got agents and user and account never evolved. We never went back and said, wait a minute, we built this thing to do time sharing. Is that actually still what we need these things for?
Basically, we're still doing this to all intents and purposes. We might be doing it in LDAP and I couldn't be bothered to write the LDAP instruction. We're embedding attributes about people into tables in databases and then we're using those attributes to make access control decisions. That's basically what we do. And if we're honest with ourselves, we've known for a little while that that's not fit for purpose.
We've been trying to work around these limitations that we have, this existing system that we have with things like automated or just-in-time provisioning, account linking, service accounts for robotic processes and we struggle with that. We struggle with it for a couple of reasons. One reason is that fundamentally a system, piece of software, API, agent is not a human. It's a different set of attributes, a different set of requirements. It's not fundamentally the same thing. We're trying to fit it into a box that was never designed to hold it.
The biggest reason we struggle with it, no pun, well, okay, a pun intended, is scale. Now, I mentioned earlier, I'm not great at maths. It's not my strong point, but that aside, in another life, I would have very happily been a physicist, preferably an astrophysicist.
Now, astrophysicists deal with things at very, very large scale, and they're really cool things, right? They're like star formation and galaxies and dark matter and really cool stuff. But as a human, we're not great at understanding scale.
So, 100 kilometers. Most of us can probably get a reasonable sense. It's like a few days' walk, it's a long day out on a bike. Kind of have a sense of what 100 kilometers looks like.
1,000 kilometers is a little harder. We're getting into kind of road trip territory at this point. It's difficult for us to really understand how far that is. Here's the sun. The sun is, my son, who's about to go and study physics, made it very clear that I had to say this very precisely, this next thing. The sun is, on average, 149.6 million kilometers away from the earth. None of us really can get a handle on how far away that is. So we solve that problem by creating a new unit called an astronomical unit, which is that distance. We are exactly one astronomical unit away from the sun.
That feels much more manageable, right? Like it's just one, it's just one thing, it's really close. We can reach out and touch it. One astronomical unit is roughly 499 light seconds away. As you all know, that means it takes about eight minutes for light from the sun to reach us, or roughly the length of time I've been speaking. So it's good, because it means I can check whether I'm going at the right speed in the presentation. This is Proxima Centauri. Everybody say hello to Proxima.
Hi, Proxima. Proxima Centauri is the next closest star to us, the constellation of Centaurus. Proxima Centauri is 4.2 light years away. Everybody say hello to Proxima. 4.2 light years. And that's just one star, which then makes us wonder, well, how many stars are there? Quite a lot, turns out. The European Space Agency have got a nice paper on this, if you're interested, it will tell you how they work it out. Bottom line is, once you get to this scale, it stops being comprehensible, right? It doesn't mean anything to us. It's unfathomably large. It's an unfathomably big number.
Or, with a typical British understatement, the universe is really rather big. So is the universe of users.
So, I've heard all sorts of numbers this week, right? I've pulled up a couple here. You could pretty much pick a number out of thin air at this point, but for the sake of having sources, this one is from a civilian security, 25 to 50 times human users outnumbered by not human users. Here's another one. This is a ratio in the range of between 45 and 100 to 1 from Cyber Strategy Institute. This question has come up quite a lot this week. I've heard it asked in various places, How many non-human users am I going to have to deal with? Non-human actors am I going to have to deal with? You know what?
It doesn't really matter how many. The answer is, really rather a lot. And those different types of user act differently. They have different threat profiles. They have different requirements. And so we've already started to try and work around that problem on the existing infrastructure that we have, which, remember, was built how many years ago? 72 years ago, right? We've started to do this mostly by creating these things called ephemeral accounts. An ephemeral account is basically an account that you create and destroy very rapidly, typically for one purpose or one request.
That has some issues. It's inefficient. It's risky. You're making lots of create and delete actions. Very easy for that to go wrong. So why are we doing that? We're doing it because we have this thing called an account. And we don't know any other way to do it. We're using the tools that we've always had, but they're no longer fit for purpose because the environment that we're using them in has fundamentally changed. If you're a farmer and you grow vegetables in a field, you probably have a tractor, right, to plow the field.
If you start growing those vegetables in a hydroponics farm, your tractor's not going to help you very much. You can try and repurpose it to filter the water in the hydroponics farm, but it's not a great solution. Put differently, the way we use the Internet is fundamentally changing. And if we keep designing our systems on this basis of we assumed a human actor, we will fail. I'm just going to let that one sit for two seconds because I haven't got much longer. Human users are the edge case.
And for those of you in product design, we know very well that we try to avoid designing major systems for the edge case, right? Now, let me be clear.
This, I think, is a true statement. But as an aside, and for another talk another day, it's really important to remember that in this context, for those systems where the human user is the majority use case, we have to be really, really good about building solid user experiences in those cases, right? This is not an excuse to say, oh, no, it's fine, I don't need to worry about my human user. But for the infrastructure, the infrastructure, is the edge case.
And if we already know that permanent user accounts for non-human users are causing us problems, we need to start to design our infrastructure for the majority use case, which is not a human. So, Eve talked about this on day one, and I was like, oh, that's a shame, I was going to do this joke, but Eve took it, so, oh, well. It's become something of tradition at these things to declare things dead, right?
So, very famously, SAML was an early and repeat victim, SAML is dead. Authorization has died at least once, but it came back more powerful than you can possibly imagine. WS-Fed is dead, which is probably a good thing. User accounts are dead, or at least they should be. We need to get to a point where we're not building infrastructure that relies on a user account. 72 years is enough time for us to realize that we really ought to build something a little bit more suited to today. There ought to be a better way to do this. There really ought to be a better way to do this.
Frankly, there has to be a better way to do this, because we cannot continue building our infrastructure if it just won't work. So, I think the way we get to something new is that it starts with a fundamental realization, which accounts is not the same thing as an identity, right? We've been conflating those things for a really, really long time. To paraphrase my friend and colleague Steve Wilson, he talks a lot about how the data is the thing that matters, and he's right. We can get to those authoritative signals, but there are different ways for us to get at it.
So, hold that thought. There are, I think, three things that are starting to come together that will help us get to a place where we can answer that question, where we can deal with this problem of, what do we do instead of user account? And we've heard about all three of these things at various points during the course of this week.
So, if you're doing this work, you need to be. One of the things that this allows us to do is to treat identity as the mutable construct that we all know that it is, right? And that allows us to vary access rights in real time, at request time, and one request at a time. And that gets us to zero standing privilege, which we all need to aim for. At the same time, we've got the advent of verifiable digital credentials and wallets, and they allow the user to present an appropriately authoritative attribute about themselves in a privacy-preserving and trustworthy manner.
And then we have AI agents, and in time, those agents will be able to present those verifiable digital credentials on our behalf. Ian has spoken about this at least three times, to my knowledge. A couple of times further back, IDFJ and Identiverse, and subsequently here at EIC, spoken about the notion of a counselor that would allow that intermediary action to happen, and we're starting to get there. Those three things coming together start to point us towards a better way to deal with users and accounts. Very briefly, then, what do we think that might look like?
If we find a way to get away from user accounts, what does that look like? Here's a fictitious example of somebody who's looking to book an evening out for her spouse, likes jazz, so she's going to go find some tickets for a gig, she's got a restaurant reservation, special night out, she's going to book a limo to take them both there and back. So she's got to find the gig, she's going to purchase tickets, to do that, she's going to create an account.
Great, another username and password, whoopee! And there's an account on the other end of it. Find a restaurant, make the reservation, oh, she's got an existing account there, that's fantastic, she gets to use a passkey to log in, hooray! And then she has to go do another account, this time she gets to create one that generates a passkey. Fine.
Tomorrow, this can look like this. Find the gig, purchase the ticket, great. Here are the relevant credentials from my identity wallet. Find a restaurant, need to make a reservation, fine. Here are the relevant credentials from my identity wallet. No account was ever created in that process, it wasn't necessary. The user experience is better, it's consistent across each one of those different environments, no off-task interruptions to figure out where the hell I'm going to store stuff, or where I'm going to retrieve it from, or, oh, did I put it in the other password manager that I have?
It's more privacy-preserving on both sides of the equation, and it's easier to automate, which is going to be really important for everybody. And somebody sitting in the audience going, yeah, yeah, but SIAM is easy, and to a degree, they're right. The tail is not quite as long, it's a little bit simpler to deal with. So what does workforce look like in this case? And very similar, right?
Somebody had a supplier, today they have to create an account on the large automotive portal, they're going to do that, they're probably going to have to wait, there's now an account to handle at the point at which they leave, that creates all sorts of problems, and leads us into this world of standing privilege that we really need to get away from. Workforce tomorrow, completely different scenario possible if you put those three different things together. No account required, and when Joe leaves, the credential is revoked, there's no account to delete, it just happens. It's just taken care of.
So, 72 years is enough time with user accounts. The world has changed. The world has fundamentally changed on the internet. We need a new identity infrastructure to support that. That new identity infrastructure will deliver us better experience, lower costs, improved security, and easier compliance. It gets us back to no standing privilege. We've got the tools to do it. It's a lift, but we've got the tools to do it now. There is a better way, but we really have to start building it now. Thank you.