OpenID Meetup

Welcome, welcome. Hello Berlin. Good to be here. It's been a year. Welcome to the OpenID Foundation session where we're going to do a tour de force for 90 minutes on some of the key themes at the OpenID Foundation and we're going to take a couple of deeper dives as we go through this 90 minutes. So we're going to have a deeper dive on the education use case and federation, deeper dive on AuthZen and the enterprise context which Ian Glazer is going to moderate for us.

We'll do a slightly longer session on verifiable credentials and we'll do a brief recap on some of the sessions that members of the community are going to be leading during the course of the week. So I'm going to share first a couple of key themes on, oh sorry, our usual antitrust statement as well as our note well statements that any contributions or comments you make are covered by our IPR agreement in this public forum and there we go.

All right, so a few headlines in the latest news. In the last six months or so quite a few of our specifications have made their way to final. So we are running on all cylinders across our workgroups. So you can see a couple of the headlines where specifications like OpenID Federation 1 and 1.1 that Mike Jones will talk about shortly. Both of those have gone to final. Authorization API 1.0 from our AuthZen workgroup has gone to final. We'll hear more about that shortly. Advanced syntax for the implementer's draft just was approved in the last day or two so congrats to that workgroup.

We won't have a deeper dive on that one today I don't think but big congrats to that group. And let's see, Hype 1.0 went to final at the end of last year so that feels like a long time ago already for those tracking the Wallace and Verifiable Credential work. But certainly all guns blazing on the digital credentials protocols work. You'll see for multiple of these families of specs that we have tests that are on their way to final very quickly.

So if you are an implementer of Federation or of FAPI or of Verifiable Credentials or of EKYC and IDA and the Identity Assurance specs, there are tests for all of them and we're really trying to make sure we get feedback from implementers on them so we can take them to final and publish them, make them available for self-certification. Across our community groups we also have a lot of great activity going on. Some of these are regional conversations and some of these are topic specific.

So Death in the Digital Estate, the final paper has come out to a great amount of media fanfare so credit to the marketing team, credit to the editors and the community group who's worked on Death in the Digital Estate. I don't think we'll talk about that much here today but I believe we're going to have a session on it during the course of the week. Dean will do a...

Great, they're going to do a session later. So we'll probably hit when that session is going to be shortly. Then for ecosystem support community group, there's a reference architecture for the open data, open banking, open finance topic. Happy to have Peru recently join that group and several of the African countries we met last week and Canada are just examples of some of the jurisdictions interested in taking part in that support group. Sounds like moral support group and maybe that's a bit of the case.

But a lot of the decision makers, lead architects, policy makers need a safe space to talk to their direct peers, how they've tackled the same problems and kind of navigating which specs to select, how to profile those specs, how to layer them together are kind of shared problems for those ecosystem leaders. And so this work group offers...

Sorry, community group offers a safe space to unpick what their requirements are. There's also a reference architecture for digital identity and by my count we have on the order of 48 to 50 countries moving towards wallets and verifiable credentials. So the trains are leaving the station and we want to support those jurisdictions with the design as they pull those programs together. For the Australian digital trust community group, if any of you are from Australia, this is a great forum for open ID foundation and related identity community members to convene.

So they're a new venture over the last year that they've pulled themselves into a community group and had a really successful hybrid event earlier this year. The open ID foundation Japan is a long standing chapter and partner. They are an independent entity but they do help amplify the work of the open ID foundation in Japan and the work there led by Nihiro Fujisan.

That community is really active and they're also working with the education federation that we'll talk a little bit more about during the course of the day as well as open ID for IDA, some important joint work with the government there. The AI community group, also very active in the last year since it was founded.

We have a couple of subgroups of that group on trust taxonomy and use cases and that group has also helped provide substantive feedback to NIST to inform NIST guidance on AI and how I think the way they describe it as some of what not to do in order to better protect your infrastructure.

We also have a live conversation going on with the board and as part of the session today we'll talk a little bit, actually sorry it's on Thursday, we'll talk about AI and the intersection of AI and identity and what the open ID foundation is thinking about and dwelling on and what we can do to substantively move the conversation and support it. Then on the city hub side there is a work item that we talked about in San Francisco.

It's underpinning an ITUT work item on how to do trust management across digital identity and specifically, well not just specifically, but inclusive of wallet and verifiable credentials. So how to do the trust management across borders. A really thorny topic. Also working on trust mapping and working on use case development.

So there are a handful of use cases that bubbled up out of the seven summits we had on four continents to address this topic of cross-border interoperability and the four that have bubbled up, four or five that bubbled up are opening a bank account, LA-28, emergency and disaster, education and age assurance. Those are all really, really hard I think as you can appreciate, but those are the five we're trying to focus on as being the potential drivers of the cross-border interoperability discussion.

Just a few headlines on the countries that we're working with and we're observing going through the life cycle for open banking and open data. The countries on the right-hand side, we've stood in this room and talked a lot about in the past.

So UK, open banking implementation, open finance Brazil, open insurance Brazil, UK for ConnectID as well as the data standards body, Norwegian health network, the Japan insurance implementation, which is a private sector implementation, Saudi Arabian Monetary Authority and the UAE government all have live implementations of open banking, open finance, open data. We have had FDX in the US select FAPI for their blue profile. Chile and Peru are going to market next year with their open finance implementations.

Singapore, we just heard in the last week, has selected FAPI and Colombia has also selected FAPI as part of their regulatory structure and they're working towards rolling it out. We're planning to meet with them probably in the September time frame. So really active particularly in Latin America is the next wave coming to market and we're really happy to have our ecosystem partners in Brazil to help support the continent as these ecosystems are planning making their plans.

We've also been working closely with the Canadian government over the last couple of years to help them with their due diligence. Their regulatory structure is basically in place to support open finance. They're currently selecting a standards body. One of the leading contenders is FDX. We've been working closely with FDX at the same time to try and support FDX in pulling together the proposals including how they might support conformance. So hopefully we'll see some real momentum from the Canadian market and they'll move rapidly through the selection and into the live category.

For digital identity and verifiable credentials, there's a huge party going on. I think many of you know this but maybe not all of the flags. There's a lot of new flags I had to discover when I was pulling this together. So in terms of what's live, it's still really nascent. So there's only a few markets that are live with verifiable credentials. We have California using our specifications and Switzerland has gone live with, I think it's still relatively narrow in the pilot, I'm not sure.

Some of you might know better than me whether it's gone wider scale into the public since the vote passed last year I believe. And then the UK had a pretty narrow pilot. Last I knew they were less than 100,000 people using it that were mostly like pensioners using verifiable credentials. And India launched the Aadhaar app. So on top of the Aadhaar stack, they've launched the Aadhaar app which is using verifiable credentials including our specs. So those ones are in the market already.

And then the party here includes all of Europe, of course, but it also includes a couple of other jurisdictions that are on their way. So Brazil, in the last few weeks we understand Brazil has selected a model similar to Europe and seeks to have interoperability with other jurisdictions. So we're engaging them going to be in Brazil next month. Joseph Heenan and Domingos from our team will head down there to support their due diligence. And let me see if I can pick out other flags. Not off the top of my head. Is it the Vatican? Not that I'm aware of. Shouldn't be.

But yeah, so there's at least the 27 member states. I know it's six of them that were less familiar to me were the Western Balkans. So all of them plan to follow the EU model and they've publicly stated that intent. That's a bit political, right?

You know, they have a political intent to follow the rest of Europe and to be aggressive with that plan. So to launch by the end of 2027 with a model similar to Europe. That ambition is being supported by the World Bank and the World Bank is seeking to kind of help them with their due diligence and due process. But we know this is hard, right? So it's going to be tricky for some of these jurisdictions. There are others. Having just come from ID for Africa last week, some of us are very jet lagged, Dima and Elizabeth and myself.

But in Africa, I spoke directly to the heads of digital identity of six jurisdictions, and they're all working already on wallets and verifiable credentials. So those included, and I'll try and go around the continent in my brain, Morocco, Nigeria, South Africa, Uganda, and Ethiopia. So those five, I know personally, plan to go down this path and are interested in collaboration and use of global standards.

Of course, taking a similar model, they call it the hybrid model, of having their existing centralized infrastructure, but then putting the wallet and verifiable credential solution on top of it. So they view that as complementary and that it could support not only some of their domestic use cases, like where they may have individuals that are not connected to Wi-Fi or to the net, they want to be able to have a verifiable credential that can work remotely without needing to be connected real time. So that serves some domestic use cases, including some refugee use cases or agriculture use cases.

But they also are interested in pan-African free movement of people, pan-African trade, and certainly cross-border trade with the rest of the world as well. So they are certainly being intentional when they think about what does good look like, and in this hybrid model, if they choose standards that could help support some of their wider and longer-term objectives. So I know those ones are moving, and I didn't have a chance to talk to Rwanda or Benin, but they are also leaders in digital identity on the continent, and they also are promising.

So when we collaborate with the World Bank, for example, we're trying to identify some of these leading countries and help support them, and then they, in turn, are in a solid position to help support their peers in other jurisdictions nearby. It's busy.

Okay, so we have, given all the movement on the ecosystems and across our work groups, we thought it was time to, in a way, finally have a larger scale event of our own. So the OpenID Foundation is going to have a three-day event in London next February. One of the key targets is to support these ecosystems, to invite them to convene with us, and to share best practices and reference architectures and requirements in a single room or a set of rooms in London.

We're also going to convene some of our working groups to have a few plenary-style sessions, as well as probably a few deeper dive sessions. So having that anchored in the calendar is already reaping dividends. So for those of you, you might be interested in taking part in that one as well.

Okay, if you want an even deeper dive, then we have time to cover today. The marketing team pulled together a year-in-review from last year, which is a tour de force of our work groups, the interop events we did last year, and a lot of the kind of key themes of the Foundation. So that is on our website under the news section.

All right, I hope I'm doing okay on time, Elizabeth, as I pass over to Mr. Jones. Thank you.

Thank you, Gail. So welcome to Berlin with the rest of us. I'm Mike Jones. I am one of the chairs of the OpenID Connect working group, among other things. And where is the clicker?

Well, you could just do it for me, Gail. So it's been a busy time and a good time. One of the first things that's happened is we got a new co-chair who is a European. And Frederick became co-chair last month with us, which is great. He's been very active and can run working group meetings when some of the rest of us can't, which is great. As Gail said, we finished some specs, which I'll go over. We had an OpenID Federation interop event at the time on conference, which Niels helped create, along with Davide Fugetti of GAR, which was great.

We began security analysis for OpenID Federation, which I'll talk about. We've adopted some more specs, so we're firing on all cylinders. So OpenID Federation was a long journey. You all know that if you've paid attention to the space. But we did finish that in February. It took a while because we kept getting feedback from implementers and deployers, including some of the production deployments in Italy and Sweden and what have you, the Netherlands, about, well, these are the parts that work for us. These are the parts that don't. This is what's missing. And so that's all a positive cycle.

It does take a while sometimes. There's also conformance tests, which Joseph's certification team has helped create. Those are not done. There's a set of tests for some things, but that's work that's current.

Now, there started to be about a year and a half before we were done a clamor to say, well, you know, the Federation spec does two things. It defines protocol independent trust establishment functionality, and it has a profile for how to use it with OpenID Connect. Can't those be two different specs?

Well, they can, but we decided at the interop last year at SUNET not to do that until we got 1.0 out the door. As soon as 1.0 was in final review, I started the surgery to split them. The split is exactly equivalent to 1.0 by design. There are a bunch of Federation extensions in process. Part of how we managed to finish 1.0 was to not include all the new proposals of things that could be done as non-breaking extensions. So I won't go into what these are. Some of them, like the wallet profile, are also in production use.

There's a profile in production use in Australia, in open banking, et cetera. But that work is now a focus of the working group. We did a security analysis of OpenID Federation a year and a half ago, and for those of you who were watching, the clever boffins in Stuttgart, as the Brits say, found a security vulnerability that was real, not just in Federation, but in OAuth and OpenID Connect and a bunch of stuff. So we're fixing those. I'll talk about that next week at the OAuth security workshop. But they're doing it again, and there's a new model out. I'll put these slides on my blog.

They'll go on the OpenID site. So do look at the model, particularly those of you who do security analysis. Please look at the model they created that's being used for the security analysis. And with that, I will turn the devices over to Niels. Yes. Thank you very much. Good morning, everybody. Welcome. My name is Niels van Dijk. I work for CERF. That's the Dutch National Research and Educational Network. First of all, I'd like to thank the OpenID Foundation for having me and for the many years of really great collaboration that we've had.

I'm going to talk a little bit about the EduGain use case. It was already touched upon a little bit by Mike as well. Give you a bit of behind-the-scenes information on the why and what are we doing. It is about OpenID Federation, no surprise. And I will actually not be going into OpenID Federation itself. I suspect that by now you should have read all the 180 pages. EduGain is an inter-federation service that is being operated out of GEANT. GEANT is the pan-European collaboration of all national research and educational networks in Europe.

And this inter-federation service actually binds together all the national identity federations that not only all of the countries in Europe have, but actually many, many countries globally have in research and education. And the whole purpose of all of these federations is actually to allow users, students, researchers, staff to log into services, to log into resources, to log into compute, storage, and all of that using their home accounts, using their institutional home accounts, so that you don't have to pass passwords around and stuff like that.

And actually, this EduGain thing is quite big. It's covering 48 federations globally. All of the orange things are formal members. The bluish ones are candidate members. We have over 10,000 entities in there, which comprises of about 6,000 identity providers, which are institutions, research institutions. Some of them are academic hospitals and stuff like that. And almost 4,000 service providers, which is there's a huge variety. These are the Amazons and the Microsofts of this world, but it's also very, very small.

A single database somewhere at the university in Germany on 17th century literature or something like that. It's a very, very diverse set of service providers that we have. And the whole purpose here, of course, is to allow folks to actually from the Netherlands log into services in the U.S., from the U.S. log into services in Japan, vice versa, and be able to share these resources in a secure, trustworthy way. And this actually works really well. The EduGain service has now been operational for more than 10 years.

It's widely used for all kinds of things, specifically in scenarios where we have to go cross-border and cross-sector. So here on your right, the most common scenario is actually when institutions want to use services that are sort of hosted somewhere else, cloud or whatnot, typically campus services. So they use it to connect their HR systems and their email platforms and their learning management systems and all of that. In this case, an example of Elsevier, the large publishers are all connected in this way to the institutions. And that's just sort of providing resources for folks to work.

The other scenarios, the one up top is the Erasmus project, which is a poster child for – Erasmus is actually an EU-funded project which supports student mobility across Europe. And students actually can, as part of their education, go to another institution in another country, get some funding for that. And we use the EduGain infrastructure to facilitate the authentication and the authorization processes that go with that.

And also to allow, for example, that when the student returns from the foreign institution, to return to their home institution, that the information of the grades and stuff like that actually gets transported as well. The other scenario in LIGO is just one example. LIGO are these really crazy guys that use lasers to detect gravitational waves and detect black hole collisions and all of that. They can actually do that. They won them a Nobel Prize a few years ago. But in the research domain, we have many very large and very small research collaborations across institutions, across borders.

And all of them need to work together, share their resources, and very often these resources are actually super expensive, like the Large Hedron Collider in Geneva, operated by CERN. Or they deal with sensitive data.

Like, for example, we have many collaborations in the healthcare sector, where you deal with sensitive data, with personal data, gnomics, and stuff like that. So identity and access is really critical to all of these collaborations. So it's obvious that we need, as a sector, we need a global trust infrastructure that can span country borders, can span sector borders, and preferably also can span protocol borders.

We have this edu-gain thing, but we're actually, we have actually commonly asked, as NRENs decided two years ago, that we're going to move away from what we're currently doing, which is use SAML 2. Why?

Well, SAML is, I was going to say dead, but of course it's resting. There are some challenges with SAML in its governance, and also for some of the things that we actually want to do in terms of our trust frameworks, SAML is not the optimal protocol anymore, I'm afraid.

However, the new kid on the block, OpenID Federation, as Mike already very, very nicely pointed out, what's really cool about OpenID Federation is that it has a layer that explains trust and that lets you describe the trust, and it has a layer that helps you to define how you can use that trust in specific protocols. But this separation is actually really crucial for us because it allows us to have multiple protocols in one trust ecosystem, and this is exactly what we're going to do.

We want to implement OAuth, OpenID Connect, but also we're working on, of course, we're working on wallets, and from our point of view, it makes no sense to have multiple trust frameworks just because you're running another protocol. We want one trust frame. An academic institution that tells me that I'm a student doesn't change because I'm using a different protocol to transmit that information. That makes no sense. It actually will only complicate things if you start doing that.

So, we want one protocol, one holistic approach to our trust infrastructure. And finally, and this is another really nice feature, OpenID Federation can be used in real time and is, in essence, a dynamic protocol. And this means that it will allow us to be scalable and secure at the same time. Our SAML ecosystem actually is using SAML metadata, which is, in essence, our lists of stuff. And over the course of 20 years that we've been running that, we found that it scales really poorly. We're struggling with these 10k entities that we have.

Well, it could be our incompetence. I would not be surprised that that is a problem, but it might be that some other issues exist there as well.

And we, for example, struggled with stuff like, okay, we want to decommission this service or this identity provider because we found that it is actually being abused. Can we turn it off?

Yes, you can, but it will then take three days before the whole of the network has actually learned about that event because of all the lists needing to be updated in all various places. So, these were some of the challenges that we were struggling with. As a consequence, we can't actually roll out OpenID Federation just like that because this is because. These are the identity federations that are currently participating in the pilot. Many of them are from Europe, as you can see, but we also have, for example, the UK, which is sort of Europe. And we have, no comment there.

And we have Australia. And if you look at the Eurovision, that's also sort of Europe. But anyway, looking at this table, there's a few things you could take away. First of all, most of the major countries of Europe are actually participating already in this pilot.

So, we're covering an enormous amount of users. And also, I took a list of the resources I could find on how many potential users are actually in these federations. And you can see it's several millions that we're touching here.

Also, most of these federations are already operational in between 10 and 20 years. And that means that we have an established infrastructure and established capability that we can't just sort of overnight replace.

So, we have to have a strategy where we can easily, or as easily as possible, introduce OpenID Federation into this ecosystem, start using it, and start migrating ultimately away from the SAML infrastructure without completely breaking down our existing trust infrastructure. We have started with the actual pilots. This is a tool created by Giuseppe De Marco. You may know him from Italy. And by the way, this is also one of the really cool features of OpenID Federation. You can actually inspect your trust relations without actually having to perform a transaction.

In the SAML world, that's impossible because you only learn about the trust once you actually do a transaction. But in OpenID Federation, you can actually explore all of the relations in the trust network through, well, just by looking at its entity configuration, by looking at the metadata that's being published.

And so, here on your left-hand side, you see the EduGain as the so-called trust anchor. So, that's the highest level in our trust infrastructure, and all of the national federations as members of that.

And then here, a more zoomed-in view where you can actually see that all of these member federations then have so-called LEAFs, which are identity provider, or OPs, or verifiers, or RPs, where you can, for example, see here up on top in the Netherlands, we've also introduced not just normal vanilla OPs and RPs, but we're also starting to introduce issuers and verifiers from the wallet ecosystem already. Now, that works really very well and very nice. I touched upon wallets already a little bit.

No, sorry, one back. What we're currently doing is, we've basically established also, for example, during a number of interop events that we had, for example, at the Time Conference, that actually on a technical level, this just works. We know it's not a problem anymore. We've used some of the software and the libraries and the tools that have been listed on the OpenID Foundation's website for this. We've written and contributed some software ourselves to implement this. That is not a problem.

The next problem is, of course, that we have an existing federation policy with Educate, which lays out all of the rules that we have for how federations can join, what kind of security and policy you have to live up to. The thing that we're now doing is, we're writing, based on the fact that we now have a place that we can technically test, we're now writing down an OpenID Federation version of the Educate policy, so that we can actually lay out the rules that we have in the SAML world. We can't actually translate all of them, literally, because there are some differences in the technology.

Also, having said that, in some cases, we actually want to take advantage of some of the new capabilities that OpenID Federation offers over the SAML world. We're now trying to make that translation, and being a global community, we will have to do that in consensus with the global community, which is, of course, as always, I don't have to tell the OpenID Foundation how such a process works. We're actually progressing very nicely, I think. We've been at it for almost a year now.

We're testing various topologies, various scenarios, and that is turning out to, well, it starts to look nice, let's put it that way. Last slide. I already touched upon the fact that we're also, as education and research in education, very interested, of course, in the use of wallet technology.

Actually, we feel that by combining a number of the specs coming out of this community, the VCI spec and the VP spec, and also OpenID Federation, we can actually make something work for our sector. In the Netherlands, I've been working on a project called AdaWallet.

Actually, there's going to be a presentation by two of my colleagues, it says here Tuesday, but that should actually be Thursday, the 21st, where we showcase what we have done. We're currently in the process where we're actually piloting with end users, with real institutions, some of the use cases that they've provided to us using wallet technology. That wallet technology is also including OpenID Federation as its trust infrastructure. The second thing I want to point you to is you're probably familiar with HYPE, the High Assurance Interop Profile.

We, together with some others, have been working on a parallel spec, well, not so much parallel, but complementary spec, I would say, called Deep Decentralized Identity Interop Profile, which is a more lightweight approach to some of the things that HYPE is doing. We have a number of use cases where we, for example, do not need high assurance, and we want to be able to do that in a more lightweight fashion. We're also very closely collaborating with Wallet Architectures Group in the OpenID Federation space, because Deep actually has chosen to use OpenID Federation as its core trust layer.

Actually, we're in the process of moving this specification to the OpenWallet Foundation. We have started talks, and I think there's general agreement that that's going to happen. So that's it for me.

Niels, can you just comment briefly on the roadmap, what you would hope for, maybe because the whole group hasn't decided, when you would hope to roll out Federation, like the first of the ecosystem within Edugain, when you'd start to see them rolling out and adopting and going live in production? Yeah.

So, actually, in all honesty, I wouldn't be amazed if we would do that first for our Wallet ecosystems, because there we have nothing, basically, and it's also more greenfield. So that makes it easier for us to actually roll out stuff. We have to, of course, make sure that we stay compatible with the existing ecosystem. One of the things that we're currently looking into is sort of trying to bridge between the SAML world and the OpenID Federation world. There was this initial folly that we thought, well, maybe we should just do a SAML profile for OpenID Federation.

And then we had a very long talk with Roland Hedberg, and he frowned upon us and said, well, guys, are you sure? So I'm hoping that in the next year, we will see the first OpenID Federation infrastructures for Wallets emerge. And by the end of next year, we will probably also see the first emergence of, well, migratory, let's call it that way, infrastructure in parallel to the SAML world. Yes. Thank you very much. I'll take the clicker, because I think I'm looking for Elizabeth. I think we need to stay on time.

But thank you very much for that review, Niels, and tremendous work by the community on rolling out Federation and thinking about Wallets. Okay.

Altsen, over to Alex and David. I love the idea. I love the idea there's a token flying around that lets me fire a laser. So cool. Go. So Altsen. As mentioned at the start, we've kind of speed run this process, and we now have the 1.0 out. But just as a recap, the idea of Altsen coming up with the standard for how an enforcement point and a decision point talk to each other. So the idea of authentication, when I say solved, in this room is probably a bit of a reach.

Yeah, going to get booed. But authorization, so how ultimately we can connect different enforcement points, be it gateways, apps, we're now in the world of agents, obviously, can talk to each other and then get a standard decision back from a decision point to determine whether some action given some identity on some subject on some resource is allowed or denied. Which is what I just said. So at the core, we kind of speed run this process over the last two, three years now, when we started it. And we've got the core version now out, went live in January.

And the important thing to call out, and I think there's a pattern now emerging, is we did all these interrupts over the last couple of years. We did some here, we did some at Enderverse, Authenticate, Gartner as well has been very helpful on this. And the final version went out in January this year, and we're now at the point where we actually have actual real adoption happening with vendors and implementers as well. Do you want to cover? Sure. What's in it? All right. So from a specs standpoint, the first thing that it contains is a standardized way to ask the question, can I do this?

Can I get access to this record? Can I get access to this bill, this particular piece of information? And we in the All of Zen group, we don't care who the I is, like the identity piece is something that the rest of the working groups under OpenID care about. We are decoupled from that. So whether you're a human or an AI or workload or whatever it may be, we don't care. All of Zen works equally well.

But then you'll quickly realize that in the day and age of a lot of data, asking, can I get access to this particular piece of information doesn't scale if you want to get access to an unknown number of records or a large number of records. So we tacked on a batch API, which as you can imagine, does batch call. So can I view, edit, delete item one, two, three, four, five, so on and so forth. You can batch any dimension of the API. So you can, you could batch users, you could batch resources. So it could be, can Alex and David view item one, so on and so forth, you could choose.

But going further, if there's really a very, very large amount of information or just an unknown amount of information, you can't really ask the fully fledged question, can I view item one? Because you don't know what it is you want to view. The question is more like, oh, tell me which records I can view, which is why we have the search API. And on the roadmap, we'll get back to that later.

We have something called partial evaluation, which is a way to get, instead of getting, in the search API, you get the list of items back with a list of users back in the future work, you'll get a predicates on those things. So in the case of items, you'd be getting a filter expression, pretty much. And then the last thing in the current spec as it stands is the discovery API. We took a page from the OpenID spec to implement a very simple JSON endpoint where you can read what features the PDPs support.

Because we also accepted that different implementations on the server side could actually support some of those APIs, but not all of those APIs. Alex and I, Alex, if I'm not mistaken, you and I do not do the search API, for instance. Some other products, graph-based products, as an example, they typically do search very well, but they wouldn't do partial evaluation. So this is the wall of fame of all the different implementations that have happened over time.

You might notice that there's a category of logos that's missing here, and that's the non-identity, the non-authorization vendors or platforms or frameworks, if you will. It is great that we got 15 plus PDPs, Alex and I, included here, both commercial and open source. Awesome. It is great that we got identity providers involved as well. So an identity provider in the process of issuing a token could actually call out to your policy decision point over all the Xen to have that standardized integration, which now means you can mix and match any IDP with any authorization service. Awesome.

It is also great that you have API gateways, and in the future, AI gateways, right? You know, API, AI, it's just one letter away, really. And that's all awesome. But I think for us, and again, this is roadmap stuff, for us, we want to go to COTS, we want to go to SAS, we want to go to dev frameworks, because at the end of the day, authorization is going to be successful when the likes of Workday and Salesforce and SAP and you name it actually truly externalize authorization to an off-the-send PDP. So what's next?

So now the spec is 1.0, we are now paying through the certification stuff, so working with Joseph and the team, and we created a profile or certification scenario at least earlier this year, which basically outloads the different kind of test scenarios you want across those different interfaces, and that I believe is already in the staging environment of the OpenID certification suite, which is great, as of last week, week before.

We've got a bit of work to do still to determine how we differentiate kind of the different levels of compliance, so, you know, we don't make someone that doesn't support Search API look bad. But a few more things to sort of dot the i's and cross the t's there, and then we can ship that out and get moving on that. And then for future state stuff, what very quickly kind of landed on our plate after we landed this first version is this idea of profiles, and do we come up with a profile for HTTP, do we come up with a profile for MCP, do we come up with a profile for XYZ scenario?

And so the next, there's two kind of tracks of work going on right now beyond partial evaluation that we're starting to look at, which is how do we start building these profiles for essentially mapping the information model of some source, say an HTTP request or an MCP message, into an off-the-send standard evaluation check?

And we've been kind of iterating a few versions, so a tool started this off originally to start defining this kind of mapping layer, this logic layer, as a way of defining ultimately as metadata in some source information model, how we can convert that systematically and sort of mechanically over to an off-the-send request, the idea being you should be able to go and pick up a profile of off-the-send for your particular use case, say you're a gateway vendor, an IVVP issuer, or an MCP server, and to find that over into the off-the-send information model.

So we somewhat opportunistically went after the MCP use case first as a kind of actual implementation of what this might look like, and the idea ultimately is through kind of the request flow, there'll be a point where either the AI gateway or an MCP gateway, I feel like the names of this stuff has changed since we put these slides together for IIW like three weeks ago, this stuff moves so fast, but ultimately this mapping logic, this metadata layer, which you can kind of define along with your source system that basically just explains programmatically how you'd take some inbound requests, convert it to an off-the-send request in a standard format, get the off-the-send response back, and provide it back upstream to whatever enforcement point that may be.

Even this has changed in the last couple of weeks, this format, but on the whole the idea being pluck some value from some source information model, apply it to the off-the-send information model, get the response back, and flow it that way.

And the other one that we're starting while we're discussing, it came up in the work group last week, is around a use case that's come from Colin McGuinness and the work going on over on that side of the house for agents, agent security, around how we have a profile of things like access requests on either human or agent identity, and how that maps into the context type model we have inside of the off-send. So that's quite early on, but things kind of are progressing.

Oh, and now we get to rehearse flags? Why is the French flag on this side? I don't get that.

Anyway, we already spoke a little bit about the roadmap, but partial evaluation is one of the big items we wanted to get done in the 1.0 spec, and then we realized it was tricky, so we pushed it out to 1.1, or maybe 2.0, we'll see. But it's going to be one of the main focuses for 2026.

Equally, an API gateway profile, it's interesting to point out that there's a lot of profiles that we can write. MCP, obviously, is one of the most important ones given what's happening in the industry today. But we also kind of want to separate between, say, plumbing profiles, technical profiles on the one hand, MCP falls in that category, API, IDP, they fall in that category. And then you have, I'm going to call them business profiles, for lack of a better word, but it's going out to the business vertical.

So the healthcare community, the finance community, FAPI, Gail, you mentioned earlier, would be one, HL7 in the world of healthcare, and other places where they may or may not be aware of what we're doing at OpenID in terms of authorization, right? And it's on us to tell them, hey, don't reinvent the wheel of authorization, we're here actually to help you do a plug and play. And then another interesting one, speaking of cross-pollination, is integrating with shared signals. Shared signals has some interesting ideas about how you can convey authorization events and security events.

What if a PDP could actually trigger those events, you know, decisions? And what does that mean in terms of an off-the-zen PDP interaction? Can off-the-zen play a part with shared signals? So that's something we're investigating.

Atul, who's the chair for shared signals, is also a chair for off-the-zen, so we're focusing on that. Yeah, and we do have an option, both the sideways French, or the Dutch, I suppose.

Oh, and you're Dutch, right? Yeah, and the Germans.

Yeah, so there's now a, the Dutch government now has a profile for off-the-zen, which Mikkel's leading, and then Roman's doing some great stuff from the German perspective as well. Yeah, and we've got a few more bits around tooling, but that's kind of where we are. Thank you. Thank you.

Okay, it's panel time. Ian, our moderator to the stars. Okay. Mr. Kaiser with hat. Right. You know it's the enterprise panel because everyone is wearing a jacket.

I also, for those of you in back, will assure you that there are three panelists sitting here. This is not some sort of deranged sort of ventriloquism act. Oh my gosh, I got the stuff.

Yes, let's go. Where is the clicker? Who has the clicker? Who has it? Gail? You really love the clicker today. I do. I do. It's a power thing. It's fine. It's fine.

Oh, you did. Okay, Elizabeth, now I understand what your text meant to me. So I want to take a little bit of time, and I'll ask Gail or Elizabeth or someone to keep us honest in terms of time, to talk about standards work, not from the perspective of forwarding the standard, but about applicability. So we've got representatives who I'll ask to introduce themselves really quickly in a moment to talk about, okay, if I am a business, if I am a government institution, if I am an institution of higher learning, why should I care about these standards? And how are they applicable?

And where are they in their journey relative to me and my use cases? And so with that, let's do a lightning round of intros, starting with Mr.

Kaiser, because you're the newbie on the panel. Like usual. I'm Mike Kaiser. I do strategy and standards at SailPoint. I am co-chair, along with Atul and Sean of Shared Signals. I'm Alex Livier, co-founder of CERBOS, the authorization management platform, and one of the co-chairs of AuthZen. David Roussard, CTO at Axiomatics, and one of the co-chairs of the OpenID AuthZen working group. I'm outnumbered. Always.

And I'm, just for context, I'm Ian Glazer. I am director of continuous identity product strategy at CrowdStrike, was SGNL. You can look at me and pretend that I am Atul Tushibagwale for the purposes of this panel. You do look similar. You have no idea how often I do that.

So, my first question to the panel is, what is your value prop for an organization? There's a lot of really good work that has gone into specs that have helped these things forward, these sort of causes forward, but it's not always clear from a specification document why I, as an organization, should care.

So, let's go reverse order. David, you're going to represent AuthZen, unless you want to represent Zakumal. You get to pick. Or Samul. What do you want to pick? Something alive.

Okay, yes. So, from an organization's perspective, why care about AuthZen?

Like, what's that core value prop? What's the value there? And maybe talk a little bit about the outcomes that an organization might derive if they were to deploy AuthZen. I actually don't think it's AuthZen specific. I think it's, generally speaking, why use a standard? It gives you independence. You're not bound to any particular vendor, any particular framework, any particular way of thinking.

So, it's future-proof. I know it sounds kind of wishy-washy, but point number one. Point number two, you might have a better sense of security or better security out of using standards because, hopefully, they've been proof-tested and they've been stress-tested and attacked maybe even.

So, if there is a vulnerability that happens on a standard, people will fix it as opposed to some opaque thing that your team has developed and you don't really know what vulnerability there might be. And the analogy would be in crypto, would you invent your own crypto algorithm or would you pick a standard crypto algorithm?

So, it's not AuthZen specific, right? And if you wanted a value prop for AuthZen, there's many. One of them that I keep hearing lately is if you use a standards-based authorization solution, open source framework, whatever, it doesn't have to be vendor, then you're saving your developers time. They don't have to do that work themselves. Much like if you're developing an app, you're not going to go develop the database layer or the authentication layer.

Hopefully, no one's implementing username and password these days, on their own, that is, or even as a mechanism for authentication. They're using reusable libraries, right?

So, it's a time-to-market thing. So, following on that, I just want to add a little bit. One of the use cases I've certainly seen around AuthZen has been large organizations who've said, I want to build essentially common services for my developers so they don't have to know identity, right? Because if we're being honest, the developer persona is one that we as identity practitioners have not done a great job building relationships with, right? We have made developers know too much about identity in many cases, right?

And this is one of the things that Vittorio was so good about, was to talk to a developer persona and say, this is why you don't have to worry too much about it. This is how OAuth will help what you do. This is how you do it. I think about AuthZen as an organization saying, I don't want my developers to be identity experts.

In fact, I want them to stay as far away from things like identity, things like cryptography as possible. But I do want to have some assurance that in the future, if I want to swap out components in my infrastructure, that I have a way to do that.

And so, the way I've seen AuthZen sort of been positioned inside an organization is, it's an insulation layer that allows me to change what is behind it. So, that may be my API gateway, that may mean my authorization provider, that may even mean my IDP in the future. And I'm okay because my developers have just coded to this facade, which is essentially just AuthZen itself. And I think that's a very powerful thing for large organizations to be able to do.

Mike, you want to represent shared signals? Sure. Shared signals, when I try and boil it all the way down, is kind of reducing risk to the organization.

So, this is a risk demigloss? Something like that.

So, reminder, shared signals, what it does is an event-based approach to sharing identity context between systems, right? The reason I say it reduces risk is that, think about all the authorization decisions and the choices you make about access inside your organization that is based off some set of data that is some measure old, right? Shared signals tries to keep all of that up to date and as near as real time as possible.

So, when those choices are made, you're making the right choice with the right data. The easiest analogy I can give is in terms of a half marathon. Anybody runners in here? I know Dima is in the back. One of my fastest half marathons was in Stockholm, of all places. I don't live in Stockholm. Some of us do. I don't know Stockholm, which means I had two ways to run my race. Either run blindly and look for clocks on the race course, at which point I can make discrete decisions every five, six kilometers. Or I can wear a sports watch, right? I wasn't wearing this.

It was a Garmin, neither here nor there. What that meant was I was constantly getting signals the entire time. A steady stream, I could look at my watch and say, I'm going too fast, I'm going too slow. Without that update of information that's constant between my decision points is nothing but risk for my strategy. And the same thing is true for your business, right? If your data is stale, then things don't work. It's great. But it's not going to be great if that data is old.

Knowing about threat, knowing about risk, knowing about just about anything, even skim events, which just became an RFC last week, you can keep things in close to real time as possible, thus reducing risk for your business. And that stands in stark contrast to sort of the modality that we've been working in for a very long time, especially those of us like myself, Mike, to some extent, who've grown up in a user provisioning world where the events that trigger actions tend to be few and far between, right?

Join, move, leave, log in, log out, but no one actually logs out. Log out is a lie. And so if you only have four events, four kinds of events to affect an identity control, that is just out of pace with the modern enterprise. And I think Shared Signals allows us to change that pretty radically. So there's a third spec that we want to talk about in this panel, which helps us maybe bind it all together. Who wants to speak to IPSE? Alex?

Sure, why not? I have nothing to do with IPSE, but I'll give it a go. So the way I kind of look at this is, you know, I have a lot of conversation with companies and businesses and governments who are, you know, on board with getting to that standards-based approach. And I think the rhetoric over the last couple of years has been very much that it's like shift left, that's going to make this problem, make authorization, make security kind of problem further upstream.

To your point, Ian, I think that model now is moving down to like a shift down and make it a shared responsibility, make it a common layer. Phil Venerables, if anyone follows him, talks a lot about this, former Google CISO, around like this should be a shared functionality. And when you move that shared model, the important thing is to make sure that shared model, that common layer that handles these things, is built to a certain stack, built to a certain standard, make sure it aligns with kind of the best practices.

And, you know, having some interaction with the IPSE working group from an authoring perspective, like coming up with what is that different levels of readiness across the different standards. So we have like a BIDC over here, we've also over here, we've got some shared signal stuff happening over here, you know, to be a production grade, you know, system that implements these standards to a suitable, secure, defensible level.

IPSE, I think, is that nice layer that comes in, sits on top and possibly profiles all these other standards to move them to a model that you can kind of rubber stamp as like, yes, this is a good way of architecting your system and gets that common layer that sits underpins all your other systems to a standard that is, you know, good to go and something you can stand by. I think the, from an enterprise perspective, one of the ways I think about IPSE is, so prior to my current role, I ran identity at Salesforce for an awfully long time and then made David do it and he quit first, he broke.

But if you have a, if you have a SaaS administrator sitting in front of their console, they are inherently not an identity practitioner and they finally click over and set up and they get to, say, the single sign-on configuration and it is just a wall of gibberish to them, right? They really don't know, nor should they, what they're supposed to click, right? What they're supposed to configure, why they're supposed to do these things.

To me, IPSE provides a very good way of simplifying for safety the experience for that practitioner and that's really important because as identity practitioners, we depend on the kindness of strangers. We depend on the SaaS administrator and the infrastructure DevOps folks and all these other people to do the right things that we strongly suggest they do. We don't always give them the tooling to do that and in some cases, we shouldn't give them the tooling to do that. We should just make it stupid easy for them to do it and IPSE is, in my hope, as it gets fully expressed, the way to do that.

So, let's see, where are we in this journey? So, we saw a little bit about AuthZen's roadmap. I want to come back to that in a second, but let's talk about shared signals, a little bit of the slightly older brother to AuthZen.

Mike, you want to talk about where we are in the formalization, specification, certification journey for SSF? Yeah, we've actually, I feel like we've made a lot of progress in like the last year and a half, two years. We went from a spec to multiple interops at which we had upwards of, I don't have a slide in front of me with logos, but like 15 to 20 various participants, all making sure it worked, finding where the issues were and resolving them. We went final on three specs last September. The first is a shared signals framework, and that is just the plumbing, right?

This is, sets up all the, how you actually do this stuff, right? And then there are two more specs. The main one is CAPE, which is session-based kind of events and risk on top of that. And those two, especially CAPE, went final also.

And so, that basically establishes how that's going to work for at least the near future, right? Certification-wise, we are hunting down both receiver and transmitter certifications. We're making good progress on that. I think receiver conformance tests and certification tests will be out soon. Transmitter will follow that. And we're continuing to see interest and adoption. I get a lot of questions when I come to EIC or other conferences saying, you know, how do I get involved? How does this work?

And it's really easy to point people to some open source implementations, Keycloak does it, for instance, and then your local friendly vendor probably does it as well. If not, harass them or tell me and I will harass them and we will make it happen.

So, shared signals especially, thank you, Mike, for that, is crucially important for certification and then the adoption side of it. Because how many people work in an office that still has a fax machine? Raise your hand. No one's going to admit. One.

Good, good. So, you two should know each other because if you only have one fax machine, life is really sad and boring, right? Because you just stare at this thing like, do something, right?

So, you need, everyone needs a phone. The way I think about the journey for shared signals right now is we're in the phase where everybody needs a telephone. Once we have a telephony network and that's what shared signals sort of enables for identity, we can do some really amazing things.

So, that certification step is a really big step forward to saying not only can multiple people have a fax machine, but actually they can work with each other and that's a big, big deal. David, why don't we unpack a little bit more on, unless you want to hand this off to Alex, meaning that you would have to answer the ipsy question.

So, you have a choice. We saw a little bit in the prior slides that you showed sort of about the journey. Maybe add a little bit more color to that. There's been six, seven interrupts. Maybe share a learning or two from those.

And yeah, I said learning, you know, it's one of my hateful words. Something that the group has learned from those experiences and then, you know, what does that roadmap look like towards maybe a March short certification even? I think the biggest learning point is that authorization is a two-sided equation in my mind.

Alex, jump in if you disagree or agree. There's the identity slash authorization side that Alex and I represent and then there's the application side or the data side or the resource side, right? So far in the working group, we've largely only seen the identity slash authorization side and to a lesser degree, the API gateway representing the resource to some extent, right? And we'll get the MCP AI folks on more to it. They just didn't exist, you know, 18 months ago or yesterday.

So, that's great, right? But the fact that we have all this then that is very mature, you know, the lessons learned. I think there was very quickly, very early on consensus as what an authorization request and a response would look like. At the end of the day, it's a yes-no question.

You know, you can't be that creative with a yes-no question and there's a lot of prior art. You mentioned ZACML. You brought it up. I'll use it again. ZACML had a format. OpenPolicyAgent sort of was very loose but they kind of had a format, very flexible. Cedar had one.

I mean, CERBOS, you have your own. So, it was easy to align, right? It was very easy to align.

Yeah, and I think for a lot of those implementations we got, one thing that we kind of took on board, sort of split across us as a working group, was we actually wrote some of those integrations ourselves. So, anything that is open source, like APA, for example, we, one of us kind of took the lead and actually wrote the interop kind of demo for it.

So, we could actually go back to those, you know, communities and say, look, AuthZend's real. Here's how it works inside of your ecosystem. I think a good example of that is AWS API Gateway. For the API kind of use case, one of us took on, Omri actually took on the task of writing kind of that example and ended up taking it to the AWS API Gateway team and went, say, hey, look, this is real. It now speaks to standard. And then now they're kind of adopted that and brought it into their product.

So, I say, I think for me, is anyone going through this process, find those either open source or kind of open ecosystem type projects that you can demonstrate your standard working in and use that as a kind of a forcing function almost for the conversation to say, like, you should adopt this and here's why. I know that's the easy part. The hard part is going to be going to, you mentioned Salesforce, Ian, going to Salesforce, going to Workday, going to SAP and telling them, hey, you've got these thousands lines of code that do authorization. You've got this authorization model.

I mean, you probably remember that there's profiles and permission sets and permission set groups and many other things I'm forgetting inside of the Salesforce ecosystem. And that's just on the one platform out of, what, 15 products. How do you get those developers, those architects to say, nevermind the code we wrote over the past 10 years, let's go ahead and use AuthZend, right? That's going to be the uphill battle. But if we win that battle, it's going to be huge. So what can we do?

What can you do to convince your providers to actually at least offer the hook for external AuthZend calls at the very least, at the very best, actually give up on homegrown authorization and start externalizing to policy in the broad sense or policy in a technical sense. There's lots of languages that exist, or even graphs for those of you who like graphs for authorization. They exist.

Well, I think on that subject, right, of let's call it RP adoption for these kinds of standards, I actually think the sneaky way to get there with AuthZend, this is just personal opinion on this, is Shared Signals is probably a place to start, right? Because of adversaries like Shiny Hunters, because of ransomware attacks, there is a heightened sense from SaaS providers about the need to be, let's say, better neighbors in the enterprise ecosystem from a security perspective.

And I think the opportunity that Shared Signals provides to provide real-time telemetry gives us the opening of a conversation, and then we can fast follow with things like AuthZend. We've got to drag those people to the forum.

Quickly, let's do a little lightning round wrap-up. Because this is just the start of EIC, which means, and I want to set expectations, there are 6,000 hours of content today alone. It's a long week. And if you count the number of times someone says AI or NHI this week... It's a drinking game. Drink it. You will not make it to last. Drinking game. Drink it. You will not make it to lunch today, let alone Thursday. But I'd like to hear very fast, what is the applicability of these standards that we're working on in the non-human world, in the agentic world? How do you think there's play there?

Keep it short because you may have no answer, but that's okay. You can sort of kill a little time. I'll start. I mentioned it during the previous presentation. The authorization people, we don't care who you are. If you're a human, or an Android, or an AI identity, a workload identity, we just work. Period. I think standards are now more important than ever because these new AI frameworks, and companies, and vendors, and open source projects are going to spin up. Some will survive. Some will die.

But if you're going to be binding yourself to some solution, do it via a standards interface so you can swap out that solution behind it, as the companies and the ecosystem evolves. A little more tangibly, if you look at MCP gateways, they're building an externalized authorization into a lot of those approaches. That's an easy wheelhouse for us. And SCIM events, we need things in real time.

Full stop, right? Look at SCIM events, building on top of shared signals. They're working on AI agentic profiles in the SCIM working group. And then EKYC for OpenID, we're looking at maybe using shared signals as EIDAS credentials are shared with financial verticals. Say they take information from an EIDAS credential, and they have an intent.

Like, we took this information because this customer has a loan. If that intent, that loan, that purpose changes over time, shared signals could be a way to do that. And then finally, death in the digital estate, which Nina's talking about on Thursday night. And there's a group on Friday. If someone dies, it would be nice for people to know, for institutions to have processes to flow through and to shift digital estates to the next of kin. So very practical all the way up to very abstract.

With that, on behalf of myself, Atul Tusharbegwale, this whole panel, thank you very much, everybody. Thank you. Amazing job. Sticking to time, Ian Glazer. This is a pro. Sorry. Who's next? DCP. Is that you? That's me. Okay. Thank you. All right.

Hello, everyone. So I'm Joseph Heenan, and I am not co-presenting with Brent. I'm co-presenting with Dima. So I think for those of you that aren't paying attention, historically, the DCP Working Group was chaired for a few years by myself, Christina and Torsten. Torsten stepped down at the start of the year with his responsibilities in the German wallet project increasing. So we made a call for new chairs, and Dima and Brent stepped up, which Christina and I are very grateful to and are very happy to have them on board.

So we now have four chairs in the DCP Working Group, which is good as it's still proving to be a bit of a busy working group, and there's lots of things going on. And I'll pass over to you, Dima. Cool. Is there a slider? Can you hear me?

Yes, you can. Have you heard about the wallets and verifiable credentials? Anyone? No? So I'm not going to stop on this slide, but whether you are building your own ecosystem, whether you are responsible for the country's ecosystem, your enterprise ecosystem, or you're trying to do any other types of credentials, whether it's for AI or payments and cards, those standards are definitely useful. I won't focus on that too much.

And it's pretty hard to navigate this space at the moment because there are a lot of standards that you need to pick from, and you also need to make sure that they work together. So this is just one representation of what choices you need to consider if you're trying to build any support for verifiable credentials. The good thing is there are profiles that tie those things together. Hype is one of those options, and that's what's being referred in the EU, and a lot of people in this room would be familiar with EU.

This is just a really good demonstration of what choices you need to make to link it all together. It's not as simple as picking one standard. You need to pick many standards to have a successful data system. Anything else to add from your side, Joseph? No? So we have three main streams of work in DCP Working Group, three main specifications being worked through. We had some specifications released last year. That was a big milestone after a few years of work by the DCP Working Group community. And we have the next versions coming out immediately after final versions were released.

We knew there is a lot more work to be done. So 1.1 versions for most of those specs is coming out in the next, hopefully, six months. But they're backward-compatible. Yes.

Well, that's the idea. So they hear. Yes. Backwards compatibility is always a goal, yes. But we knew that certain features are missing, and we had to cut down MVP scope for some of the ecosystem that tried to go live already.

Okay, great. Thanks, Dima.

So again, those of you that have been paying attention will know that there's been two competing standards for presentation for a while now. Well, more than two, but two big ones at least, which is the one from the ISO Working Group 10 that develops the mobile driving license and MDOC standards, as well as the VP verifiable presentation specification that comes out of the DCP Working Group. So there was an awful lot of overlap between those two protocols, but they made some very different design decisions and different people have supported different specs.

And it's all, unfortunately, a bit of a fragmented mess, but the Working Groups recognize that and are trying to figure out how to fix that. So we've been meeting for a while to try and figure out exactly how we should fix that, and in particular, where we actually meet to fix that, because there's all sorts of different SDOs around and people have love and hate for various SDOs, and various SDOs take a long time to set up new Working Groups and some don't. So we have been having a discussion between the two Working Groups for a while now, led by myself and Lofi from WG10.

And I think we've considered a couple of proposals, including setting up a new Working Group at OIDF that then people from the ISO Working Group do, setting up a new Working Group at FIDO that everybody joins, or setting up a new Working Group at OIDF as a temporary place, whilst we later then transition to a formal ISO and OIDF joint Working Group, which is called a PSDO, I learnt, Public Standards Development Organization Model within ISO-speak, but that takes months and months to set up because it needs a legal framework to be negotiated and all kinds of other things.

So that's why there was a kind of temporary start at OIDF, and as you can imagine, people are quite passionate about some of these standards bodies and exactly how things should happen, but we believe we've made progress and fingers crossed within the next week or two, we'll get an agreement to actually start work at a new Open ID Foundation Working Group, whilst we kind of do the legal, or whilst our colleagues at OIDF do the legal negotiations with ISO to try and set up a proper PSDO joint Working Group that hopefully the Working Group will agree to move to as its final home.

So we're getting there, hopefully we'll get there this week or next week.

Lots of the WG10 people are in face in somewhere near Marseille next week in France, so hopefully that'll get the final few people to agree and we'll get that over the line and actually start the technical work and that will mean for a short period of, well, for some period of time we'll actually have three presentation standards then because there will be a new combined one that kind of takes the best of both protocols, but we'll do some guidance on how people migrate and everybody should carry on with their role out of the existing standards whilst we sort this out, but this is going to make the future much cleaner and less fragmented for everyone, we hope.

We are also working with the European Commission, because obviously the EU has selected various of the DCP Working Group specs to use as the basis for the EUDI wallet, so we've been working with them on the testing, test case development, they need to have a formal set of test cases listed out for the conformance bodies in each member state to use.

So working with them, there's a launchpad event in the second half of the year where we'll do some more inter-ops, they've been looking at our conformance tests and looking to use, the idea of working with them on the test cases is that that will essentially recommend that the test bodies use the OpenID Foundation certification test as part of the EU wallet certifications, so that's the whole aim, and we've also been doing a lot of work on the conformance tests and these are now in the kind of final testing stages before they go live, we've got tests for both presentation and issuance, when they're combined with height 1.0, the interoperability profile, so we are focusing on interoperability with these conformance tests, so we are focusing solely on the interoperability profile, we'll be able to test issuance for both the wallets and the issuers, we'll be able to test presentations for both the verifiers and the wallets using the traditional redirect flows, and for wallets we're also able to test the digital credentials based browser API that is described in OpenID for VP, which is probably what we expect people to be using in their day-to-day work, which is probably what we expect people to be using in the future once the support for it is rolled out across all the platforms, so if you do have an implementation of any of the specifications please do try running the tests, if you do run them please let us know what happens, even if you fail that's useful information, especially if you think the failure might be a bug in the test, do email the certification team and let us know your results because we do need a few people to have tested the tests before we actually put them into production and launch self-certifications, and we do hope to within the next couple of weeks be in that position where we've got the three implementers that have kind of run each test suite so that we can then take them on to the next step and get the working group to approve launching self-certifications, and then any wallet issuer or verifier will be able to run the certification tests, submit their results to OpenID Foundation, and then they'll be listed on the website as certified once they've paid the certification fee, and that also gives you the right to use the OpenID certified logo to describe your product, so well worth doing, and yeah drop director at OIDF.org if you actually want to be included in any of the press releases that are going out about the tests when we release them as well, and now I believe I'm going to pass over to Mark.

Yeah thank you Joseph, slight surprise I hadn't realized I was covering this, I thought you might, but that's okay, so we've been running a program amongst the staff to expand out the conformance tooling kind of business proposition, up until now it's been something where effectively it's a self-service application that you run against your own implementation, but some ecosystems and some businesses don't wish to do it as a self-service thing, so they wish to have things like conformity assessment bodies, which if you've ever done anything in European Union you may be familiar with, which essentially is an independent entity licensed to do conformance testing and more formal certification services within a European context, so we've effectively been working on this program to build a much more formalized approach to defining who may test entities, so we're effectively setting a bunch of rules and requirements, we are licensing effectively one or more authorized auditors to do testing of the test service provider to make sure that they're a legitimate organization and that they do things the way we would like to see them done and give their customers the confidence that they're dealing with, a proper well-behaved organization and then those test service providers will in turn be able to use our brand and use our test tools when selling testing services to an entity that requires or wishes to be tested by a third party.

I don't remember if there's another slide, there might be, that's it, okay well I'll just say one more thing, there is a level of sustainability needed behind this as well, so there are fees involved in this program but they are pretty modest, they're in line with the less costly end of our current charging model for self-certification, so that shouldn't be a huge factor for people getting involved in this and the fees charged by auditors and test service providers are a matter for the competitive space, we're not defining that, we're not trying to control the whole environment around this, that's going to be a normal kind of customer supplier negotiation part of the process, so there you go.

If you want to find out more about that then contact me or Gail or Elizabeth. And by the way this is applicable to not just to DCP Working Group, so in general OpenID Foundation has certification tests for most of the specs and that's a secret source for any implementers and they're available to be tested, we recognize that this is a different model that we also try to take to scale the use of those tests, so that's applicable to whether you use OpenID Connect, whether you use FIPE, whether you use DCP standards.

Thanks Dima and the final word on that one is on Thursday at 2.30 there will be a session that myself, Mark and Christian Bormann from Sprint are doing, talking about why we really need this certification, the kind of German government take on that and all the standards, then talking about the tests and the scaling program and how it might be used in the EU. And that's us, so I shall pass over to Juliana. Spot the inconsistency there. So are you at all? No I'm Juliana today everybody, so imagine somebody smaller, blonder and more Canadian and you're somewhere around the right ballpark.

So a quick bit of history, there's been a piece of work going on involving Juliana Kafik, who's ex-Microsoft and has done an awful lot of work around the kind of business propositions behind digital identity in a higher assurance context. She's been contributing with some support from the OpenID Foundation into a project that was run by NIST to look at how to use MDLs in the context of financial services initially in the United States, but that's now extending out to a bunch of other markets.

So there's that been going on, there's a draft discussion paper which is published on the EKYC and IDA Bitbucket at the moment, although that'll be moving again of course. There's also, so there's links there which you can probably find by just searching, but if you struggle at all do reach out. We also have got work that's deriving from the EKYC and IDA Working Group's final specifications around the claims relating to identity assurance and we're going to build on that.

So up until now we added a number of kind of end user claims, things like place of birth, which didn't exist on the JOC claims registry before, but the challenge that we're facing is that there's a whole bunch of other claims which are really the metadata about how an identity was established that are not registered at the moment, and we're hearing from a bunch of relying parties and verifiers that standardizing that is going to be the next important step from their perspective. So I'll just switch my thread a little bit there.

Effectively there's a changing landscape and risks are increasing, so verification methods are changing, things are becoming more remote, whether that's via a pure play identity assurance provider or through reusable identities of various sorts including MDLs and other verifiable credentials.

There's a growing threat landscape which means that the online validation and verification of government issued physical credentials and building the relationship between the credential and the human presenting it is becoming significantly riskier because of AI generated deep fakes and synthetically generated fake documents and all that sort of stuff. So those what used to be strong controls are getting significantly weaker.

There's the assurance gap which is essentially this weakening of those kind of establishment of identity based on documents approach which is kind of pervasive across a lot of industries. I know that in the US in particular, and some of the focus here is US based because of the focus of Juliana's work, there are significant uses of government issued documents at various stages in the financial services journey like when there's a high risk transaction going on, a driving license or passport may need to be presented.

And then finally the story from the relying party side is that if they are going to be using new approaches to identity assurance then they really need to make sure that it meets their examiner defense obligations under regulations. I can I think translate that to something which isn't US focused to say which is we need to be able to demonstrate that we've done the identity assurance correctly to auditors and regulators. And so with that all being said, there's industry reaction to these challenges. Not all of it is, some of it's permitting other approaches to be taken.

So the FinCEN work is relaxing some of the pre-existing rules to allow for the risks to be mitigated. Some of it is more positively focused, what do we change in the future? So there's a paper out from NIST as you can see there about what we could do to improve this in a more constructive direction and a more well thought through direction than simply relaxing some existing regulations. I'm going to say this is a probable work item, this is very much breaking news.

We had a kind of subgroup get together last week and we've decided that a significant work item we can do is to take forward the standardization of the claims and look at developing registries for legitimate values to allow that kind of identity assurance metadata to be more interoperable across implementations going forward. So if you've got interest in standardizing identity assurance metadata, it's a bit of a dry subject but it needs to be done, do come and join us at the EKYC and IDA working group.

There's a white paper in progress currently, a discussion paper, not formally a white paper that Juliana has written which I'm sure she'd love everybody's feedback on if you've got an interest in this topic. It's derived from work she did with NIST and has been working with regulators and financials in Australia. She's been working with the European Commission and I believe there's some interest in it from the Japanese direction as well.

Okay so switching a little bit, the identity assurance specs that we got to final last year, we've now got draft conformance testing tools available for that and similar to what Joseph was saying about the DCP test plans, we still need probably two or three more real implementers if possible to come forward and test the test tools before we take it into a more general, available and confident pose that the test tool does what it should be doing and allows for a reasonable assessment of implementations.

I think that's all I need to say in that one and now we're into agenda things so over to Elizabeth. Thank you very much.

Thank you, I'm done with that. So that's really it from presentations for this morning, we've done an amazing job sticking to time. If you're interested in hearing me talk for a moment I will tell you some of the sessions that are happening later this week, nothing to do with what's on screen, that's for our Thursday session which you should come to. Kentara is in this room next if you want to continue on the standards track. There's also, you know, I hear ID Pro is pretty good, we're in A3.

Nat has a keynote this evening or this afternoon at 310, he's going to be talking about AI, I don't think Nat's in here right now to tell you any more about it. We have some wallet business model talk tomorrow with Torsten, that's not directly affiliated with the OpenID Foundation but it's, you know, closely associated with our work. Justin Richer is doing a talk on Wednesday beyond OAuth. There's an interop track tomorrow that our members might find interesting with Heather Flanagan and Rachel Selling.

George Fletcher is going to be talking about leadership in customer identity and access management on Wednesday. Mike Kaiser, specifically Mike Kaiser, is doing a talk on AI intents and purposes, that one sounds good, Wednesday at 1225. Alex Olivier, if you want to hear him talk again, is doing a smarter ID layer on Wednesday. David Brossard, again, if you want to hear him talk again, AI identity standards, that sounds fun, that's also on Wednesday. Christina and Paul are doing a talk on the German wallet, the Sprint projects, Thursday to, I think that's 2.50 on my note, but please check.

And then we have an OpenID Foundation sort of track happening at 2.30. And unfortunately, at the same time, one of the Kim Cameron award winners, Sachin, is going to be doing a talk on shared signals, so like two OpenID Foundation sessions competing with one another. So that one's actually at 2.50, so you could probably do both, you could probably do both if you wanted to, if shared signals is your thing and you want an implementer's take on it. And then we have a few Dade sessions, so Dean is doing a keynote on Thursday evening, and then there is a Dade session as well on Friday.

And that's pretty much it. I will also plug the Digital Identity Advancement Foundation, because OpenID is a sponsor, we have a few talks on Friday as well. That's it.

Stickers, I have stickers, if you want a sticker, come see me. Mark made them. Thank you all for coming.