SIOP with Kristina Yasuda

Vittorio Bertocci: Buongiorno everybody, and welcome. This is Identity Unlocked. And I'm your host, Vittorio Bertocci. Identity Unlocked is the podcast that discusses identity specifications and trends from a developer perspective. Identity Unlocked is powered by Auth0. This season is sponsored by the OpenID Foundation. In this episode, we focus on the self- issued OpenID provider specification, or SIOP in the OpenID Connect Working Group in the OpenID Foundation. Today, we are chatting with Kristina Yasuda, Identity Standards Architect at Microsoft, and one of the authors of the specification and longtime advocate of decentralized identity. Welcome, Kristina.

Kristina Yasuda: Konichiwa, Vittorio. Thank you for having me.

Vittorio Bertocci: Thank you for joining me today. And as it's tradition, let's start with how you ended up working in identity.

Kristina Yasuda: Yeah, so for me, working in identity was really a deliberate choice. As a passion project, I've been working with an NGO, internetbar.org, on the Community Impartment Project. And we've been producing music with marginalized people around the world including refugees. And that's where we realized that sometimes we can't even pay those people because they don't have their identity. And to bring into the digital world, they don't have a digital identity. And once thing is hearing that there's 1 billion people who don't have identity, but another thing is really experiencing it firsthand. So then we started looking into the options how we can issue identity without over- relying on the governments and existing authorities, we were introduced to the concept of decentralized identity. And then we started digging more and more, and meeting amazing mentors like Nat, and now Hiro's introduced me to the amazing world of already existing, widely- adopted standards, such as OpenID Connect. And I just fell in love. I thought I wanted to work in the space. And as we got deeper, we realized that there was a need to take the best of both worlds. You know, somethings really work, something doesn't. If it can bring the best of decentralized into this already existing architecture, maybe we can make it better. I used to spend all my free time researching on identities and I'm really happy to be able to do it professionally.

Vittorio Bertocci: And so you are now working in Microsoft, right?

Kristina Yasuda: Yes. In Pam's team.

Vittorio Bertocci: We had your boss in last season, Pamela, talking about the standards in general.

Kristina Yasuda: I made sure I listened to that one.

Vittorio Bertocci: Of course, because it's the boss. Yep. All right. Awesome. Thank you, Kristina. It's so interesting. It's unusual, because almost everyone that I interview for the show, they always start with like," Oh yeah, who would have thought I would have ended up in identity?" And they always suggest a really unprobable trajectory there. And I normally tell them," Yeah, you are not special. Everyone did something odd like you," and now I can no longer tell them because I finally found someone who purposefully came to identity. So great, thank you. So let's get into the main topic today. The first question is probably the hardest, what is SIOP in practice?

Kristina Yasuda: Right. So it's the ability of end users to act as an OpenID provider themselves, right? So giving the ability to end users to authenticate themselves and present claims about themselves directly to the relying party without redirecting to an external identity provider.

Vittorio Bertocci: Oh wow. That's interesting. That's the classic scenario which I tell people,"I have to use my passport. I cannot just write my identity on my post- it and give people the post-it, because people don't trust me directly." But you're telling me that instead in this particular case, the post-it is what we want to do. So that's super interesting. So can you go into more details about, why would we want to do that? What would be a concrete scenario where having the user being able to be their own OpenID provider is actually useful, as opposed to using an external provider?

Kristina Yasuda: Yeah. So we have identity providers for a reason, right? And they work quite well, but no one is secured from the provider death. Either it's planned or sudden, and it's not just refugees who have the threat of not being able to suddenly authenticate themselves. So one example could be in Japan, exactly 10 years ago, we had the big earthquake. And tsunami washed away entire cities, including the government functions and the businesses. Right? Which included some businesses doing IDPs. And so that, while the restoration was happening, make users unable to authenticate themselves and use certain services. So that could be one of the examples. And also because if the user is giving you the post- it, you don't need to ask an issue to write that post- it every single time, right? Ideally you want that post- it given to you once from the issuer, but trusted issuer, and you can just keep giving it. So the issuer doesn't know where you're using that post- it, and which posted you're using. If you know, you ever see three or four from the same issuer, is that kind of from... I hear from some implementers that some IDPs or companies want to have less access to personally identifiable information in certain cases. So they actually want users to be able to handle the information instead of them doing it.

Vittorio Bertocci: Wow. So much to comment, so much interesting material there. So first I think the thing you say, about the tsunami is incredibly insightful. That is a scenario that people really don't think about. You would think about the cloud, but the cloud is really made of buildings. And unfortunately, occasionally buildings do get washed up by a tsunami. So that is an incredibly interesting thing to mention. And so you mentioned that there are people were unable to authenticate because literally their provider no longer existed, and instead that with the work that you are doing with SIOP, you would enable people to have some continuity, instead of relying on the continuous existence of a provider. Did I understand correctly?

Kristina Yasuda: Yes. And I think that inability of IDP could be physical, but also intentional. For example, if I'm an opposition speaking up for my people in a country that is not so democratic, the company can order certain big companies to stop authenticating me or stop giving my identity. And those are also cases where probably... Maybe those are the edge cases, but they open up those possibilities that we usually do not think about.

Vittorio Bertocci: Makes a lot of sense. And yeah, we should probably think about those possible worst case scenarios more often. So that's great, thank you. Now I understand the high level scenario. Now, taking OpenID, which is designed to broker those interactions between a remote identity provider and a user and underlying party, to make it work the way in which you foreshadowed seems quite the jump. So are there mechanisms in the protocol that you can leverage for building on and creating this scenario?

Kristina Yasuda: Yeah. So in the existing mechanism, relying parties usually have an established trust relationship with identity providers, right? But if now we're asking if we want to enable users to be the OpenID providers, if you use existing system, you would have relying parties' established trust relationship beforehand, with every single user, right? And obviously there's much more users than there are identity providers, so that's not very scalable. So we needed the mechanism for the users to prove validity of their identifiers and the claims directly to the relying party, ideally with the minimum pre- established trust. And for the identifiers, where the user is proving that they are in control of that identifier, a cryptographic verification was one of the methods that was looked at. So currently chapter seven of OpenID Connect is where the self-issued Open Identity provider initially has been outlined.

Vittorio Bertocci: Tell me more about this chapter seven of OpenID Connect core specification, before you actually came in and added the new capabilities. Like, the original chapter seven, what do they say there?

Kristina Yasuda: Yeah, so original chapter seven introduces this concept of self- issued OPs that we have been talking, and it defines new mechanisms in existence in the rest of OpenID Connect. For example, one I was about to mention, using the thumbprint of the public key of the user to prove that the user is actually controlling that public key that is used to sign the response.

Vittorio Bertocci: So traditionally, the signature that you are talking about is the signature done with the public key of the identity provider. And as you mentioned, there are far fewer identity providers than users, and so a relying party can simply look up that key and verify that. Instead, in the new mechanism that you are describing, the key is not coming, the key that signs the tokens that you produce, is not coming from a well- known identity provider that multiple parties can find out about, but it's coming from a specific user. So that's the change in respect to where normal OpenID. Did I get it right?

Kristina Yasuda: Yes, exactly. And other limitations people are having is... So the current scenario is users having OpenID provider on their devices, right? And that's where not always they can have a server that can host an endpoint to do the dynamic client registration, or to host the user info endpoint, to return claims about the user. So that was another limitations that the current chapter seven simply says," Use these set of restriction parameters," which is not very scalable as well.

Vittorio Bertocci: I see. So they predicted the scenario, but they didn't go far enough to flesh out the details to actually make it viable. Is that what you are telling me?

Kristina Yasuda: Yes. I think we were very grateful that the concept is there, but with the development of the certain new mechanisms that I'm hoping to mention later, there's a need to give a bit more flexibility.

Vittorio Bertocci: I see, great. So tell me more about what you guys are planning. What are the things that you are adding or substituting, on top of what you had in chapter seven, that actually make the scenario viable?

Kristina Yasuda: Yeah, so as I started, one mechanism currently defined for the user to prove the control the keys was JWK Thumbprint. But any mechanism is to use decentralized identifiers. And decentralized identifiers offer you a mechanism where if a user presents you with a DID, which is a string, if you follow the particular rules under which that DID has been created, you can get a document, DID document, which contains different information about the user, including the public keys of the user. So you get those keys from that document, and you check the signature of the response and check that the user is in control of those keys. That was one layer of interactions that we added.

Vittorio Bertocci: Fantastic. Thank you. Like you said, there are so many things that are so salient, that I need to make sure I understood. I'm sorry. I'm slow. So great. You mentioned that there is these identifiers that you called DID, and the magic property of this identifier is that when a relying party receives it, this identifier contains information for the relying party to reach out somewhere in some registry, I guess, and find out for these user in particular, what key should be used for checking the signature. So that the user has an opportunity when they present this token which came from their local OP, as opposed to some centralized place, to demonstrate that they are risky. Did I get it right?

Kristina Yasuda: Yes, exactly. And I think there's a comparison of JWK Thumbprint, that is also a way to prove control of the public key. But in the case of DIDs, because the ID document, as you said, sits inside a registry, user can rotate to public keys in that DID document, right? If those keys have been compromised for whatever reason. So I think that is one benefit of using DIDs over the current JWK Thumbprint mechanism.

Vittorio Bertocci: I'm tempted to ask you more details about JWK Thumbprint, but I think that the details will be very low level. So we'll just add it in the links to the show, so that if people want to know they can follow it. The main thing that instead I believe is an important part of a teacher, is these magic registry from where we are getting stuff from, these DIDs, where does it live? Because I think that's an important part of the story. Earlier we said when stuff gets washed away, like servers, in similar case, identity provider no longer exists, then we have a problem because you can no longer retrieve stuff. And one might wonder like," Hey, I have to hold these DIDs somewhere, so how do I prevent the next tsunami from washing away the hardware on which these DIDs live?" So can you comment on that?

Kristina Yasuda: So specification for decentralized identifiers, which sits in W3C, doesn't exactly specify where that registry has to be. That is left for the each DID method to decide. And of course you hear a lot about blockchains, de- centralized ledger technologies, being used as one of the registries, but that is not the requirement per se. So you can use other types of similar technologies if they fulfill the requirements of... So technically, you can have a register that is in the cloud too, I guess. Whether that brings the benefits to this new technology is a different question, but technically you can do that too.

Vittorio Bertocci: Okay, fantastic. Thank you so much for clarifying that point. I believe it's one of the points that is the most confusing this early because some people say like," Wait a minute, here is... Aren't you just kicking the can farther?" And it's great that you mentioned that those things can live on the blockchain, but that functionally you can achieve this in effect. As long as you can resolve this thing and you can extract the keys, then you solve the problem. Great, fantastic. Okay, so you added the ability, instead of using the JWK Thumbprint to use DIDs, great. What else did you add on top of chapter seven?

Kristina Yasuda: So one of those important aspects is discovering registration. And to talk about this, we probably should mention another use case or the driver behind the self- issued OpenID provider, which is... As we migrate more and more to say, digital world, there's increasing need to do authentication, authorization at the edge. So for example, when I'm getting into the car, we're not there yet, but probably I'm using my device to tell the car it's me. And as I said, I'm authorized to drive it. Or if I'm letting in someone into my house, probably I'm not relying on simply the cameras I've set up. We're asking the user to present some proofs on their device to tell me that it's actually them and not the criminal. So the assumption here is that user would have self- issued OpenID provider on the device, at least in the beginning. Probably in the future, we would have users renting parts on the server and the hosting self- issued OPs there. But right now, the first use case we have is user having a selfish OP on the device. So when they talk about discovery, which is how relying party knows how to invoke an app or software on user's device, if the self- issued OP is a native app, so the option we have now is to use the custom schema, OpenID://. And the custom schema is a mechanism that mobile operating system offers to the app developers. If they pre- registered a custom schema, the relying party using that schema would be redirected to that application, which reserved that schema. However, there are obviously several limitations. So one is, it's not only native apps that could be an edge hosting self- issued OP. Some people have been mentioning PWAs or browser wallets. And now there are some platform limitations from the OS providers. For example, in iOS, the behaviors is unspecified. If several apps registered the same custom schema, which wallet will be opened when the relying party comes, is that custom schema. So probably we would need to talk to OS providers if we want to entirely solve this problem. So this is not a perfect solution, but it is a solution we have now. And another important point I wanted to mention is registration, where again, because of the limitations of not being able to have endpoint for dynamic client registration, the proposal now is to pass registration parameters in the authorization request, together with other request parameters. And any parameters defined are subject identifier method supported, whether you're using DIDs or JWK Thumbprint. And if you're using DIDs, so which DID method you are using. And we're getting there, but which credential format you're using. And if the self-issued supports the same parameters, the flow continues. If it doesn't, the error message goes back to the relying party.

Vittorio Bertocci: Great, fantastic. So here, just for clarifying, you mentioned dynamic registration, which just in case someone just tuned in, is a mechanism that OpenID uses for allowing clients which don't have an existing relationship to just create an entry just in time and then work out this thing. And you said that the dynamic registration is not available, and then you would devise your own mechanism by passing parameters. Did I get it right?

Kristina Yasuda: Yes, exactly.

Vittorio Bertocci: Perfect. And then the other part, which I found really, really interesting if I understood correctly, is you have parameters for clients to register and clients for the provider to register. And at random you'll match the two to see whether the expectations of the relying party and the capability of your provider match, because you mentioned that you might have multiple flavors of DIDs and similar. So it's, I think, an emerging phenomenon that happens at random. Did I interpret correctly?

Kristina Yasuda: Yes. That's it.

Vittorio Bertocci: Fantastic. This is really great. You are clarifying so many things that I didn't get just by reading specs, so I am ultra grateful and I hope that the listeners will have the same light coming up. Because really, you are being incredibly clear. Thank you. So there are so many moving parts here. I know that the specification is still being vigorously debated. Just yesterday we had a call, and lots of different opinions and similar. So can you tell me a bit more about the bureaucracy of it? Like, where do we stand with the specification?

Kristina Yasuda: Yes. So this mechanism of self- issued OP, as I mentioned, have been defined in OpenID Connect, chapter seven. But a similar profile, the ability to use de- centralized identifiers as identifiers, have been also developed in Decentralized Identity Foundation or DIF. So the current work I've been talking about actually comes from based on the liaison, a relationship we established between OIDF, OpenID Foundation, and Decentralized Identity Foundation. And there are not very many people who are experts in both fields, DIDs and OpenID Connect. So it has been very important, this work has come this way thanks to the great contribution from both communities. And yes, as you just mentioned, the work is still vigorously debated. And one interesting aspect worth mentioning is... So again, as we move more digital and more transactions become digital, there's a need emerging to present claims from different sources in one transaction. So for example, if I just moved to Japan from the US, and I want to get driving license in Japan, I have to present my valid US driving license. I want to present my residence card in Japan, the passport and other documents. And if you do it physically, you have to gather all those paper documents separately and have them verified by each issuer. And if you want to do it digitally, you have to ask your relying party to establish a trust relationship with each identity provider, which is an issue of each document, right? So is there a way to have these documents available to me in digital format, and being able to send one transaction? That's where community has also been looking into verifiable credentials, verifiable presentations, which is this new credential format. So another big debate is about how can self- issued OP support these VPs and verifiable credentials in the response? And the trick here is that there are different types of verifiable credentials. So one is JWT, which is native to OpenID Connect. But another one is JSON- LD, using LD proofs, which is still undefined how that comes into OpenID Connect.

Vittorio Bertocci: So what are LD proofs?

Kristina Yasuda: I'm not an expert, I'll be honest. It's this new mechanism of signing JSON- LD documents.

Vittorio Bertocci: I see, so it's like an alternative to placing stuff in JWT, instead that you do LD proofs, whatever they are. So we'll have a link, again. That's our trick for all the stuff that we can't flesh out right away. We'll have a link that defines that, but functionally, it's just another way of a signing stuff.

Kristina Yasuda: Yes. Functionally, it's... Exactly. Another way of signing stuff and to give people, maybe... Not to confuse people, but give probably a couple of other pieces of this puzzle. So today they really talked about the presentation. How does self- issued OP presents the claims to the relying party and authenticates. But how do they get those claims they can present to the relying party is yet another question. And if we're using some new identifiers in the presentation, probably we need to tie the claims to those identifiers and the issuance too. There's work in that sphere as well. And again, another aspect is if you have several proving mechanism, for example, there's also... This is out of scope of defining in the self-issued OP itself, probably. But there's a way to combine these other query languages in other communities, such as Presentation Exchange and Decentralized Identity Foundation, or even eKYC identity assurance work in OpenID Foundation, which would... You know, there's no reason that we can't put those verified claims inside the relying party asking," I want you, the end user, to give me the claims verified under this trust framework." So those are, I think, different touch points around this work.

Vittorio Bertocci: That's great. And that part, the eKYC, is actually the subject of one entire episode, which we will air before ours. So fantastic. So much stuff I'm tempted to summarize, but I'm sure that I will do... Well, let me try it anyway. Most of this stuff that we've been covering, all the details that you explained, seem to be largely about creating a mechanism so that a user can present these identifier and proving that they are the identifier. And the thing that you added now is like, okay, we described all of this stuff about the identifier, but we also needed to have some mechanism in which we actually get attributes from actual issuers. And then present those attributes together with the identifier mechanism that you described, and then you painted a picture of how you might operate in synergies with others.

Kristina Yasuda: Yes. And probably, you know, just to add one piece, because there has been a lot of attention towards decentralized identifiers and verifiable credentials, right? But they are data models and credential models. So we need a transport. How do we deliver those? How do we use those in a protocol? So I think this work is very important to make those new innovations, so to say, is that we have usable to actually take it to the people and put them to the real life test, as they say. If they survive, we have an adoption. If they don't, probably we don't. And just to clarify, federation is good. Federation is awesome, it works. And this work is... Self- issued OP's really about adding the tool in this toolbox that we can offer to the end users as a mean to authenticate themselves and present claims about themselves better in certain scenarios we've talked about, such as edge authentication or tsunamis.

Vittorio Bertocci: That's fantastic. This is the clearest, most insightful description I heard of this ever, I'd say. This distinction between a data model and transport and how one is... Fantastic, great. I have nothing to add. What would you say is a call to action, if you want to issue a call to action to our listeners?

Kristina Yasuda: We're looking for implementations, as I said, to give this a real life test. We have certain mechanisms already defined in the specification, and now we really want to check if they work for your use case, for your combination of different parts. So if you can implement, give us feedback. I'm not asking you to file the issues or do the pull request in our repositories, that may may be too much. But at least if you can give us an initial feedback, that would be increasingly valuable. And probably also, if I did a good job to help Vittorio today to clarifying this concept of self- issued OP to you, probably helping to clarify that to other people around you will be the best action I could ask you to take. To take away the whale of this concept.

Vittorio Bertocci: Amazing, fantastic. You really gave us a lot to think about today, and I believe you really shone a light on something that wasn't very clear until now. And I'm sure that lots of people will have a light going in their head listening to this, and I'm sure that we'll get tons of questions, which is also great. And I hope that people will take you on your call to action, because they are both really useful. So I want to really thank you for your time today, Kristina. Thank you for coming here and telling us about SIOP.

Kristina Yasuda: Thank you so much, Vittorio. I really, really enjoyed it. And thank you for asking amazing questions that made me think a lot too.

Vittorio Bertocci: Far too kind. My only skill in here is not to be very bright, and so having to keep asking for explanation. Thanks again. And thanks everyone for tuning in. Until next time. The OpenID Foundation is a proud sponsor of the Identity Unlocked podcast. Since its formation in 2007, the Foundation has committed to promoting, protecting, and advancing the OpenID community and technologies. Please consider joining the Foundation and contributing to current working groups. To learn more about the OIDF, please visit WWW openid. net. Thanks, everyone, for listening. Subscribe to our podcast on your favorite app or on identityunlocked. com. Until next time, I'm Vittorio Bertocci and this is Identity Unlocked. Music for this podcast, composed and performed by Marcelo Woloski. Identity Unlocked is powered by Auth0, copyright 2020, Auth0 Incorporated, all rights reserved.