The OpenID Federation 1.0 specification has started its 60-day review to become an OpenID Final Specification. Draft 46 of the specification, which was published today, is the target of the 60-day review.
Thanks to all who participated in the Working Group Last Call (WGLC) review, which was based on Draft 45. Your feedback resulted in a number of clarifications and editorial improvements. The changes made in -46 are detailed in the Document History section.
Almost there!
Today the OpenID Connect Working Group started a two-week Working Group Last Call (WGLC) for the OpenID Federation 1.0 specification. During the two weeks ending on December 4, 2025, working group members will identify any issues that they believe should be addressed before it becomes final. Of course, responses of the form “It’s ready to go as it is” are welcome too!
Draft 45 of the OpenID Federation specification, which was published today, is the target of the WGLC review. It adds two features motivated by the security analysis of the last Implementer’s Draft. They are:
peer_trust_chain header parameter: This enables an RP to provide a Trust Chain from the OP it is establishing trust with to the Trust Anchor that it selected at registration time. This works with both Automatic Registration and Explicit Registration and can be used in other trust establishment regimes. When a Trust Chain is also provided from the RP to the same Trust Anchor, together these enable a property called Federation Integrity, which is described in How to link an application protocol to an OpenID Federation 1.0 trust layer.trust_anchor_hints claim: This enables Entities to publish the Trust Anchors that they are configured to trust. This can facilitate determining what Trust Anchors are shared between parties.It also contains several important editorial improvements, including organizing the Entity Statement claims by where they may and may not appear. The changes made in -45 are detailed in the Document History section.
Thanks to all who helped us reach this point! Nearly done…
As has become traditional, I gave the following presentation at the Monday, October 20, 2025 OpenID Workshop at Cisco:
I also gave this invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 21, 2025:
Draft 44 of the OpenID Federation specification has been published. The draft contains improved descriptions of a number of features. The one breaking change made is that Trust Mark Status responses are now signed.
Some of the changes made are intended to facilitate implementation of features needed for some Swedish government use cases. In particular, extension points were added to make it easier to use OpenID Federation for trust establishment for systems where existing entities may already be deployed, and may not be able to be modified.
The changes made in -44 are detailed in the Document History section.
Thanks all for the continued progress towards finishing the specification!
A new version of the Updates to Audience Values for OAuth 2.0 Authorization Servers specification has been published that incorporates feedback from the OAuth working group during IETF 122. I look forward to a vigorous and useful discussion of the specification at IETF 123 in Madrid.
This specification updates a set of existing OAuth specifications to address a security vulnerability identified during formal analysis of a previous version of the OpenID Federation specification. The vulnerability resulted from ambiguities in the treatment of the audience values of tokens intended for the authorization server. The updates to these specifications close that vulnerability in the affected OAuth specifications – especially JWT client authentication in RFC 7523. In parallel, the OpenID Foundation has also updated affected OpenID specifications, including OpenID Federation and FAPI 2.0.
As summarized in the history entries, the changes in this draft were:
Finally, Filip Skokan was added as an author, in recognition of his significant contributions to the work. Thanks to Filip and Brian Campbell for their work with me on this specification.
I’m happy to report that the OpenID Connect Relying Party Metadata Choices specification has been approved by the OpenID Foundation membership as an Implementer’s Draft. An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification.
The need for this was independently identified by Roland Hedberg and Stefan Santesson while implementing OpenID Federation. The contents of the specification were also validated by Filip Skokan, who implemented it. Filip has been added as an author.
The abstract of the specification is:
This specification extends the OpenID Connect Dynamic Client Registration 1.0 specification to enable RPs to express a set of supported values for some RP metadata parameters, rather than just single values. This functionality is particularly useful when Automatic Registration, as defined in OpenID Federation 1.0, is used, since there is no registration response from the OP to tell the RP what choices were made by the OP. This gives the OP the information that it needs to make choices about how to interact with the RP in ways that work for both parties.
Thanks to all who contributed to reaching this milestone!
The OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 specification has been approved as a Final Specification by the OpenID Foundation membership.
As I wrote at the start of the review period, the specification is glue that ties together OpenID Connect, W3C Web Authentication, and FIDO Authenticators, enabling them to be seamlessly used together.
There are three useful normative definitions in the spec – two ACR values and one AMR value, all used in ID Token claims.
The two ACR values defined by the specification are:
phr:phrh:The AMR value defined by the specification is:
pop:hwk and swk methods, it is unspecified whether the proof-of-possession key is hardware-secured or software-secured.I believe this approval completes the work of the EAP working group.
Draft 43 of the OpenID Federation specification has been published. A number of features in draft 42 were discussed during the recent OpenID Federation interop event and the changes made in draft 43 are largely a result of conclusions reached there and resulting discussions that followed.
Before the interop, there were 40 open issues. As a result of the progress made at SUNET, and the ongoing engagement of interop participants since then, we’re now down to 17 open issues. And 9 of those propose extension specifications, post-final work, or reviewing the text.
The changes made in -43 are detailed in the Document History section.
Thanks all for the significant progress towards finishing the specification!
Ten years ago this week, in May 2015, the JSON Web Token (JWT) became RFC 7519. This was the culmination of a 4.5 year journey to create a simple JSON-based security token format and underlying JSON-based cryptographic standards. The full set of RFCs published together was:
It’s certainly the case that we co-designed JWT and its underpinnings with OpenID Connect, while also attempting to create general-purpose, widely useful standards. Given the adoption that’s ensued, it seems that we succeeded.
As I wrote in my post JWTs helping combat fraudulent and unwanted telephone calls, “It’s often said that one sign of a standard having succeeded is that it’s used for things that the inventors never imagined.” I’m gratified that this applies to JWT and the related specifications. As was written in the post Essential Moments in the OAuth and OpenID Connect Timeline, it’s now hard to imagine an online security world without these standards.
That said, there’s work underway to keep JWTs and the use of them secure for the next decade. Five years ago, the JSON Web Token Best Current Practices specification was created. As I wrote then:
This Best Current Practices specification contains a compendium of lessons learned from real JWT deployments and implementations over that period. It describes pitfalls and how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise arise.
My coauthors Yaron Sheffer and Dick Hardt and I are now updating the JWT BCP to describe additional threats and mitigations that have become known in the last five years. See the updated JSON Web Token Best Current Practices specification.
Similarly, my coauthors Brian Campbell and Chuck Mortimore of the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants are updating it and related specifications to address vulnerabilities caused by ambiguities in the audience values of tokens sent to the authorization server. See the RFC7523bis specification.
I’m truly grateful that my coauthors John Bradley and Nat Sakimura and I created something useful and widely used ten years ago, of course with substantial contributions from the OAuth, JOSE, and OpenID Connect working groups. I look forward to what the next decade will bring!
Duende Software just posted an insightful piece titled Essential Moments in the OAuth and OpenID Connect Timeline. It’s a trip down memory lane, recounting significant developments in the identity and security standards repertoire that we now take for granted.
It reminds us that all of this has come about in the last 15 years. These standards didn’t happen by accident. They were all created to meet specific needs that we understood at the time. Fortunately, they’ve also largely stood the test of time. I’m proud to have been involved in creating many of them – of course, always in close collaboration with others.
At the end of April, I had the privilege of gathering in Stockholm with 30 participants to perform interoperability testing among 14 different OpenID Federation implementations. Leif Johansson and SUNET were fabulous hosts for the meeting at their offices in Stockholm. People from 15 countries participated, coming from as far as Australia and New Zealand! We performed eight different classes of tests between the implementations plus tested the OpenID Certification tests being developed for OpenID Federation.
It was great to have many of the core contributors to OpenID Federation come together and meet one another, most in-person, a few virtually, many for the first time. The sense of community and shared mission in the room was palpable! Besides testing, we also took time for architectural discussions, addressing open issues, and of course, socializing over drinks and dinners.
I must say that the OpenID Foundation staff who helped organize the meeting did a bang-up job! Stephanie Meli and Gareth Narinesingh both pitched in in numerous ways, resulting in a flawless and fun event! I’d normally be the one blogging and posting to capture the essence of the event, but they already more than covered that base. Their posts are full of facts, anecdotes, and photos. Check them out…
I thought I’d add a few more photos and graphics to capture the spirit of the interop.
I gave the keynote talk So you want to use Digital Credentials? You’re now facing a myriad of choices! at EIC 2025. I opened by describing engineering choices – credential formats (W3C VCs, ISO mDOCs, SD-JWTs, SD-CWTs, JWPs, X.509 Certificates), issuance and presentation mechanisms (bespoke and standards-based, in-person and remote), mechanisms for choosing them (query languages, user interfaces), and trust establishment mechanisms (trust lists, certificates, and federation).
I then upped the ante by talking about the criticality of usability, the challenges of building ecosystems (something Andrew Nash first explained to me most of two decades ago!), and how digital credentials are not an end in and of themselves; they’re a tool to help us solve real-world problems. And of course, I closed by coming back to my theme Standards are About Making Choices, urging us to come together and make the right choices to enable interoperable use of digital credentials in ways that benefit people worldwide.
View my slides as PowerPoint or PDF. I’ll also post a link to the video of the presentation here once Kuppinger Cole posts it.
My friend Giuseppe De Marco shared the article “Documenti su IO: 5 milioni di attivazioni per IT-Wallet” with me about how five million people are now using the Italian digital wallet. It adds the information that 4.3 million health cards, 4 million driver’s licenses and 100,000 European Disability Cards have been issued to those wallets. These are significant accomplishments!
(Yes, the article is in Italian. ;-) I read it with the assistance of machine translation.)
These accomplishments are made possible through use of standards. Having just been at an OpenID Federation interop event in Stockholm, Sweden, I find it particularly timely that this is an example of five million people productively using OpenID Federation in their daily lives.
This article about the Italian Digital Wallet System is a good companion piece, providing insights into the goals of the Italian Digital Wallet project. I recommend them both!
The OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 specification has started its 60-day review to become an OpenID Final Specification. Recent steps leading up to this were:
acr” values) defined by the specification, which enabled me to finally register them in the IANA “Level of Assurance (LoA) Profiles” registry. Doing so required me to create two XML Schema Description (XSD) files – something I never thought I’d have to do! Thanks to Leif Johansson for explaining to me how to do that.The specification is glue that ties together OpenID Connect, W3C Web Authentication, and FIDO Authenticators, enabling them to be seamlessly used together.
The two ACR values defined by the specification are:
phr:phrh:The Phishing-Resistant definition dates back 2008!
For the record, the two XSD files that I wrote to get us here are:
As has become traditional, I gave the following presentation at the Monday, April 7, 2025 OpenID Workshop at Google:
I also gave this invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, April 8, 2025:
A significant event in digital identity occurred without fanfare today. Presentation Exchange was removed from the OpenID for Verifiable Presentations specification. It had once-upon-a-time been the only query language used for verifiable credential presentation. In October 2024, the Digital Credential Query Language (DCQL) was added alongside it. Today, after much discussion by the working group, Presentation Exchange was removed, making DCQL the only query language supported. Importantly, this was done before OpenID4VP became a final specification.
Replacing Presentation Exchange (PE) has been a multi-year journey. I’ve been advocating for its replacement for years, including leading two sets of unconference discussions titled “What does Presentation Exchange do and what parts of it do we actually need?” – one in August 2023 at the OAuth Security Workshop and one in October 2023 at the Internet Identity Workshop. These discussions were intended to create awareness of the need to replace PE and start building consensus for its removal. Others also took this position early with me, including Tobias Looker and Oliver Terbu. Daniel Fett and Brian Campbell were receptive to the possibility early as well.
Removing a feature that people had taken a dependency on is not without pain. Numerous prototype wallets and verifiers used parts of it. But that’s the rub. There was so much there in Presentation Exchange that most implementations didn’t use most of it. As a result, interoperability, while possible, was a tricky and sometimes elusive target.
Presentation Exchange was ambitious in scope. It was a Swiss Army Knife of a specification. A goal was to enable complex queries for multiple credentials based on a general-purpose query language intended to be able to be used over credentials represented in JSON in any way. You could even include attributes of credentials other just their claims in the queries, such as algorithms and formats. You could ask for 2 of this or 3 of that and one or more of the following, as long as it is in format X, Y, or Z. It didn’t follow one of my guiding standards principles: “Keep simple things simple.” As a result, negative feedback from implementers grew over time.
Now we have a purpose-built query language designed for the task and protocol at hand. Is it as simple as it could be? No. Are all the features motivated by real-world non-hypothetical use cases? Yes.
The creation of DCQL was led by Daniel Fett. A precursor query language that helped inform DCQL was created by Oliver Terbu, Tobias Looker, and myself. Discussions at the Internet Identity Workshop informed what became DCQL, as did discussions at the IDUnion hackathon in Nürnberg in 2024 that included Kristina Yasuda, Christian Bormann, and Paul Bastian.
You can see OpenID4VP when PE was the only query language, when it had both query languages, and now with only DCQL. Compare for yourself.
Let me close by saying that I respect the people who created Presentation Exchange to a person. I count many of them as friends. They took a complex multi-faceted problem and wrapped their arms around it, producing a concrete solution. Much can be said in favor of those who pick up the pen and dare to create. Much was learned from what they produced, and it helped bootstrap an emerging industry. We wouldn’t be where we are today, were it not for their pioneering efforts!
In the end, the removal happened unceremoniously, with the merge of a pull request, like so many other changes – nearly anticlimactic. But this one marks a sea change in how credentials are presented. Thanks to all who made this happen!
I didn’t want to let the moment pass without recognizing its significance.
Vladimir Dzhuvinov and I led a discussion on The Cambrian Explosion of OAuth and OpenID Specifications at the 2025 OAuth Security Workshop in Reykjavík.
The abstract for the session was:
The number of OAuth and OpenID specifications continues to grow. At present there are 30 OAuth RFCs, two more in the RFC Editor queue, 13 OAuth working group drafts, and another eight individual OAuth drafts that may advance. There are nine JOSE RFCs and seven working group drafts. There are four SecEvent RFCs. On the OpenID side, there are 12 final OpenID Connect specs, three final FAPI specs, one final MODRNA spec, three final eKYC-IDA specs, and 24 Implementer’s drafts across the OpenID working groups, plus another ten working group drafts.
The number of possible combinations boggles the mind. And there’s no end in sight!
What’s a developer to do? How have people and companies gone about selecting and curating the specs to implement in an attempt to create coherent and useful open source and commercial offerings? And faced with such an array of combinations and choices, how are application developers to make sense of it all? How can interoperability be achieved in the face of continued innovation?
This session will prime the pump by discussing choices made by some existing open source and commercial offerings in the OAuth and OpenID space and lead to an open discussion of choices made by the workshop attendees and the reasoning behind them. It’s our goal that useful strategies emerge from the discussion that help people grapple with the ever-expanding sets of specifications and make informed implementation choices, while still fostering the innovation and problem-solving that these specifications represent.
The slides used to queue up the discussion session are available as PowerPoint and PDF. Also, see the list of 101 OAuth and OpenID-related specifications referenced during the discussion.
The topic seems to have touched a chord. Many people were clearly already thinking about the situation and shared their views. Some of them were:
Thanks to the organizers for a great tenth OAuth Security Workshop! And special thanks to the colleagues from Signicat who did a superb job with local arrangements in Reykjavík!
Kim Cameron first told me what Digital Identity is on February 1, 2005. He said that the Internet was created without an identity layer. He encouraged me “You should come help build it with me.” I’ve been at it ever since!
What I wrote about digital identity a decade ago remains as true today:
An interesting thing about digital identity is that, by definition, it’s not a problem that any one company can solve, no matter how great their technology is. For digital identity to be “solved”, the solution has to be broadly adopted, or else people will continue having different experiences at different sites and applications. Solving digital identity requires ubiquitously adopted identity standards. Part of the fun and the challenge is making that happen.
I’m not going to even try to list all the meaningful identity and security initiatives that I’ve had the privilege to work on with many of you. But I can’t resist saying that, in my view, OpenID Connect, JSON Web Token (JWT), and OAuth 2.0 are the ones that we knocked out of the park. I tried to distill the lessons learned from many of the initiatives, both successes and failures, during my 2023 EIC keynote Touchstones Along My Identity Journey. And there’s a fairly complete list of the consequential things I’ve gotten to work on in my Standards CV.
I’ll also call attention to 2025 marking twenty years of the Internet Identity Workshop. I attended the first one, which was held in Berkeley, California in October 2005, and all but one since. What a cast of characters I met there, many of whom I continue working with to this day!
As a personal testament to the value of IIW, it’s where many of the foundational decisions about what became JWS, JWE, JWK, JWT, and OpenID Connect were made. Particularly, see my post documenting decisions made at IIW about JWS, including the header.payload.signature representation of the JWS Compact Serialization and the decision to secure the Header Parameters. And see the posts following it on JWE decisions, naming decisions, and JWK decisions. IIW continues playing the role of enabling foundational discussions for emerging identity technologies today!
It’s been a privilege working with all of you for these two decades, and I love what we’ve accomplished together! There’s plenty of consequential work under way and I’m really looking forward to what comes next.
Images are courtesy of Doc Searls. Each photo links to the original.
I’m writing to highly recommend the article “How to link an application protocol to an OpenID Federation 1.0 trust layer” by Vladimir Dzhuvinov. In it, he defines two kinds of integrity for Federations, and describes how to achieve them:
This ensures mutual trust between two entities is established always from a common trust anchor. Any resolved metadata and policies that govern the client application and the OpenID provider in a transaction will then fall under the rules of the same federation and thus will be aligned and consistent with one another.
It ensures the trust chains for an entity to a given trust anchor will invariably result in consistent metadata and policies. The natural way to achieve this is for the federation topology under a trust anchor to form a tree. Topologies that lead to multiple paths from a leaf entity to a trust anchor are to be avoided.
The article also explores how application protocols, such as OpenID Connect or digital wallet protocols, can achieve those properties in practice (and when they do and don’t need to).
Finally, I’ll note that, as a result of Vladimir’s and others’ thinking about the topic, we just added a section on Federation Topologies to the OpenID Federation specification, which provides concrete guidance on how to achieve Metadata Integrity.
I’ll stop here so as not to repeat all the useful content in Vladimir’s article. By all means, give it read!
The OpenID Connect working group recently adopted three new specifications that build upon and provide new capabilities to OpenID Federation. But I’m not only happy about these because of the engineering benefits they bring.
I’m particularly happy because they bring new active contributors to the work, specifically Michael Fraser and Łukasz Jaromin, as well as continuing the strong work by Giuseppe De Marco, who’s become a leader in the space. They’re also supported by a few veterans: Roland Hedberg, John Bradley, and yours truly, plus now the full OpenID Connect working group.
Here’s the three new specifications, along with an abstract for each of them:
1. OpenID Federation Extended Subordinate Listing
This specification acts as an extension to OpenID Federation 1.0. It outlines methods to interact with a given Federation with a potentially large number of registered Entities, as well as mechanisms to retrieve multiple entity statements along with associated details in a single request.
2. OpenID Federation Wallet Architectures
As digital wallets become increasingly deployed for managing identity credentials, establishing an architecture for trusted communication is required to allow each participant in the ecosystem to evaluate other participants’ compliance with mutual trust frameworks and accomplish secure and trusted transactions.
This specification defines how to use OpenID Federation 1.0 to enhance the security and interoperability of wallet ecosystems, facilitating trust establishment among the parties and enabling secure metadata exchange and policy application across large scale deployments. It outlines the general architecture of a federated trust infrastructure for wallet ecosystems, identifying participant roles and describing the use of those roles.
3. OpenID Connect Relying Party Metadata Choices
This specification extends the OpenID Connect Dynamic Client Registration 1.0 specification to enable RPs to express a set of supported values for some RP metadata parameters, rather than just single values. This functionality is particularly useful when Automatic Registration, as defined in OpenID Federation 1.0, is used, since there is no registration response from the OP to tell the RP what choices were made by the OP. This gives the OP the information that it needs to make choices about how to interact with the RP in ways that work for both parties.
Thanks to the members of the OpenID Connect working group who helped refine them before adoption, and are now working on progressing them in the working group.
Powered by WordPress & Theme by Anders Norén