OpenID Foundation: Latest News

So I think we can probably skip over to, do you want to talk about the work groups real quick, John? Yeah. Next two slides back down. There you go. So we have a good number of work groups that we have fairly active. AB Connect, which is the, so OpenID Connect was originally called Artifact Binding for historical reasons, which only Nat and I know and will never tell. So the work group is called AB Connect, just to confuse people.

FAPI, Financial Grade APIs, Shared Signals, which if that's new to you, involves IDPs and relying parties being able to share risk signals in the background around account compromise was the original thoughts. Digital Credential Protocols, which is something I've been working a lot on and most of the European wallet stuff are all based on that work, both the OpenID for verifiable presentations and verifiable credential issuance. We have IGov, which is a working group that's mostly targeted towards creating profiles for government deployment of OpenID standards.

We've mostly been focusing on OpenID Connect and OAuth profiles in that working group, kind of converging a bit with FAPI. We're going to start thinking more about what kind of profiles we may want at an international level for the digital credential standards.

EKYC, which is standards around know your customer schemas, et cetera. Moderna, which is a work group that was targeted and is targeted towards telcos. Both the GSMA and some of the individual carriers have deployments of OpenID Connect based around a Moderna profile.

AuthZen, which is around authorization. Okay, I've gone blank on IPSC. Bringing it all together.

Oh, right. If you stack them all up. Yes. The enterprise profile, which is our newest one. Interoperability profiles for security in the enterprise, I believe. Yes.

So, as I say, that's our latest one and has been going for almost a year now, I guess. So, on this one, I'll just tag in briefly and say we're going to talk about death and the digital estate and the ecosystem community group today. We won't talk about the Australian Digital Trust community group, but if any of you are from Australia, let us know. We'll make sure you're read in on that effort and that new community group. And we will talk about CityHub towards the end.

But on the next page, I think it's got some of the thought leadership themes, which I thought you might have a couple of comments on. What we're trying to do as a board on delegated authority and a few of these kind of top themes.

So, these are the areas that the OpenID Foundation board has been looking at and figuring out how we can encourage activities in the working groups in those areas. We've had a lot of success around open finance around the world with a number of countries adopting the FAPI profiles, both one and two.

The IPSC, which is working on enterprise profiles for deploying OpenID Connect. Huge amount of work that's been going on. The OpenID Foundation is kind of being pulled between ISO wanting to get mobile drivers licenses done based on Connect standards. And the European Commission wanting to get EIDAS done based on OpenID Connect standards, which aren't necessarily asking for exactly the same thing.

So, trying to get the specs worked on interop events and being able to get things done in time so that various legislation can reference them. So, there's been a huge amount of effort over the last year around the verifiable credentials ecosystems. And we have other pieces of the OpenID Connect framework such as federation and other parts, which will eventually be part of the verifiable credential ecosystem.

So, the board is trying to look at it, not just the individual pieces that we have now, but what other pieces do we need to develop to fit in to actually have a working ecosystem. Global interoperability.

Again, it's actually kind of surprising from the verifiable credentials point of view. Europe and the way that European countries look at deploying verifiable credentials is quite different from the way that US states look at deploying mobile driver's licenses. They may be using technically, or intend to use the same technical standards, but different parties have different trust relationships.

So, in Europe, we have relying parties that trust issuers. The issuer is responsible, i.e. the German government is going to issue a PID. The relying parties trust that the German government is going to properly make sure that the wallet that they put the PID in is secure, and it's going to authenticate the user properly, et cetera.

So, the trust model is the relying party trusts the issuer and the issuer needs to be able to trust the wallet and make sure that the wallet does everything well. Around mobile driver's licenses, especially in the US, we have a situation where nobody trusts the issuer. Because they're American states, well, American states. At least in the US.

So, there's a whole, even though it's the same protocol, a bank that wants to use a driver's license or know your customer wants to know, well, what wallet did you really issue that into? How did the wallet verify the person, et cetera?

So, even though it may be the same standards and the same, at a high level, a three-party issuer, holder, verifier, from a global point of view, cultural differences in the way that people look at things creep into this. So, we have to understand those differences so that we can actually start addressing how do we get these things to work cross-border because that is one of the things. People will, if you have an electronic passport or a mobile driver's license, if it doesn't actually work cross-border, a lot of people are going to be highly disappointed.

And some of the stuff that we have, we've also been looking at how do we delegate authority in Europe, in some ways we call it proof of responsibility. So, how do we, in the protocols, deal with cases where your wallet might be controlled by an AI agent that does things on your behalf, which strikes me as a horrible idea, but we should at least identify that it's a horrible idea if we don't want people to do it.

And if we do want people to do it, how do we represent that in the protocol for kids being able to represent, have adults, their parents be able to do actions on behalf of a child to access social media, et cetera? So, those are some of the things that we're working on from a board point of view. And I think we'll probably skip through this in the interest of time.

So, we can just fast forward to the section that Joseph's going to talk about and get into the verifiable credential. That's the press, lots of press.

Oh, sorry, pause. Oh, yeah.

Awesome, awesome recognition of OpenID Foundation affiliated folks that were named in the identity top 25. So, big kudos to everybody in the top 25, but certainly- They all got their picture in Times Square for five and a half seconds.

Yeah, exactly, exactly. So, carrying on, we're going to dive into this particular quadrant on the digital credentials, protocols, and we can give Joseph the clicker to get to his slides.

Thank you, Joan. Okay, good morning, everyone. I'm Joseph Heenan. I'm the Standards Specialist and Certification Director at OpenID Foundation, and I'm also the CTO at Authly, one of the vendors in this space. And I'm one of the co-chairs of the Digital Credentials Working Group, along with Christina and Torsten, who unfortunately can't be here this morning, so you just have to listen to me.

So, I'm just going to do a bit of an overview of the specs, which won't be new to some of you, and then I'll talk about some of the latest status, which will be new to a lot of you, probably. So, the Digital Credentials Protocol Working Group focuses on two specs, OpenID for verifiable credential issuance, OpenID for verifiable presentations.

So, in this three or four-party model where we have the issuer, the wallet, and the verifier and the user involved, OpenID for verifiable credential issuance deals with getting the credential from the issuer to the wallet, and OpenID for verifiable presentations deals with getting a credential from the wallet to the verifier, and how the verifier requests the credential and things like that.

And then we have one spec that's kind of overlapping them all called the OpenID for verifiable credentials high assurance interoperability profile, or HYPE, which builds on top of the issuance spec and the presentation spec, and is opinionated to increase the interoperability by reducing the optionality and also increasing security by when it's picking options, picking the options that generally represent the higher security ones like you might want to use for mobile driving licenses or European ID cards and that kind of thing.

And having interoperability at this kind of protocol layer is crucial because this is a very nice, simple model where you've got one issuer, one wallet, and one verifier, but that's not the reality. We're gonna have a lot of issuers, far more than there is on my slide. We're gonna have multiple wallets, at least in the short term, and we're gonna have an awful lot of verifiers, probably thousands if this all works well. So unless we get these protocols secure and interoperable, it's gonna be a nightmare to deploy these ecosystems.

So going right back to the days when we actually started the work on these standards, there were a number of core problems that we identified and set out to solve with these standards. There are an awful lot of people developing new protocols that were completely greenfield and had some questionable properties. The OpenID for verifiable financial issuance and presentations, they build on top of OAuth 2 and OpenID Connect, which are well understood protocols already. We know the security properties very well.

And it also looks very familiar to people that are already familiar with OAuth 2, which, as everyone knows, is used basically everywhere billions of times a day in these things. And another issue is that there's an awful lot of different credential formats out there. The big one's probably been W3CV verifiable credentials, ISO mobile driving licenses, SDJOTs. So the OpenID protocols are designed to be credential format agnostic. There's always been a lot of controversy around DIDS, so you can use the OpenID for verifiable credential specs with DIDS, but you definitely don't have to.

You can use them without DIDS. And there's an awful lot of different ways, as John was mentioning, that trust is established in some of these verifiable credential ecosystems. So the OpenID specs are pretty flexible in how you can manage that trust and give you a lot of different options.

Again, Hype is a bit more opinionated about this. It does want to be an interoperability profile, but it still gives you quite a bit of flexibility as to how you actually do the trust management. So talk a little bit about global adoption. So the European Digital Identity Wallet Architecture Reference Framework, or ARFF, that mandates the usage of both the OpenID protocols and Hype.

We're also working with the European Commission at the moment to take the specs through a process that will hopefully result in them being named in the next revision of the European Digital Wallet Implementing Acts, which gives them the weight of law at that point, rather than just being in a reference framework. We've been doing a lot of work with NIST. Gail's going to talk a little bit about some of that a bit later. We did some work with the Japanese government Trusted Web Project last year. They've deployed these protocols for various use cases and done some testing around them.

And we're also very grateful that the Japanese government provided some funding to develop the conformance tests for these protocols as well, which is very much appreciated. And we did run a prize at EIC last year. The specs got the Innovation Award, is great recognition and great work by the team. And we've been doing a lot of interoperability events recently. We've been working, for example, with the potential large-scale pilot in Europe. That's not the only large-scale pilot we're working with, but it's one we've done a lot of work with. We've been working with NIST, as I mentioned.

And we've also been doing some work with the ISO working group that's working on MDLs. We did an interoperability event with them in Utrecht two months ago now, I think. Testing out OpenID for VP with a profile that we're hoping will be incorporated into a future revision of the ISO MDL specifications. And we have a security analysis of these protocols. So OpenID Foundation has a general policy. We like to do formal security analysis of our protocols before they become final. We work with a team in the University of Stuttgart who do this. They turn the specs into a mathematical model.

They turn the threats we wanted to prevent in the specs into a mathematical model and do some clever maths to prove that the two things do actually do what they said and we do prevent the attacks we intended to. So we've got an older analysis done by Fabian that's linked there. We're working on an updated analysis at the moment with them for the version of the protocol that runs over the digital credentials API, which I'm gonna talk about in a bit more detail later. I suspect some people haven't heard about that. And some highlights. So verifiable presentations.

I'll get into the status a bit more later, but we're asking people to kind of concentrate on implementing draft 24. That's the one we recently did interoper on, or draft 28, which we're currently trying to get through public review into final status. So verifiable presentations, it's designed to have a high degree of security. It can operate without a wallet backend in some cases.

In some cases, you do need a wallet backend, but when you do need a wallet backend, it's still designed to expose the minimum information necessary to the wallet backend so that the wallet provider's backend doesn't get to know everything you're doing. Various security levels can be supported. As I mentioned, if you want the high security, you can then go for hype. It's pretty easy to use for developers. We've had people implement this in just a couple of days. It's a relatively low lift at this point.

It supports presentations of multiple credentials in one response, so that can be particularly important. I think particularly for some payment use cases, it's useful to also be able to present a loyalty card at the same time as your payment credential, but there are plenty of cases where you might need multiple credentials to solve a particular authentication that you're trying to get through.

And there's various different wallet deployment models supported, so although a lot of people are focused on mobile app-based wallets with or without backends, there's also web-based wallets, and the presentation spec is not opinionated about this. Either model will work just fine. And as I mentioned, various trust frameworks and credential formats can all be supported, so we're trying to make sure we're inclusive and it will work in any country in the world and be compliant with their laws.

Okay, so I'm gonna talk a bit more about the Digital Credentials API, because some people may not have come across this yet. The problem that was identified is that presenting credentials on the web currently relies on custom URL schemes and QR codes. They have some poor security properties and the user experience isn't great. When I say custom URL schemes, I mean things like these ones on the right that applications can register for them, and it's how the verifier actually launches the wallet, basically. And I should say thank you to Tim Capalli for these slides, because I stole them from him.

So the problems with these things is when you actually invoke, when the verifier tries to invoke the wallet, you just, this is an example selector on Android, you just get a list of wallets. You're not given any of the context about which credential is wanted, who's requesting it. You end up with an app context switch when you do this. It doesn't necessarily gracefully fall back for any errors, like if there's no apps installed that could actually handle the particular thing wanted, and users don't really understand selecting wallets that users understand credentials.

So what the Digital Credentials API does, this is a working group at the W3C that's been developing this. We have at least one of the co-chairs in the room, Heather. They've been doing great work. We've been working very closely with them, and it's building on top of some of the things that came from Passkeys, because Passkeys have solved a relatively similar problem, but for a very different type of credential.

And the advantage of building on what's already done with Passkeys is that there's already been a lot of thinking about how the user interface should work, but also how you do this cross-device securely, which is one of the big problems with the custom URL schemes, and showing custom URL schemes, particularly in QR codes, is very possible. It's very pishable, and it's quite hard to actually do binding across the devices and ensure that the user's devices are actually in proximity to each other, and it's not attacker trying to convince the user to do something they shouldn't.

So this is the solution. This is how it ends up looking. This is a dialogue provided by the OS. This particular example came from Animo's verifiers. Thank you to them for providing me with a screenshot. And the advantage compared to, if you remember, the wallet selector we had up before, which was just giving you a list of wallets, what's happened here is we've passed a query to this API. The query format is defined in OpenID for verifiable presentations.

The OS has shared that query with all the installed wallets in a way that doesn't leak it, which I'm not going to get into the details of, but it is privacy preserving. This is not a privacy problem. The wallets have said what credentials they have that match the query, and then the OS has provided a list to the user of all the credentials that match, which in this case is just one. So the user just gets a, this is what's been requested, a driving license. This is the fields, the name, and the family name. And it says at the top, func.animo.id is who's requested it.

And then the user gets a chance to either see more details or just to agree and continue. And if they continue, then the actual wallet gets launched and the wallet then has an opportunity to do biometrics or other authentication with the user to do more authentication on the verifier and things like that.

Okay, so I'll switch over to the issuance spec now. So the issuance spec, we published a second implementer's draft just two, three months ago. We're encouraging people to implement that right now so we get some feedback on that spec. Very similar properties to the presentation spec, easy to use for developers, various security levels can be supported. A whole variety of business requirements and user experiences can be changed as different flows that when you send the user a credential offer or the wallet can initiate fetching the credential. It's pretty flexible and the same as presentations.

It supports all the trust frameworks and credential formats that we're aware of and can be expanded to fit more credential formats if people want. And we've developed conformance tests that support these protocols. So this very busy slide is kind of an overview of what we have conformance tests for at the moment. The highlights, we've got tests for OpenID for verifiable credential issuance with the High Assurance Interoperability Profile. We've got tests for both issuers and wallets. They're in an alpha stage.

If you've implemented the latest implementer's draft of that, please let me know and I'll tell you how you can, particularly if you've implemented it with the High Assurance Interoperability Profile as well, please let me know and I'll help you run the tests and we'll see if they actually work or not. For verifiable presentations, we've got a much more mature set of specs, sorry, set of tests.

Again, we're targeting hype, but we've got the older implementer's draft, but also the latest implementer's draft three that was published, I think, just around Christmas. Although we're actually using the version slightly after that that includes some important MDL changes and for the wallets we can test with the browser digital credentials API I mentioned as well. So this is very comprehensive.

And as I say, we've used these in a couple of interop events now and we've got, I think, probably approaching 20 plus wallets that have passed these tests and similar number of verifiers that have passed them as well. And we're trying to move all these specifications towards final. So we've had implementer's drafts of all of the specifications in the last few months. I'll not go through the details because I don't have huge amounts of time.

The things we're focusing on at the moment or things that have happened recently in the verifiable presentation spec, if any of you are familiar with older versions, then it initially included presentation exchange from diff. That was a great query language. It helped us get the presentation spec up and running quickly and really provided a basis for all the initial work that happened. But what happened as we progressed things is we got a lot of feedback from developers that actually that spec is not great. And there are a lot of things that could be improved in it.

And we've now got a query language called DQL, D-C-Q-L or DACL, I think I'm meant to pronounce it. I keep on pronouncing it wrong. I've been told. So we had that in the latest implementers draft. We've had a lot of people implement it and we've had really great feedback from developers. So the end result was that in the spec that we're trying to take to final now, we've actually removed presentation exchange entirely as an option now. So the only option is to use DACL. And we've had some good feedback on that. We've recently made some changes to support multi-IP authentication.

That means when you're using the digital credentials API, you can make queries that will work with multi-IP. Will work with multiple trust ecosystems. You can potentially supply multiple certificates if you need to query both say EU and US credentials or something like that. We'll be doing a lot of interop testing. We're gonna be doing more interop testing on the final proposed version of VP in June. So if you're implementing the latest spec, let us know and we can include you in that interop work. What's the other? I shouldn't go too deep into any of these things.

There's a few topics we're working on in VCI at the moment. We're looking at working with the W3C on how we would do a similar browser API for issuance because that's only defined for presentation at the moment. So that's something we're trying to resolve before we go to final if we can. We're working on presentation during issuance, which is important for some European use cases at a minimum. And we'll be doing interop testing on the latest implementation. We're looking at the latest implementers draft and getting some good feedback there.

And we're doing a lot of work on hype at the moment as well. It was originally targeted just at SDJOT, but we've been working with the ISO working groups that work on the MDL and the underlying MDOX spec. And we've had some quite encouraging work with them where they're supporting us in defining how MDOX would work in more detail with the VP and VCI specs, incorporating that into the hype. And then the hope is that the ISO working groups will agree to just reference hype rather than defining their own custom bits on top of it. We're actively engaging with them on that at the moment.

And I think that's me. In 20 minutes, as promised. So thank you, Joseph. So quick show of hands. Any of you who've been in the DCP work group, can you raise your hands? Just a huge thanks to all of the members of the DCP work group. They've been meeting twice a week for weeks and weeks and months and months in order to get to the point we're at now, which is remarkable. And if I can have the clicker, I will show you the remarkable results. Failed to mention some of the timelines actually. So we are trying to get all these specs to a stable version by the end of June.

So that's why the working group is so busy at the moment because we are just trying to finish off all those last things, get them in June because the EU need a stable version by June to reference them in the implementing acts. And ISO wants stable versions by then so they can hopefully reference them in their specs as well.

Yes, not every day you have your specs being referenced in implementing acts. So pressure is definitely high, not only due to the EU's demands, but also ISO's demands as well as NIST demands. And then we also have very valued friends in these standards bodies who need to be able to refer to our underlying specs. So a huge appreciation to our peer standards bodies for their ongoing collaboration. If I can click forward, hello, there we go. As is our practice now, before we move to final, we wanna make sure we have interoperability of the specifications, which I'm gonna talk about.

And Joseph already referred to the known security properties and the due diligence we're doing with the University of Stuttgart. The objectives of our interoperability is pretty obvious to any of you who've ever taken part in this before, but we wanna prove out the specs themselves, provide the results to our SDO peers, conform the feedback into the tests, which we make open source for anyone to be able to take advantage of. We wanna brief our government partners that we're delivering on their requirements and in the timelines that they're kind of looking for.

And we absolutely wanna make sure we get to a place where there's global scale adoption, right? So we see similar types of adoption as we've seen with OpenID Connect. So I gotta point this in the right direction or I don't get it. So huge shout out to our implementing teams. So all of these players, including a corporate player who didn't have the permission at short notice to give their permission to use their brand, but incredible work by these teams to achieve the results that you're gonna see in a moment.

Joseph has talked through a lot of these core requirements, but we have clearly defined the specs that were gonna be used by these implementers so that they could have the right running start to prove out the interoperability, including very specific Ducal queries. So if you're interested in any of this information, happy to share it with you offline. But of course, we also ensure that the implementers could prove their implementations against our conformance test as the gating point to take part in the interop.

So if any of you are building towards OID for VP or VCI, please do take advantage of the tasks that Joseph has written and his team has written so that you could also take part in the next wave of interop events that we'll be having. We're approaching this a bit like a marathon. We keep doing them over and over and over again so that we can bring more and more people into the club with us. So the results that we saw as of, I think this was Sunday night, I totaled up all the manual pairs that we could have possibly had across the seven wallets, eight verifiers and four Ducal queries.

And if we kind of skip out the ones where there weren't results because they hadn't built it yet, like they had MDoc, but they didn't have SDJOT, or they simply hadn't done that particular pair and rerun the test, we had 153 pairs that were running and 98% of them passed and 9.8% were viewed as resolvable. So the implementers believe they knew exactly what the root cause was and again, it was kind of a known issue on the implementation side.

So from these results, the co-chairs and the folks working on the specs believe that the underlying specs are solid and the testimonials from the implementers refer to exactly the same, that they have the confidence that specs are where they need in order to move into scale production. And that includes players like Google deploying it, which they referred to in their blog post last Wednesday. We also have the results from Microsoft. Is Juliana in the crowd? There she is.

Thank you, Juliana. And I don't know if we have any Matter folks in the room, if Oliver's around, but big thanks to Juliana and the Microsoft team, as well as Oliver Teraboo and the Matter team for pulling together a verifier, which was taking, I think it was nine or 10 wallets across a single verifier to achieve these results. You can see 100% pass on two of the four Ducal queries and the success rate's a bit lower for a couple of the other Ducal queries because they proved it out, they had to make a few adjustments and then they got the passes later.

But this is kind of an example of all of these different wallets running these different queries for these different SDJOTs and MDocs and getting meaningful results. And it was really cool to see how Microsoft was setting up the platform with Matter in order to show that this is real for relying parties, like they could do this at scale in the way that they were running these campaigns.

So again, really important takeaway and these are results we're gonna be submitting to ISO to kind of share with our work group 10 and four colleagues so that when they're making their decisions on what should go into the ISO documentation and specs, that they have this evidence to be able to lean upon it. All right, with that, we're gonna switch. Let me just quickly pause. Any questions for Joseph on the specs? Or interrupt?

Okay, we're happy to take questions towards the end as well. So for this piece, I think we're gonna go into death and, Mark is gonna talk.

Okay, Eve. Thank you so much, Eve. Thank you. So there are slides and I think they're ahead, yes. Just get through the EKYC stuff and then the DADE section. So DADE stands for Death and the Digital Estate. Dean Sachs, who unfortunately isn't here this week, started this conversation, actually, I think at Identiverse last year and he invited some of us, including Mike Kaiser, who's standing there in the back ready to heckle, and myself onto a panel to discuss the challenges with the digital estate.

Not sort of just pure financial, not physical estate, but what happens when your loved one passes away and there's digital assets left behind. So Dean created these slides. He decided that a community group at OpenID Foundation would be the best way for us to collect use cases, to understand what it means to have these digital assets and who should be able to use them, what are your wishes when you pass away about what should be done with them, and how do you deal with the aftermath when somebody that you know passes away and you're somehow responsible for dealing with what happens.

So we've come upon this topic at a really interesting time because it's getting a lot of international notice. There's a lot of articles being written, both about the struggles of the survivors and dealing with massive numbers of accounts that we all live with, things like that. Also mistaken, sort of mistaken identity. If you haven't passed away but somebody in the electronic system thinks you have, what are the consequences of that? Both halves of those are really quite troubling. And it could really, the systems that get messed up can be accessed to your financial assets and so on.

At the same time with Gen AI rising, we've seen discussions about things like grief bots, death bots, people simulating those who have passed away in a chat bot sort of thing. And is that okay? What are the cultural implications? What are the different cultural implications around the world about what's appropriate? So what we're doing, I think, yeah, we're working on a white paper that will come out around Cybersecurity Awareness Month. So this is a great, we invented a forcing function for ourselves to summarize what we've been learning.

We're a community group, not a technical working group, although it's hard to keep from solutionizing. We are collecting use cases. We're collecting things like the design patterns for when you are able to set up a legacy contact in your bank account or in your social account. So we're collecting those for use by a lot of folks. And we're finding out about our peers around the world, like the Digital Legacy Association, that is something I didn't know existed until recently. And we're hoping to work with them to maybe feed into the technical picture around what might be possible in future.

So probably expect either a future working group or we've got many touch points with the EKYC and IDA working group because of that delegation of authority connection primarily. And we're looking forward to providing kind of the design patterns around what would be good ways to solve this in these difficult cases. So Mike and I pretty much this week are representing Dade here. We're both co-chairs along with Dean. And if you'd like to contribute, we make it easy to do so. And this white paper is in active development right now with help from Heather, who I see over there. That's it.

If you have any questions, you can come find me. Thank you. I appreciate that, Eve. I don't think I personally could underscore enough the importance of this conversation, right? If we as an identity community haven't solved these problems for people, you know, as they move into, I think the concept is that by 2050, there'll be more dead people on the internet than people that are alive, right? Which is terrifying and very troublesome, right?

We may be technologists and familiar with how to handle our own information, but can our next of kin have the same ability to get access to our information? And if we have that trouble and our families have that trouble, what does that mean for the rest of the global community? So thank you for all your work. Appreciate it. Okay. You're gonna do this one? Okay. I'm introducing Mark Hain, Technical Director. Go for it.

Mark, do you want a microphone? Or are you gonna just do this? Okay. Yep. This doesn't work. Thank you.

Oh, there's one down there. Right.

Hi, everybody. I'm Mark Hain. Amongst other things, I'm on the staff at the OpenID Foundation. I'm also CTO of an ecosystem in the UK financial services sector around digital identity. So in the EKYC and IDA working group, we've been going through a bit of a transition. We delivered the OpenID Connect and OpenID for identity assurance specs in September last year, which was a huge hurdle to get over. And we're now seeing some implementation of those specs. But the question is, what do we do next?

There's a little bit of work going on around a spec called OpenID Attachments, which we'd split out from the identity assurance specs. But that's almost finished. That's now open for membership review before heading toward final over the next couple of months. And so we've had a bit of a discussion about that.

And off the back of a spec or a draft that we created about three years ago, we started looking at a thing called OpenID Authority, which actually turns out, crosses over into a lot of different areas, including the DADE side of things, a lot of the kind of age assurance and parental authority for children and young people to access services online, and legal entity delegated authority use cases. So there's a lot of really interesting work there.

And I'm intending that we work quite closely with DADE and other stakeholders around this kind of, on behalf of set of use cases to work out the concepts that we need around this, the gaps that exist in the technical space, and move that forward. On the identity assurance side of things, we're now hard at work getting the conformance testing suite upgraded from the beta version that we previously produced into one that matches the final spec that we produced, and make that ready for wider consumption.

That's well underway, and we have, I think, three or four real world implementations that we're going to use to test the test tool as well. So that's really great news.

Yeah, I think that's kind of most of that slide covered. We're getting the conformance testing out to beta.

Again, you may not be aware, but we were also contributing our work into the GainPop community group, and proving out different use cases there to allow for identity assurance metadata to be communicated between unalike identity systems. That was quite useful input into the kind of final stages of the identity assurance spec delivery. And we're hoping in a matter of two or three months, I think, to get to final tests. And so thanks to Joseph and the rest of the conformance testing team who are working hard on delivering that. I'll come on green button. Now switching into white papers.

The main thing that is relevant from my side on the white paper side is one that's coming forward on agentic AI as well. That is the final kind of broad set of use cases that we're looking at around the delegated authority kind of domain. And we'll be working with Dade a gentleman called Tobin South, who's a post-grad student looking at this space. He's going to be authoring a paper on behalf of the OpenID Foundation. I think we've got slides about it in a minute, haven't we Gail?

To address what is the scope of the problem, what could or should be done and what gaps exist in the standard space that should be filled in that space. And also there's work going on around particularly protecting children online. So there's white paper coming forth around that kind of age appropriate online access using delegated authority for representing parental authority. That's coming through as well. So the attachment specs moving towards final briskly, the authority spec, I'm afraid it's not implementers draft two. We're going to be moving to implementers draft one.

But again, I think that's going to be dependent upon the conversations that we have underway around all of the other kind of delegated authority use cases. And we may need to make adjustments to that to make it more generally applicable. If anybody, by the way, has interest in that delegated authority kind of domain, please reach out to us. We'd love to have your contributions in the working group. I'm going to skip through Eve and Dean's slides.

Sorry, we had to reorganize the things a little bit that Eve had to get off somewhere else. And I've already kind of mentioned a little bit about the AI side of things. There's a lot moving in this space, of course. And from my own personal perspective, I think there's quite a lot of anti-patterns going on. The idea of just giving your username and passwords to an AI kind of fills me with horror. I'm maybe slightly less horror struck about there being an agent acting for me, make sure that we do that consciously.

We express that it is authorized to act for me when I have authorized it to act for me or cases that I'm kind of interested in addressing. And a number of us in the foundation are going to be supporting Tobin as our lead author on the agentic AI side of things and the authoring of the white paper around that. He's going to be creating a state of the union paper about this and hopefully identifying gaps that need to be filled in that space. And I think OpenID Foundation is well positioned, as it says.

We've got a lot of people who have interests in this and expertise in this space and a number of opinions that should lead to a really interesting paper. Yeah, so I don't need to say too much more about that. And in the interest of time, yeah. So if you wish to engage, there's details down there, director.ydf.org as a shortcut is probably the best thing. And in the interest of time- Or join the EKYC and IDA work group and then you're going to get read in on feedback on paper.

Yeah, absolutely. And I don't think this is for me to cover. So who's next? Excellent. We're going to be moving to the topic of enterprise security and the working groups that are touching on that. And Mike Kaiser will go first, talking about IPSE and shared signals.

Thank you, Mark. Thank you much. Show of hands, who here likes dolphins? Right? There's a longer story I can tell on Thursday in my other session. People in generally like dolphins and it's a good illustration for shared signals because dolphins in general, when they're not being jerks, are cooperative, right? And that's really what the motivation behind the shared signals framework and the shared signals working group is.

For a long time, security and identity has been in silos of information where one vendor or one component knows something about an identity and doesn't choose to share it with the group. Shared signals and the shared signals framework gives us a way for sharing that context in real time or near real time in an event-based method so that you can have an informed group of actors serving the enterprise, serving the organization.

Now, this diagram shows you what it is. And I like to say the shared signals framework, the whole thing, because when I tell people, hey, do you like sharing signals? Everyone says, yes. But what I actually mean is this specific SSF transport layer you see at the bottom that handles the plumbing, basically the transport for all of this, signing of the events, setting up a transmitter receiver you'll see here in a minute. And then on top of that, you have different event types or classifications, right?

From the risk-based events in the far right, which kind of account level kind of things to the new hotness, which I call, which is CAPE, which is basically session-related events from everything from session revoked to credential change to what have you. And then finally to something that's coming, which are SCIM events, which is actually in last call in IETF. And that's what my session is on Thursday. But basically these different kinds of events get sent over this base transport layer. Here you see a little bit more technical detail, what that means.

Upshot here, your takeaway is you have a transmitter and a receiver and the receiver calls out to the transmitter and says, look, I want these kinds of events about these types of identities. Sets up a stream and either push or pull method. The transmitter sends those to the receiver. There's trust established, all the things you'd expect. And the other thing to note is that this standard is descriptive, not proscriptive. In other words, the transmitter doesn't say, I did this, you have to go do X, Y, and Z.

No, the transmitter just says, look, I changed the device compliance status for this identity. I know about it, I'm telling you, you do what you ever you need to do in the proper context. So there's control on the other side. Keep in mind there's an enterprise standard so that the organization owns both. So in most cases, the enterprise is going to decide, you're going to send this event, you're going to receive it and you're going to take this action as a consequence. Updates to the spec, we're moving them to be final in the near future.

We've had three different interop events at the last two Gartner London events and the last Gartner one in Dallas. We learned quite a bit through those. As a result, we've done a couple of things like adding a new subject format based off of IP addresses, addressing lifetimes of streams, working on some authorization issues, and in general, reorganizing it for readability and to promote adoption going forward. The interop events, the most recent one was actually in March. We had five or six of the first interop. This is what you see on the screen is the second interop. We shot up to 12, 13, 14.

It went a little bit down in March in part because it was in London as opposed to in Dallas. But overall, there is pretty wide scale adoption. I personally am aware of around 28 to 30 different vendors or enterprises that are putting this in production or moving to production, which is pretty incredible for how long we've been at this. And this just shows you, oh, here's the March one. So it's pretty good feedback from audiences. Customers and clients are all like, yeah, didn't you already do some of this stuff? And we're like, no, not really.

You could do it on a one by one, but the standard really helps promote that and helps people get value out of having a whole ecosystem, as I said, of informed actors. In terms of adoption rates, you can see there's a number of vendors who are already solidly in production.

As I said, there's a vast number who are on their way. Several government agencies in the States and elsewhere have it.

Google, for example, has a legacy risk implementation and Microsoft has one internal. So it's not a foreign concept to most of the vendors who talk to, and everyone is at least interested in discussing it, as far as I can see. In terms of what we're going to do in 2025, obviously we already had the interoperability event. We're talking about moving to final, as I talked about before. There are conformance tests from the OpenID, which was a wonderful forcing function.

It's a lot easier to hand a conformance test to somebody and say, comply with this, especially because the conformance test had links back to the spec. So when people have trouble understanding what they're supposed to do, it's great to be able to say, here, this is what it should look like.

Super, super helpful. We're also looking into using shared signals with financial services and transactions and things of that nature, exploring that. And we're also providing input into the Aspen Institute upcoming discussions on solutions around due diligence and those types of things. So it's an exciting time for the working group in general. IPSE. How many of you are familiar with five standards in this room?

Or 10, or 15, or... It spirals pretty rapidly upwards, right? And so what IPSE tries to do is try to make sense of them all and give advice on how to best implement and deploy these within an enterprise. You have lots of different standards for lots of different organizations or working groups. More than one way to implement these standards is looking for advice to not only implement them well, but to do it in a secure way.

SSO, of course, is not enough to implement things. So they need to all kind of have a coherent approach. That's a general idea behind IPSE. Charter scope is pretty broad if you look at this, right? Everything from stuff you'd expect like single sign-on to user lifecycle management to some type of signal sharing, kind of like shared signals that I talked about before.

Remember, it's defining profiles, not actually creating new standards. So it's, this is how you do it. This is how you use it. This is a best practice to make things consistent and usable across the board. Started in October 2024, kind of in two parallel tracks. One is the session lifecycle, kind of more access management-focused, IDP-focused. And the other is identity lifecycle. Has to do more with managing that identity over time, right? There are levels within the system which indicates increased capabilities, but it doesn't necessarily mean it's better.

It's just to identify what level and what part of the approach you're implementing so you can communicate with other people in the organization. There was a webinar that was well-attended. People came to hear about what we're doing, what we're talking about. So there's obvious interest in developing this further. In terms of what we're doing or how far we've gotten, we've got SL1 already in progress.

There's, it's on GitHub, it's up for adoption. The SL1 SAML 2 profile is out there for your viewing.

The IL1, we've just started. It just released onto GitHub about two weeks ago or something. So it's up for discussion, up for iteration. And we're looking to have SL1 and IL1 together because they work best in unison, obviously, shooting for a potential interop event for Gartner in December. SL is that session lifecycle and identity lifecycle. So session lifecycle, think more of an access single sign-on kind of approach. And identity lifecycle is identity lifecycle creation to end of identity.

To that end, the IL1, the identity lifecycle approach is largely focused around SCIM 2.0, for instance. And that's about it. I was trying to be very quick. Next up is Off-Zen, I believe. With David, there, and Oliver. Good morning, everyone. I did not know that about dolphins. Thank you. My name is David. This is Alex. We're both on the open I.D. All-Zen working group and we're going to walk you through a quick summary of what we do. We do have a longer session on Thursday, or a slightly longer session that'll will walk you through what All-Zen is.

But in a nutshell, the whole idea of All-Zen, I've got to put that in the slide, so bear with me. The whole idea of All-Zen is that there's many different ways of doing runtime externalized authorization. Alex has a way of doing it. I have my own way of doing it. There's other ways of doing it. And we don't speak the same language.

So if you, a company, you bought into Alex's PDP, policy decision point, and started doing the plumbing, and then one day you want to switch to my PDP because it's better, of course, right? So that's the way it is. Then you'd have to redo the plumbing. So the whole point of All-Zen is to actually, first and foremost, is define authorization APIs that we all follow and abide by. And there's really three authorization APIs you can think of. One is the binary yes, no authorization API.

Hey, can Alice view document one? You send that off and you get a yes or a no back, or true or false back. That's API number one. Number two is what we call the search API. We're currently specifying that within the working group. And that's where you can say, hey, I know I'm dealing with Alice. Which documents can she view? And you get a list of documents back, document identifiers back. And then the third API is the partial evaluation API, which is about, instead of getting the list of documents back, you're going to get constraints on the documents.

So instead of saying document one, two, three, you're going to get back, oh, documents that are in draft in this department, so on and so forth. And those in turn can be used to build data filtering, access reviews, and many different things. So the first implementer's draft came out in... My timer didn't start, so keep me honest on time. The first draft came out, implementer's draft came out in November. That included just the first API that I mentioned. We're working towards... We have a draft three that came out a couple of months ago in March that defined the search API.

And then we're working towards implementation of full standardization. I mean, sorry, in the summer or the fall. There's a few additional things that we're going to be doing around authorization, like a discovery API. So that if you talk to a PDP, you talk to Alex's PDP, you want to know what it does. The discovery API is going to tell you that. You talk to my PDP, it's going to tell you that, right? Not all PDPs have to implement all three authorization APIs. We're giving that flexibility.

We've also been doing, like Mike was mentioning, in terms of interops for shared signals, we're following the exact same model. We started doing interops last June at Identiverse. We did some at Authenticate and Gartner since. If you want to take part, please let us know. The latest one was in March in London. The next one is going to be in June at Identiverse. There we go. This is the basic demo that we put together for the first set of interops. If you want to illustrate authorization in multiple layers, think about it this way.

You have an app, a front end, that will consume data from the back end. In our demo, we use to-do items, right? And as you go down the layers in your app, you may want to trigger authorization. In this particular interop, what's interesting is that we're bringing authorization checks in the API layer. So think of an API gateway as an instance. That can act as what we call a PEP, an enforcement point calling out to the PDP. And that can be for functional authorization. It could be for medium-grain authorization, as was the case in the interop.

And then you can go deeper all the way in the app and have the app also act as a PEP and call out to PDP. So you can choose, right? That's part of the goal of Xen, is to give you that flexibility from an architectural standpoint. What that means is when we did the first round of interops, we had about 14, 15 different entities that took part in and proved compliance with the binary API. All of those logos you see here, we are all PDPs, policy decision points, which is nice, but you know, if you want this to grow further, then you actually want to bring in PEPs, policy enforcement points.

So this is where in the March interop in London, we invited API gateways. So the logos at the bottom are all API gateways, which is cool because now we're expanding the interoperability, right? So you have the likes of Broadcom Layer 7, Envoy, Kong, Tyke, WSO2, Zooplo, and many more. One thing I did include in the slide is that as we work towards more interops, we also want to work with IDPs now. An Okta and a Ping from the authentication side and a Microsoft and so on and so forth should be able to act as a policy enforcement point for authorization.

There's patterns that we're working on to make that happen. And with that, I'll hand it over to you. Thank you. So where do we go next?

As I said, we landed the first draft of the spec. We have the evaluation endpoint, the valuations for that kind of batch scenario. The subject search is now in draft. And then what's coming next up is the discovery mechanism. So you want to go and set up a PDP, integrate the application. How can you go and interrogate the PDP to find out which of the APIs it supports?

And then on the roadmap, we started to go for that partial valuation use case, which I think is pretty contentious and complicated, but really this end goal of there'll be one way of defining through the standard, how you get back that criteria, that filter that you can then apply down to a database query or subject access review and those kinds of things. Had a lot of discussion around how we go about putting profiles on top.

So the API gateway, for example, that's a standard structure that we could put a profile in place to have in the 1.0 spec to make sure that every API gateway passes the context, the principle, the resource, the actions, attributes to the PDP. Then going on to how we kind of work with the wider ecosystem. So event delivery, obviously shared signals is the profile we want to support early on and bring that in, and then start working towards IDPs as well. So how do you use a PDP to work out, for example, what claims go into a token? So there's the next steps.

The big next interrupt for us is Identiverse. This is a preview, I guess, of our interop application, really focusing on that search API example. So you can go in and interactively pick a PDP. We tell you basically what endpoints it supports and then various use cases around resource subject. Action search, that's hard to say. And answer those questions, like what resources can a particular principle get access to? Who can edit a particular resource? And what actions can a certain principle do on a particular resource? That's it. That's it.

Yeah, join the working group. Thank you.

All right, now we're gonna move on to those working groups that are really working on open data and open finance ecosystems and in creating and cultivating. Where's Dima? Dima? He was a little bit reticent to present, given that he doesn't have any FAPI swag today. So I wasn't sure if you were actually in the room anymore, if you'd stormed out. But Mark may be in the room. But Mark may be in the room. You can check out Mark's T-shirt. I am planning to use Mark if he's in the room. Not yet. What's over 60 here?

Yeah, John, let's do the first slide, Dima. Sorry? You want me to do the first slide?

No, no, no. All right, what's the first slide? I can do it. You do it. Okay. That's fine.

Yeah, that's fine. Can you hear me? Yes.

So, I'll be quick, given that we don't have too much time. FAPI is a security profile. It's OAuth2-based API security profile that's typically used by open banking, open data, open identity ecosystems, but also private API ecosystems that enterprises deploy. What differentiates FAPI from other profiles of other specifications is formal security profile. It's formal security analysis that's done by University of Stuttgart that guarantees that the protocol is secure.

We also have comprehensive conformance testing, like many other specs within OpenID Foundation that gives us assurance that implementations read the spec and implemented the spec correctly and implemented properly. So, these are the two main things.

So, FAPI has been deployed in the real world since 2018. And as I was doing an account for another presentation tomorrow, I think even the top four ecosystems give us about two and a half billion API calls a month, which is pretty impressive number. FAPI2 is the latest version of the protocol, the simplest and the easiest to implement.

So, it's the big news of this year. It's now final.

So, it's available to be deployed and it is recommended to be deployed. Message signing is another specification that is used to achieve non-repudiation in FAPI world. That's being worked on right now. The latest news from certification team, which I'm probably still in Joseph's thunder, FAPI2 final tests are also available.

So, people implement this can test it now. And FAPI2, while the spec is relatively new, we already have multiple ecosystem running live those specifications, which gives us great assurance that they're working. That's why we don't need any interrupt tests. I'll skip the comparison between the different versions of FAPI2, you will see it in the slide index. If you want to know more about FAPI real ecosystem, there is another presentation by Nat and myself tomorrow.

So, please come along and ask more questions. I think that's probably the main thing. I just want to add one kind of key message on the FDX side since coming from the financial data exchange event summit in DC about a week and a half ago. I think we're waiting for the final formal decision, but they're working towards having two profiles, what they call blue and green, and the blue version they're making FAPI2. It's currently machine to machine.

They're not launching the consent API challenges at the moment, but they are working towards having FAPI2 in that blue profile, which is a big step forward from what was recommended as FAPI to incorporating that as a formal core capability within their criteria. So, once it's gone through there, completed the governance process and it's looking good, then we're on track potentially to do an interop, not because we're worried about the standards, but just to give the US market players an opportunity that it's working and interoperable and it's a great milestone for the FDX community.

So, that's something we're exploring and we think will complement. Yeah, the financial data exchange is a industry-led consortium nonprofit that is enabling open banking in the US and they're seeking to deliver on the CFPB's regulation 1033, which is now in effect in law. Those of you who are following the US market know the CFPB has got its own challenges, but at this moment, the law is in effect and the financial data exchange is putting together the capabilities to deliver against that. And if anything, they might tweak 1033, but that doesn't mean they're likely to fully revoke it.

So, from the OpenID Foundation's perspective, the financial data exchange is one of many ecosystems that are adopting FAPI. We didn't have the data here, but I know Nat and Dima will talk about it tomorrow. There's around 14 or 15 ecosystems that have selected FAPI so far. Many of them are live in Australia with ConnectID that Dima's leading, as well as Saudi Arabia, the UAE, the UK was the first. Australia has selected it and we're looking to deepen that relationship with Australia.

So, we're very, very active in the support of that ecosystem and encourage you to hear more from Dima and Nat in their talk tomorrow. And these are national, sort of wide, national infrastructure type of ecosystems. There's another talk on Friday by Eric Dominguez from Radium that will, it's probably somewhere there, yep, that he'll tell us everything about his marathon, no, sorry, not marathon, the FAPI deployment in Brazil. Yes.

Yes, Open Finance Brazil. In case you're wondering what FAPI stands for, here's Mark in the middle of the room. He can turn around and tell you it's not standing anymore for financial API. It's not standing for financial grade API. It's just FAPI. Yeah. Because it's usable in healthcare, it's usable in telcos and so on. We couldn't get around that issue in the past.

Ecosystems community group, once again, briefly, a lot of experience, as we talk to a lot of ecosystems deploying FAPI, and it started off with FAPI, we recognize that it's one spec or one profile, one protocol is not enough for ecosystem to deploy it. You need multiple parts. Sometimes those parts sit in multiple working groups. Sometimes those parts conflict or contradict each other. So this ecosystem community group is designed to essentially capture the requirements, work with ecosystems, capture the requirements of those ecosystems to feed them back into the right working group to work on.

Pretty excited about it. So if anyone is building ecosystem or is in charge of the ecosystem governing body, let me know. Let's talk. That's it. Thank you. Thank you. Hello. I'm Mike Jones. Thank you for spending your time with us this morning. I'll be talking with you about the OpenID Connect working group and some of the developments that have been happening in there of late. Especially some OpenID Federation related developments. I was in Stockholm, Sweden last week with some of you doing a interop event for OpenID Federation. It was a great deal of fun.

We had 33 participants with 13 different implementations. We did eight different kinds of tests together that included testing the certification tests that are under development. And Gareth, one of our diligent staff members, was on site and gathered a lot of candidates of the collaboration in progress, both in the meeting rooms and over dinners, and has made some LinkedIn posts about that. There's another one to come recapping the results. So collaboration happening. Roland Hedberg on the left, thinking hard.

So there were 15 different organizations that were represented as part of the interop. Some of these you know. Some of these are startups. Some of these are infrastructure players. Some of them are government identity players or contractors to them. So a very diverse set. Many in Europe, some in far off lands like Australia. So a little bit about the status of the OpenID Federation spec itself. We've been working on this for a while. We keep getting feedback from deployers and implementers.

We received a ton of valuable feedback in Stockholm last week, both on the spec and on the certification tests that are underway. The result was we determined resolutions for a number of the open issues that had been previously discussed in the working group, which is great. And we're currently applying those proposed resolutions to the specification. The plan is for us to complete resolving the open issues. There'd been about 30. There's now less. And take it to review for final status within a few months.

Note also that some proposed extensions to Federation capabilities are now happening in other specs, just like OpenID Connect is actually a family of specs. OpenID Federation has become a family of specs. We expect the core spec to be done within a few months, but there's some others like an extended listing spec, a wallet spec and whatnot that'll continue development. And there's some more proposed.

It says, what else has been happening in the OpenID Connect working group? We did a security analysis of OpenID Federation at University of Stuttgart, and they're good. They found a problem that was actionable by attackers in real ecosystems. And the fun was, it wasn't just about OpenID Federation. It affects four OAuth specs, depending upon how you count. It affected FAPI2. It affected FAPI1. It affected CIBA Core. And so each of the affected working groups, both in the IETF and the OpenID Foundation, have diligently updated the specs to close the actionable vulnerability.

And there's a whole backstory where before any of this went public, we talked to deployers who we were aware of that might have been vulnerable and had them fix their deployments before we did anything public. And there's a blog post about this, which you can read some of what we did. We've developed certification tests. Those are underway. We've held the OpenID Federation interop last week, which was great. We'd done a few of them pre-COVID and got a lot of feedback, but we've had a lot of progress and deployments, including production deployments to 5 million real people in Italy since then.

We've adopted some new specs, some related to Federation. There's also an OpenID provider command spec. We have a spec out for review for implementers draft right now, the relying party metadata choices spec. So one bonus update for a working group that had been fairly dormant, but we're now in the process of finishing one of the pieces of work and then declaring victory. There's an enhanced authentication profile working group. It had been doing two work items, one related to token binding, which unfortunately met an untimely end, which is the long discussion of token binding.

It's a bit of a distraction to have over drinks, but there's one that defined some ACR values and an AMR value that are used particularly in conjunction with phishing-resistant authentication, such as WebAuthn or FIDO2 authenticators. And this actually goes back to work that predates OpenID Connect in some ways. There's a product called phishing-resistant authentication for OpenID too. There's also phishing-resistant hardware-backed authentication. That is in current OpenID Foundation wide review for final status.

There'll be a vote starting shortly, then we will declare victory on the working group and be done with it. Any questions about any of that?

All right, I, oh, Mark Hain. I don't. Next silly question.

Farf, according to Nat. All right, I'll be around. Talk to me. Thank you. Thank you.

All right, hey, everyone. I'm Joseph Heenan, our standard specialist and certification director. I'd like to talk about conformance and certification. So we've already covered a lot of this, so this will be just a quick summary of where we are with all the various conformance tests.

So FAPI, as was mentioned, we've got final two tests. They're in beta. If you have an implementation of FAPI2, you can do that. If you don't, you can do that. And then we've got a bunch of other tests that are in beta. If you have an implementation of FAPI2 final, please get in touch. I'll give you instructions on how to run the test because we do need some feedback before we actually put those into production and start issuing certifications. So we want to make sure they're right. And there's one or two tweaks we still want to make before they go into production as well.

As Mike mentioned, we've got federation tests. We've been featuring those at the interop. So we're continuing to work on them, take on the feedback we got from interop participants, and then continue to build out the testing because it's relatively basic, the testing we have at the moment. I believe there's more we can check. As Mark mentioned for EKYC, we've been aligning the tests with the final version of the specification and working with the working group to figure out what a certification actually looks like for the EKYC specs.

Again, if you've got implementations, do get in touch with me on that. If you've got implementations, do get in touch with me or Mark and we'll help you run the tests. Shared signals, again, already mentioned. Beta tests were used in the interops. And thank you very much for the kind words that were said about the shared signals test, Mike.

And yep, so again, we're continuing to work on those. We've got tests for transmitters at the moment, but not so much for receivers. So we'll build out some tests for receivers as well. And obviously as the tests move to final, we'll keep up to date and keep continuing to work with the working group.

And the OpenID for verifiable credentials specs, as I mentioned earlier, we've got tests for both the VP verifiable presentations and VCI verifiable credential issuance specifications for the latest implementers drafts, incorporating the security and interoperability layer in the Hype higher assurance interoperability protocol specification. Although there are a few cases where you can at least run the tests if you're not Hype compliant. And those tests do cover testing the digital credentials, browser API for wallets at least.

And again, we're continuing to build out those tests as more checks we can add. We're using them in the interop testing that will be done at the end of this month on VCI and then in June on VP.

And again, as the test moves to final, which is already starting to happen for VP over the next few weeks or so, be updating the test to match the final specifications or at least the ones that are undergoing review. And I think that's all my updates. Thank you. Thank you. Thank you. Thank you. Thank you.

Gail, you're welcome up here with me if you want to. Hi, I'm Elizabeth Garber. This is the last update we have. So we're making fantastic time. I will try and make up for the few minutes we're running over. I have a bunch of different hats that I wear. Some of you I saw at the IDPro talk this morning. I'm also the marketing and strategy director here at the OpenID Foundation. And I also support CIDI Hub, which stands for Sustainable Interoperable Digital Identity. It's one of the strategic initiatives that the OpenID Foundation engages in with a number of other nonprofits in the space.

So I am the secretariat and program manager for CIDI Hub. CIDI was established in order to solve the challenge of cross-border interoperability for digital identity. We engaged last year with more than 25 countries. We traveled the world. We had sessions in, well, our very first session was in Paris in 2023. And then last year we met at ID for Africa in Cape Town. We met prior to EIC last year here in Berlin. We met in Washington, DC, and finally in Tokyo. And we're continuing our work this year. But we've also engaged with a number of international organizations like UNDP.

We've had World Bank attendees at our events. I saw Adam sneak in a moment ago. We've had representation from the OECD, UNHCR, a number of academic partners, and, of course, more than 10 identity nonprofits have engaged. And in terms of our work stream, last year we ran four different work streams. Some of them were combined. We looked at champion use cases, and I'll show you which ones those were. Trust framework mapping, which was led by Nick Mothershaw, who's also in the back and can jump up if he is inspired to say anything.

And then the minimum technical requirements for interoperability, as well as governance and metrics of success. Those were combined.

Over 2024, we published the say in progress because it's a relatively old slide that I keep reusing. But these have all now been published. We have events, post-event reports from each one of our events that I just described to you. We have the use case reports, which covered the topics of displaced persons, in particular focusing on refugee registration. But we've also explored some others like disaster relief. We have a report on education and opening a bank account across borders.

And then finally, we have two different reports that were deep dives into particular, well, one of those a deep dive into a particular topic of governing global credential ecosystems. So that looks at governance across border. And our full end of year report, which has a summary of all the lessons we learned at each of those events in those work streams. And as we looked in depth at the topic of trust frameworks and governance.

This year, yeah, this year we are focused on building out our concept of a digital common. So one of the big lessons learned that we took was global interoperability for digital identity is not a really great question to be asking divorced from all of the other themes that countries are trying to grapple with. There are a number of different challenges of interoperability and a number of different challenges happening locally and you cannot tackle one without the other.

And so what we are trying to do is bring together to curate and build an open repository of tools for digital credential ecosystems and national jurisdictional frameworks. So that includes trust frameworks, rule books, legal and regulatory frameworks, human rights analysis, and then the more technical architectures and patterns for achieving global interoperability.

Oh, that's it, okay. Anything you'd like to add to that, Gail? I know that was a whistle stop tour, but I was trying to gain back some time. A couple of quick additions. Our next City Hub Summit is gonna be before ID for Africa again in Ethiopia. And that's been, exactly. And so we're looking forward to discussing the use cases and the findings to date since we last met with them in Kenya, but also exploring some of the kind of next phase of use cases. We've seen agentic AI rise up.

We have a white paper here on that topic, as well as the Olympics has been a theme where we thought for LA28, there's an opportunity. And I think some other identity stakeholders are thinking about how the Olympics or other major cross-border events could serve as a catalyst for adoption and driving the cross-border interoperability in practice. And so not only are we gonna have that event, but we also have the UN IGF where we've been invited to conduct a workshop and hold a booth at the 20th anniversary of the IGF at the end of June.

So we're looking forward to gathering additional feedback and partnering with an African nonprofit in conducting that workshop. And going through the rest of the year, we seek to take the OpenID Foundation Board's guidance, as well as the Secure Identity Alliance Board's guidance, which are two of the 10 plus nonprofits who are looking to see this mature into a formal public private governed entity and how we can do that most effectively and continue to align this work with the OECD, the UNDP and like other IGOs.

So we think we have gathered some really valuable insights, which Elizabeth just recapped, but now we wanna level that up and think about it in terms of institution building. So that's kind of what we're focused on at the moment and excited to see the work on standards progressing, convening at events like this, as well as the event in Geneva that Daniel Goldschneider is conducting, but really trying to push that global dialogue forward. So if you have any questions on City Hub and the roadmap ahead, or would like to engage, just let Elizabeth or I know.

With that, thank you. I think we've hit the end of the agenda.

Elizabeth, wrap us up. We have it. Wrap us up. So there's a lot happening at the foundation. So I'm Natsaki Murata, Chairman of the OpenID Foundation. And thank you very much for coming to this session, full room, standing room only. And we have a bunch of OpenID rated sessions sprinkled all over the program this week. So please find them. And if you're interested, join them in active conversation, because the best part of this kind of conference is to engage and converse. So that's it. Thank you very much for coming. Thank you. Thank you. Thank you. Thank you. Thank you.