Self-Issued OP and OpenID Connect for SSI (OIDC4SSI)

Hi everyone. My name is Christina. I work as identity standards architect at Microsoft corporation, and I just said, I'm here to introduce, to use this new specification family called open and Deconnect for so self overly, but we only call O IDC for SSI. So let's get going. So regardless whether you're a skeptic or true believer of, you know, self-sovereign identity, decentralized identity D IDs VCs from different conversations, having in different worlds. And I serve as a liaison officer between open ID foundation and decent rest identity foundation.

So I get to talk to different people from this different backgrounds. I think there's one vision that people tend to share is where the user can present their credentials and information directly to the, without verify or party having to call back to the issuer or a third party provider. And for the purpose of this presentation, I'm going to use a term user-centric identity.

If there's a better term, let me know, but this is what I'm going to mean when I use a term user-centric identity and I'm not going to convince you about SSI or, you know, go with details because I think Kim D did a wonderful job and it's such an norm to speak after her. So I'm here to tell you a, if you're a business already using open eConnect already, and I'm sure you already have existing authentication mechanisms, how you can in a most simplest and most secure way, integrate SSI.

So if you're relying party who already deployed many connect and want to, you know, start receiving claims directly, or if you're identity provider who wants to issue directly into the use, there's local storage, this is a session for you, but not only is that. So I'm sure, you know, there are other transport protocols such as DICOM being discussed in the space. And for some use cases, maybe that's a better solution, but if you're sticking to the HTPs world, if you're not trying to transport credentials over Bluetooth for whatnot, open eConnect might be a good way. Good place to start.

Even if you don't have open eConnect infrastructure is installed right now. And of course, if you're an Analyst consultant, wondering whether SSI is going to be real, or is it just a hype, maybe the reconnect we'll offer as bridge, and that will shows the future of SSI. So user centric identity is real right. One example that directly pops into the mind is driving license is getting into our digital wallets. So now we can directly present digital wallets to differents without verifiers having to talk to the states every single time.

I mean, the state's issuers or DMVs in like in the us. And another example of the user center identity is real, is vaccination for nationals. That was a perfect example where, because there is no way issuer in the United States, hospitals in United States can set up federations or pre-negotiate metadata with verifiers around the world with ho, sorry. It was restaurants in Japan or border controls in Germany. So that's where this model where user holding and carrying the credential and digital format that verifies around the world anywhere can verify in a trustable manner.

That model of user centric identity looks very natural and fit perfectly well. The today's examples, mobile driving license and vaccination credentials are very concrete examples of user centric identity, right? So I'm here to propose to talk to you about the work of many foundation that offers a more general standard way to do.

If you want to apply this user standard identity approach to other verticals, not just identity or vaccination credential, because you can't always have a spec specification like MDL in ISOs that took seven years, or you can't handle to have 10 different consortiums different standards like it's happening in vaccination credential space right now. So that's that right?

It, in the, in the graph, in the picture I used to depict user identity. There's one piece missing. If it's a user who's presenting a credential directly to a verify based on what would know if it's worth trusting, if that credential being presented from the user is, you know, who trusting. And that's a piece that verifiable credential as, as a picture, which is verifiable data registry, which allows this cryptographic verification, but we see verifiable credentials is just a data model.

So the question becomes, how do you actually transport this VCs from the assure to the holder from the holder. And that's where we believe open eConnect offers a very attractive solution.

And again, I wanted to emphasize that this work on the YDC for SSI is being conducted in liaison with decent identity foundation and opend foundation. So we are really having the best brains from both worlds. And again, we think that it's, it's worth trying new protocols too, but to start with, it's a great idea to leverage the simplicity and security of opend connect. That's being deployed across billions of instances, and it's been tested and formally analyzed by different industry experts.

So it sounds really attractive to existing opend connector piece or new R piece relying parties on HS on the internet to access SSI credentials using this way. So, so much for the, you know, setting the context. So what exactly do we mean when we say ODC for SSI components? So if you look at the left part where I have number three, the issuing credentials part, there is specification code claims allegation, which is the first specification you would use to issue credentials. And this specification comes on top of any existing open connect flow.

So code flow, you know, you you're used to use using, but when you go through the presentation of the credentials, you see two specification. And this is because if it's a user directly presenting the credential, you're essentially turning a user's model device or user agent into an open provider into the credential provider. So that's where, as I will explain a bit later, a trust model changes. So self issued or PD two, the specification under number one is the specification that covers this piece.

Ooh, I have a laser point and another specification in this presentation flow is what we call open ID, connect, follow presentations, which specifically targets how the transport for follow presentations from the holder to the verify they query language, the syntax, how to request. There's a small overview before we does a deep dive, what each specification provides self issue. They'll tell you how to do proof possession of signing keys and, and claims because essentially that's the key piece of the trust and the self model.

How does the user can prove the control of the keys so that you're relying party can trust information coming from the user in the middle column, you see ODC for BP, which is a beautiful overlay on top of C two, in the sense that if you want to transport, add more trust to model in transport credentials issued by the third parties. This is a specification that you'll give you that power. And that claims ion it is a bit more general on specification, but it includes support for issue five credentials to AKA selfish ID provider.

What is it to one explanation that seems to work when I explains this is so right now open ID provider identity provider is sitting provided by a third party, right? It's sitting on the third party server and you take it, imagine taking it, you take it and put on the user's device and yes, style can be a browser wallet, PWA, but just imagine it's on the user's wallet. So that's, you know, you're, you're putting opend provider within the user's local control.

And I put this to pictures to illustrate this trust model where on the left side, imagine the usual opend connect, third party provider flow code flow. And again, I apologize for over simplification, but when the user tries to log in, essentially by redirecting the user relying party is talking to the third party provider.

And because they're only that many providers, there's an opportunity for relying party to pre-established trust, to, you know, pre-negotiate metadata to exchange the secrets and, you know, make sure the third party provider that's going to log in billions of users is trustworthy. What happens in the right model self issue model is because of the user tries to log in. It's a user's device who sends ID token self tested or sorted credentials directly. But trust happens on the first use.

And what we mean is nine party does not know whether it has talked the same type of instance beforehand, or if ever it's going to talk the same instance again. So that's where this trust model based on proof of possession of signing keys trust on the first use becomes very important and becomes very important. How does the user establish keys DDS to shares a self-assertive claims and another very important piece when considering use cases, implementations and security considerations for selfish model are same device and cross device model.

When you're browsing an website on your wallet and you find it deep link, and the app on the same device opens to share credentials, you can tie these two using, using session. So you, you you're sure you're sending the response to the same part from the request came well. What if you scan the QR code, you found on your laptop using your phone, or what if you scan the QR code, you found on the kiosk in your office using your phone.

So what if your like party is not on your phone now, that's when you can't really use the session to find these response to the entity from whom you received your request. So that's where you are trying, you are using your security mitigations are needed, but I have to know this is not the newest problem, because if you're familiar, why they see connect device flow have a similar properties. So they're really trying to find the best mitigation here.

And so SIOP, if you're thinking of using it one, you can use it to authenticate the user or receive claims, but you have to be aware that those authentication and claims will be based on the self attested signature. And again, if you want to add more trust and receive third party trusted third party verified claims or see for repeat the specification to combine it with.

And I just wanted to quickly summarize the differences between SYOP one, because maybe you have an impression that foundation as a, you know, federated identity, but trust me, the people involved with any foundation who've been working open connect with specifications for more than 10 years now, there as there's the most passion of people about user-centric identity and sell through identity as no one else, you have students industry. And that's why from 2012, this idea of self issue OB has been in the specification. It has been there.

And what we're doing now is we are simply extending that model that, you know, the great minds of open ID foundation editors have put in there. So what we did the biggest change extension is the format of the SVA tested signature. Because as I have been saying this signing part, the cryptographic trust becomes the roots becomes essential. And initially JK thumbprint was the only option. And now we are extending into identifiers resolvable to cryptographic material.

So user can include decentralized identifier as an identifier, anxiety, token, relying party with results at D I D obtain a D ID document and obtain a DD document and check the signature and then app invocation initially. So sorry, and that is using the IDs with those who allow the, for the key rotation. And so in location, custom schema, open ID it, that was the way to do it. And that had some concerns because on iOS, you would not have a way to choose which app to open.

So now we are exploring options using universal links and app links, which would become really powerful if combined the trust framework. So that's where we need your industry help to prevent another NASCAR problem.

And again, how do you obtain the birth fire registration metadata? You can't pass it inside the registration parameter inside the request, or we're exploring the option to have a resolvable client ID where you can by resolving client ID, obtains registration information. And if you're familiar, open ID connect, federations entity statements, which is the new specification too, offers a really powerful mechanism to do it. You can use the IDs, but there's another powerful mechanism too. And another important point is a response mode, and this is unique to cross device style.

And C essentially is an implicit flow. So you would use form post for same device style, but if you're using cross device, there's an opportunity to do a direct HTP post from your device to the site backend.

All right, a quick request response example. So response mode, post client ID, you can use a D I D redirect your I, and then registration parameter ID token is very simple. ISS becomes selfishly.me, and you can use a DD, the subject identifier to check the signature and very quickly ODC for Verifi verify presentations, ODC for VP. And here it does not work only for SYOP two. It works for any connect flow. So if you already have an existing opend connect deployment, this is that place to start.

If you, if you're trying to, you know, give your existing line parties for follow presentations, just add access specification and even be good to go. So the index would use claims, parameter use an opend connect and various introducing career language of presentation exchange in distress identity foundation. And the specification. The purpose was to support both JS and signature of GWS, which are very familiar with, but those also to expand the, this new developments to include J OT and signatures of length data proofs. And there are two ways.

If you can include VPs, you can either directly and embed some insights ID token, where you can send them back insights of VP token alongside ID token. So to help you imagine a VP token would look like this would be the request forc for VP. And if you're requesting VP token, if would put this presentation definit, which is se query language from presentation exchange in diff it's very powerful, very detailed. It allows you to specify the credentials. You're looking for part of a note to send back the VP token.

So you send back an ID token, and because it's a style up example that uses link data proofs and VP token, the ID token is very simple with self issue.me and the response you directly sent back a link data proof signed presentation. It's linked data proof. So it's not basics four URL and coded. If it's Jo VP, you simply have one strength. So it's really you it's, it's, it's fairly simple. And I just wanted to demonstrate a quick demo and I'll be quick on time. So let me do this. And so we extended our Microsoft authenticator application and returning it into the book credential wallet.

So if you already have authenticator, usually you would see only authenticator passwords and address, but if you scan the new, any Q code that supports our service, you would have this new blade code credentials. And what if let's say an employee sent me a note saying, I need you to verify yourself. I need you to get and employment and see, let's see what happens if you, I do shared credentials. It automatically opened my app, but it says credential not found. I don't have a credential. I have to go get it.

So here I'm demonstrating the same device site where the relying party in C on the same device. So, okay. This is very weird.

Okay, here we go. So this is the verification where you're receiving your first reply credential based on your government ID. And usually this was take a bit longer, but here for the demo purposes, Verifi verification is done. Okay. And here it tells you to open a syndicator up a deep link Eagle does it, your identity wallet, and you have to remember the pin. You enter the pin because this is what currently the mechanisms we have to prevent the sessioning of if it's across device style. So now we received a credential.

This is a Verifi credential, essentially, which is signed by this identity verification partner. So now I can go back and here, let's now demonstrate a cross device style where I'm ver I'm done verifying. I want to share the credential.

So, and you can use your normal camera app to do it. And because automatically be open of indicator and to ask you for, give me a true identity. And if I give permission, now that we're five presentation is being, sorry. Credential is being checked and approved by my employee and employee says, okay, I know who you are now. I want to give you an employment credential. Now let's use the camera on the syndicator employee ID, just put an ID.

And again, this is another session prevention, and now we have two cards then verify employee. And the thing with SSI and user identity is to need a place where you can use these credentials, right? So what can I do is this credential? I know I'm verified employee, but what doesn't give me what if we can get a corporate discount, right? So here's visa QR code, which is not coming, how it is coming. And I just refreshed how impatient.

Oh, but they already scanned. Oh, and one thing I wanted to note is this part is very important because it shows that the, to whom you're about to present your credential is verified. It's trustable. And it's very important because we are putting so much trust into the users and we are introducing SSIS, essentially the user needs to know whom the trust and whom to not to learn your extent and the do right now, arguably. Okay. So now you see on the website, the discounts are applied and I didn't have to Christina. Unfortunately we are running out of time, but sorry, I'm done.

Thank you so much for your insights. I'm sure we'll have multiple opportunities in the future to take a further deep dive. Yeah. In what you just mentioned. Thank you so much for your time. And yeah. Thank you. We look forward to you having an incredible time ahead. Thank you so much.