Musings on Digital Identity

Category: Specifications Page 1 of 22

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

Securing Verifiable Credentials using JOSE and COSE is now a W3C Candidate Recommendation

W3C logoThe Securing Verifiable Credentials using JOSE and COSE specification (a.k.a. VC-JOSE-COSE) has reached W3C Candidate Recommendation status. The Candidate Recommendation milestone is described in the W3C Process document. Please review the Candidate Recommendation of VC-JOSE-COSE. Thanks especially to Gabe Cohen, Orie Steele, and Brent Zundel for doing the hard work of getting us to this point!

Since I last wrote about this work, the W3C Verifiable Credentials Data Model (VCDM), which is also at Candidate Recommendation stage, has been narrowed to only use JSON-LD to represent credentials. VC-JOSE-COSE secures VCDM payloads with JOSE, SD-JWT, or COSE signatures. While I’m admittedly not a fan of JSON-LD, to the extent that Verifiable Credentials using the VCDM are in use, I’m committed to finishing a solid VC-JOSE-COSE specification so there is a simple, secure, standards-based way to sign these credentials.

Of course, there are lots of Verifiable Credential formats to choose from, and more on the way. Choices already existing include ISO mDoc, IETF SD-JWT, IETF JSON Web Proof (JWP), and W3C VCDM. The IETF is also planning to create a CBOR-based selective disclosure representation in the newly formed SPICE working group. It will be interesting to see how these all shake out in the marketplace!

Fully-Specified Algorithms Presentation at 2024 OAuth Security Workshop

OAuth Security WorkshopI gave a presentation on Fully-Specified Algorithms for JOSE and COSE at the 2024 OAuth Security Workshop in Rome. The slides used to update participants on the progress of the work are available as PowerPoint and PDF.

Thanks to the organizers for another great OAuth Security Workshop! And special thanks to the colleagues from Fondazione Bruno Kessler who did a great job with local arrangements in Rome!

COSE “typ” (type) Header Parameter Specification in RFC Editor Queue

IETF logoI’m pleased to report that the COSE “typ” (type) Header Parameter Specification has been approved by the IESG and is now in the RFC Editor queue.

The version approved by the IESG and sent to the RFC Editor is:

It joins CBOR Web Token (CWT) Claims in COSE Headers in the RFC Editor queue. Because of the reference to this spec by CWT Claims in Headers, they form a cluster, and therefore will become RFCs at the same time.

Eight Specifications Published in Preparation for IETF 119

IETF logoMy co-authors and I published updated versions of eight specifications in preparation for IETF 119 in Brisbane. The specifications span three working groups: JOSE, COSE, and OAuth. The updated specifications and outcomes when discussed at IETF 119 are as follows.

1, 2, & 3: JSON Web Proof, JSON Proof Algorithms, and JSON Proof Token. Updates were:

  • Normatively defined header parameters used
  • Populated IANA Considerations sections
  • Allowed proof representations to contain multiple base64url-encoded parts
  • Specified representation of zero-length disclosed payloads
  • Added Terminology sections
  • Updated to use draft-irtf-cfrg-bbs-signatures-05
  • Updated to use draft-ietf-cose-bls-key-representations-04
  • More and better examples
  • Improvements resulting from a full proofreading

Continued reviews and feedback from implementations are requested.

4: Fully-Specified Algorithms for JOSE and COSE. Updates were:

  • Published initial working group document following adoption
  • Added text on fully-specified computations using multiple algorithms
  • Added text on KEMs and encapsulated keys
  • Updated instructions to the designated experts

It was agreed during the JOSE meeting to describe what fully-specified algorithms for ECDH would look like, for consideration by the working group.

5: OAuth 2.0 Protected Resource Metadata. Updates were:

  • Switched from concatenating .well-known to the end of the resource identifier to inserting it between the host and path components of it
  • Have WWW-Authenticate return resource_metadata URL rather than resource identifier

It was decided to start working group last call during the OAuth meeting.

6: COSE “typ” (type) Header Parameter. Updates were:

  • Added language about media type parameters
  • Addressed working group last call comments
  • Changed requested assignment from 14 to 16 due to conflict with a new assignment
  • Addressed GENART, OPSDIR, and SECDIR review comments

This document is scheduled for the April 4, 2024 IESG telechat.

7: Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE. Updates were:

  • Changed to use key type EC for JOSE and equivalent EC2 for COSE for uncompressed key representations
  • Changed identifier spellings from “Bls” to “BLS”, since these letters are people’s initials

We received feedback to not add compressed key representations to the draft.

8: Use of Hybrid Public-Key Encryption (HPKE) with JavaScript Object Signing and Encryption (JOSE). Updates were:

It was decided to start a working group call for adoption during the JOSE meeting.

Thanks to all who contributed to the progress made on these specifications, both before and during IETF 119!

COSE “typ” (type) Header Parameter Specification Addressing IETF Last Call Feedback

IETF logoOrie Steele and I have updated the COSE “typ” (type) Header Parameter Specification to address feedback received during IETF Last Call. No normative changes were made.

Thanks to those that reviewed the specification!

The specification is available at:

Besides the spec being useful on its own, it’s worth noting that the CBOR Web Token (CWT) Claims in COSE Headers specification references this spec, and so won’t exit the RFC Editor queue as an RFC until this one also does.

Continued refinement: OpenID Federation draft 33 published

OpenID logoOpenID Federation draft 33 has been published at and 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, a summary of changes made in -32 and -33 is:


  • 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.


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

Fully-Specified Algorithms adopted by JOSE working group

IETF logoThe “Fully-Specified Algorithms for JOSE and COSE” specification has been adopted by the JOSE working group. See my original post about the spec for why fully-specified algorithms matter. Thanks to all who supported adoption and also thanks to those who provided useful detailed feedback that we can address in future working group drafts.

The specification is available at:

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

Hybrid Public Key Encryption (HPKE) for JOSE

IETF logoThe new “Use of Hybrid Public-Key Encryption (HPKE) with Javascript Object Signing and Encryption (JOSE)” specification has been published. Its abstract is:

This specification defines Hybrid public-key encryption (HPKE) for use with Javascript Object Signing and Encryption (JOSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key.

HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in JOSE is provided by JOSE-native security mechanisms or by one of the authenticated variants of HPKE.

This document defines the use of the HPKE with JOSE.

Hybrid Public Key Encryption (HPKE) is defined by RFC 9180. There’s a whole new generation of specifications using it for encryption. The Messaging Layer Security (MLS) Protocol [RFC 9420] uses it. TLS Encrypted Client Hello uses it. Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) brings it to COSE. And this specification brings it to JOSE.

One of our goals for the JOSE HPKE specification is to keep it closely aligned with the COSE HPKE specification. That should be facilitated by having multiple authors in common, with Hannes Tschofenig and Orie Steele being authors of both, and me being a COSE co-chair.

Aritra Banerjee will be presenting the draft to the JOSE working group at IETF 118 in Prague. I’m hoping to see many of you there!

The specification is available at:

On the Closing Stretch for Errata Corrections to OpenID Connect

OpenID logoThe initial OpenID Connect specifications became final on February 25, 2014. While the working group is rightfully proud of the quality of the work and the widespread adoption it has attained, specification writing is a human endeavor and mistakes will inevitably be made. That’s why the OpenID Foundation has a process for publishing Errata corrections to specifications.

Eight issues were identified and corrected that year, with the first set of errata corrections being published on November 8, 2014. Since that time, suggestions for improvements have continued to trickle in, but with a 9+ year trickle, a total of 95 errata issues have been filed! They range from the nearly trivial, such as an instance of http that should have been https, to the more consequential, such as language that could be interpreted in different ways.

I’m pleased to report that, with a substantial investment by the working group, I’ve managed to work through all the 87 additional errata issues filed since the first errata set and incorporate corrections for them into published specification drafts. They are currently undergoing OpenID Foundation-wide review in preparation for a vote to approve the second set of errata corrections.

As a bonus, the OpenID Foundation plans to submit the newly minted corrected drafts for publication by ISO as Publicly Available Specifications. This should foster even broader adoption of OpenID Connect by enabling deployments in some jurisdictions around the world that have legal requirements to use specifications from standards bodies recognized by international treaties, of which ISO is one. Just in time for OpenID Connect’s 10th anniversary!

BLS Key Representations for JOSE and COSE updated for IETF 118

IETF logoTobias Looker and I have published an updated Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE specification in preparation for IETF 118 in Prague. This one of suite of IETF and IRTF specifications, including BLS Signatures and JSON Web Proofs that are coming together to enable standards for the use of JSON-based and CBOR-based tokens utilizing zero-knowledge proofs.

The specification is available at:

CBOR Web Token (CWT) Claims in COSE Headers Draft Addressing IETF Last Call Comments

IETF logoTobias Looker and I have published an updated CBOR Web Token (CWT) Claims in COSE Headers specification that addresses the IETF Last Call (WGLC) comments received. Changes made were:

  • Added Privacy Consideration about unencrypted claims in header parameters.
  • Added Security Consideration about detached content.
  • Added Security Consideration about claims that are present both in the payload and the header of a CWT.
  • Changed requested IANA COSE Header Parameter assignment number from 13 to 15 due to subsequent assignments of 13 and 14.
  • Acknowledged last call reviewers.

The specification is available at:

The specification is scheduled for the IESG telechat on November 30, 2023.

JSON Web Proofs specifications updated in preparation for IETF 118

IETF logoDavid Waite and I have updated the “JSON Web Proof”, “JSON Proof Algorithms”, and “JSON Proof Token” specifications in preparation for presentation and discussions in the JOSE working group at IETF 118 in Prague. The primary updates were to align the BBS algorithm text and examples with the current CFRG BBS Signature Scheme draft. We also applied improvements suggested by Brent Zundel and Alberto Solavagione.

The specifications are available at:

Thanks to David Waite for doing the heavy lifting to update the BBS content. Thanks to MATTR for publishing their Pairing Cryptography software, which was used to generate the examples. And thanks to Alberto Solavagione for validating the specifications with his implementation.

OAuth 2.0 Protected Resource Metadata updated in preparation for IETF 118

OAuth logoAaron Parecki and I have updated the “OAuth 2.0 Protected Resource Metadata” specification in preparation for presentation and discussions at IETF 118 in Prague. The updates address comments received during the discussions at IETF 117 and afterwards. As described in the History entry, the changes were:

  • Renamed scopes_provided to scopes_supported
  • Added security consideration for scopes_supported
  • Use BCP 195 for TLS recommendations
  • Clarified that resource metadata can be used by clients and authorization servers
  • Added security consideration recommending audience-restricted access tokens
  • Mention FAPI Message Signing as a use case for publishing signing keys
  • Updated references

The specification is available at:

Fully-Specified Algorithms updated in preparation for IETF 118

IETF logoOrie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” specification in preparation for presentation and discussions at IETF 118 in Prague. The updates address comments received during the discussions at IETF 117 and afterwards. Specifically, this draft adds descriptions of key representations and of algorithms not updated by the specification. See my original post about the spec for why fully-specified algorithms matter.

Hopefully working group adoption will be considered by the JOSE working group during IETF 118.

The specification is available at:

What does Presentation Exchange do and what parts of it do we actually need? (redux)

IIW LogoI convened the session “What does Presentation Exchange do and what parts of it do we actually need?” this week at the Internet Identity Workshop (IIW) to continue the discussion started during two unconference sessions at the 2023 OAuth Security Workshop. I briefly summarized the discussions that occurred at OSW, then we had a vigorous discussion of our own.

Key points made were:

  • There appeared to be rough consensus in the room that Presentation Exchange (PE) is pretty complicated. People had differing opinions on whether the complexity is worth it.
  • A lot of the complexity of PE comes from being able to request multiple credentials at once and to express alternatives.
  • Ultimately, the verifier knows what kinds of credentials it needs and the relationships between them. PE tries to let the verifier express some of that to the wallet.
  • Code running in the verifier making choices about the credentials it needs will always be more powerful than PE, because it has the full decision-making facilities of programming languages – including loops, conditionals, etc.
  • Making a composite request for multiple credentials can have a better UX than a sequence of requests. In some situations, the sequence could result in the person having to scan multiple QR codes. There may be ways to avoid that, while still having a sequence of requests.
  • Some said that they need the ability to request multiple credentials at once.
  • Brent Zundel (a PE author) suggested that while wallets could implement all of PE, verifiers could implement only the parts they need.
  • Not many parties had implemented all of PE. Torsten Lodderstedt suggested that we need feedback from developers.
  • We could create a profile of PE, reducing what implementers have to build and correspondingly reducing its expressive power.

The slides used to summarize the preceding discussions are available as PowerPoint and PDF. There are detailed notes capturing some of the back-and-forth at IIW with attribution.

Thanks to everyone who participated for an informative and useful discussion. My goal was to help inform the profiling and deployment choices ahead of us.

P.S. Since Thursday’s discussion, it occurred to me that a question I wish I’d asked is:

  • When a verifier needs multiple credentials, they may be in different wallets. If the verifier tries to make a PE request for multiple credentials that are spread between wallets, will it always fail because no single wallet can satisfy it?

Fodder for the next discussion…

Page 1 of 22

Powered by WordPress & Theme by Anders Norén