Zero Data Enabled Zero Trust

Thanks very much. Yeah, and and I should mention, I'm obligated, I think as an author, I have an updated book Learning digital identity, which just came out last year. That's a pretty old one.

So yeah, I'm gonna talk to you about zero Data Enabled, zero Trust. We'll get to zero data in a little bit. Let's talk first about zero trust. So Zero Trust is based on the principle that we should assume breach, that we should never trust that someone inside the network simply because they're inside the network, like was just said, right? I mean like the hotel analogy, just because somebody got in the front door doesn't mean they should be able to go into every door. Now if we're going to assume breach, the only thing we can do that will solve our problem is to authorize every access.

It doesn't mean we necessarily have to authenticate the user every time, but we do have to authorize every access. Now, authorizing every access can only be practically done with a policy-based access control system. So I'm gonna just review policy-based access control for a minute just to make sure we're all on the same page. So in a zero trust policy-based access control scenario, Alice is gonna access some server. Her device is going to have a posture, right? What's the device posture? It's going to present some sort of identifier for Alice to the service.

The service has this embedded authorization client generically, it's called a policy enforcement point. The first thing that's gonna happen is Alice is gonna authenticate. So there's some authentication service that's gonna get called. So Alice can authenticate. Once that happens, the client is gonna formulate a request and the request is going to go to a policy engine. The request is gonna include authentication information.

It's gonna include the device posture and the policy engine generically called a policy decision point is gonna have to formulate or is gonna have to evaluate the request on the basis of information that it gets from policies and information it has about the context of the authorization that's happening. So that's generically called a policy information point. Where does that get its information?

Well, it gets it from some sort of signal aggregator, which is taking signals from a bunch of trust providers, right? So these trust signal providers, it could be something as simple as the identity system itself that's providing additional attributes or group memberships. It could be something more complicated like is Alice currently on call? Right? So how difficult you wanna make this depends on how, you know, how much time and money you've got, I guess. But you could, you can get pretty sophisticated and what kinds of signals you are inputting into the decisions that you're making.

Now the problem with this is this last part right back here, because it is pretty complicated, right? Every one of these trust signal providers is some kind of API that you've gotta integrate. Integrating with APIs is expensive. It can have, it can be really difficult to scale.

I mean, if you think about zero trust, we're trying to authorize every access to every system, to every network. And so now I don't just have a few trust signal providers, I might have dozens that I have to in, I have to create API integrations for, you might have to negotiate data sharing agreements with different parts of the company or even different companies in order to do it has security problems because as we know, every API integration is one more place that can be attacked.

And there's also privacy problems if we're getting signals that are going back, depending on the, on the use case, you might create privacy problems. If you're making phone the so-called phone home problem of, of checking. So these are all the problems that APIs present for us. There are also some use cases where it's even more difficult than you might imagine. So for example, if you're an airport, you have people from hundreds of companies coming to your facility on a, you know, here, here and there, right?

They, they're not, it's difficult to know who all is coming. They're from hundreds of different companies and they need access to critical infrastructure. So you've gotta make this zero trust decision. You're gonna integrate APIs from hundreds of companies in order to do this. Another difficult use case hospitals. And in fact this is, this is, this is real.

NHS for example, in in Great Britain has the problem of medical professionals moving from facility to facility and trying to ensure that the medical professional is the right medical professional, has the right credentials, are they allowed to work in this facility? What do they have access to? These are real problems if you are a credit card provider. One example, they have lots of partners, right?

I mean, and all of these partners need information about who are the card members who can have access to my services. So millions of card members, hundreds of companies all trying to figure out who has access to what. And then another one, which is I'm sure no one in this room has ever had this problem, but sometimes you might be surprised to learn. Mergers can mean that there are different IT systems that don't get integrated for years, right? And so now you've got, I, I mean I I heard about a bank that was the product of two mergers.

So three different divisions that literally couldn't transfer, know your customer information from one division to another. That they did it physically with like PDFs because their IT systems couldn't talk to each other.

So, so these are all really difficult use cases where API integrations can be more than just expensive or difficult to scale, but can might be in some cases almost possible in the physical world. We don't do this. Imagine if when you went to buy beer, what had to happen was you had to create an account and once you create an account and presented them with a bunch of documentation, they would go out and proof your identity and store a piece of information in their system that yes, you are of legal age to buy liquor.

And then every time you went to buy liquor, you had to log into their system so that they could make sure it was really you. And then they'd check their database to see if they had already proofed you to see if you could buy liquor. And then they would say, okay, I mean it sounds ridiculous, right? I mean that's not how we do it, but that's how we do it online all the time. That's the only way we do it online is we store all of this stuff in databases. By the way, you'll notice that that is not a six pack, it's an eight pack. There's a funny story about that that I'll tell you offline.

So anyway, we don't do this in the physical world. The physical world is full of zero trust situations without API integrations. Why? Because we use credentials. And by the way, this is a great example from World War II of zero trust, right? Spies are among us. We assume breach. We're gonna ask for your credentials everywhere you go, right? So this was zero trust in World War ii. So how do credentials work? So assume you go to your pharmacy, you wanna pick up a prescription, they need to know your address or that you're over 18 or whatever, what do you do?

Well, at least in the US we supply a driver's license. Now I was the CIO for the state of Utah. The driver's license division insisted that they were not in the identity business. They wanted no part of the identity business. They were licensing people to drive cars. That's what they did. And yet this works. Why does it work? It works because we package all of these great attributes up. The provider is, is a trusted provider. It's tamper evident, it includes a nifty little biometric authentication device called a picture.

And we can use this to go to the pharmacy and prove our age or our address or whatever else we wanna prove. The pharmacy doesn't have to have the agreement of the state to do this. They don't have to do any API integration. There was no data sharing agreement that had to be negotiated. They just decided they were gonna start doing it and it worked. Okay. Can we do it online? Yes we can. If you've been paying attention, you've heard about decentralized identity in many sessions.

You've probably heard the term verifiable credentials mentioned verifiable credentials is a W three C standard for authentic verifiable data packet transfer. I mean, we typically think about it in terms of, oh, it's identity attributes. If you can put it in A-J-S-O-N document, you can stuff it in a verifiable credential and transfer it in a reliable way. Okay? How does it work? Let's say that Alice wants to apply for a loan at her bank. She needs to prove to the bank that she's employed and she makes a certain amount every year. Her employer a tester org has issued a credential to Alice.

She's holding that in her wallet, right? So she's the holder and the subject, when she goes to her bank, she presents to her bank. Not the whole credential, but a proof of information the bank needs to know and the bank can now know that information cryptographically, okay? They do that without having to have, having to actually talk to Alice's employer, right? So that's a key feature. So that's the basic idea. We call this the credential exchange triangle. This is the basic idea of how credentials work.

I mean, it could be in the physical world. This happens to work online as well. Now there's some important properties that we want out of credentials and I call it credential pro fidelity because it's all cryptographically verifiable. Okay? So this is not a matter of who do we trust. This is a matter of we just trust cryptography. And the cryptography tells us things. First of all, we can know who issued the credential.

Second, we know that it was issued to the presenter, which is an important factor. It, I can't give my credential to someone else and them use it to get access. We know it hasn't been tampered with and we know it hasn't been revoked. Not just whether or not it's expired, but literally it hasn't been revoked like five minutes ago. So let's look at our zero trust architecture with a verifiable credential lens.

So if we replace the identifier up there that's going from Alice to the service with a credential proof, the first thing we can do is we can get rid of the identity store and the authentication because we know the credential was issued to the person who's presenting it cryptographically. So we don't need to do authentication. Alice is the only person that can present Alice's credentials. The second thing we can do, we don't need all of these trust signals because the credentials can carry the information that would be in the trust signals.

That means we don't need a signal aggregator and we don't need the policy information point. What we do need is we need to know who trusted issuers are. Who do we trust? So I know who the issuer was that is, I have an identifier for them. But remember back when we were talking about buying beer, you're presenting a driver's license or a state issued id, right? We trust that the state did a good job of proofing.

So, so the policy engine does need to know what credentials it trusts. So that's a key idea. But notice how much simpler this is than what it was before. Now I use the term zero data in the title because I thought it was cute, but it's actually from a guy named St.

Jean, St. John Deacon. The idea is simply that when we're using verifiable credentials, we can transfer much less data, right? We might be able to store zero data in some scenarios. I'm not saying we could do that in all scenarios, but in many scenarios we could. And certainly that's our goal, right? Is data minimization minimize the amount of data that we have to store. Doesn't necessarily mean that less data is gonna be in shared.

In fact, more data might be shared because it's easier, but that data is shared in a way that gives us better signals, right? I think Martin Carpenter said in one of his talks that you could imagine that we might have dozens or even hundreds of credentials that have information that we could now use to make zero trust decisions better authentication, better than simply username, password, better security, that the cryptography is better. We don't have to store as much information, we don't have as many integration points that can be broken into better privacy. There's no phone home problem.

We're not storing a lot of data about people that we don't need. We don't need to be data hoarders. It can be cheaper, right? We have organizational benefits 'cause we don't have to worry about all of this data that we've got stored. So we don't have to spend all the money to keep it safe. Can be faster and certainly more flexible, right? 'cause there's a lot more data we can put in the credentials because the API integrations, we don't have to make the API integrations doesn't cost as much money. So we can decide that we want to use more data. Okay?

So if you want, would like to see a demo of how this works. A company called in DCO who's an AWS marketplace partner, created a demo using their proven platform. That's the brand name proven with a verifiable credential solution using Amazon verified permissions. Amazon verified permissions is the, is the service for the C policy engine. So if you've heard of Cedar policy language and it's an open source policy engine, verified permissions is the service that we, that we run for that.

And so this demo essentially shows using verified permissions to make policy decisions from signals coming out of credentials. And that QR code will take you to their demo on, on YouTube. So back to this example, my contention is that using credentials for zero trust decisions is faster, less expensive, more secure, more private. And all of the technology we need to do it exists today, right? This is not like, oh we could do this. It all exists. We could make it happen right now. And so I think we're gonna see a lot more use cases for verifiable credentials inside our zero trust scenarios.

And that is the talk. So happy to take questions. Thank You very much Phil. That was really interesting and really good to see that as a whole, to get the whole story told. I have two great questions actually here. Yes.

And it's, you see that we have experts in the room as well. First question is, are there emerging techniques for confirming that the holder is the subject that is the binding between the person and the credential? How can you prove that?

Yeah, how do, how do you get the link? 'cause I said that, that you know, that the person presenting the credential is the person it was issued to. The way that works is a nifty bit of cryptography that involves when the credential is issued, the wallet gives a blinded secret to the issuer and the issuer puts that blinded secret into the credential. And then when the credential proof is presented, that proof can contain a zero knowledge proof that the credential actually has the blinded secret that matches the identifier. That's unique to the presenter.

Now, one caveat there, I said that the presenter is the person who the credential was issued to. Actually it's the wallet, right? So we still have to have some sort of biometric link between the wallet and the person in order to really know that it's the person doing it.

So, so yeah, we, we, it's not doing anything magic with the person, it's, it's, it is the device. The wallet that the credential was issued to is the wallets that's being used to issue the cred to, to present the credential.

Okay, great. Thank you. I hope that answers the question. The second is in case an ID card is stolen, usually the criminal will not look like the person on the photo. But if a digital wallet is stolen with device and pin of course, and no one is double checking, is this true or can we, can we enforce That?

Well, I mean, yeah, so there's a lot, there's a lot of things there, right? So if it's stolen, if they get either the PIN or you know, can somehow break in, break into the device and the person who it was stolen from doesn't know it was stolen and isn't doing anything about it, then yes, that device could be used to present credentials. But that's three different things that have to happen, right? First they have to get past the device security. So like anything good device security is important.

Second, they, they have to the, the person, if the person knows that it was stolen, there are ways of essentially repudiating an entire wallet cryptographically so that that wallet can no longer be used to make any presentations even from even if you happen to get into it. So those are the, those are the ways you can protect against that. Right. Okay.

Again, thank you very much Phil for answering the question, for briefing that presentation. Thank you very much. Thanks. No more questions.