Musings on Digital Identity

Category: OpenID Page 1 of 11

The Journey to OpenID Federation 1.0 is Complete

OpenID logoThe final OpenID Federation 1.0 specification was published today. This marks the end of a nearly decade-long journey and the beginning of new ones.

At the 2016 TNC conference, Lucy Lynch challenged Roland Hedberg, saying “If there is someone who should be able to bring the eduGAIN identity federation into the new world of OpenID Connect, it is you.” That was the starting point for the work.

Originally, the specification was titled “OpenID Connect Federation 1.0” and the mission was exactly that – to enable multi-lateral federation when using OpenID Connect. Over time, we realized that the core trust establishment framework defined by the specification could be applied to any protocol and the spec was therefore renamed to “OpenID Federation 1.0”. Indeed, for a while, people had been clamoring to separate the protocol-independent trust establishment framework from the protocol-specific features for OpenID Connect and OAuth 2.0. I made that split after OpenID Federation 1.0 entered final review, and the resulting OpenID Federation 1.1 specifications also entered review for final status today.

Like OpenID Connect, OpenID Federation benefited from multiple rounds of interop testing while it was being developed. Interops were held at NORDUnet 2017, SURFnet 2018, TNC/REFEDS 2019, Internet2/REFEDS 2019, three virtual interops in 2020, SUNET in 2025, and TIIME in 2026. Each time, we listened to the developer feedback and used it to improve the specification.

The early and enthusiastic support from the Research and Education community was foundational. They already knew what a multilateral federation is and why it’s useful. They patiently explained what they needed and why they needed it.

Many people contributed to the journey, but I want to call out the contributions of my co-authors in particular. Andreas Åkre Solberg was an early contributor and the inventor of Automatic Registration, which greatly simplifies deployments. John Bradley brought his practical security and deployment insights to the work. Giuseppe De Marco spearheaded production deployment for multiple Italian national federations and the Italian EUDI Wallet, informing the specification with real-world experience – particularly with the use of Trust Marks. Vladimir Dzhuvinov was an early implementer and brought his rigorous thinking about metadata operators and establishing trust to the effort.

Feedback from early implementations was critical to shaping the protocol. They included those by Authlete, Connect2ID, Raidiam, SimpleSamlPHP, DIGG, Sphereon, SPID/CIE in Italy, Shibboleth, GÉANT, SUNET, SURF, GRNET, eduGAIN/GARR, and of course Roland’s own implementation.

Demand for using OpenID Federation for protocols other than OpenID Connect and OAuth 2.0 informed our thinking as the specification developed. It is used for open finance in Australia. It is used for digital wallets in Italy. It is used for healthcare and national identity in Sweden. Each deployment brought insights to the effort that shaped the result for the better.

A team of security researchers at the University of Stuttgart performed a security analysis of the last implementer’s draft in 2024. They found an actionable security vulnerability applying to multiple protocols that we promptly fixed. Thanks to Dr. Ralf Küsters, Tim Würtele, and Pedram Hosseyni for their substantial contributions both to OpenID Federation and also to OpenID Connect, FAPI, and OAuth 2.0.

Multiple organizations played important roles in supporting this work. Special thanks to GÉANT, Connect2ID, and the SIROS Foundation for their significant financial support and encouragement. Multiple organizations hosted meetings at which significant discussions occurred, including NORDUnet, SUNET, SURF, GÉANT, and Internet2.

While this is the end of the journey for OpenID Federation 1.0, it is equally a step in important journeys under way. Multiple extensions to OpenID Federation are being developed, including OpenID Federation for Wallet Architectures 1.0 and OpenID Federation Extended Subordinate Listing 1.0. These provide important enhancements to the federation framework defined by the core specification needed for particular use cases.

Ecosystem building, adoption, and deployment is always a long journey and one we’re in the midst of. National use cases in Europe and Australia are leading the way.

I am confident that the inherent benefits of the scalable and modular OpenID Federation approach will continue to win adherents the world over. For instance, it is scalable and easily managed in a way that large-scale PKI trust bridges will never be.

Watch this space from more stories from these journeys as they develop!

Finally, my most significant thanks go to my friend and collaborator Roland Hedberg. He did the very hard thing – starting from a blank sheet of paper and on it creating a new, useful, and elegant invention. My sincerest congratulations, Roland! It’s been a privilege to be on this journey with you!

Roland Hedberg

OpenID Federation Interop Event at TIIME 2026 in Amsterdam

OpenID logoImplementers of OpenID Federation gathered at the 2026 Trust and Internet Identity Meeting Europe (TIIME) unconference in Amsterdam on Friday, February 13, 2026 to test their implementations with one another. 12 people with 9 implementations and from 9 countries performed interop tests together. Participants were from Croatia, Finland, Greece, Italy, Netherlands, Poland, Serbia, Sweden, and the US.

The interop was organized by Niels van Dijk of SURF and Davide Vaghetti of GARR. Davide ran the interop, including assembing the test federation with the participants. Giuseppe De Marco’s OpenID Federation Browser was a useful tool for visualizing and understanding the test federation. The test federation remains assembled and I’ve observed that some participants have continued to test with one another in the days since the in-person interop at TIIME.

Here’s some photos and graphics to capture the spirit of the interop.

Davide Running TIIME Interop

OpenID Federation Browser View of GARR Federation

TIIME 2026 Interop Participants

SURF Trust Anchor

Davide Presenting Trust Mark Request

OpenID Federation Presentation at 2026 TIIME Unconference

OpenID logoI had the pleasure of presenting an overview of OpenID Federation during the 2026 Trust and Internet Identity Meeting Europe (TIIME) unconference in Amsterdam. It was the opening talk in a day dedicated to OpenID Federation – Friday, February 13, 2026. There were ~90 practitioners in attendance. They asked great practical questions, including about how to decide what Federations to trust and the use of Trust Marks.

See the deck I used titled “OpenID Federation Overview” (pptx) (pdf).

I’m really looking forward to what I’ll learn during the discussions today. Many deployments are being described, including the GÉANT eduGAIN OpenID Federation pilot. Plus, there’s a “TechHUB” interop event today during which people will test their OpenID Federation implementations with one another.

My Federation Keynote at TIIME 2026

Initial Drafts of 1.1 OpenID Federation Specs

OpenID logoThe OpenID Federation 1.0 specification contains two kinds of functionality:

  1. Protocol-independent federation functionality used for establishing trust and applying policies in multilateral federations, and
  2. Protocol-specific federation functionality that can be used by OpenID Connect and OAuth 2.0 deployments to apply the protocol-independent federation functionality.

At the urging of implementers and working group members, I’ve created new specifications splitting the two kinds of functionality apart. I’m pleased to announce that initial editor’s drafts of both split specifications are now available for your reviewing pleasure. They are:

  1. OpenID Federation 1.1 (protocol-independent)
  2. OpenID Federation for OpenID Connect 1.1 (protocol-specific)

Together, they are equivalent to OpenID Federation 1.0, by design. No functionality is added or removed from that present in 1.0. Rather, it’s factored into protocol-independent and protocol-specific specifications.

Reading every line of the 1.0 spec to perform the split had the additional benefit of identifying editorial improvements to apply to the 1.0 spec before it becomes final. I intentionally started the split while 1.0 is still in the 60-day review to become final exactly so improvements identified could be applied both to the original and the split specs.

As background for this work, several people had suggested splitting the two apart into separate specifications – particularly once the core federation functionality started being used with protocols other than OpenID Connect, such as with digital credentials. There was a discussion about this possibility at the Internet Identity Workshop in the Fall of 2024. During the April 2025 Federation Interop event at SUNET, there was consensus to do the split after finishing OpenID Federation 1.0. Starting the work to perform the split was proposed to both Pacific-friendly and Atlantic-friendly OpenID Connect working group calls in December 2025 after the 60-day review had started, with no opposition to proceeding.

Now it’s your turn! Please review both OpenID Federation 1.0 and the OpenID Federation 1.1 and OpenID Federation for OpenID Connect 1.1 specifications derived from it. Please send any issues found to the OpenID Connect Working Group mailing list, or file GitHub issues in the respective repositories: OpenID Federation 1.0 repository, OpenID Federation 1.1 repository, and OpenID Federation for OpenID Connect 1.1 repository. Please review for both the readability and correctness of the specs and whether you believe aspects of the split should have been done differently. In particular, please consider the examples in Appendix A, which contain both protocol-independent and protocol-specific content.

Hopefully this split will make the OpenID Federation content easier to navigate and understand for those using it and considering it. Happy New Year 2026!


Note: I updated this post on January 20, 2026 to link to the now-released versions of the 1.1 specs, rather than the editors’ drafts. Also, since the initial post, OpenID Connect Federation 1.1 was renamed to OpenID Federation for OpenID Connect 1.1.

OpenID Federation Discussion at 2025 TechEx

OpenID logoI was encouraged by Pål Axelsson to hold an unconference discussion giving an overview of OpenID Federation during the 2025 Internet2 Technology Exchange conference in Denver. So I did so with a receptive and engaged group of participants yesterday, Thursday, December 11, 2025. See the notes from the Thursday session by Phil Smart, which include links to multiple Federation pilots.

Afterwards, several people told me that they were sorry to have missed it. So I reprised the discussion today, Friday, December 12, 2025, with a second equally engaged and mostly non-overlapping set of participants. See the notes from the Friday session by James Cramton, which captures both the breadth of participation and some of the key points made. Mihály Héder from Hungary is prototyping and was particularly engaged.

See the deck I used to queue up discussion points titled “OpenID Federation Overview” (pptx) (pdf).

The participants were some of the world’s experts in multi-lateral federation. It was great spending time with them and learning from them!

Finishing the OpenID Federation 1.0 Specification

OpenID logoThe 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!

Working Group Last Call for OpenID Federation

OpenID logoToday 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…

OpenID Presentations at October 2025 OpenID Workshop and IIW

OpenID logoAs 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:

OpenID Federation draft 44 Incorporating Features Motivated by Swedish Government Use Cases

OpenID logoDraft 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!

Updates to Audience Values for OAuth 2.0 Authorization Servers

OAuth logoA 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:

  • Focused RFC 7523 updates on JWT client authentication case.
  • Described client responsibilities for the audience value of authorization grants. No longer mandate that the audience for authorization grants be the issuer identifier, so as to make a minimum of breaking changes.
  • Deprecated the use of SAML assertions for client authentication.

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.

OpenID Connect RP Metadata Choices is an Implementer’s Draft

OpenID logoI’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!

Final OpenID Connect EAP ACR Values Specification

OpenID logoThe 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:
    Phishing-Resistant. An authentication mechanism where a party potentially under the control of the Relying Party cannot gain sufficient information to be able to successfully authenticate to the End User’s OpenID Provider as if that party were the End User. (Note that the potentially malicious Relying Party controls where the User-Agent is redirected to and thus may not send it to the End User’s actual OpenID Provider). NOTE: These semantics are the same as those specified in [OpenID.PAPE].
  • phrh:
    Phishing-Resistant Hardware-Protected. An authentication mechanism meeting the requirements for phishing-resistant authentication above in which additionally information needed to be able to successfully authenticate to the End User’s OpenID Provider as if that party were the End User is held in a hardware-protected device or component.

The AMR value defined by the specification is:

  • pop:
    Proof-of-possession of a key. Unlike the existing 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.

OpenID Federation draft 43 Incorporating Feedback from Interop Event

OpenID logoDraft 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 of JSON Web Token (JWT) and Preparing for the Future

IETF logoTen 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:

  • RFC 7515: JSON Web Signature (JWS)
  • RFC 7516: JSON Web Encryption (JWE)
  • RFC 7517: JSON Web Key (JWK)
  • RFC 7518: JSON Web Algorithms (JWA)
  • RFC 7519: JSON Web Token (JWT)
  • RFC 7520: Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)
  • RFC 7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
  • RFC 7522: Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
  • RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

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!

Essential Moments in the OAuth and OpenID Timeline

OpenID logoOAuth logoDuende 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.

OpenID Federation Interop Event at SUNET in Stockholm

OpenID logoAt 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.

In-Person Participants at SUNET

Logos of Participating Organizations

Roland Hedberg

OpenID Federation Browser View of KIT Federation

Celebrating in Stockholm

So you want to use Digital Credentials? You’re now facing a myriad of choices!

EIC 2025 LogoI 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.

EIC 2025 Andrew Nash

Thought Experiment on Trust Establishment

Will people be able to use it and want to?

Standards Are About Making Choices

Thank You to SIROS

Mike Jones Candid

Five Million Italian Digital Wallet Users

OpenID logoMy 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!

Finishing the OpenID Connect EAP ACR Values specification

OpenID logoThe 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:

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:
    Phishing-Resistant. An authentication mechanism where a party potentially under the control of the Relying Party cannot gain sufficient information to be able to successfully authenticate to the End User’s OpenID Provider as if that party were the End User. (Note that the potentially malicious Relying Party controls where the User-Agent is redirected to and thus may not send it to the End User’s actual OpenID Provider). NOTE: These semantics are the same as those specified in [OpenID.PAPE].
  • phrh:
    Phishing-Resistant Hardware-Protected. An authentication mechanism meeting the requirements for phishing-resistant authentication above in which additionally information needed to be able to successfully authenticate to the End User’s OpenID Provider as if that party were the End User is held in a hardware-protected device or component.

The Phishing-Resistant definition dates back 2008!

For the record, the two XSD files that I wrote to get us here are:

OpenID Presentations at April 2025 OpenID Workshop and IIW

OpenID logoAs 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:

Page 1 of 11

Powered by WordPress & Theme by Anders Norén