OpenID for Verifiable Credentials

Thank you very much and it's great to be back on this stage. And with that topic, for those of you that don't know, we have shown the first public demonstration of an implementation of Open ID four VPA couple of years back here at EIC. So thanks a lot for our call for running this great conference and hosting us. So today we would like to give you an update on what has happened in in Open ID four VP space or Open ID four VC space and what we are planning to do in the working group. I had the same problem with one, it seems I'm okay.

So the problem we're working on, or the problem one is to solve is interoperability on the protocol layer. So meaning if you have the three party model with the issuer, the wallet, and the verifier, there are two interfaces basically. One for issuing the credentials and one for presenting the credentials. And on top of that, there are so many options for credential formats, for cryptographic algorithms, the way you manage key material, the way you manage trust.

And we pretty early in the process decided even though we would like to agree on one set of those standards, it's, it's most likely not gonna happen. And that's why we said, okay, let's focus on the protocol layer only and build a protocol that can be used with all sorts of different formats, algorithms, and so on. And so the first prototype, for example, used Anora Who I knew, I will get your attention on that point and nowadays people use it with, with verifiable credentials, SD OG and all sorts of other credentials. So that's possible. How do we make that work?

We have a sort of a set of specifications. So on the left hand side we have open ID for vrr five credential issuance. That's the main spec that describes the interface between the wallet and the issuer. On the right hand side we have open ID for verifier presentations that obviously describes the specifies, the interface between the wallet and the verifier. And there are other specs that also have been developed in the working group. One of those is the open ID for VC high assurance INTERABILITY profile with SD VC called hype. Why is there a need for profiles?

Simply as I said, the protocol is independent or agnostic to formats and trust management mechanisms, but in order to be really able to deploy it, deployments need to make decisions and hype is one instantiation of such a set of decisions in a profile. There are others, for example, in the ISO 23, 20 20 dash four, thank you, those three specification. And in 18 or 13 dash 7 5 7, Sorry I was Blanking. There's another one for using open ID for VC in conjunction with Mdoc. And we also, and that's our newest brainchild or no, we have self, self issued.

I self issued OP V two for Pseudonymous login. And we have our newest brainchild which is open ID for VP over Bluetooth flow energy, which is a crucial piece of it because it will then also allow to do in-person presentations in a credential format agnostic way between two different devices in in proximity. I'm so excited we won a prize. Yay.

So thanks to all of you and thanks to copy, copy Cole, we won the European Identity and Cloud Award and we are super proud of that and I would like to again thank all people that our editors, co-authors, members of the DCP working group at Open ID Foundation, implementers, fellow competitors in that field that helped us really to make open idfa VC better and yeah, become that successful. Thanks a lot. And with that I hand over to Christina. Thank you. So we wanna award in European Union, but this is to illustrate, we do have global adoption.

On the left hand side we have a RF architecture reference, reference framework in the context of EI does two in the middle, 18, 13 dash seven, I've heard some folks mention it. Basically presentation of mdoc format online that's used openly for referral presentations. So that is being prototyped in America. And Japanese government also does have trusted web project where again, multiple companies implement the wallet model and some of them do use open for BC and they've run the conformance test report for example.

It's not on the slide, but we also have MIP use of playing for VC in their open source libraries. So I think that publicly, I can mention Uganda and tobacco, but if you're interested, I would encourage you to find MIP folks. They are at EIC. We do have a growing number of open source libraries.

Again, I do not claim that we've got all, and we do not guarantee that OSM at the same level of, you know, support for recent version. But if you're looking for a place to start, depending on the language that you, you know, you develop in, you do have a multiple options. This is pretty new. We have started focusing more and more on conformance tests. So the goal is to really help developers to stay compliant with a specification and make sure they're interoperable among themselves.

So for example, potential, our scale pilot is doing a big interop event with over a hundred implementations and that would be the first place where we are going to test it. And Joseph sitting by right there is our key person leaving this. So if you want more details, I would highly encourage you to talk to him. We what we have available right now, we started with presentation side. We do have tests already available for digital VC and MOC profile and it's currently being updated and we do have over a dozen of wallets that have already passed certification in progress.

Obviously we do need issuance as well. We are starting tests for D, VC and MOCs. And if you don't see what you need to be conformance tested, this is not the full picture, we want to help you. So let us know maybe there are ways to collaborate for funding. We do have joint funding problem, like for example, Japanese government chimed in when they were, they wanted some tests being built for their project.

So yeah, like we'd love to, you know, double click on this offline. Now, security analysis, I think we've heard a couple of presentation at this EIC too. There are multiple people working on this. What we do have available now is in the GitHub repository of DCP working group. We do have security and trust in fabric credentials document, which covers the basic assumptions, security considerations, requirements for the components. It is a very holistic document. I do recommend to take a look to have an overview of the threat models in this space.

And based on that we do have a formal security analysis as a master thesis from University of Stuttgart, which you can find at QR code. And just very quickly we do get asked for where can I find the overview of this.

You know, obviously presentation is a good start but you can't cover everything. The white paper, the technical part's, a little bit outdated, but the first part where we try to distill the myth and you know, explain the motivations of our work in detail, I think that part is still very, very valuable.

Now, well we have 10 minutes left, but the focus of today's presentation, we really wanted to focus on the updates, not really technical details, but explain you what we've been doing and why we've been doing. So. I'll cover issuance and tour, then we'll help as present presentation. So highlights current status.

Again, we get this question a lot. We publish the first implementers draft in April. So an opening foundation before the specification becomes final.

We ha, we usually go through multiple cycles of implementing drafts. So that's basically when the working groups us, we do believe this version is stable enough, it meets the current requirements use cases we want to try and to operate using that. So currently we have a lot of implementations for trying to build and align around for this first implementers draft. Just few bullet points on what do we value in the specification, easy to use for developers, hopefully enabling you to reuse your existing observation servers, your existing libraries, whatnot. That's really important for us.

Various security levels here because these specifications are built on OAS OS is a module of framework and in idea if you do have different RFCs that you can layer on top of basic specification depending on the security level you need. So all that applies here. So for example, center constrained tokens, Depop, whatnot, all of that can be layered. But also what's very important, especially in Europe emerging as a topic, the key management hardware, software, wallet of the station, all that is also can be layered on top. Now there is business requirements and user experiences here mainly.

So especially during issuance, you need to do identity proofing. You need to know who is the user you're talking to, right? And for example, I was talking to this Swiss government this morning where say a originally just started with an online identity proofing but then the requirement came in they, you have actually have to do it in person too. And the protocol supports, you know, both options. It's pretty flexible around that. And also another thing we would like to mention here is the flow can be either initiate by the wallet or by the issue.

So again, that's a different user experience and trust already covered. But we do support various trust frameworks and credential formats. Just to illustrate that at the high level what this issuance is, it's an OS protected API. So in the first part is where authorization server on the issuer side is main is responsible for user authentication, gathering user consent. So what send a request issuer does all that and returns and access token. And that access token is now what protects access to the issuance endpoint.

The bottom, yeah, I don't know if there's a laser, but the bottom orange part where that's where the actual credential issuance happens. So design is very deliberate. The fir. So in the first part is server can focus on user identification and in the second part is server can focus on issuance because they're, again, if you're doing batch issuance for example, or multiple credential formats, they're not requirements you have to take care. The bottom part I already covered, just quick you explodes, but the main point here is the blue is the wallet, the yellow is the issue.

It just illustrate the responsibility of each actor in the flow because we do again get questions on that. So this is a wallet initiated flow where wallet knows who is the issuer and wallet, you know, tries to fire off that request. So user opens the wallet, chooses, adds this credential, it goes to the issuer screen, it's issuer's responsibility to identify the issue to the user, sorry, like we saw in the previous screen. And after that the magic happens. Backend back channel user consents, authenticate and credential gets issued into the wallet. So that's ation code flow.

This flow is designed for the servers that already have means to authenticate the user. So for example, if you, if you're a bank and you have already your database of users and you just want to turn that data into credential that can be used with wallets, this is the flow we would recommend. And also this flow is more secure than the pre authorized code flow, which is this one. So this is where the user identification part happens before this flow starts, right?

So this one's optimized for in person for example, where user goes in office, in person does identity proofing based on that the issue generates the, in this case QR code doesn't have to be, I was just, I think I was trying to illustrate cross device flow here, but user scans that QR code and after that there's no more contrary to here. There's no more yellow screen within the wallet. So no more screen switches within the wallet because you know, issue already authenticated the user beforehand. So after that, if everything goes well, the user just smoothly gets the wallet.

So again, the balance between security, your identity proofing requirements, your screen switches, ux yeah. And now the updates. What we have done since the last update, so first is optimizing insurance for credential batches. This is if you're using a credential format that does not use your knowledge proofs for unlink ability. So that's when you most likely have to issue credentials per line party. So that's where in one go we had an implementer issuing, I think I've seen maximum 250 credentials in few milliseconds. So we are working on this flow, it already was working.

So it's not like we are introducing it from you, but we're trying to optimize it, make it better listening to implementers feedback. Now deferred authorization got removed. We asked the working group, the implementers, no one complained, no one said they wanted. So that removed but, so yeah, from a security concerns perspective, this change was applied. A new endpoint that we introduced as an extension is notification endpoint to motivations.

So what this helps with is after the issuer issues, the credential to the wallet before there was no way for wallet to tell the issuer whether it was successful or failure or not. And that was kind of impacting UX credential lifecycle. For example, issuer would think it issued credential, but in fact user didn't receive it for various reasons.

Mobile, mobile apps could be flaky. So that is a new extension. Now the topics under discussion, the discussions we're focusing on where we would like your input, use cases, whatnot. So first is the wallet key at the station. If you follow e iida, the keywords are W-I-A-W-T-E. We've making a lot of progress on this. We're hoping to do a PR and give some clarity in really short, short period of time. Also optimizing number of endpoints. Right now we have credential endpoint, batch endpoint and deferred endpoints.

And the implementer feedback has been from the implementer perspective, it maybe we can have one or two endpoints that can have multiple functionalities so that discussion is ongoing. Also discussing adding a mechanism for the issue to notify the wallet about certain events. So the notification endpoint I mentioned in the previous slide was about wallet telling the issuer whether issuance was successful or not. This is about after that happens, issuer sending the wallet, like for example, wallet user data changed, I need you to use your access token and refresh the credential things.

Things like that. This one I think we need to discuss a bit more before we can agree that we need it or specific mechanisms. Last one is issuer metadata enhancements. So it's happening in this world model is basically issuer is trusting the wallet to display the credentials, right? The branding, the colors, whatnot. And they received some feedback how to improve it. So we are working on that. And I think I am a bit over time.

I'm sorry, towards end. Here's the presentations part Just a bit.

Sorry, Just a bit. I guess I will be focusing on the highlights and the updates. So what I would like to point out for open ID for vp, first of all we are through the second implementers draft, so we are bit more mature than for open ID for VCI. And I would like to point out again, and that's very important, even though we share the name open ID with open ID connect core, the design principles that we utilize and that we apply are different. And from the beginning we try to come up with a design that allows a wallet to be built without to relying on, on, on a backend.

And, and, and that's the, that's the reason why Open ID four VPs looks different, much different than open ID connect. So it's designed for the highest degree of privacy, even though that means to sacrifice a bit the simplicity on the, on the verifier side, we can support various security levels in the same way as for open ID for VCI. We also have different mechanisms to authenticate, for example, verifiers and establish trust with them.

And yes, we nevertheless believe it's easy to use for, for developers. And we always told that we can present different credential formats, but we can also present different credentials in different formats in the same response.

And the, the protocol also supports different deployment models. And guess I I I, one illustration for that is that that the number of different architectures we also see in, in the innovation competition for those of you that have joined the other presentations that we have given today.

And yes, very stress frameworks again. So I will, I think skip this one and just go straight to the updates. We are super excited about the progress we have made in open, open ID for VP in, in, in a couple of areas. First one is we are cooperating with W three C and, and, and browser vendors to, in the end develop a new API that will be resulting in an even better user experience and an even more privacy pursuing way to request credential presentations from websites to a wallet and even going forward on the operating system level.

And that in the end will allow us to over time get rid of custom schemes and all those traditional invocation mechanisms. It's still a long way to go. But in the end with beside that, it'll also provide us with browser and operating support, operating system support for presentations of credentials across devices. And that's right now and today an unsolved topic, right? Because most, most protocols, user QR code between devices and it can be easily phished, right?

With that extension we will be able to have a proximity, a validation mechanism built in into the protocol based on, oh, I run out of time based on, based on Bluetooth low energy. Yeah. So I would say if you wanna know more about what we have been doing and where we are, please join the working group. We have Atlantic calls every Thursday at 4 5, 4, 4 o'clock. Yeah. So we have calls twice a week. We also have a more US and Japanese friendly call on Tuesday.

Yeah, thank you for your attention. Thank you very much. So the worst thing that can happen to a pre to a moderator here is to have a set of really great questions and the time is up. Yeah. So I will send the questions over or you can look them up in the, in the, in, in, in the session because they were really great. So there's a lot to follow up. For those who are really interested to in the answers, please reach out to them just afterwards.

Oh, On next week. I think 11th and thirteens Open World Foundation is helping us host AMAs, like ask me anything on both of these presentation and issuance protocol.

So yeah, that would be a great place to come with your questions because I'll be hosting those with Oliver and I don't want them to be one-on-ones. I was explaining I want it to be more like implementers coming with questions like what is this? Are you working on this? So please come with your questions next week.

Yeah, Reach out to them, but only after the final panel that we now run. Thank you very much again. Thank you. Thank you.