Mike Jones: self-issued – Musings on Digital Identity

In IETF, JSON, OAuth, OpenID, Security, Specifications
I’m pleased to announce that RFC 10070, which closes an actionable security vulnerability in OAuth 2.0 JWT Client Authentication, has been published. The abstract of the specification is:
This document updates RFCs 7521, 7522, 7523, and 9126 with respect to the treatment of audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications.
As I described when writing about draft-ietf-oauth-rfc7523bis, which became this RFC, the security vulnerability was identified during formal analysis of an earlier draft 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 ambiguities enabled a malicious authorization server to use the token endpoint of a legitimate authorization server as the audience value, resulting in a client authentication JWT that the attacker could use there.
It’s interesting to note that the fix utilizes uses two features of OAuth 2.0 that did not exist when we wrote RFC 7523:
Both these newer features have become core components of how OAuth 2.0 is used in practice today.
The vulnerability was present in all of these OAuth 2.0 specifications, each of which were updated by this RFC:
Multiple OpenID specifications using JWT Client Authentication were also affected, including OpenID Connect Core, FAPI 2.0 Security Profile, OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core, and of course, OpenID Federation. All of these have since been updated or are in the process of being updated to address the security vulnerability in the same manner as is done by RFC 10070.
This specification was the result of thoughtful, careful, and timely action by those responsible for the affected specifications and ecosystems, including leaders in the OpenID Foundation, the IETF, and especially my co-authors Brian Campbell and Filip Skokan. Thanks to all who helped us achieve this important result!
In Events, Federation, OpenID, Post-Quantum
I gave the following presentation updating people on developments in the OpenID Connect Working Group at the Monday, November 2, 2026 OpenID Workshop at CrowdStrike:
I also co-presented this material on the transition to post-quantum cryptography with Joseph Heenan:
The next day, I gave this invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, November 3, 2026:
On September 8, 2026
In Claims, JSON, OpenID, Specifications
The OpenID Connect working group has published the initial version of the OpenID Connect Token Hash Algorithm Implementer’s Guide 1.0. Thanks to Filip Skokan for writing this. Quoting from the Abstract:
This OpenID Connect Token Hash Algorithm Implementer’s Guide 1.0 identifies the hash algorithms to use when calculating OpenID Connect ID Token hash claims, such as at_hash and c_hash, Financial-grade API s_hash, and profile-defined token hash claims, for JWS algorithms whose hash function is not completely determined by the algorithm identifier in JSON Web Algorithms (JWA) [JWA].
This guide records implementation guidance for existing and registered JWS algorithm identifiers. It is intended to remain open for maintenance and is not intended to advance to Final Specification status.
For instance, it specifies that SHA-512 is to be used with Ed25519 and SHAKE256 is to be used with the ML-DSA algorithms. Note that decisions remain to be made for the SLH-DSA algorithms.
The spec is listed in the set of OpenID Connect Implementer’s Guides.
In Cryptography, FIDO, Phishing Resistance, Privacy, Security, Specifications, W3C
The World Wide Web Consortium (W3C) has published the Web Authentication (WebAuthn) Level 3 specification as a W3C Recommendation, meaning that it now a completed standard. While remaining compatible with the Level 1 and Level 2 standards, this third version adds additional features, in part, to enable improvements to user experiences with passkeys.
Meanwhile, between the publication of Level 2 in 2021 and Level 3 and 2026, the FIDO Alliance published versions 2.2 and 2.3 of the FIDO2 Client to Authenticator Protocol (CTAP) specification, which this specification can be used with. See my post about CTAP 2.3.
I highly recommend Tim Cappalli’s detailed summary of the changes in Level 3 of WebAuthn.
The one thing I’d add to Tim’s description of what’s next for WebAuthn is:
The raw signing extension is used the wwWallet cloud-based digital identity wallet by the SIROS Foundation.
Congratulations to all who contributed to reaching this important milestone!
In CBOR, Cryptography, IETF, JSON
The JOSE and COSE HPKE specs, “Use of Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE)” and “Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)” are continuing to progress towards completion.
The JOSE HPKE spec successfully completed its second working group last call (WGLC) in February 2026, received its shepherd review in March 2026, received a review from Area Director Deb Cooley in May 2026, successfully completed IETF last call in May 2026, completed IANA designated expert review in May 2026, was reviewed by the IESG in June 2026, and was approved on an IESG telechat in July 2026. This week, based on IETF last call feedback and with the support of Area Director Deb Cooley, the two key encryption algorithms using ChaCha20/Poly1305 were removed. The rationale for why these algorithms didn’t make sense in JOSE was that JOSE doesn’t have a ChaCha20/Poly1305 content encryption algorithm registered; so the Key Encryption algorithms removed would have encrypted the key with ChaCha20/Poly1305 but content would have had to be encrypted with AES. Assuming this new WGLC succeeds, the spec should progress