Musings on Digital Identity

Month: May 2026

Progress Report on Handling an Actionable Security Vulnerability

OAuth Security WorkshopI gave a presentation at the 2026 OAuth Security Workshop in Leipzig describing the actions we took when an actionable security vulnerability was discovered affecting numerous OpenID and OAuth specifications. Much of the information discussed was not previously public.

As I described when writing about a spec we created to address the problems, the security vulnerability was identified during formal analysis 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.

The presentation detailed how the vulnerability was discussed privately among authors of affected specifications, privately disclosed to affected parties and developers, disclosed to the OAuth working group, disclosed publicly by the OpenID Foundation, and fixed in the affected specifications (which is still a work in progress). I presented the tradeoffs considered, the decisions made and the reasons for them, and reflected on lessons learned. See the presentation deck I used (pptx) (pdf).

The thoughtful, careful, and timely action by those responsible for the affected specifications and ecosystems was impressive. I was honored to be part of it.

I’ll close by saying noting that the OAuth Security Workshop came into existence in November 2015 in response to an earlier security vulnerability also discovered through formal analysis. Describing our handling of another such vulnerability at this OSW was therefore certainly in keeping with the reasons for the workshop in the first place!

Post-Quantum Signatures for JOSE and COSE

Congratulations to Mike Prorock and Orie Steele on the publication of “ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)” as RFC 9964! This is a major step forward towards enabling widely-available post-quantum signatures for the Internet and devices.

The abstract from the RFC is:

This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204.

As I discussed at TDI 2026 and will discuss tomorrow at EIC 2026, transitioning to post-quantum algorithms is a multi-step process:

  1. Developing PQ algorithms
  2. Creating standards for using PQ algorithms
  3. Updating software to use PQ standards
  4. Deploying the updated software in your environment

Mike and Orie successfully completed step 2 for JOSE and COSE signatures today!

The JOSE and COSE algorithm identifiers for ML-DSA were actually registered with IANA in July 2025, once it was clear that the document was stable. Some deployments already exist. For instance, Yubico has created prototype Yubikeys (hardware passkeys) supporting ML-DSA signatures. The algorithms are now recommended in the FIDO2 CTAP2.3 Server Requirements.

I played a few supporting roles progressing this spec. I co-chaired the COSE Working Group with Ivaylo Petrov where the work occurred. Ivo and I made a consensus call in May 2025 to standardize only one private key representation – the seed. (As I often advocate, “Standards are about making choices”.) And I requested early allocation of the algorithm identifiers with IANA in July 2025.

Orie said to me while the spec was in AUTH48 with the RFC Editor: “This may be one of the most consequential RFCs I ever create.” I completely agree! And special congratulations, Mike Prorock, on your first RFC!


Here’s a slide from my TDI 2026 presentation on what’s hard about deploying post-quantum cryptography. I’ll make the same case tomorrow at EIC.

What's Hard About Post-Quantum Cryptography

Final 1.1 OpenID Federation Specs

OpenID logoI’m pleased to report that the Final 1.1 OpenID Federation specifications have been published. These meet the demand for cleanly separating the protocol-independent OpenID Federation functionality from the protocol-specific OpenID Federation functionality for OpenID Connect.

As I described when these specs were first published, the 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, we created new specifications splitting the two kinds of functionality apart. 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. You can use the 1.0 and 1.1 specs interchangeably. We also intentionally kept the 1.1 section numbers aligned with 1.0 to make them easier to use together.

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 became 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. OpenID Federation 1.0 draft 48 applied those improvements.

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. And now it’s done!

This split is intended make the OpenID Federation functionality easier to navigate and apply. Enjoy implementing and deploying!

Thanks to the SIROS Foundation for sponsoring my work on creating the 1.1 Federation specs!

Powered by WordPress & Theme by Anders Norén