Musings on Digital Identity

Category: Federation Page 1 of 4

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

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!

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!

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!

Integrity Properties for Federations

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

  • Federation Integrity, which is defined as:
  • 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.

  • Metadata Integrity, which is defined as:
  • 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!

Three New Specs Enhancing OpenID Federation and New Contributors

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

Fourth and Likely Last Implementer’s Draft of OpenID Federation Specification

OpenID logoThe OpenID Foundation has approved the Fourth Implementer’s Draft of the OpenID Federation Specification. This is a major step towards having the specification become final.

The previous Implementer’s Draft was in 2021. A lot has happened since then, largely motivated by feedback from actual implementations and deployments. Some highlights of progress made in the spec since then are:

  • Changed name from OpenID Connect Federation to OpenID Federation, since Federation can be used for trust establishment for any protocol (including OpenID Connect).
  • Introduced distinct Federation endpoints.
  • Clearly defined and consistently used the terms Entity Statement, Entity Configuration, and Subordinate Statement.
  • Clearly defined which claims can occur in which kinds of Entity Statements.
  • Clearly defined Entity Types and the Federation Entity entity type.
  • Enhanced description of Trust Mark issuance and usage.
  • Defined relationship between metadata and metadata policy.
  • Clearly defined interactions between policy operators.
  • Defined where constraints may occur.
  • Tightened descriptions of Automatic Registration and Explicit Registration.
  • Added Historical Keys.
  • Defined and used trust_chain JWS Header Parameter.
  • Allowed Trust Chains to start with non-Trust Anchors.
  • Clarified use of client authentication.
  • Used OAuth Protected Resource Metadata.
  • Consistent error handling.
  • Added General-Purpose JWT Claims section.
  • Comprehensive use of content types and media types.
  • IANA registration of parameters, claims, and media types.
  • Added and improved many diagrams.
  • Substantial rewrites for increased consistency and clarity.
  • Added Giuseppe De Marco and Vladimir Dzhuvinov as editors.

As a preview of coming attractions, I’ll note that profiles of OpenID Federation are being written describing how it being used in wallet ecosystems and how it is being used in open finance ecosystems. And we’re creating a list of implementations. Watch this space for future announcements.

Special thanks to all the implementers and deployers who provided feedback to get us to this point!

Celebrating Ten Years of OpenID Connect at Identiverse and EIC

EIC 2024 LogoIdentiverse LogoWe held the second and third of the three planned tenth anniversary celebrations for the completion of OpenID Connect at the 2024 Identiverse conference and European Identity and Cloud Conference. That concludes celebrations in Asia, the Americas, and Europe!

At both Identiverse and EIC, panelists included Nat Sakimura, John Bradley, and myself. Chuck Mortimore joined us at Identiverse. And Torsten Lodderstedt added his perspectives at EIC. We shared our perspectives on what led to OpenID Connect, why it succeeded, and what lessons we learned along the way.

The most common refrain throughout our descriptions was the design philosophy to “Keep simple things simple”. This was followed closely by the importance of early feedback from developers and deployers.

Chuck reached back in time to his OpenID slides from 2011. He reflected on what he was thinking at the time versus what actually happened (and why). Torsten pointed out the importance of cooperation, certification, security analysis, open standards, and an approachable community. At Identiverse, Nat reached back 25 years, examining the intellectual underpinnings and history of OpenID. And at EIC, Nat tackled assertions that OpenID Connect can be complex. John concluded by observing that the OpenID idea is greater than any particular specification.

Our recent OpenID Connect 10th anniversary sessions were:

They build upon the celebration at the OpenID Summit Tokyo 2024.

Thanks to the organizers of all these events for sponsoring the celebrations!

Proposed Implementer’s Draft of OpenID Federation

OpenID logoThe OpenID Connect working group has started working group last call (WGLC) for a proposed Implementer’s Draft of the OpenID Federation specification. As described in the WGLC message:

OpenID Federation -35 has been published at https://openid.net/specs/openid-federation-1_0-35.html and https://openid.net/specs/openid-federation-1_0.html. This draft is being proposed as the fourth (and hopefully final) Implementer’s Draft of the specification.

An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification. The two-week working group last call ends on Friday, May 31, 2024. Unless reasons are identified during the last call to substantially revise the specification, the 45-day OpenID Foundation-wide review of the specification for approval as an OpenID Implementer’s Draft will shortly follow.

Special thanks to all the implementers and deployers who provided feedback to get us to this point!

OpenID Federation Session at April 2024 IIW

OpenID logoJohn Bradley and I convened a session on Trust Establishment with OpenID Federation at the Internet Identity Workshop (IIW) on Thursday, April 18, 2024. The material used to drive the discussion was:

The session was well attended and the discussion lively. Numerous people with trust establishment problems to solve contributed, including experts from the SAML federation world, people involved in digital wallet projects, and several people already using or considering using OpenID Federation. Thanks to all who participated!

Continued refinement: OpenID Federation draft 33 published

OpenID logoOpenID Federation draft 33 has been published at https://openid.net/specs/openid-federation-1_0-33.html and https://openid.net/specs/openid-federation-1_0.html. The working group continues refining the specification to make it more consistent and easier to read and implement.

We published draft 33 now to get these improvements out to implementers. Per the history entries at https://openid.net/specs/openid-federation-1_0-33.html#name-document-history, a summary of changes made in -32 and -33 is:

-33:

  • Addressed #2111: The metadata_policy_crit claim MAY only appear in Subordinate Statements and its values apply to all metadata_policies found in the Trust Chain.
  • Fixed #2096: Authorization Signed Request Object may contain trust_chain in its payload and should not in its JWS header parameters.
  • Strengthen language requiring client verification with automatic registration.
  • Fixed #2076: Promoted Trust Marks to be a top-level section.
  • Added General-Purpose JWT Claims section.
  • Moved Federation Endpoints section before Obtaining Federation Entity Configuration Information section.
  • Fixed #2110: Explanation text when multiple entity_type parameters are provided in the Subordinate Listing endpoint.
  • Fixed #2112, #2113, and #2114: Defined that client authentication is not used by default and that the default client authentication method, when used, is private_key_jwt. Specified that requests using client authentication use HTTP POST.
  • Fixed #2104: Allow trust marks in Subordinate Statements for implementation profiles that might want this.
  • Fixed #2103: Addressed ambiguities in the definition of constraints.

-32:

  • Tightened OpenID Connect Client Registration section.
  • Tightened appendix examples.
  • Fixed #2075: Trust Mark endpoint for the provisioning of the Trust Marks.
  • Fixed #2085: Trust Marked Entities Listing, added sub URL query parameter.
  • Made fetch issuer unambiguous by making the iss parameter REQUIRED.
  • Introduced the term “Subordinate Statement” and applied it throughout the specification. Also consistently use the term “registration Entity Statement” for Explicit Client Registration results.
  • Clarified where Entity Statement claims can and cannot occur.
  • Renamed policy_language_crit to metadata_policy_crit.
  • Fixed #2093: Numbered the list defining the order policy operators are applied in.

Special thanks to Stefan Santesson for his thorough review of the specification in the context of the Swedish Federation deployment!

Invited OpenID Federation Presentation at 2024 FIM4R Workshop

OpenID logoThe OpenID Federation editors were invited to give a presentation on OpenID Federation at the 18th FIM4R Workshop, which was held at the 2024 TIIME Unconference. Giuseppe De Marco, Roland Hedberg, John Bradley, and I tag-teamed the presentation, with Vladimir Dzhuvinov also participating in the Q&A. Topics covered included motivations, architecture, design decisions, capabilities, use cases, history, status, implementations, and people.

Here’s the material we used:

It was the perfect audience – chock full of people with practical federation deployment experience!

Celebrating Ten Years of OpenID Connect at the OpenID Summit Tokyo 2024

OpenID logoWe held the first of three planned tenth anniversary celebrations for the completion of OpenID Connect at the OpenID Summit Tokyo 2024. The four panelists were Nov Matake, Ryo Ito, Nat Sakimura, and myself. We shared our perspectives on what led to OpenID Connect, why it succeeded, and what lessons we learned along the way.

The most common refrain throughout our descriptions was the design philosophy to “Keep simple things simple”. I believe that three of the four of us cited it.

I recounted that we even had a thought experiment used to make the “Keep simple things simple” principle actionable in real time: the “Nov Matake Test”. As we considered new features, we’d ask ourselves “Would Nov want to add it to his implementation?” And “Is it simple enough that he could build it in a few hours?”

The other common thread was the criticality of interop testing and certification. We held five rounds of interop testing before finishing the specifications, with the specs being refined after each round based on the feedback received. The early developer feedback was priceless – much of it from Japan!

Our OpenID Connect 10th anniversary presentations were:

Thanks to the OpenID Foundation Japan for the thought-provoking and enjoyable OpenID Summit Tokyo 2024!

Panel in Tokyo

The Nov Matake Test

25 Years of OpenID

There Came Mike Jones

Ten Years of OpenID Connect and Looking to the Future

OpenID logoTen years ago today the drafts that would be approved as the final OpenID Connect specifications were published, as announced in my post Fourth and possibly last Release Candidates for final OpenID Connect specifications and Notice of 24 hour review period.

The adoption of OpenID Connect has exceeded our wildest expectations. The vast majority of federated signins to sites and applications today use OpenID Connect. Android, AOL, Apple, AT&T, Auth0, Deutsche Telekom, ForgeRock, Google, GrabTaxi, GSMA Mobile Connect, IBM, KDDI, Microsoft, NEC, NRI, NTT, Okta, Oracle, Orange, Ping Identity, Red Hat, Salesforce, Softbank, Symantec, T-Mobile, Telefónica, Verizon, Yahoo, and Yahoo! Japan, all use OpenID Connect, and that’s just the tip of the iceberg. While OpenID Connect is “plumbing” and not a consumer brand, it’s filling a need and doing it well.

It’s fitting that the second set of errata corrections to the OpenID Connect specifications were just approved, as described in the post Second Errata Set for OpenID Connect Specifications Approved. While we are proud of the quality of the final specifications, with 9 3/4 years of thousands of developers using and deploying the specifications, it’s unsurprising that issues would be found that needed clarification and correction.

The updated OpenID Connect specifications have just been submitted to the International Organization for Standardization (ISO) for Publicly Available Submission (PAS) status. Approved PAS submissions are published as ISO specifications. This will foster adoption in jurisdictions that require using standards that are published by organizations with international treaty status.

Celebrations of the tenth anniversary of the approval of OpenID Connect will occur worldwide in 2024. The first will be in Asia at the OpenID Summit Tokyo in January. The second will be in the Americas at Identiverse in May. The third will be in Europe at the European Identity and Cloud Conference in June. Join us at these events for the celebrations!

I can’t wait to see what the next decade brings for OpenID Connect!

On the journey to an Implementer’s Draft: OpenID Federation draft 31 published

OpenID logoOpenID Federation draft 31 has been published at https://openid.net/specs/openid-federation-1_0-31.html and https://openid.net/specs/openid-federation-1_0.html. It’s the result of concerted efforts to make the specification straightforward to read, understand, and implement for developers. Many sections have been rewritten and simplified. Some content has been reorganized to make its structure and relationships more approachable. Many inconsistencies were addressed.

Some inconsistencies fixed resulted in a small number of breaking changes. For instance, the name “trust_mark_owners” is now consistently used throughout, whereas an alternate spelling was formerly also used. The editors tried to make all known such changes in this version, so hopefully this will be the last set of breaking changes. We published draft 31 now in part to get these changes out to implementers. See the history entries at https://openid.net/specs/openid-federation-1_0-31.html#name-document-history for a detailed description of the changes made.

A comprehensive review of the specification is still ongoing. Expect more improvements in the exposition in draft 32. With any luck, -32 will be the basis of the next proposed Implementer’s Draft.

We’re definitely grateful for all the useful feedback we’re receiving from developers. Developer feedback is gold!

The Key Is Not Enough! – OpenID Connect Federation at OSW 2023

OAuth Security WorkshopVladimir Dzhuvinov gave the innovative and informative presentation “The Key Is Not Enough!” on OpenID Connect Federation at the 2023 OAuth Security Workshop in London. This action thriller of a presentation covers history, goals, mechanisms, status, deployments, and possible futures of the work. The comparisons between X.509 certificates and Federation Trust Infrastructure are particularly enlightening!

Page 1 of 4

Powered by WordPress & Theme by Anders Norén