If you’ve logged into a website in the last 10 years, chances are your credentials have been authenticated by the OpenID Connect protocol. Millions of applications employ this open standard to add an additional layer of security to the login process.
The organization behind OpenID Connect is the OpenID Foundation, a standards body that develops and maintains specifications for numerous digital credentials and identity protocols. Executive Director Gail Hodges has a front-row seat to seeing these standards develop from ideas to fully-adopted protocols. Since 2021, she has supported projects that improve security in OIDF specifications, enable cross-border digital identity, and define what identity looks like when AI agents stand in for human users.
In this condensed and lightly edited Q&A, she explains why post-quantum concern is pulling enterprises off SAML, where verifiable credentials are actually being deployed, and the two things existing standards cannot yet do for agentic workflows.
It’s time to transition from watch, wait, and see, to pick a post-quantum resilient algorithm and start integrating those solutions.
Gail Hodges, Executive Director of the OpenID FoundationAll are of great importance. It’s critical to have security as part of the DNA of what we do. That manifests in the way we contemplate and develop the consensus-based technical standards, but also in how we take it through the process. As most of our standards go to final, if they merit having formal security analysis done on them, we’ll make sure we complete that formal security analysis with an independent third party like the University of Stuttgart, to have that kind of rigorous security assessment using mathematical proofs.
There is trust in both our standards as well as trust in the implementations that leverage our standards. We really want to see that go end to end, all the way through to the conformance and any self-certification that people might choose to deploy. From a security point of view, it’s about not just using a standard but also then having that conformance to the standard.
For the privacy preserving aspect, some of the technical specifications have optionality as to whether privacy is central or not. Some of the use cases, it’s not imperative, like some of the enterprise use cases. But it’s critical that the standards give that optionality, and that there’s due consideration for those privacy implications.
Interoperability means functioning within a given implementation, within a given enterprise, within a given country or jurisdiction, or of course cross-border. Our specs are designed by default to support interoperability. But how to actually do that in practice, especially for really quite complex and thorny topics of cross-border digital identity or cross-border federation and trust registries, that stuff gets really quite tricky and extends beyond just the technical specifications.
There’s quite a bit. First and foremost we’re a technical standards body, so the first pillar of our focus is on having robust technical standards and taking each of our families of technical standards through their natural life cycle.
We have rapidly grown. We’ve gone from having one major standard, OpenID Connect, into another standard, FAPI, a high-security OAuth 2 profile used for API protection, which is particularly useful for data sharing. Those two were kind of dominant, and now we have many different spec families that are all being picked up and going through that adoption cycle. It’s incredibly active amongst our working groups.
We also want to make sure we’re providing thought leadership on some of the most tricky security questions. We’re not a lobbying organization, but we often work directly with government stakeholders who are trying to set up their own implementations and give some independent feedback on what standards they might need, or how to combine those standards. And then on subject matter items, it can be AI as a subject, it can be use of verifiable credentials in financial use cases, or age assurance. That’s a really hot issue. Death and the digital estate is another one.
I’ll go in scale order. OpenID Connect is the most scalable, already used by billions of people around the world for login and for single sign-on. That’s the standard we’re most well known for.
What’s particularly interesting there is the demand for implementers of SAML to transition to OpenID Connect. The most common alternative to OpenID Connect has been SAML, most frequently adopted by research and education and government use cases. And what we’re seeing is a real substantive concern that SAML is not going to be post-quantum resilient.
So making that transition over to OpenID Connect, and how to make that transition, is a massive consideration. Often the people who implemented SAML are not even around anymore. So there’s a real issue with how to go about a migration. The board of the OpenID Foundation and several working groups are trying to figure out the right way to provide some concrete guidance for those stakeholders making that transition.
Some communities are already very active. The academic and research side, via eduGAIN, have already selected OpenID Connect and OpenID Federation and are making that transition for tens of thousands of research entities. It’s actually a huge number globally that are networked together, both for projects and for direct university relationships. But of course many private entities also have legacy SAML infrastructure. So there’s a fair bit of work there.
The temperature has risen. Even in the last couple of months people are much more concerned that AI algorithms like Mythos, or whatever else, are going to make it much easier to find compromises and issues in existing implementations, and that quantum computing development is moving that bit faster. So it’s time to transition from watch, wait, and see, to pick a post-quantum resilient algorithm and start integrating those solutions.
On our side, we need to be ahead of the market to make sure our specifications have any fine tuning or fine tuning guidance we need to give. Our specs and protocols are designed to be post-quantum resilient — you can swap out the crypto essentially — but that doesn’t make it super easy for the implementer. There’s still a lot of lift to make that transition from one protocol to another, or change their crypto. So we want to offer that guidance, be in line with best practices like what NIST is recommending. They brought in their dates recently. We are trying to do the same, and we’ve got to be a couple of years ahead.
That’s a really hot spec right now, with a lot of government-led and some private-sector-led ecosystems adopting it. Where you hear most of the momentum is jurisdictions like the EU, which has adopted OpenID for Verifiable Credential Issuance and OpenID for Verifiable Presentations, and the High Assurance Interoperability Profile, as part of the EU Digital Identity Wallet.
And not just because Europe has selected it. I’m counting on the order of 50 different countries that are leaning in the same direction. The Western Balkans, six countries there. India is already live with, I think they told me, 20 million consumers. California is live with OpenID for Verifiable Presentations and Verifiable Credential Issuance. And there’s others expected to come as well.
There’s also a collaboration with ISO, ISO/IEC JTC 1/SC 17 Working Group 10, which works on 18013-7 for presentation. We’re working together on a harmonized protocol for presentation to make it easier for implementers hosted in the Digital Credentials Harmonized Protocols Working Group. That’s an important piece of the upcoming work, which has kicked off and is progressing swiftly.
A lot of the most active work is happening outside of the US, where there’s real momentum and regulatory requirements. In the US context, outside of California, one of the most interesting use cases is opening a bank account, and other types of financial institution transactions.
Getting that unblocked is two pieces. One is more regulatory guidance, and there’s an expectation of the Treasury offering regulatory guidance later this year. The other piece is providing a bit more visibility on the metadata side, on both proofing and authorization. That is in response to lessons from the NIST and National Cybersecurity Center of Excellence (NCCoE) project that was designed around opening a bank account.
It’s good to see the major banks participating in projects like the NCCoE, putting some sweat equity into understanding what it looks like, and NIST creating that playbook to unpack what opportunities will tip the tide of adoption. Those of us who are hip deep in it think that it is inevitably valuable for financial institutions, and other regulated institutions that have high-risk transactions, to start consuming these credentials.
But I’m concerned that C-level stakeholders don’t yet get it, because they haven’t seen it before. It still feels new. It doesn’t feel real in people’s lives in that respect. So we need to keep breaking down some of those barriers so these credentials can play their natural role.
I would consider it in a way naive if they didn’t have some people starting to look and research and play around, at the absolute minimum. Because it’s in their best interest to have their head around what it can mean to them and their businesses, and how to integrate and consume it.
I’m more fluent with the financial institutions and some of the healthcare work — when you’re taking people through a funnel, and you want to take them through different kinds of Know Your Customer (KYC) processes, they should be thinking about the R&D of the next best thing that’s coming. And this is one of the next best things that’s coming. You can be doing the R&D and start to incorporate it into your processes, so you’re learning in production along the way. And then you start to open that aperture as you get more comfortable with the technology and use cases.
I think that was the question a year ago, or maybe even two years ago. Maybe the assumption by engineers that were not familiar with identity and access management and security best practices was thinking, ‘oh, we’ve got to reinvent.’ But we know those requirements and we can adapt to them.
Let’s say 90 to 95% of the use cases, there’s standards that exist for them. It’s partly the education on how to use those standards, and partly what is missing in the ability of implementers to adopt existing standards so ecosystems can adopt them at scale.
There’s a lot of great work happening both in IETF and the OpenID Foundation. We’re seeing the adoption of Model Context Protocol (MCP), and advancements in MCP — Anthropic and OpenAI and Snowflake have announced enhancements to their platforms. Two years ago my observation would be you have the large language models moving very, very quickly to get stuff out to market as quickly as possible. And now there’s an interesting moment where there’s a recognition that the product pipelines benefit from incorporating standards where the standards exist.
Over the last 15 to 18 months, since MCP launched, we’ve seen this steady improvement of: oh, let’s incorporate OAuth 2.0. Okay, now maybe client metadata would be interesting. Oh, maybe identity chaining could be interesting. There’s not a question anymore around the fact that valuable standards already exist. It’s a question of which ones would be fit for purpose for these AI use cases, and how to configure them.
To give some examples of things we know are not where they need to be: Delegated authority. How am I delegating authority where I know it’s definitively this human person delegating authority to this particular agent? And how exactly does that delegated authority work when you have to know the human identity, the agent identity, and the relationship between them? Generally speaking, delegated authority is a bit of a gap in technical standards.
We have some work at the OpenID Foundation in the electronic Know Your Customer (eKYC) and Identity Assurance Working Group for several use cases. But whether it’s delegated authority for age assurance between a parent and a child, and knowing for sure the relationship between the two, or death and the digital estate — the person who’s passed and then the loved one who’s taking care of that estate, and the relationship between them — that has to be assured. It’s a similar type of problem with the consumer and the person who’s authorizing the agent to perform a transaction, or the enterprise entity and the agent being authorized to perform a transaction. So we’ve got a known gap there, and one we collectively need to keep pushing hard on to close.
The other one is multi-party trust across different entities — how you establish that trust. That’s another one we think is going to take a bit of time to fully address. It can work when you’re in one particular ecosystem, but what happens when you’re cutting across different contexts? That’s not yet fully addressed.
On the threat side, the one that has me most concerned is AI-enabled attacks. I still feel like we’re in the infancy of what that is likely to look like, and how easy it will be to exploit existing problems and known issues. I’m hearing word on the street that financial institutions are already seeing higher write-off rates than they’ve seen in the past, so there’s real pressure coming. That unto itself could motivate more change amongst enterprise decision makers and those C-level folks.
Now, what is the pace of change there? This is not stuff where it’s easy to go from zero to 100 and rework your infrastructure. So trying to imagine that the threat is true and real, and prioritizing the steps to mitigate the risks, is super important.
Then there are the foundational challenges — older infrastructure, or infrastructure that’s not quite ready, like SAML, or implementations that are going to be using older crypto, and organizations that are not as agile to upgrade their crypto over time. In that medium term I see the challenges around the SAML migrations, and the challenges around post-quantum.
As a member of my board said, it’s not that one’s going to have all crypto algorithms updated in real time. There’s going to be those that are prepared and then those that are not prepared, and we hope to have as few entities as possible in the unprepared category. So how do we help everybody go through that curve as quickly as possible?
The analogy I give is the Y2K bug before January 1, 2000, where it was different in that you knew there was a specific date, and there was a whole lot of work that needed to be done, but people were collectively — technologists and C-level folks — very aware that they needed to check what the risks were and go through the process to address it. Here we have a bit of a moving target. Unless you’re a U.S. government supplier and you have a fixed date you know you need to work towards, generally speaking it’s confusing because it’s a bit wishy-washy. And then there’s also not one single crypto that everybody’s going to move to. There’s a little bit of ambiguity around which crypto you might choose, and is that going to work from an interoperable point of view with your counterparties? That confusion worries me.
In that medium term I see the challenges around the SAML migrations, and the challenges around post-quantum.
Some of these might end up getting conflated together, and that’s fine. Teams might say, I want to put best practices in place for AI, and while I’m at it I’m going to cross off my SAML migrations and I’m going to get more post-quantum resilient. So people can be more thoughtful at that senior executive level: if they’re going to open up the hood on their engine and fix some stuff, they should be thoughtful about combining some of these repairs together.
We probably didn’t do as much justice as I should have to some of the enterprise specifications — AuthZEN and Shared Signals. We think those are really well placed to support identity and access management (IAM) infrastructure as it is, and enterprise clients as they are today.
But we also see promise in how these final standards can support the next wave of AI use cases and requirements. So starting to think about how to implement them and take advantage of those leading edge standards could be particularly valuable for some of the enterprises.
This Q&A is condensed and lightly edited from an August 2026 SIGNAL interview with Gail Hodges. Hodges’ views are her own and do not represent the position of SecureW2.
SIGNAL publishes interviews with the practitioners and standards authors shaping security practice — subscribe to get them in your inbox.
