Thank you. Yeah. Welcome everybody to my presentation on securing the foundations offi credential ecosystems. My name is Daniel fet. I'm a security and standardization expert here today for Auth lead. And I've been working on all security for almost 10 years now, and I'm involved in many of the specifications and standards that are written in the field, not only of Earth, but also in the verified credentialed ecosystem space. So I hope that image like this is familiar to all of you. The famous three party model, or whatever you wanna call it in verifiable credential ecosystems.
The usual setup is that you have a wallet that is usually running on a mobile device, could be somewhere else as well, and you have issuers that issue credentials into that wallet, and then the wallet can present those credentials or presentations derived from those credentials to one or more verifiers.
All of this is hopefully controlled by the holder, in this case, the user. So that's a, that's a model that I presume everybody view is familiar with.
Now, the, if you, if you look at this, this is of course not the, like, not the low level picture here. So if you take this one step further and look at what protocols are being used and what standards are being used in this space, you have of course the issuance protocols that are used to issue something and the presentation protocols on the other side of the wallet to present those credentials. And then we have something, so we have credential formats, that's one format or multiple formats that determine how a credential is designed, what it looks like, how it's secured and so on.
And then as a foundational building block here, we have trust frameworks, which is here, meaning the, both the protocols to establish trust, but also of course there's a legal framework to, to, to establish trust to, to, to make sure that the verifier can trust the issuer.
And that's the most important thing, I guess, and around other relationships in this constellation as well.
So that's, these are the foundations, so to speak, of the verifiable credential ecosystems. And that was one part of my talk title. The other part is securing this, and before we can secure it, we of course need to know what does security mean? So what does security mean in such an ecosystem? And there are a few very important properties that I wrote up here. The first and most obvious one is that the credentials are authentic. So the credentials can only be issued by authorized issuers. That's important of course. And they cannot be forged or manipulated by attackers or malicious user.
So even if they are in your wallet, nobody can modify them, right? And there's key binding, which is usually also desired, which means that credentials can be key bound and if they are key bound, they cannot be presented without the holder's intent.
So even if the verify, for example, gets a complete credential, the verify cannot turn around to present that to somebody else, how exactly the key binding is designed and whether that's holder binding and so on. That's probably a talk of its own.
But let's, let's say the, the key is bound to the device for copy protection and then there's session binding. And this becomes important later on in the talk. The with session binding, I mean that the user knows in which context of credential is presented and to whom, because if the user does know in which context, if credential is presented, then the presentation doesn't mean anything. So that's super important. It's also always important that the wallet shows the user who is the receiver of that presentation. And then that it's then short on technical level that this is the real receiver.
Then we have a couple of privacy properties, data minimization.
So if you have a credential and only the data that is actually required for a certain use case is released in a, in a specific presentation, even if the credential contains more claims than that, there are a couple of ways to achieve that. Zero knowledge proofs is one way, selective disclosure like an SD drug is another way. And then there's un linkability, which means that two presentations cannot be linked together.
So even if for example, a verifier offers us multiple services, for example, you proof your age to a, to a website at some point, and later on you order something from that website, it's clear that unless you release directly identifying data, the website should not be able to say that you are actually the same user. That's, that's important whenever verifiers collect large amounts of data or when they could potentially collaborate with each other. And then there's the last point here, which kind of needs a question.
Markets under discussion, especially in the EU wallet context, that the verifiers cannot prove the correctness of the data to third parties, what we then call deniability. So the user can deny having made a certain presentation or repudiation that as well could, would probably deserve a separate talk as well.
So the question is, we've seen the foundations, we've seen what security means now are those foundations secure?
And to to, to figure out or to, to close in on the, on the answer here, let's take a closer look at the protocols. And the protocols that I will talk about here are those designed by the on development by the Opend Foundation, but essentially the considerations apply as well to other protocols. So for the credential issuance, the OpenID Foundation has open ID for verifiable credential issuance. And that is based on auth. And essentially the wallet here acts as an auth client and the issuer acts as an auth authorization server.
So it's more or less a normal auth transaction happening between those two. And then we have on the other side, open ID four verifiable presentations where the, which is also based on Roth, but here the verifier acts as the OATH client and the wallet acts as the authorization server.
So we have essentially two separate oath transactions here.
Now, using Roth is generally a good idea. There are existing implementations of auth, which you can use both open source and proprietary. We have years of practical experience with deploying and using auth. We have existing add-on standards, for example, MTLS to secure tokens or Depop and, and pixie to secure specific aspects of the flow. So that's cool. We have a large, large set of buildings, block building blocks that we can combine. It's also the natural companion for jaws. So if you want to use SD draw, that's a very good fit and it has well understood security. What does that mean?
Well, there, the security of oath has been analyzed extensively. There are more than 20 academic research papers, some of which I have contributed to. There are formal models in various formal like security models. For example, the Universal universal composability model alloy, the web infrastructure model.
And they are security proofs both for auth and auth in specific settings as well as Oak Myy Connect. And for auth, we also have a document that I'm also involved with the, OR security best current practice.
I'll see, which is right now still a draft, but hopefully fi hopefully finished soon. And we even have a form proof for the security of the combination of issuance and presentation. So that's great. We have built on top of something that is well understood, well analyzed. And the question is, are we done here?
So, so, so could there be anything that is insecure about this? Well, you might be familiar with Better Rich Law, bitter Rich Law, which says that any headline that the question mark can be answered by the word no. And that's true here as well, unfortunately.
So what's left to do, and there are a couple of things left to do. I select a few of them to to, to walk you through them to give you an impression what the kind of challenges are that we have in the space so that you, you get a feeling why those challenges still exist and why we have not solved them. And I'd start with replay attacks.
But before that, just a quick reminder, a few words that I'll be using in the following and m Mighty for verify presentation. So I'm going to talk about the presentation side of things.
As I said, the verifier acts as the author client and the wallet acts as the authorization server. But we have a couple of new things as well. We have something that's called a VP token that's similar to an ID token for those familiar with Open ID Connect.
We have a new response mode, which is called Direct Post. And we have a new client ID scheme, which is an extension to client A essentially.
Okay, so I presume that you're not intimately familiar with those protocols. So I try to keep sim things simple here. Let's look at a very simple credential presentation flow. We have a service ww.service.com that wants to get a presentation from you. So this is the verify and it has a big blue button sign in. And if you click on that button, your wallet app opens. Let's say it's on the same device here, right? So your wallet app opens and we'll ask you do you want to present your credential to service.com? And that's exactly what you expected.
So you click on the okay button and then a presentation is sent to the service. And now the service has your data. So in this case, my first name, that's all good, that works.
That's, that's, that's fine.
However, there's something called replay attacks. So what's a replay attack? Very simple. Let's assume that you have just gotten on your device. The question, do you want to present your credential to malicious service.com? And maybe you are fine with that, right? Maybe it's not called malicious service.com, so maybe it's a little bit more hidden, but it doesn't matter if you present your credential to a malicious service, the malicious service will get your data, but it shouldn't be able to do anything malicious with your credential, right?
So you click on, okay, and malicious service.com receives your credential.
The problem is, if a replay attack happens, then the malicious service.com just turns around, takes their credential and shows it to service.com.
Now, service.com with if, if there would be no protections against these kinds of attacks, then service.com would be able to or would consume your credential, your presentation, and then the malicious service would essentially be locked in under your name@therealservice.com. How can we protect against that?
Well, it's a very well known, widely used mechanism that is used in open ID for verifiable presentations as well. The idea is that every time you go to service.com, you the, the service when you click on the big blue button sign in also creates a nots, which is a number used one.
So it's a, it's a fresh random number. And when you present your credential, then that credential contains a signature that only you can do because you have the key button that only you can do over that nos.
So anytime service.com receives a presentation, it expects the signed nons in there as well.
Otherwise, you won't be able to get into service.com. And the service.com website would probably bind that nons to something that is in your browser. So a cookie more commonly a web session that is tied to a cookie in your browser. So replay attacks are essentially a solved problem, right? So they are, we, we, we know how to defend against them.
It's easy, it's how we do it in authors, how we do it in augment connect, how we do it in open 80 for verified presentations. However, there's also another type of attacks which is phishing attacks.
And here you can see the title of the slide is Phishing or Flows because this all applies to or as well. So let's say you@service.com and now service.com com is, so no, sorry, you're not@service.com, but the attacker on his own device starts to service.com and the attacker doesn't click on the big blue button, but takes the URL behind that button and forwards it to another website.
Let's say fake service.com. Now you as a user get a request because you're at fake service.com and you click on sign in because you want to sign into fake service.com and you as a user get a request. Do you want to present your credential? Now it will say to service.com, but maybe you don't notice what happens is that@service.com the, so if you do the presentation and you send it to service.com, it will not be accepted because service.com will notice due to that cookie or the lack of that cookie in your browser that that session was not started in the same browser.
So because of the lacking cookie, the phishing attack will not work. Now in open ID for verified presentations, we have something that's called the direct post mode. And that in the direct post mode, it allows you to send the response directly to the backend of the verifier. And that is, is required because we have certain limitations. So that means that the presentation is not sent through the browser on your device, but the presentation is sent to a backend that, and that call happens outside of the browser. The problem with that is in that backend, you cannot check cookies.
So the backend will accept your presentation. And since the backend knows, okay, the attacker started this, this session, the backend without any other information would accept that request.
And there's essentially two ways to solve this. Either you have an operating system which we don't currently have, like not in a reliable way that tells you, look, that request comes from fake service.com, not from service.com. And then your wallet can notice that this was a forwarded request cost requested itself signed. It cannot be modified by the attacker.
The other way is we tell the backend, okay, look, you accepted that thing, but please don't consume it yet. First send the user back into the browser and check whether there's a cookie. And if there's no cookie, then don't accept that that credential, that presentation and this. So this is a very generic problem. This affects all kinds of redirect protocols.
This is not something that is specific to Open ID four verifiable presentations and implementations need to protect themselves so that we have seen those two solutions and both of them can be implemented with open ID for verified presentations. However, the only one that is practical right now is the one with the redirect back to the browser because we don't have that operating support to do this check right now.
We do have a very similar problem in cross device flows as well. In cross device flows, you scan a QR code on one device and then you have the wallet app on another device.
This means you have no chance of asking the browser whether the request was started in the same browser because it was never started in the same browser. So you have will have that problem always. And what you usually do to avoid that or what you could do is to have, again, the platform help you doing, for example, proximity check via Bluetooth between those two applications.
We currently don't have an API, we don't have browser operating support for this, but let's work on that in the WICG.
So that's, that's work in progress. Until then, we cannot really secure the cross device flows. So coming to my summary here, reusing what's already defined and what is tested and what where we have experienced is great.
However, the security does not automatically translate to any new applications and extensions that we built on top of the existing one. So we do need new security analysis, we need to make new considerations and we still have unsolved problems plus of all the the phishing problem. And second one is the secure crust device problem. And that's all I have for you today. That's all I was able to scram into. Well it's 20 minutes, sorry for that, but there's so much more to say on this. If you're interested in this, please come talk to me or any, my colleagues here at EIC. Thank you.
Well, thank you very much Daniel. I suggest the best way to dis to an, to have your questions answered would be to talk to Daniel's colleague who is present here from the same company. So you could just talk to him.
