Building Secure, Trusted and Interoperable Self-sovereign Identity with OpenID Connect

All right. Good afternoon. It's a pleasure. See you for me to together with Christina Yasuda from Microsoft to present you our work on utilizing open ad for building applications based on verifiable credentials. This is a work we are conducting at the open ID foundation in liaison with the decentralized identity foundation and with ISO. So first question, why the heck do you use open ID for that purpose? There are other protocols around, well, we think that we were, we came up with is, is a pretty easy solution.

And there's reasons for that open idea connect from the beginning, which was back in, I think 2012 already had a concept of the self issued. Okay. The ope that resides on the phone of the user. We somehow extended that concept in the work in our recent work, but that's, that's a good, pretty good starting point. And secondly, what we like to drew, what we, what we are trying to do and ale the assessment to you, whether we succeeded is to leverage the simplicity and security of open ID. So first of all, there are existing libraries out there, right?

It's just based on HCPs and, and random numbers and developer are very familiar with the concept. Second is mobile friendly from the beginning.

Third, the security of open idea. Wasn't only shown in production and by analysis, it was also very fight by researchers. And as we are speaking, recent developments, such as financial grade, API two are being analyzed by researchers again, and they in the past have found issues with the protocol, but we were able to fix that. And now we are in a constant conversation with, with researchers all over the world and meet regularly once a year. And you should note that in your calendar or of security workshop coming up, I don't know, may next year close to EIC.

I, I guess, yeah, it will be in London next year. All right. And we not only want to allow applications, new applications to be built on top of verifiable credentials. We also would like to allow existing applications that either consume identity data, or assure or assert identity data to also utilize the concept of very fabric, credentials, wallets, and presentations. So let me map what we do to the two different interfaces that we have in a, in a solution. You typically have wallet somewhere in the middle, and you've got an issue on that issue credentials.

And you've got the verify that consumes credential by way of a presentation on the issue on site. We've got something that is surprisingly called open ID for credential issuance, But no, there's no connect. It's open ID, not open connect. So very subtle difference.

We, we will dig into that later on and the presentation side, we've got two because we decided to modularize that stuff. So it's built on O on self issued op and that's now version two, which is focusing on authenticating key material and, and cryptographic verifiable identifiers. And we've got open ad connect for verifiable presentations, which in the end helps or allow us to transport request and transport verifiable presentations. And with that, I hand over to Christina. Thank you.

So let me quickly run you through on the presentation side, what you just saw on the right side, what it conceptually means, what is, you know, features, you know, what you have to know? So first, what is the difference between the standard currently mainstream openly connect with self issued open ID provider SYOP V two and after two years of intensive conversations, we came down that the difference is actually not that big. The biggest difference is the signature on the ID token.

The usual ID token at you as a relying party, as a service provider would receive right now would be signed by this third party, open ID provider, right? The ID token signed by, you know, big provider, Google, Microsoft, whatnot are testing that Alice, the users identifier is a certain string. Well in the selfish model, what happens is conceptually this open ID provider moves into the Alice environment controlled by the Alice, right? It could be locally on the device. It can have a cloud component.

That's not the most important thing here, but an ID token, which is usually used to authenticate Alice here is signed by the key controlled by Alice, which means ISS equals subject in the ID token, which is how as underlying party would want to differentiate these two models. There are other differences, but this is the main thing you would want to know. Then the question becomes, what about the claims about the users that are insides ID token. If it's signed by the user controlled key, say become well self attested by the user, right?

But what if you want to receive claims by trusted third party, you know, signed by the government, signed by company, whatnot. That's when this additional layer comes in which we call iConnect for profile presentations, again, conceptual model, the same players, the user, the RP, and the issue and Astor show in the previous slides, the issuance being Sping decoupled from the presentation, but still to verify is the cred, the signature on the credential by trusted third party, be it a government or not, you would want to discover the keys from the issue, whatnot.

So this is what this cloud is supposed to symbolize, but that's the idea. So when the Analyst is trying to get access to some resource, it requests the there's a request coming from RP, asking for a token is this additional third party signed what people call credentials these days. And that's how, when, when Alice returns self subject signed ID token, and this credentials website can verify in now get Alexei signed ID token with this credentials signed by the party. That's verified trust The key feature that has been driving us.

And the key message I've been trying to spread throughout this a is the number of credential formats. Number of identifiers. How do I discover the keys? Probably most for vocation mechanisms, but let's at least talk let's at least have two servers, two applications or application server talk. So we can exchange this credentials. And then later on, if they're sample vulnerability found in the one credential format, we can switch with another credential format, whatnot, but let's talk let's converge on the transport protocol. And then we can, you know, be flexible and adjust to each use case.

So this is why the whole open idea for profile credentials, family allows your choice, implementers choice, use case specific choice regarding identifiers. You know, how do you get that public key to verify the signature, the credential format. There's a lot in the space and thanks God, we have liaison is diff and you know, I, so it helps us really figure out this relationship between different credential formats.

Like, you know, like my MDL that you're familiar with, whatnot, revocation mechanisms, you know, trust established mechanism, obviously cryptography with new advanced crypto emerging. Just yes, a note. Can you go back please? We had an interesting exercise at, at the I w west I w so we gather the group and tried to find out what's the credential format. And we came up with a list of 11 of them And we love that sound. That's right. You wanna add that? You can do so because No X five, nine, You can, you can add them because we are working on that stuff.

So we continue to work on that stuff. So if you want to contribute, reach out to us so we can, we can evolve you in that, in that community effort. Sorry for interrupting. Great. Yeah. So some examples, the real simple, just kidding. We don't have time for examples, but if you wanna deep dive more ask the question, we can go back, essentially you're extending the claims parameters, open ID connect request, to be able to specify what credential I'm actually asking.

And then the response we define the new artifact called VP token, which is, you know, the trusted third party signed assertion, as opposed to an ID token and ID token. They'll tell you where to find all the claims you have requested. And so the previous example was for credential format being verifiable credentials, data models, defined C. This is how it would work with ISO compliant, mobile driving license specification.

Again, the request is extended to include the request requesting a certain format, being MDL seaboard in this case, and response would include if you want seaboard a whole seaboard mobile driving license, which is a really, you know, sort of specification also works ASCRS, the Hyperledger project. You can, again, just changes format, ask for different for credential format, with, you know, different signature suites potentially. And you would get the same, you know, VP token, which should be an anonymous credential in ID token in material to find it moving forward.

Both specifications are first implementers draft status, which means you have an IPR protection if you're going to implement it. So you have to worry about it, but people still ask when's going be final.

Well, we're going to, we're planning to go to second implementer's draft because there external specifications relying on those specifications. And that would be really hopefully readily stable, closer to, we have number of ongoing testing implementations, some very interesting names and back to Charleston to talk about credential issues. And just one note on that, if you want to help us to evolve the specification pretty quickly implement it. We prototypes give us feedback, help us to evolve it. And we are, we, we already had tremendous support from the community.

So the people that are working on it feeded us feedback. That's why we are really have really quick, quick cycles for publications. So we published new versions every couple of weeks.

And so, so this is really an agile community. Please come and join. Yeah. I must say that we are starting to build testing. We conformance suite with the bunny foundation and certification team up by Joseph. So that's coming too, Right?

Let's, let's look onto the issue on site. So that's the picture that Christina already has shown before for the, for the issuance.

We, in the end, we end the end, ended up with a pretty simple solution. We said, well, let's do something that is as simple as the user info endpoint and open ID connect. And that just adds what it needs to issue credentials, which means proof of possession, different credential, formats, and so on. And that's what we ended up with. It's as simple API, which is in the meantime, or of protected. So it's even not based on connect because we really slim it down to what's really needed to issue credentials. So the process is, is quite simple because it's, ooff based.

So the wallet reaches out to the issuer requests, the authorization to issue credentials gets back an access and potentially a refresh token, which, which also shows the potential. Because if you get a refresh token, you can perhaps with the same authorization issue, credentials in different formats, you can refresh credentials and so on and so on. So it's a pretty pragmatic way to implement credential life cycle management. And then you've got that API that you send a request to in order to get the credential that's as easy as it is. So it's boring, it's simple.

And we have implemented prototypes and it works pretty well. What we have done is we have defined two ways right now to all the rise credential issuance. The one way is do whatever you do with your oof application today. So you can use the code flow, you can use any outflow, your Seeba use device code, whatever, and the other point, and, and you can, can use that to ask the issue, to issue a credential from within the wallet, during the processing of a presentation request.

And that's a unique feature right now, because let's just suppose, I mean, I do not buy that users really prepare for credential presentation. They do that at talk in a net talk fashion if they need a credential someplace else. So you're starting the presentation request. You hit the wallet and then, well, you don't have the credential what's then deadline, no, you reach out to the issue. And that's what you can do with that, with that flow.

However, if you have a flow where you do have some done something with the, on the issuers website, for example, you passed an exam and then you're, you are offered. Well, do you want download your certificate into your wallet?

Well, you are. Yes. I want to that's where the all pre-authorized code flow had been designed for. That's a new kind of oof grant type that in the end does not require the, the typical oof dance in the end to get the access code. And it's also based on preexisting experience with real existing products, right? And since we are going for different credential format, we are also supporting different formats to do the proof of session for the key material that the credential in the end is gonna bound to.

Well, just some examples, as I said, it's simple. Oof. You can use a scope value with the credential type in it. You can also use authorization details if you have a more detailed requirements to request authorization, and then you just do that API call and the API call contains the access token that you just obtained. You specify the type you specify the format in this case I use it did. So I also passed it did information and I do the proof of possession. In this case, it's gonna be a Jo that just proves that I control the key behind a did key private Key. Just add the context.

The reason why it's proof is really important is because now issues and presentations does not happen at the same time when user is presenting this credential, it's receiving to the verifier. It has to prove that it's the same device that receives a credential that is still presenting that credential in the same device, same user. That's why this is an absolutely important and a new, new element into the existing loss flows.

Well, and then you get back to credential and if you wanna do it again, you do it again. And that, for example, is one, one kind of credential is an LD proof actually, or adjacent LD based credential. The current, the current status of the, of the specification. We just released a new, a new version just before I, I w and we are working on, on evolving that, and we are heading or aiming for first implement us draft by the end of this year. And as you can see, there are couple of implementations going on. We ourselves have already done a, a prototype in a lab funded project.

And that looks, that looks really pretty good. But as I said before, if you wanna help us to improve it, please implement it, give us feedback, join the community, join the calls regularly on Thursday, the SYOP call, if you will, if you know, if you wanna do more, go on open id.net connect working group, right? Christina? Yes. We published the white paper today, title Long discussions, sleepless nights. And here we are open for five credentials, really targeting decision makers in both private and public sector architects. And some of you in the room, obviously, implementers.

We want you to know about, we want to demystify some of the, you know, conception that have been floating around and to really tell you, what is the concepts, what are the use cases? And what's the architecture actually tailoring this, been work this work for. And so I already said, but like really want to inform about the perception of the work we are doing. In our own words, we have input from a lot of experts from a lot of different communities, not just 90 foundation foundation, ISO whatnot. So scan the Kia code.

I really wanted to make this joke be like, scan this Kia code to get a fiber credential that you attended the session today. But, but instead of we Will do that, we will do it next time. Okay. Okay. Okay. But instead of fair fiber credential, you're going to get a white paper. So consider that as a bear talking, you get after attending the session, but yeah, please read the white papers there. Couple of call for action.

Obviously, comment, if you disagree or agree, even just telling us this really resonated with us, like for example, zero section that tries to, you know, define how different ways people use a term decentralization and, you know, there's already feedback coming. This is what they've been looking for, for example, right. Even that kind of feedback is super, super useful. A store already said, please implement. And you'll take it from there. It's a first draft.

Yes, exactly. Sorry, just to clarify, it's a first editor draft. So by no means, you're saying this is a final, final version. We are going to publish a next, hopefully final version based on the feedback we are going to get.