Thanks to all who helped us reach this important milestone! This was originally announced on the OpenID blog. These now Final specifications are:
Don’t just sign in. Also sign out!
The JWK Thumbprint URI specification has been published as RFC 9278. Congratulations to my co-author, Kristina Yasuda, on the publication of her first RFC!
The abstract of the RFC is:
This specification registers a kind of URI that represents a JSON Web Key (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs.
The need for this arose during specification work in the OpenID Connect working group. In particular, JWK Thumbprint URIs are used as key identifiers that can be syntactically distinguished from other kinds of identifiers also expressed as URIs in the Self-Issued OpenID Provider v2 specification.
Kristina Yasuda and I have published a new JWK Thumbprint URI draft that addresses the IETF Last Call comments received. Changes made were:
The specification is available at:
I gave the following presentations at the Monday, April 25, 2022 OpenID Workshop at Google:
I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, April 26, 2022:
Kristina Yasuda and I have published an updated JWK Thumbprint URI draft that addresses the OAuth Working Group Last Call (WGLC) comments received. Changes made were:
The specification is available at:
The IETF OAuth working group has adopted the JWK Thumbprint URI specification. The abstract of the specification is:
This specification registers a kind of URI that represents a JSON Web Key (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs.
The need for this arose during specification work in the OpenID Connect working group. In particular, JWK Thumbprint URIs are used as key identifiers that can be syntactically distinguished from other kinds of identifiers also expressed as URIs in the Self-Issued OpenID Provider v2 specification.
Given that the specification does only one simple thing in a straightforward manner, we believe that it is ready for working group last call.
The specification is available at:
As requested by the chairs during today’s OAuth Virtual Office Hours call, Kristina Yasuda and I have updated the JWK Thumbprint URI specification to enhance the description of the motivations for the specification. In particular, it now describes using JWK Thumbprint URIs as key identifiers that can be syntactically distinguished from other kinds of identifiers also expressed as URIs. It is used this way in the Self-Issued OpenID Provider v2 specification, for instance. No normative changes were made.
As discussed on the call, we are requesting that that the chairs use this new draft as the basis for a call for working group adoption.
The specification is available at:
I had a fabulous time talking with my friend Vittorio Bertocci while recording the podcast Identity, Unlocked: OpenID Connect with Mike Jones. We covered a lot of ground in 43:29 – protocol design ground, developer ground, legal ground, and just pure history.
As always, people were a big part of the story. Two of my favorite parts are talking about how Kim Cameron brought me into the digital identity world to build the Internet’s missing identity layer (2:00-2:37) and describing how we applied the “Nov Matake Test” when thinking about keeping OpenID Connect simple (35:16-35:50).
Kim, I dedicate this podcast episode to you!
I gave the following presentations at the Thursday, December 9, 2021 OpenID Virtual Workshop:
The JSON Web Key (JWK) Thumbprint specification [RFC 7638] defines a method for computing a hash value over a JSON Web Key (JWK) [RFC 7517] and encoding that hash in a URL-safe manner. Kristina Yasuda and I have just created the JWK Thumbprint URI specification, which defines how to represent JWK Thumbprints as URIs. This enables JWK Thumbprints to be communicated in contexts requiring URIs, including in specific JSON Web Token (JWT) [RFC 7519] claims.
Use cases for this specification were developed in the OpenID Connect Working Group of the OpenID Foundation. Specifically, its use is planned in future versions of the Self-Issued OpenID Provider v2 specification.
The specification is available at:
I described the relationship between OpenID and FIDO during the October 21, 2021 FIDO Alliance plenary meeting, including how OpenID Connect and FIDO are complementary. In particular, I explained that using WebAuthn/FIDO authenticators to sign into OpenID Providers brings phishing resistance to millions of OpenID Relying Parties without them having to do anything!
The presentation was:
I’ve defined an Authentication Method Reference (AMR) value called “pop” to indicate that Proof-of-possession of a key was performed. Unlike the existing “hwk” (hardware key) and “swk” (software key) methods, it is intentionally unspecified whether the proof-of-possession key is hardware-secured or software-secured. Among other use cases, this AMR method is applicable whenever a WebAuthn or FIDO authenticator are used.
The specification is available at these locations:
Thanks to Christiaan Brand for suggesting this.
I gave the following invited “101” session presentation at the 33rd Internet Identity Workshop (IIW) on Tuesday, October 12, 2021:
The session was well attended. There was a good discussion about the use of passwordless authentication with OpenID Connect.
I gave the following presentation on the OpenID Connect Working Group during the September 13, 2021 OpenID Workshop at the 2021 European Identity and Cloud (EIC) conference. As I noted during the talk, this is an exciting time for OpenID Connect; there’s more happening now than at any time since the original OpenID Connect specs were created!
The OAuth 2.0 JWT-Secured Authorization Request (JAR) specification has been published as RFC 9101. Among other applications, this specification is used by the OpenID Financial-grade API (FAPI). This is another in the series of RFCs bringing OpenID Connect-defined functionality to OAuth 2.0. Previous such RFCs included “OAuth 2.0 Dynamic Client Registration Protocol” [RFC 7591] and “OAuth 2.0 Authorization Server Metadata” [RFC 8414].
The abstract of the RFC is:
The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.
This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.
Thanks to Nat Sakimura and John Bradley for persisting in finishing this RFC!
The 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!
I gave the following presentation on the OpenID Connect Working Group at the Third Virtual OpenID Workshop on Thursday, April 29, 2021:
Today marks an important milestone in the life of the OpenID Foundation and the worldwide digital identity community. Following Don Thibeau’s decade of exemplary service to the OpenID Foundation as its Executive Director, today we welcomed Gail Hodges as our new Executive Director.
Don was instrumental in the creation of OpenID Connect, the Open Identity Exchange, the OpenID Certification program, the Financial-grade API (FAPI), and its ongoing worldwide adoption. He’s created and nurtured numerous liaison relationships with organizations and initiatives advancing digital identity and user empowerment worldwide. And thankfully, Don intends to stay active in digital identity and the OpenID Foundation, including supporting Gail in her new role.
Gail’s Twitter motto is “Reinventing identity as a public good”, which I believe will be indicative of the directions in which she’ll help lead the OpenID Foundation. She has extensive leadership experience in both digital identity and international finance, as described in her LinkedIn profile. The board is thrilled to have her on board and looks forward to what we’ll accomplish together in this next exciting chapter of the OpenID Foundation!
I encourage all of you to come meet Gail at the OpenID Foundation Workshop tomorrow, where she’ll introduce herself to the OpenID community.
I gave the following invited “101” session presentation at the 32nd Internet Identity Workshop (IIW) on Tuesday, April 20, 2021:
The session was well attended. There was a good discussion about uses of Self-Issued OpenID Providers.
As described in my last post about OAuth JAR, after it was first sent to the RFC Editor, the IESG requested an additional round of IETF feedback. I’m happy to report that, having addressed this feedback, the spec has now been sent back to the RFC Editor.
As a reminder, this specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and does so without introducing breaking changes. This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].
The specification is available at:
An HTML-formatted version is also available at:
Powered by WordPress & Theme by Anders Norén