All right. Good to see you all. Gail Hodges, Executive Director, OpenID Foundation. What we wanted to do for this section is to acknowledge quite a bit has happened in just the past year on the topic of AI and at the Foundation on the topic of AI.
So I was going to share a couple of headlines from the AI and Identity Management Community Group and their journey and what they've been doing to support the conversation and ask Nat and Dima to kind of share a few themes from what's happening in their working groups that relate to AI and hence why I'm a phone-a-friend on our Austin co-chairs as well because there's some conversation going on there as well.
So to kick us off, some of us will have heard earlier this week from Martin Kuppinger who kind of framed AI as an overlay against the wider identity frameworks that we've had in the past and Nat did a deep dive, you know, talking about the gaps that he was seeing in the standards domain. And again, earlier this morning I was hearing George Fletcher talk about the plethora of different standards work that's going on not just at the OpenID Foundation but the IETF, ITU, our friends at the W3C, FDX, the list is long, right?
So there's just an explosion of use cases as well as private sector solutions to try and close some of the gaps where there are not existing standards. So in that kind of context of, I don't know, when we look at what's signal to noise, what I wanted to do was kind of bring that back into what the AI and Identity Management Community Group is doing and some of these leading-ed conversations in the working groups.
So the AI and Identity Management Community Group started with the premise that this is chaos and we need a safe space to convene to be trying to process all this chaos in real time as it's happening. And so part of that was acknowledging that when MCP launched, you know, thought leaders like Aaron Parecki and others, you know, in the IETF OAuth working group were like, wait a second, you know, Anthropic, maybe you should be thinking about how OAuth 2 could be playing a role and how you could make some adjustments to MCP.
Similarly, there was a blog post that Peter Kesselman wrote and some contributions that he and other co-authors contributed to the IETF that related to SPIFI and that has started to come into some of the recent announcements as well. So it's happening super fast, right? It's happening at a faster pace than standards would traditionally play.
In the AI and Identity Management Community Group, they said we've got to set some baselines, we need taxonomy, we're going to work on taxonomy documentation, we're going to work on trying to articulate the use cases, which is extremely hard as there are so many and it's very broad, and we're also going to look at threat modeling.
And Sarah Caccetti and Chris Phillips led some feedback to NIST on their security and AI request for consultation and that paper, which is forthcoming, and some of the work they've done already, but additional work to come is basically trying to say what not to do, right? In this moment of chaos, please let's provide to the broader community what not to do while we try and build up the foundations of what good looks like. So first I'll kind of ask if there's any comments from either of you on the AI and Identity Management Community Group and then we'll go into the specs.
Any particular additions? The only thing I'd probably add is that I think the primary role of the foundation and the board sort of leading the foundation is to provide a space for those conversations to happen. So that's what clear demonstration in AI Community Group, AAM Community Group, we have a space where people can come and safely discuss those things. The Community Group is not designed to produce standards, it's a discussion forum, a safe space, and if there are specs to be defined, that goes into existing working groups and potentially even new working groups to deal with.
But yeah, I think the main purpose for us is to sort of foster this community and the interactions. And one of the key outcomes of the first sessions of AI Community Group was actually the link between AI community and identity community, because initially they developed separately and then the last year there is a lot more conversations between the two, and that was a big important outcome that people don't start reinventing things when we already have a lot of things in identity space solved.
I don't have much to add, but yeah, in the beginning it looked pretty bad, scary, everybody's sharing their credentials, the full credentials, maybe SSH keys, right? That was really, and the MCP had no authentication, authorization, whatever, for right, right away.
Yeah, that's going to be handy. The same with OpenCLO, right? If you hand everything into the quote-unquote agent, of course they can do a lot of things positively as well as negatively, potentially.
So yeah, it's good that now we're talking. Yeah, absolutely. And I think we've even seen members of the identity community be picked up and now be insiders, right? Nick Steele going to OpenAI, Tobin South is over at Anthropic and there are others, so there's these direct connections to work through a lot of this together. So I'd like to take the conversation, Nat, to the end of your talk where you introduce federation, OpenID Federation, as one of the conversation points, right?
We're not in the mode of saying, hey, we have all the magic special specs and this is magically going to solve your problems, but really trying to unpack what the requirements are, what the use cases are, and what's best fit. And in some cases that could be existing standards. So I thought in that kind of context of trying to explore what's emerging, what those requirements are in the agentic AI space, why federation and OpenID Federation could be interesting, might be relevant as people are thinking about their architectures. So it might not be OpenID Federation.
I believe the OpenID Federation is going to be a very useful tool for that, but some kind of federation arrangement, setup, scheme, depending on which country you are in, you use different words, but is needed. And also, you know, the registering, especially manually registering all the agents and tools, it's not going to work.
I mean, you can't really do it. So it just lacks the scalability. So you need to have something like that, which goes beyond just the keys. In my talk, I said that, yeah, it's signed by a key, but you can't trust it, right? Unless you have some way of deriving trust from that. And federation is a mechanism for doing that. Whether that key is trustworthy, from which party it is coming, what kind of metadata is associated with, what kind of policy is associated with it, and so on and so forth.
So, yeah. Yeah, I think it's super useful for the situations in general, not just for Gentic, where you need to externalize trust, and because where you have something that's coming from outside of your organization, and you have to work out if your trust is system, whatever that system is, it could be in sort of open banking relying party, or digital identity relying party, or it could be an external agent. And then you have a way to walk the chain of trust to make sure that you get to the point where you say, okay, now I see the endorsement chain, then I can trust this entity.
That's probably a good segue to another family, to maybe two families of specifications, Dima. Both the FAPI family of specifications and what that could offer to a Gentic use cases, and similarly, OpenID for verifiable credentials. They're different pieces of the puzzle, but maybe you could comment on both of them, because there are definitely just those very early architecture, early ideas, and use cases starting to come out where they're pulling on the specs and trying to bring them in to solve real problems.
Yeah, sure. I think there are probably two angles with FAPI.
So, if you take a step back, there are a lot of agents out there that are expected to perform financial transactions and help people with their financial matters, whether they analyze their bank account data and shift money between different accounts, or do additional things to do with their banking. The great news is that we already have this financial infrastructure in place. A lot of countries, they already have open banking ecosystems implemented.
So, we've got the baseline infrastructure to query six different infrastructure to query securely, to query transaction data, to perform payments in many jurisdictions. So, we have the baseline. I personally see there's a massive opportunity to build on that to enable AI agents.
Yes, we have missing bits and pieces because of the way the entities onboarded to those ecosystems, but this is where Federation potentially can help and different types of clients, different types of accreditation required. But I see FAPI as a fundamental existing building block that can be used to enable that use case.
So, that's on one side. And the simpler one is also FAPI is super useful if you take away the situations where you need the user consent.
So, FAPI can be used for securing system-to-system communications. And a lot of agents connect to systems and a smaller, short FAPI profile for system-to-system communication is super useful. It can be both, right?
So, it can have consent or... Yeah, we're not saying then when you need to skip the consent when you need the consent. I think there are situations where it's truly machine-to-machine communication. And you have two choices in general. You can either define the profile from scratch yourself.
Okay, I'm going to use OAuth and I'm going to pick those options. Or you can just point it to FAPI, which has four or five predefined options for you.
So, it's still OAuth profile. For those of you who don't know, FAPI is a secure and interoperable profile.
That is, we formally analyze it from a security perspective. We have a conformance test and naturally we run a lot of interop because of wide deployments. It's a heavily tested profile. I think it's billions of transactions a month at the moment. That's on FAPI. I'm going to come back to the verifiable credential part of the question.
But maybe, Nat, you'd like to add to that. You know, why in ecosystems or private entity systems that are trying to manage their security posture, why they might want to be thinking about FAPI? There could be use cases beyond open banking and open data.
So, for organizations to demonstrate that their system is implementing a sensible security posture using a formally analyzed protocol and using it and also testing against the conformance suite would be a very useful piece. I mean, security is not only that. That only tests the protocol and the perimeter thing, right? When it comes to financial transactions, a lot goes behind that.
So, it's only a piece of the entire thing, but it still is useful and you can skip a lot of lines with that. I'd say that's kind of on the leading edge of what we're exploring right now. We know for open banking and open data ecosystems, if you're federating health data or access to financial data, that FAPI is a great fit and those ecosystems are naturally migrating to it because there's nothing that really competes directly with it in terms of its core benefits.
But the potential for it to be deployed much more widely, like within the bank architecture or for other open EKYC use cases or where there's a single IDP like the government is exchanging data externally, that this kind of predefined security analyzed FAPI posture could be attractive to avoid making risky decisions and trade-offs on other parts of the security architecture. I mean, you can roll your own protocol, but then you have to do all the analysis and things yourself. Or accept the risk.
So Dino, let's come back to the OpenID for Verifiable Credential piece and where that could fit in. Because there's lots of chatter around Verifiable Credentials, of course, but there is perhaps some novel situations where one might want to use a Verifiable Credential as part of an agentic AI use case.
Well, one of the big discussion topics at the moment is how do agents convey, so we'll discuss the trust bit, but the next level is, the next step is how do agents convey what they authorize, if they actually truly have the authorization from a person, a delegation of a person, and what is their limits or what are their limits or constraints of what they're allowed to do. Naturally, that falls into Verifiable issuance of the Verifiable Credentials piece.
And whether we talk about intents in A2P protocol and other similar protocols, or you're talking about even federation, if you think about it, it's a chain of Verifiable Credentials of sorts. So I think those standards are useful and that there's a lot of exploration in this space, communities looking. Delegation is a big one that George touched earlier today. How do we convey the delegation for all the different types of use cases, including AI?
Otherwise, the entities that do accept those actions, once again, they're taking on a lot more risk than they're willing to, especially if there are financial or personal data transactions involved. Perfect. I'm going to now phone my friends on the AuthSend group. And I'm coming back to you two to talk about SDO coordination. So George prompted an important question on what good looks like to coordinate with other SDO peers with the plethora of specs that are out there. But I thought I'd pick either one of you.
Maybe you'd be interested in commenting on what's been discussed with the AuthSend community group around potential applications to use AuthSend for agentic AI. Yeah. So as I mentioned earlier, we've been kind of circling around the MCP kind of world. Because ultimately, if you look at it, we are now giving these agents the ability to reach out and do things in the real world. And Patrick, your talk yesterday, I loved your analogy around we shouldn't be to protect the bank. You shouldn't be arresting the criminals. You need to be guarding the vault.
And I think that's a really, really good way of kind of anchoring it. Because MCP is the way we are going out and giving arms and legs to these agents in the outside world. So what we've been, well, our tool, thanks for the credit for this, our tool started working on this, basically a profile on top of AuthSend to basically allow you to map different information models. So MCP has an information model based on JSON RPC, if you want to get into the weeds.
But what we've been working through is a way of basically applying metadata to things like MCP, but it also backports to things like open API specs as well, to basically define at a tool or a method level what the authorization check needs to be for that to be allowed. And it's not a strict one-to-one mapping, but it's more of a dynamic mapping. So an MCP tool can advertise, OK, to execute me, here's the AuthSend check. This value needs to go into this field of the information model. And that way, it can be handed off to any AuthSend compatible PDP to make a decision, allow or deny.
And then that can be enforced at a gateway or down to a service level. But the kind of meta point now is we're looking at how, as these new use cases come up, because MCP is what we're dealing with today, who knows what's going to be the thing in six months' time or a year's time or two years' time. It may not be MCP, it may be something else. So from a spec perspective, we're trying to find ways of having these metadata layers that sit on top that can map to these different information models and then into the AuthSend layer. So any AuthSend compatible system can manage it. Absolutely.
And I think one of the real, even in the next week or two, what we're trying to unpack is how our different... You're free, Alex, you're safe. Run away while you can. Elizabeth's panel brought up that there are all these interconnections between the standards. And so more and more, we're thinking of the world through the lens of reference architectures and how to support ecosystems and private entities on how to stack some of these specs together.
And when we're looking at some of these agentic AI use cases or ecosystems that are trying to unlock the potential of agentic AI use cases, as well as protect against the threats of LLM-enabled attacks, what does that look like? And typically, from a board point of view, we're empowering and supporting our individual workgroups. But now we have this need to think strategically across some of the workgroups and see whether we even have opinions or consensus emerging on how to combine some of these specs.
So one, we'll keep baking. I wanted to bring this back to Nat and to Dima to talk about any last recommendations or asks you might have of the audience. So as we are trying to explore things internally, we're also trying to get the smartest messages we can out to the community on what they can and should be doing now. So any parting comments from you both? I think the main one is join the community. So if you have a use case, if you have a problem, come and discuss it. Reach out to any one of us. Anyone in OpenID Foundation will point you in the right direction.
It's a free to join, open community that is designed specifically for these type of things. And I think if you join, we can make those standards stronger.
And again, we're not, a lot of discussions are happening, not just about OpenID Foundation standards. We're using standards from many other standards bodies. And so it's not exclusive. If you don't see the use of OpenID Foundation, it means there is no point for you to join the community. Community is looking at standards that are using ISO, FIDO, IETF standards and any others as well. So I think the main one is join and participate. Yeah. So it's just the repeat. We often start creating standards at OpenID Foundation and push it to other organizations like IETF.
And we are very open organization. And I, you know, to my dismay, I asked ChatGPT that what's the process in OpenID Foundation is like? And it answered, it's a pay to play place.
No, it's free. You just need to write the contribution agreement. That's it. Right. We need a contribution agreement because we might use something you wrote. And we want to keep our standards to be freely available and also freely implementable without worry of being hampered by patents.
So, yeah. So we provide a safe space free of charge.
Of course, if you can sponsor them, that's nice. But please come join us. Definitely come join us.
And, you know, I'm going to harken back to Elizabeth's talk on Tuesday night, which I think has already caused, you know, fascinating ripple effects in the community on what is our role. And we think as the OpenID Foundation, we have a crucial role, you know, to act between the private sector and the public sector to offer safe spaces to convene, to develop the fundamental standards and infrastructure, but also to bring our integrity and our values to the table and make sure that that is being knit into the very fabric of how we work.
And it's certainly how we work as a foundation to be open to everybody, to have the lowest possible barriers to entry and to work in lockstep with liaisons with our SDO peers to really have a huge impact. So I think this is a pivotal moment in our industry, even in the five years I've been in the middle of it from a standards point of view. It's incredible, but clearly only the beginning. So thank you to my speakers and thank you to all of you because we're in it together. So thank you.
