How to Build Interoperable Decentralized Identity Systems with OpenID for Verifiable Credentials

Hello everybody. Welcome to our session. We wanna present you how to build in trouble, decentralized identity systems with open ID for verify credentials. Open ID for Verifi Verify credentials is a family of protocols that are being developed at Open ID Foundation in close co collaboration with other standardization bodies, most notably Decentralized Identity Foundation, ISO and Etsy. Let me start with a question. Who here in the, in the room is, is familiar with Open Id connect, huh? Quite a bit.

And saml, don't be shy. Okay, thank you. So basically the main difference to what we want to achieve with these things, decentralized identity is, is the architecture for the information flow, right? So in federated identity, the party consuming the data called service provider relying party is directly talking to the source of the identity, the test, the identity, the identity provider or op. And in decentralized identity, there's a user agent in the middle, it's called a wallet, for example. And you see on the slide what's the typical conceptual architecture for decentralized identity.

So on the left hand side you see what's called the issuer, that's the source of the claims about, for example, the end user and that issuer issues a credential and that's gonna be stored in the wallet of the user and then, or it's called the holder. And the user then decides where and when to use those credentials and also in what combination. And that's, that's a big difference. It also makes it much harder to get it secure and to get it right from a user experience standpoint. Because in the federated world, you have a end-to-end secured connection between the source and the recipient.

Here you have to intermediary. So there's a lot of work going on to really make that secure. There are other sessions on that, but let's keep in mind there are a lot of benefits and promises, but it's also challenging to get it work. And we will touch on some of those points in the course of our presentation. The benefits of the approach are, well, and I think Victoria Bei touched on that in the keynote and the morning. It's more privacy for serving. So you get your credential and then you decide as a user where and when to use that isn't, not involved in that process and doesn't see it.

And that's good. And you can also to some degree take your data and port it to someplace else, right? Depends on the security posture of the credential, but there is much more in it because if you virtualize physical credentials, it's gonna be much cheaper and much faster to issue those credentials. So in instead of producing a plastic card, you just send a stream of bites that is stored in the wallet and can instantly be used and you can utilize cryptography to make it secure instead of relying on visible elements on a plastic card to make sure it's not, had not been modified or tempered with.

And what excites me the most is the university of the approach, right? Once you have virtualized the credentials, you can use them online and offline, right? So the digital credential can be presented when you, when you are boarding a plan, but you can also use them on the website that hasn't realized yet. So for example, for the COVID certificate, you can use that digital certificate or that digital credential to do a presentation in the physical world, but you can't use that to do onboarding for your flight, which I find pretty pity, right?

So we are working on, on solutions to to, to make that happen, right? To have that universal to, to have that seamless approach between physical and, and, and digital space. When you look onto that architecture, then you will see we've got two different interfaces. We've got an interface between the issue on the wallet and we've got an interface between the wallet and the verifier. And given the number of participants, It's very important to make sure we can build that in an interoperable manner. And there are two elements to that that we need to understand.

First is the, the format of the data to be transferred. We call it credential format. And second is the protocol. And open ID for VC focuses on the protocol. So what we wanna achieve that those connections between the different parties can be implemented in a secure, simple and interoperable manner. And we have been working on that for more than two years now, close to three years I guess. And we have learned a lot because that space is super complex. There will be a session later in the afternoon where we're talking about the different technologies that are able today in that space.

But there is a multitude of credential formats, there are multitude of, of, of, of protocols. So it, and, and that's, that's really a burden and that's an obstacle for, for adoption. So the first thing that we have observed is defining new protocols is hard, or let me put it that way, defining new protocols is super simple. Getting it right is hard and that's why we decided to not invent a completely new thing but be based on work and preexisting stuff or of two and open Id connect, but I also also would like to point out open ID four VC is a new kind of protocol.

So it's not open Id connect, there are elements in it that use open, ID connect most notably CV two for authentication. But the rest is based on o of and as one of our cos typically says we are standing off on the shoulders of giants, meaning O of two is a very rich ecosystem with security mechanism, with modularity and so on. And we utilize that and we leverage that. But where needed, we also modify it, for example, to be more privacy preserving. Second point, very important.

There are so many different credential formats right now, if you're coming from the open ID connect world, well that's so simple. You've got Jason web tokens and that's it. Yeah. You know how to process them. You can build that system all good in this world, the last time counted we had 16 different, at least 16 different credential formats, right? There are NCRs, there are Jason LD based verify credentials, there are jojo, adjacent based verify credentials. There is acdc, there is Caesar, there is, I don't know, guardian notes and guardian envelopes.

So, and this is, that's a fact, right? It's an emerging market. And what we decided is we design a protocol that is credentialed format agnostic because other format, format protocols are available are tied to a certain format. And that means if you use a protocol, then you're tied to that credential format, which also means if you wanna do a change, because some features that you need are not available in that format, you also have to change your protocol and perhaps even the crypto suite. And we don't think that's the right way to go.

We want to support modularity and that's why we designed open ID four VC in a way that you can use it in combination with any credential format and you can also present credentials in different formats even within the same transaction. Next point, decentralized identifiers. DIDs are a big topic and decentralized identity, but we also perceived that not everyone wants to use debts, right? There are other ways to, to represent key material. There are X 5 0 9 certificate, like them or not, they're not here to go away, right? And they're all raw public keys.

So what I perceive or what we perceive in the, in the community is there is now a movement towards pragmatism, right? Let's get things done, which means we need to have other mechanism to represent key material, established trust and so on. And last but not least is the most complex part. You've seen how complex such a ecosystem can be. Couple of wallets, couple of issuers very fast and so on. They need to establish trust. The typical way that is done in a federated system is you establish trust before the transaction happens. There is some registration process, you set up something and so on.

That is not feasible or not desirable in a decentralized setup because of the, just the amount and the number of, of, of connections you have. So you typically rely on third party front party to help you to establish a trust. We have seen it in open banking, but it's also no the case in decentralized identities. So we designed the protocol in a way that it can be combined with different ways to establish trust between the parties. All right, let's talk about open ID for verifiable credentials. So we have three diff, three core specifications. We have more.

Christina will will talk about the newest addition to the, to the family in her part of the, of the presentation. So on the left hand side for the interface between the issue on the wallet, we have a protocol called open ID for verifiable credential issuance. So this is a dedicated protocol, it's an API actually of protected API that can be used to issue credentials in a wallet. And as I said, for different credential formats and also using different security mechanisms. On the right hand side, we've got open ID for verified presentation.

That's the complimentary protocol that is used to present the credentials that were issued into the wallet. They aren't really connected. So if you want to issue, for example, a credentials using a different protocol, you can do that right? And open ID for verify presentations is also based on oof can also be combined with oof functionality in a, in, in a joint flow. For example, if you want to issue or authorize payment or an electronic signing.

And then we've got a second specification, which is called self issued op V2 version two in the open connect core specification, there was already a self issued op specified. That's basically the idea. You've got the op in your hand and that op can authenticate you to some RP that was very, very visionary at that time. And we built on that concept and evolved that into the version two. That can be used in conjunction or in conjunction with the other protocols or standalone to do pseudonym authentication, right?

So the user has a, a key pair in, in, in, in his wallet or her wallet and uses that to present a cryptographically protected identifier to the relying podium. Let's talk about adoption.

As I said, we have been working on that stuff for two to three years now and we are really excited about the feedback from the community and the adoption. And this, this slide is just too small to list all of them and to thank all of them and to appreciate the cooperation and, and, and input just the selection. On the left hand side, you'll see the European, oh, have you heard about e IDAs?

Who, who has already heard about e IDAs V two? Alright, so open ad for VC is gonna be a technical underpinning of open ad for, for of e IDAs V two. And we are really excited and and really proud about that. So it's gonna be used for online presentation for issuance and pseudonymous authentication. And we also have established liaison with the European Commission recently and yesterday joined the first call. And we are trying to help them to really, yeah, we do our best to help the European Commission to make the European Digital identity wallet a big success.

And also on the other side of the, of the punt open ID for VC is, is is really appreciated and, and, and adopted. So this, for example, decided to build a, a reference implementation that uses open ID for VP to present mobile driver's licenses.

Yeah, through that, that protocol. And there are other, other initiatives going on. The col Californian department for motor vehicle for example, is gonna adopt a similar approach. But let's not forget other initiatives. So for example, at Decentralized Identity Foundation, and I think it's more than one a year ago when you presented at Universe, yeah, so there was this jut VC presentation profile and was, it has seen huge adoption in industry. So you can see among others, ping, Microsoft, IBM SPS of zero gen digital implemented that profile. So we are really amazed to see that. Yeah.

And it helped us to also evolve the protocol and there are libraries, open source libraries available and I see Daniel in the first row. So, and we hope that we will, there will be more open source libraries going forward at open a wallet foundation. So right now you can see there are implementations available in a couple of different programming languages.

And yeah, if you, if you, if you have your own implementation or you know of existing implementations, please let us know. Implementers are the core of our success, right? So getting their feedback, getting the, the, the, the, the protocol evolved according to their feedback is very important. And having those libraries help people to adopt and implement our protocol quickly. And with that, I would like to pass over to Christina. Thank You.

Wow, your time boxed perfectly. So from here we'll talk about a bit more details, what you need to know when you actually start implementing and using or even deciding whether you should implement a protocol. We'll start with the issuance. And here my goal is to really give you the context why we've built certain features and extension points into the protocol, why we are extending it in one way and not the other so that you can make a decision to know what you can actually do with a protocol for issuance.

What we did first is we defined a credential point, a new api, which is protected using owa, using owas access token refresh token, the mechanism we all know. So you would protect the endpoint you used to issue credentials just like you protect any other endpoint in your system. Then another thing we're really trying to achieve is to support various security levels. So including really, really high security levels, right?

So if you're familiar with Sappi on top of OAS for example, we are now working on a high assurance profile that would enable you to do a really, really high assurance security implementation of issuance and presentation. And then we do want to tailor for the area's business requirements. So for example, for issuance, if you want to do identity proofing and authentication of the user in person or remotely, that's supported.

If let's say you need to have an in-person admin approval and you can't issue a credential right after you collect the data from the user, we have a deferred assurance for you. If you have a scenario we, when you have to issue multiple credentials because that's how you want to prevent a linkability or if you want to issue multiple credential formats because that's what your customer wants. You have, you have a batch endpoint for you that's supported for example, right? And then we want to help you deliver the best user experience you can to your customers.

So therefore example, multiple ways to initiate the flow. So you customers first, right? And then Tristan talked about it. But we do have a mechanism where the issuer can get wallets capabilities.

Hey what, what can you do? Why? Why should I trust you? Right? And how the wallet gets information about the issuer, Hey issuer, what can you give me? What can you issue me? Not necessarily needing to do pre-registration. So it could be a bit more dynamic with trust mechanisms built in. Now to the protocol flow on the left hand, on the left hand side we have a credential issuer and the right hand side is a wallet. So first the wallet will send the request, Hey issuer, I want you to give me this credential and add the, oh there's no pointer and add the issuer.

The issuer will get consent from the user, it'll identify the user, authenticate the user, get consent and return access token. So this access token up until here, it's pretty much, you know, the all us you know. And then that access token is used to protect the credential issuance endpoint. So here the wallet will give some additional mechanisms like hey, here's the cryptographic proof. I want you to bind the credential to you know, proof of possession and all that and happy credential is issued and you can repeat two and three as long as you have a valid access token.

Refresh token for example, so let's say you are an identity provider that has already has a database about the user, right? And you wanna turn the data you have about the user into very fiber credential. So this is a flow, you'll use authorization code flow. On the left hand side, I want to highlight, I said, you know, different user experience, multiple ways to start the flow.

If so, imagine there's a general government wallet, right? It's already preconfigured user downloads a wallet application, it opens it, it says to get your digital driving license, go here to get your digital marriage certificate go here. That's the wallet initiated flow. But there are scenarios when the wallet doesn't know where the issue is, right? In those cases, issuer will send a credential offer to the wallet. It could be a QR code on a screen. That wallet just can scans and finds out where it finds the issuer. So that's more issuer initiated flow.

And then we also support issuers during presentation, the wallet received a request to say, Hey, can you please present this credential? But credential unfortunately wasn't stored on the wallet. You can start the issuance flow from there too, right? You don't want to leave the user hanging and then the wallet will ask the user, do you wanna start the issuance flow there? In the middle is the US issuer interface, right? And it's up to the issuer. How do you authenticate the user at your identity provider authorization server is up to you, you can use password web and whatnot.

And then you get user consent. And between those last line, there's magic happens in access token credential and point whatnot and credentials issued. But what if you don't have the data about the user? What if you are not an existing identity provider? We have a flow for you. Pre-authorized code flow is what you will use. So this is when you do not authenticate the user as existing authorization endpoint, that's when you can have the interaction with the user upfront.

It could be in person, user comes into your office, you'll cate the user or you ask the user to upload the all the data you need or you maybe even upload the selfie to a Porwal, right? After you do that, you send the offer to the wallet, the wallet uses, it asks the user, Hey, I received the offer from the issuer. Do you wanna get a credential? If user consents, it gets a credential. I mean there's magic in between, but that's why it's called pre-authorized. The actual user proofing identification happened before the offer happened.

Now let's go to the presentation again, the first slide, you'll give you the high points while we're designing certain extension points. One important thing to note is in the issuance flow, the wallet was acting as a client, right? The wallet was asking here it's the verifier, the relying party who needs the data? Who's acting as a client?

So first, but no very important point, we're trying to design, not trying, we are designing for the highest of privacy possible, right? So it's kind of related to the last point. Don't make about different wallet architecture. So the bottom line, the architecture where all the keys, all the credentials are stored locally on the wallet using your hardware back secure area, whatnot, for example, that is the highest priority.

Then again, we are trying to tailor for what various security levels you can use the flow in adding, let's say tickets, the tickets when you know, maybe you, you want to issue it as many wallets as you as you want. But those six tailored for the use cases where you absolutely need to know who is requesting the presentation of a credential and the wallet absolutely needs to know which wallet it's using to receive the credential. Then again, users first we want to enable you to give as rich user experience as possible.

So both same device and cross device flows are supported, which will go into then presentations of you can present multiple credentials in one flow. So if it's needed you can request, hey, give me a driving license and your insurance card and employee credential in one go. You don't have to, you know, ask user multiple times. For example, in, I already kind of mentioned but various deployment models or local cloud wallet, browser wallet, whatnot. Up to you what your architecture needs. So first basic flow, same device presentation.

Where on the device where the user has a credential stored, right? So in this kind of assumes it's a smartphone, but it's a browser wallet, maybe it can be the browser or if it's a cloud wallet could be a different interface. So let's say on the, on the phone user goes to the verifier website. The verifier has let's say deep link in this case to say hey, click here to start to get my service. And that takes a, the user to the wallet. Wallet.

Now it's wallet who also indicates the user gets the user consent that you really want to present the credential and after that the data being sent to the verifier and the user can happily continue the user's online journey. So it's a basic redirect based security that has given us. But now that's could be limiting in some use cases. There are use cases where user is interacting with the verifier on the device, which does not necessarily store the credential, right? So user is browsing user's favorite website, hopefully your website on the desktop.

So that's when one example is QR code very far displays a QR code for the user saying hey, if you want to get my service, go here. So that's when, so that website is one device and then user is interacting on device two, whereas actual credentials being stored, again, it's now up to the wallet to authenticate the user. You can do it on it's, it's up to you how to do it. So if here you want to do like a liveness check being like, hey user, you know, take your selfie, want to make sure it's actually the, the actual physical U user interacting with the wallet.

You could do it potentially here, you know there's a pin you wanna share a credential, user consents, authorizes great credential is presented, user can happily continues its digital journey. That was presentation now. So a year ago we published a paper called Fiber Credentials at eic, which kind of tried to, you know, demystify certain elements of an industry and has been really well perceived. So here are the five points, five facts I want you to absolutely remember from today's presentation. So first is naming is hard.

Even though the protocol is called open fiber presentation credentials, it, it is absolutely not about only three C data model. It's not. So for example, in E IDAs 2.0 MDOs play a role. You can absolutely present M docs whether they're in c b, you can issue them over opend for VCI and you can present them online using opend for vp, like different credential formats.

Second, if you want to use a d, OT or blockchain to anchor the keys as a key discovery mechanism, you can do it with absolutely not a necessity. If you want to reuse your existing X 5 49 certificate trust chain, you're absolutely empowered to do that. And then we really value implementer's feedback. If you implement and come talk to us, hey, we are not sure if we need to do this and we are not sure we can do it with our protocol.

We'll sit down with you, we'll identify which extension point we've already designed can be used for your requirement, for your need and hopefully we can help you there. And if we identify that, oh, it's not built in yet, but it's actually very helpful, we'll go back to the working group and discuss there and you know, if there's a consensus we'll build them. So it's an open standards body and that's why we are moving an agile. So everything's public, right? So you can see the latest version anytime you want. And the same time you can also get the latest kind of ratified stable version as well.

It's modular and flexible. Some people might, let me rewind. So it might look that having one document, one whole stack in one document that can be implementable right away, it might look easier, but it's actually, when we're talking about credentials, there's so many use cases. It's not just government, it's not just education, it's travel, it's payments, it's education, it's, there's no way this one stack can tailor for everything.

That's why our philosophy is being modular and flexible so that you can meet the need of your regulation, of your users, of your community, of your ecosystem, right? But also means you need to have profiles, you need to, you still need to have that stack. It's not gonna be a universal stack, but you need to have to give your community of implementers that stack. And we are actively helping you to come up with that. And this high assurance profile work we are doing is one of the examples. So we have, we currently have three core specifications in our fam happy family is expanding.

So on the right hand side for presentation, we have openly for profile presentations over Bluetooths being designed. Yes, when we talk with the governments, we do get a question. So great this works over the internet, tls htp, but what about the in-person, right? Where there's no internet connectivity. So this work is actually done with Moip who is actually working the government in Africa, Philippines, India.

And, but we do need more expertise in this area. So if you do have expertise in in the polluters offline, like please come talk to us, we would love to know more. Security and trust is very important. Security and trust. So pretty much, even though it says security and trust for openly, for fiber credentials, it is a really deep analysis of this whole issue. Vault verifier. And we need feedback here too. As more and more implementations comes in as a scale expands, the more questions, what about security?

You know, and trust is increasingly being talked about. How do you establish trust?

No, just violating the signature is not enough, right? You need to know why. You need to trust an entity who actually signed. So that's a really good document. And then we're starting our certification. So if you start implementing, you want to make sure you're actually interoperable with other implementers, not yet, but we'll soon have a self-certification suite for you, just like open the deconnect has a self-certification suite, we'll offer you the same for openly for VC family.

And then there's high assurance profile, which is for regulated, maybe regulated more environments or when you need the highest degree of security and privacy. We are giving you one way to do the highest assurance. One call to action, please implement, please try it out. And if you, and for fiber credentials, we need an ecosystem, right? We need multiple issuers, we need multiple wallets, we need multiple verifiers to, you know, really offer the value of this new emerging model. So please implement, be interoperable and come back to us and tell us hopefully it works.

And is there any things you want us to tailor Taylor? Again, we are happy to talk to you and there's one year url you can go with other information or at this conference if you see anyone visit US shirt or with SD dash j, come talk to us. It's our ambassadors. I'm sure they'll be happy to explain more about the works happening here.

And yeah, thank you for your attention. Is that how you say it? Thank you for being here. Thank you very much. It was a very interesting presentation. And actually we have some questions from the audience.

Oh, awesome. Here is the first one. What happens being reliant on a battery to show your identity. Imagine that you're crossing the border but you don't have battery on your phone. What do you do? You don't have battery on your phone. You go and borrow a charger from someone standing behind you. I I would, I would actually use my password, but yeah. Yes.

Well it's, it's another, another, another solution. Another question. Is there any measures in place to prevent wallet cloning? For example, wallet Cloning or cloning? Wallet cloning basically would, would most likely mean you try to clone credentials and key material in order to impersonate a user. So the way you typically prevent that in, in a verifi verify credential way is to, to use the secure areas that Christina mentioned. So you put the key material that is used to do the cryptographic holder mining into this kind of hardware which can be cleaned. That's typical a solution.

And it's also part of the, the high assurance profile that we just mentioned. Yeah, perfect.

And, and the open ID for VC protocol family fully supports the kind of security and You can have the wallet at the station when someone you trust tells you this is Z wallet, not cloned wallet that you're talking to. Yeah.

So there, yeah, we are slowly building it in. Great. Another question.

Yeah, Give us one. Well it is actually good. We see that they engaged an agreement on protocol and format is nice, but what about the semantics, which was mentioned several times, for example, agreement on level of assurance. What can you say about that? Do one? Yeah. Okay. That's a good question. First of all, we are trying to solve the tooling layer, right? And there are other organizations like Open Identity Exchange and Trust over p that are working on the, on the more, I would say conceptual power trust models and so on.

And for example, also the legislation is done for example, in in in the IDAs by the, by the respective bodies. So we are focused on a technical part, but the protocol is, is enabled to support different kind of levels of assurance. So the way we approach it is you design the certain level of assurances you need and we will give you the tools in the protocol how to communicate your requirement, right? So you have the mechanism, how to communicate, negotiate what you need, what you can support from a level of assurance, what, not from a metadata perspective, but how, what's behind it.

You gotta design it. We can help you, but you know, we can do everything we, We try to help, but we do not solve Walter Harmer. Sorry.

No, but that, that's perfect. Thank you very much. Thank you. That's all for your insights All. Thank you very much. And.