Musings on Digital Identity

Category: Federation Page 1 of 3

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!

Touchstones Along My Identity Journey

EIC 2023 LogoI had the distinct honor of being invited to give a keynote talk at EIC 2023. The result was Touchstones Along My Identity Journey. My talk abstract was:

In 2005, Kim Cameron excitedly told me about digital identity and set my life on a course to “Build the Internet’s missing identity layer”. In this talk I’ll tell key stories from my identity journey — stories of the people, ideas, and lessons learned along the way. I’ll speak of technology and collaboration, usability and business models, solving problems people actually have, and building new ecosystems. Come with me on this journey of exploration, trials, triumphs, and humor as I recount touchstones of the human endeavor that is digital identity.

Kuppinger Cole has posted a video of my keynote on YouTube. I was pleased with how well it went. After the first few sentences, I was in the zone! I hope many of you find the messages in the talk useful.

My slides are also available in (PowerPoint) and PDF.

Special thanks go to the OpenID Foundation for supporting my trip to EIC this year and to designer Alistair Kincaid at MATTR for helping me transcend my usual black-bulleted-text-on-a-white-background presentation style!

EIC 2023 Keynote Photo

EIC 2023 Keynote Photo with Kim Cameron

EIC 2023 Keynote Photo for OAuth

How do you know who to trust?

EIC 2023 LogoGiuseppe De Marco and I presented the session How do you know who to trust? at EIC 2023.

A key question when granting access to resources is ‘Who do you trust?’. It’s often important to know who the party is that you’re interacting with and whether they’ve agreed to the terms and conditions that apply when accessing a resource.

OpenID Connect enables identities of participants to be securely established but doesn’t answer the question of whether a participant is trusted to access a resource such as your personal data. A complementary mechanism is needed to do that. In small-scale and static deployments, it’s possible to keep a list of the trusted participants. However, in large-scale and dynamic deployments, that doesn’t scale.

This presentation described how the OpenID Connect Federation protocol enables scalable trust establishment with dynamic policies. It does so by employing trust hierarchies of authorities, each of which are independently administered. Examples of authorities are federation operators, organizations, departments within organizations, and individual sites.

Two OpenID Connect Federations are deployed in Italy, enabling secure access to digital services operated by Italian public and private services with Italian digital identities. This presentation described why OpenID Connect Federation was selected for them and how it meets their needs. OpenID Connect Federation is also being used by the GAIN PoC.

Our presentation is available in (PowerPoint) and PDF.

EIC 2023 Federation Photo

OpenID Connect Federation updated in preparation for third Implementer’s Draft review

OpenID logoThe OpenID Connect Federation specification has been updated to add Security Considerations text. As discussed in the recent OpenID Connect working group calls, we are currently reviewing the specification in preparation for it becoming the third and possibly last Implementer’s Draft.

Working group members (and others!) are encouraged to provide feedback on the draft soon before we start the foundation-wide review. We will probably decide next week to progress the draft to foundation-wide review. In particular, there’s been interest recently in both Entity Statements and Automatic Registration among those working on Self-Issued OpenID Provider extensions. Reviews of those features would be particularly welcome.

The updated specification is published at:

Special thanks to Roland Hedberg for the updates!

OpenID Connect Federation Keynote at January 2020 OpenID Japan Summit

OpenID logoI gave this keynote presentation at the January 2020 OpenID Japan Summit: Enabling Large-Scale Multi-Party Federations with OpenID Connect. View it in PowerPoint or PDF.

Thanks to Roland Hedberg for collaborating on the presentation with me and for being primary author of the OpenID Connect Federation specification.

And as a preview of coming attractions, I’ll also be presenting on OpenID Connect Federation at Identiverse in June 2020.

OpenID Connect Federation draft 09 ready for your review

OpenID logoDraft 09 of the OpenID Connect Federation specification has been published at https://openid.net/specs/openid-connect-federation-1_0-09.html. This version of the specification benefitted from in-person review by experts at IIW. Major changes were:

  • Separated entity configuration discovery from operations provided by the federation API.
  • Defined new authentication error codes.

The authors believe that this version should become the second Implementer’s Draft, in preparation for interop testing in the coming year. Please review!

OpenID Connect Federation Progress at TNC19

OpenID logoCheck out the post OpenID Connect Federation Progress describing the recent updates that Roland Hedberg and I made to the OpenID Connect Federation 1.0 specification. We used the TNC19 conference — a gathering of federation experts — as a venue to get together to review and refine the specification. Besides getting lots done on the spec, I also really enjoyed the TNC conference and its attendees!

Given that the syntax and semantics should now be stable, it’s my hope that early adopters will start kicking the tires — building implementations and making trial deployments. I can’t wait for the useful feedback that results!

OpenID Connect Federation Specification

OpenID logoThe OpenID Connect Federation 1.0 specification is being developed to enable large-scale federations to be deployed using OpenID Connect. It enables trust among federation participants to be established through signed statements made by federation operators about federation participants.

The design of this specification builds upon the experiences gained in operating large-scale SAML 2.0 federations, and indeed, is authored by people having practical experience with these federations. The primary authors are Roland Hedberg and Andreas Ã’¦kre Solberg, with additional contributions by Samuel Gulliksson, John Bradley, and myself, as well as members of the OpenID Connect working group, which is the home of the specification.

A key innovation that differentiates OpenID Connect federations from most SAML 2.0 federations is that OpenID Connect federation employs hierarchal metadata, where participants directly publish statements about themselves, versus the aggregated metadata approach used by many SAML 2.0 federations, where the federation operator publishes a single file concatenating all the metadata for all the federation participants.

The specification was just updated so that the latest version can be discussed at a SURFnet OpenID Connect “Wisdom of the Crowd” session today.

The latest version of specification is available at:

This URL always points to the latest published version:

Please review and/or implement this important specification and send your feedback to the OpenID Connect working group!

What Does Logout Mean?

OAuth logoDigital identity systems almost universally support end-users logging into applications and many also support logging out of them. But while login is reasonable well understood, there are many different kinds of semantics for “logout” in different use cases and a wide variety of mechanisms for effecting logouts.

I led a discussion on the topic “What Does Logout Mean?” at the 2018 OAuth Security Workshop in Trento, Italy, which was held the week before IETF 101, to explore this topic. The session was intentionally a highly interactive conversation, gathering information from the experts at the workshop to expand our collective understanding of the topic. Brock Allen — a practicing application security architect (and MVP for ASP.NET/IIS) — significantly contributed to the materials used to seed the discussion. And Nat Sakimura took detailed notes to record what we learned during the discussion.

Feedback on the discussion was uniformly positive. It seemed that all the participants learned things about logout use cases, mechanisms, and limitations that they previously hadn’t previously considered.

Materials related to the session are:

OpenID Connect EAP ACR Values specification

OpenID logoThe OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 specification has been submitted to the OpenID Enhanced Authentication Profile (EAP) working group. Per the abstract:

This specification enables OpenID Connect Relying Parties to request that specific authentication context classes be applied to authentications performed and for OpenID Providers to inform Relying Parties whether these requests were satisfied. Specifically, an authentication context class reference value is defined that requests that phishing-resistant authentication be performed and another is defined that requests that phishing-resistant authentication with a hardware-protected key be performed. These policies can be satisfied, for instance, by using W3C scoped credentials or FIDO authenticators.

The specification is glue that ties together OpenID Connect, W3C Web Authentication, and FIDO Authenticators, enabling them to be seamlessly used together.

The specification is available at:

OpenID Connect Back-Channel Logout Specification

OpenID logoA new back-channel OpenID Connect Logout spec has been published at http://openid.net/specs/openid-connect-backchannel-1_0.html. This can coexist with or be used instead of the front-channel-based Session Management and HTTP-Based Logout specifications.

The abstract for the new specification states:

This specification defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out; this differs from front-channel logout mechanisms, which communicate logout requests from the OP to RPs via the User Agent.

This completes publication of the three planned OpenID Connect logout mechanisms: two that communicate on the front-channel through the User Agent (browser) and this one that communicates on the back-channel, without involving the User Agent. See the Introduction for a discussion of the upsides and downsides of the different logout approaches. As much as we’d like there to be a single logout solution, both experience and extensive discussions led us to the conclusion that there isn’t a feasible one-size-fits-all approach.

Reviews of the new (and existing!) specifications are welcomed.

Thanks to John Bradley, Pedro Felix, Nat Sakimura, Brian Campbell, and Todd Lainhart for their contributions to the creation of the specification.

HTTP-Based OpenID Connect Logout Spec

OpenID logoA new HTTP-Based OpenID Connect Logout spec has been published at http://openid.net/specs/openid-connect-logout-1_0.html. This can coexist with or be used instead of the current HTML postMessage-based Session Management Spec.

The abstract for the new spec states:

This specification defines an HTTP-based logout mechanism that does not need an OpenID Provider iframe on Relying Party pages. Other protocols have used HTTP GETs to RP URLs that clear cookies and then return a hidden image or iframe content to achieve this. This specification does the same thing. It also reuses the RP-initiated logout functionality specified in Section 5 of OpenID Connect Session Management 1.0 (RP-Initiated Logout).

Special thanks to Brian Campbell, Torsten Lodderstedt, and John Bradley for their insights that led to some of the decisions in the spec.

Growing list of OpenID Connect libraries available

OpenID logoAs described in today’s openid.net post, a growing list of OpenID Connect and JWT/JOSE libraries are available. Check them out at http://openid.net/developers/libraries/.

OpenID Connect Specifications are Final!

OpenID logoThe OpenID Connect Core, OpenID Connect Discovery, OpenID Connect Dynamic Registration, and OAuth 2.0 Multiple Response Types specifications are now final! These are the result of almost four years of intensive work, both by specification writers including myself, and importantly, by developers who built, deployed, and interop tested these specifications throughout their development, significantly improving the quality of both the specs and their implementations as a result.

Throughout the development of OpenID Connect, we applied the design philosophy “keep simple things simple”. While being simple, OpenID Connect is also flexible enough to enable more complex things to be done, when necessary, such as encrypting claims, but this flexibility doesn’t come at the cost of keeping simple things simple. Its simplicity is intended to make it much easier for deployers to adopt than previous identity protocols. For instance, it uses straightforward JSON/REST data structures and messages, rather than XML/SOAP or ASN.1.

I want to take this opportunity to thank several key individuals without whose enthusiastic participation and expertise OpenID Connect wouldn’t have come into being. Nat Sakimura and John Bradley were there every step of the way, both motivating the features included and providing their insights into how to make the result both highly secure and very usable. Breno de Medeiros and Chuck Mortimore were also key contributors, bringing their practical insights informed by their implementation and deployment experiences throughout the process. I want to acknowledge Don Thibeau’s leadership, foresight, wisdom, and perseverance in leading the OpenID Foundation throughout this effort, bringing us to the point where today’s completed specifications are a reality. Numerous people at Microsoft deserve credit for believing in and supporting my work on OpenID Connect. And finally, I’d like to thank all the developers who built OpenID Connect code, told us what they liked and didn’t, and verified that what was specified would actually work well for them in practice.

Of course, final specifications are really just the beginning of the next journey. I look forward to seeing how people will use them to provide the Internet’s missing identity layer, making people’s online experiences, both on the Web and on their devices, easier, safer, and more satisfying!

Vote to Approve Final OpenID Connect Specifications Under Way

OpenID logoThe vote to approve final OpenID Connect Core, OpenID Connect Discovery, OpenID Connect Dynamic Registration, and OAuth 2.0 Multiple Response Types specifications is now under way, as described at http://openid.net/2014/02/11/vote-for-final-openid-connect-specifications-and-implementers-drafts-is-open/. The OpenID Connect Session Management and OAuth 2.0 Form Post Response Mode specifications are also being approved as Implementer’s Drafts. Voting closes on Tuesday, February 25, 2014.

Please vote now!

Public review of proposed Final OpenID Connect Specifications has begun

OpenID logoI’m thrilled that OpenID Connect is significantly closer to being done today. Proposed final specifications were published yesterday and the 60 day public review period, which leads up a membership vote to approve the specifications, began today. Unless recall-class issues are found during the review, this means we’ll have final OpenID Connect specifications on Tuesday, February 25, 2014!

My sincere thanks to all of you who so generously shared your vision, expertise, judgment, and time to get us to this point — both those of you who worked on the specs and those who implemented and deployed them and tested your code with one another. I consider myself privileged to have done this work with you and look forward to what’s to come!

Fourth and possibly last Release Candidates for final OpenID Connect specifications and Notice of 24 hour review period

OpenID logoThe fourth and possibly last set of release candidates for final OpenID Connect specifications is now available. Per the decision on today’s working group call, this message starts a 24 hour final working group review period before starting the 60 day public review period. Unless significant issues are raised during the 24 hour review period, we will announce that these specifications are being proposed as Final Specifications by the working group.

The release candidates for Final Specification status are:

Accompanying release candidates for Implementer’s Draft status are:

Accompanying Implementer’s Guides are:

Third Release Candidates for final OpenID Connect specifications

OpenID logoThe third set of release candidates for final OpenID Connect specifications is now available. The changes since the second release candidates have mostly been to incorporate review comments on the Discovery, Dynamic Registration, and Multiple Response Types specifications. All known review comments have now been applied to the specifications.

The release candidates for Final Specification status are:

Accompanying release candidates for Implementer’s Draft status are:

Accompanying Implementer’s Guides are:

Second Release Candidates for final OpenID Connect specifications

OpenID logoThe second set of release candidates for final OpenID Connect specifications is now available. The updates to these specs since the first set of release candidates are the result of the most extensive reviews that the OpenID Connect specifications have ever undergone — including 10 complete reviews of the OpenID Connect Core spec. Thanks to all of you who helped make these the clearest, easiest to use OpenID Connect specifications ever!

The release candidates for Final Specification status are:

Accompanying release candidates for Implementer’s Draft status are:

Accompanying Implementer’s Guides are:

Please do a final review of the OpenID Connect Core specification now, because the results of all review comments have now been applied to it. A small number of review comments to the other specs remain, and will be addressed in the next few days, at which point a third and hopefully final set of release candidates will be released.

Page 1 of 3

Powered by WordPress & Theme by Anders Norén