How Do We Get There From Here? Charting a Course Into the Future of IAM

Thank you all for sticking around so late in the evening. I was worried I was gonna be giving this presentation to a totally empty room and I'm glad that I'm not. So I wanna talk a little bit about charting the core to the future of I am, especially from sort of the business perspective. 'cause I think one of the things I've seen a lot of during the conference over the last few days is there's a very nice and very admirable focus on how these identities are gonna affect our personal lives. And that's important.

But I think it's also important to realize that the course that businesses are likely gonna take internally is probably gonna look a little bit different and should look a little bit different. Now, before we dive into that, I wanna do a little bit of a retrospective that might be surprising right now. Unsurprisingly, in the very distant past when we all lived in tribes somewhere, which all humans did, at some point, the identity breach was impossible because you knew everyone in your tribe, you'd grown up with them. You could recognize their face, you could recognize their voice.

They couldn't really impersonate anybody else. Life was good in that respect, right? But as soon as we started moving into cities and villages first, right? It became possible for people we didn't know to encounter us and vice versa. And so impersonation was possible. And so for the very first time over 5,000 years BC we saw people starting to stamp their signature onto things that they wrote to say, I wrote this, it's me. So it was an assertion of who they were, but it wasn't really provable, right? Somebody else could forge your stamp and stamp it on something and you know, who knew.

So we moved forward a little further and people came up with the idea of wax seals started in China, but it spread across the entire world rather quickly. And it provided two benefits.

One, I could stamp something to assert who I was and I could also detect whether anybody had tampered with my message because if the seal had been broken, the message had probably been read. So we had sort of a message tampering feature built into communications 3000 years ago, right? Then the Romans had this little problem where people would show up at their fortresses along the frontier and claim to be Roman soldiers and then get inside and attack people.

So they started issuing what they called watch words, we might call them passwords, to authenticate people trying to get through the perimeter. 2000 years ago, right?

In 1379, ad an assistant to the Pope started using a cipher book to make sure that not only could they determine that their messages hadn't been read or intercepted and they came from a legitimate person, but that they hadn't been actually consumed, nevermind, tampered with, but that they couldn't be read. And so encryption was born in its earliest form and we finally get to 1677 AD when the British government realizes that there's a bit of a problem with these wax seals, it's getting easier to forge them, right?

And of course people are signing documents now on ink on paper, 'cause we're not just putting clay tablets or stone tablets out there. But that wasn't super reliable either because unless you knew what the person's signature was supposed to be associated to, unless you'd seen it before, that wasn't really helpful. And so they mandated that all official documents needed to be signed and stamped. So something that you knew and something that you had, sounds familiar, right? This was almost 400 years ago.

And of course in 1876 with the advent of the camera, the very first concept of a photo ID came into existence. So why am I stopping in 1876? We're here talking about the future of it and security, right?

Well, the point I'm trying to make here is that every single problem that we think is really new that we're facing today is actually as old as humanity itself. What's changed are two things, context and scale. And every time those two things change, we adapt how we address these challenges. But the challenges have never changed. So now that context has changed, that means our current solutions aren't really fit for purpose anymore. And now we need to adapt. So there are some assumptions that have been true in the past that aren't true anymore.

And I always find those are the most dangerous assumptions. Assumptions that were never true are pretty easy to dis discard, right? But assumptions that were true at some point in the past that have become untrue can be really difficult to dislodge from our minds. So IT and HR functions that are run best separately, I can't tell you how many IIM projects I've seen in business fail because one side didn't want to talk to the other and didn't really think they needed to be involved in the decision making. Identity data is all best stored in a directory, right?

We've got lots of attributes about users with credentials in there. And you know, I don't know who loves that more than an attacker who just got access to your network and you know, wants to great memory for some stuff, right? And of course we have the belief that current MFA is user-friendly because we're doing push notifications. And that's so much better than carrying around tokens on our key chain that we can swing around for self-defense when we need to. That's not true anymore either. And that causes some problems, right? HR processes are really manual.

And if you talk to any law organization, they will tell you that multiple times a year they spend up to seven figures clawing back access and IT assets and things that users wrongfully received, right? It can't independently validate that, right? Because they don't have access to the identity information that per purse first presented when they got hired. They're just getting a ticket, they're actioning the ticket done, right? That doesn't work. Credentials, of course, are constantly stolen, left, right, and center. We ourselves were victims of an attack that sought to do that.

Thankfully they weren't super successful, but that was what they were after, right? And current MFA techniques are hugely user unfriendly because as we try to mitigate attacks against MFA as it exists today, we're adding steps and that may mitigate the attack. But I assure you users don't love typing their username, their password, receiving a push notification and then maybe typing a code. It's not fun. So we need to sort of break it down into what are we really trying to accomplish? And what we're really trying to accomplish is pretty simple, right?

We wanna securely identify the user, we want to give them access to things they're supposed to be able to access. We wanna make sure that they're doing that on the device they're supposed to be doing it on. And of course, we wanna be able to create and enforce policies that make that true. And we want to be able to do that without repetitive annoying challenges, without being vulnerable, hopefully to new types of attacks. And of course, we want to adjust for the fact that many users in today's environment, especially those working remotely, have lots of devices, right?

And if we can't do that, then it isn't the way forward, right? Again, time to adjust. We have to recognize that no amount of tweaking MFA and usernames and passwords is gonna fix them, right? And I realize I'm in, I'm, I'm in a room full of people who probably realize that we've been talking about digital identity all week. And I think the key realization is that we meet, we need to take a step change. We need to take a leap of faith and sort of abandon some of the paradigms we've had up until now.

I love this quote that the invention of the electric light did not come from the continuous improvement of candles, right? As innovators, especially at larger organizations, we have to realize that in the beginning there's going to be a conflict between the next incremental improvement we can do to the system we currently have. And taking a leap to something that initially may not serve every single requirement the business has under the umbrella of identity, right? But it's gonna start to solve problems that the current solutions can't solve. And we need to embrace that.

And if that requires spinning off a small little working group to work folk, you know, to work just on that and not have to compete with resources with, you know, the larger IT organization, that might be what we need to do. So the question I wanna ask is, should a user in the future really need to think about identity and authentication at all? Right? Why do they do that right now? They do that right now because we need information from them. Historically, we needed to ask them for things because there was no other way to get that data. Is that really true anymore though? I don't think so.

My goal would be that in five years from now, a user holding a digital identity of some kind in their pocket onboarding to a new organization they just got hired at, should think that MFA died. Now they're gonna be wrong, right? In the background, there's all sorts of data we need to collect and understand about them, their location, their behavior, what they're accessing that we're gonna need to know. And that's not gonna change. But they shouldn't have to think about it. So what do we have to do? We need to fake a murder. All right? So how do we successfully fake the murder of MFA?

Well, we need to accomplish all the objectives we talked about before. There's really only three, right? Identify the user, identify their device, and enforce access policies about what they're supposed to be able to get to. We need to make sure that we do that with a user experience that's so transparent that in most cases they don't even know it's happening beyond their giving their consent to log in. And of course it has to be performant. 'cause if it's slow and it redirects you to five different websites that flicker on your screen, that really hasn't accomplished the goal either.

And so there's a number of emerging technologies, many of which people have been talking about all week here that sort of paved the way for this to happen. But I think the way that it's gonna happen in the business world is gonna be a little different and needs to be a little different than the way it's gonna happen for personal IDs that we might use to interact with state agencies and things like that, right? Especially considering, you know, we're gonna be looking at device behavior, we're gonna be tracking what users do.

Now, those are things we don't want to do in the personal realm, but when it comes to using corporate resources to access corporate assets that have sensitive data, we absolutely do want to have a look at what the users are doing. But this can inform our decision making about authentication and authorization without having to bother the user. So verifiable credentials are obviously gonna be a key part of that because if you want to not have to type a username and password anymore, you need to replace them with something, right?

Passkey, were an amazing first step for that. Got rid of the password, but they don't know anything about you. So you're still typing your username at least the first time.

Well, with a verifiable credential, of course it does know things about, you can know many things about you. And I've always said, if you're gonna take on the two fields that are on the login screen, why would you only aim to kill one? Kill both. But the other thing we wanna do is realize that that doesn't end at the moment of log, right? The threat continues after the user has been authenticated and authorized. And so we wanna do things to detect identity threats and be able to respond to them. We wanna be watching constantly.

And there's a number of protocols that are being worked on right now that allow us to do that. Shared signals risk-based access. There's a number of different names for the efforts that are going on, but the idea is to essentially say, okay, I've given you a session. Does it look like your session cookie's being used in two places? Does it look like there's a device accessing an application you have access to, but it's not secure? We wanna block that device, right? We wanna be watching the whole time.

And for applications to be able to talk to each other about that is really important because if I'm accessing HR data and I'm trying to exfiltrate a lot of HR data that may not be directly related to me going over to active directory and trying to look at user data, but it might be, and I might wanna be able to let that application know to terminate its session as well, right? So we want these things to be able to talk to each other.

Now, verifiable credentials, I'm pretty sure at this point in the conference, everybody has a pretty good high level idea of how that works. But just in case, you know, the basic idea here is not that different from the way X 5 0 9 certificates work in the idea that I want to be able to issue you something that has attributes about you that are cryptographically verifiable. I want the verifier to be able to check that without having to phone home and tell me about every single usage, right? And I wanna store a record of that on some kind of verifiable data registry.

Now, one of the really cool extra bits about it is, unlike a certificate where I have to present the whole thing, I can selectively disclose only the pieces of data that are relevant to what I'm trying to do. And that's a pretty huge gain for privacy. But let's talk about the problems that it actually solves for us. So talking to a HR and IT organizations, including our own and a number of others, you know, the process today still looks pretty much the same way it did 15 years ago.

You show up for your first day at work or for an interview and you present a physical identity document in most cases. And the folks at hr, they're gonna take a look at it and they're gonna make a value judgment. Did he just come with a fake ID that says LOV on it? If anybody remembers that movie or does it look legit? And if it does look legit, then we're gonna proceed forward and we're gonna start a background check, right? But sometimes there's a very urgent need to get you onboarded. Happens a lot.

And so what they're gonna do is they're gonna issue a ticket to it saying provision a laptop and some credentials for this person. And it can't see that identity information. And they're not really qualified to validate the authenticity of documents anyway. So they're gonna take the ticket's word for it and they're gonna create some credentials and they're gonna send 'em to your manager who will then give them to you and then you'll reset your password and you'll get a laptop in the mail, or you'll get it on your first day in the office.

And do we know that we actually delivered that laptop and credentials to the person who we interviewed umpteen weeks, maybe months ago, whose background check is still pending? Well, I can tell you from talking to it and HR organizations, the answer is no.

Many, many times a year, this does goes completely wrong. But if we imagine a future where on interview day I can show up and I can then identify myself with a digital credential that HR can keep a record of, they may even choose to issue me with a temporary ID that I can hold onto throughout the interview process. Well now I show up for my first day at work and I present the same digital credential that I had during the interview. It's verifiable in the ticket to it.

I can include some of the information about that verifiable credential so that it can provision a laptop with my existing credential and send it to me, right? And I can deliver it to the wallet via push notification or via any other method that's being worked on, right? And I get the laptop and because it's already been pre-provisioned with my credential, I'm the only one that can unlock it. So if it went to the wrong person, 'cause the mail messed up, no big deal. But if it came to me, now I can log in. So how do we get here?

The way we've been thinking about it's there really needs to be two distinct on-ramps. The first one is for the majority of folks who right now do not have a digital id, right? And we don't want to exclude them from this system. And so we need to have an on-ramp. And we think that third party identity validation is probably the best way to go for this. There's numerous organizations around the world that have the ability to validate documents from all kinds of places.

And if the attributes on your ID match the ones you gave us during the interview and during your onboarding, we can be reasonably confident that you're the same person we are trying to hire. And then we would aim to issue you an employee ID as a verifiable credential. Now in the corporate world, right, we don't really want people logging into their corporate resources and assets using their personal id. I think that breaks down a barrier that really probably shouldn't be broken down.

We want them to use a corporate credential and then we can tie login credentials to that, to various systems as that person changes job roles if they happen to. And all the user really needs to do after receiving those credentials is consent to log in, right? In the background. We can verify the credential, we can do things like looking at their device. We can look at their behavior, we can see what, you know, where they usually log into during the course of, you know, doing their job responsibilities. We can ask the shared signals framework.

Anything weird going on in any of the other applications they're logged into, Hey, we can come to an authorization and authentication decision without really ever having to bother them, right? Just ask them to consent to log in. And of course, if they come to us with a digital id, if they happen to be European citizens or citizens of a few lucky states in the US that have digital driver's license says, then the only question we really have to ask ourselves is, do we trust the source? Right? Is the issuer someone that we want to trust?

And if the answer is yes, and the details match what they told us during the interview, great funnel them into the same onboarding process. And in fact, in the very beginning of this, it's not necessary to actually issue them a verifiable credential. If you're not ready to do that, what you can actually do is simply use identity validation or an existing verifiable credential from a state entity to issue them a pass key if that's what your infrastructure concurrently support. And that way you don't have to worry about anything downstream from there. Everything just keeps working.

But the idea would be to migrate to a verifiable credential over time. Now, one of the other things I hear a lot at the conference is, you know, that's gonna replace directories, that it's all gonna be decentralized, it might go on blockchain.

And again, in the case of your personal state id, there's a very good reason to do that, right? We want this to be resilient, we want it to be accessible from anywhere. We don't want somebody to be able to take down your country's server and then now you can't validate yourself. But in the corporate space, the incentives are different. Is it really desirable or even necessary to want to have all of the corporate asset data and the things you're entitled to do published all over the internet? Probably not, right?

I don't think directories are actually going anywhere, but I think they are gonna change a bit and in a good way. So when we were attacked, right? One of the reasons that the attacker went after our active directory was because that's where all the credentials were.

Well, in a verifiable credential world, you don't need to have any credentials in your directory. You can imagine a future where the directory instead is gonna simply be a whole bunch of public key information tied to some authorization attributes. If the attacker breaches that good for them, they're not gonna be able to steal your credentials or, or escalate their privileges, right? So they're gonna be more focused on authorization, less on authentication. The authentication information is gonna live in your pocket, right? Or on your corporate laptop for that matter.

If you don't wanna use your cell phone, we wanna have tighter integration with HR so that if someone in HR needs to look up or someone in H in it needs to look up whether the person logging in is in fact the person that has the HR record, they should be able to do that. But all of those HR style attributes, you, your manager, your job title, all that stuff does not need to be exposed at login time anymore. Verifiable credential solve that problem. So again, the goal there is to make that so that essentially you have as lightweight a directory as possible.

You want it to be flexible because of course no one is gonna cut over from username and password to verifiable credential overnight. So you want to have a directory where the schema can include usernames and passwords. And as you start, and then of course be able to remove those fields as you decide that that person's either moving to pass keys or two verifiable credentials, sadly, something you can't do with active directory today, that would actually help smooth that process a lot. And so we're actually working on a directory that aims to accomplish that goal.

And of course with the shared signals framework, we wanna make sure that as many applications as pop possible are able to share that threat data with each other. And so in the end, we essentially envision a pyramid looking somewhat like this digital identity and verifiable credentials at the tip of the spear. This is what the user's gonna see and interact with. In an ideal world, they really shouldn't have to think about it very much at all.

There was a panel on just a little while ago where you said the ideal wallet is a wallet that just you get data in and out of the user doesn't really have to think about it unless something's wrong. Right? Underneath that we're gonna have a directory that stores your corporate authorization. We're gonna think about authorization attributes, not credentials, right? Underneath that, we have a shared signals network that's gonna be telling us, once we've authorized you and done the first two steps, are you doing the things we expect you to do?

Because if not, we need to cut you off even if you are the right person. Right? Under that, we're gonna have single sign on because of course, again, this only works nicely if you don't have to do it five times a day, right? And of course those mechanisms already exist. And finally, we need to make sure that there's a secure access layer underneath that actually protects the connectivity. Once we've done made all the decisions about you, your behavior, your device, you're not doing anything nefarious somewhere else, now we need to connect you in a way that also is as unobtrusive as possible.

That may be a VPN still for some infrastructure that's legacy. But ideally, if you can do that via zero trust network access, so much the better because then the user doesn't need to think about where their applications are located either. And the nice thing is work in all of these areas is ongoing solutions are already available. And if we remove that need to necessarily decentralize everything about identity in the corporate space, I think we can actually arrive at this future a lot faster than we think.

And so, in my opinion, the future is quite bright and let's go do it. Thank you very much. I'm glad to hear that you're so optimistic. I'm also delighted that you are one of those people who are trying to balance user experience with security, but how is this message landing so much with the enterprise though? Because for quite some time we've been going MFA is the way to go. Yeah.

You know, it's, that's, it's like I was saying, the assumptions that were true are the hardest ones to dislodge because everyone remembers when they were true. And in fact, there are a lot of tokens for MFA still sold today. That's how hard that is to dislodge. So I think there is some inertia there, but I think there's also an eagerness to find a solution that can really work for enterprise. And if you present it as you actually don't need to rip out everything and change everything about how you do it, I think that does actually land better.

'cause the moment you mention, unfortunately distributed ledgers, which we now say as the code word for blockchain, people do get a little bit nervous. And if you say, well actually your directory doesn't have to go away, we just want you to use it a bit differently, that is more well received. And of course there's the, the plus that from an end user point of view, it's kind of just much easier. Right? Absolutely. Absolutely.

Okay, we don't have any questions online, so everybody, Josh Green, Thank you very much.