Orie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” specification to incorporate feedback from IETF 120 in Vancouver. Specifically, the registrations for fully-specified Elliptic Curve Diffie-Hellman (ECDH) algorithms in draft 03 were removed, along with the previously proposed fully-specified ECDH algorithm identifiers, while continuing to describe how to create fully-specified ECDH algorithms in the future, if needed.
The specification is available at:
Orie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” specification to incorporate working group last call (WGLC) feedback. Thanks to all who took the time to comment on the draft. Your feedback was exceptionally actionable and helped to substantially improve the specification. Responses to each WGLC comment thread were sent on the IETF JOSE working group mailing list.
The updated draft attempts to discuss the full range of the problems created by polymorphic algorithm identifiers. Guided by working group feedback, it strikes an engineering balance between which of these problems to fix immediately in the specification and which to describe how future specifications can fix later as the need arises.
I look forward to discussing next steps for the specification at IETF 120 in Vancouver.
The specification is available at:
We held the second and third of the three planned tenth anniversary celebrations for the completion of OpenID Connect at the 2024 Identiverse conference and European Identity and Cloud Conference. That concludes celebrations in Asia, the Americas, and Europe!
At both Identiverse and EIC, panelists included Nat Sakimura, John Bradley, and myself. Chuck Mortimore joined us at Identiverse. And Torsten Lodderstedt added his perspectives at EIC. 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”. This was followed closely by the importance of early feedback from developers and deployers.
Chuck reached back in time to his OpenID slides from 2011. He reflected on what he was thinking at the time versus what actually happened (and why). Torsten pointed out the importance of cooperation, certification, security analysis, open standards, and an approachable community. At Identiverse, Nat reached back 25 years, examining the intellectual underpinnings and history of OpenID. And at EIC, Nat tackled assertions that OpenID Connect can be complex. John concluded by observing that the OpenID idea is greater than any particular specification.
Our recent OpenID Connect 10th anniversary sessions were:
They build upon the celebration at the OpenID Summit Tokyo 2024.
Thanks to the organizers of all these events for sponsoring the celebrations!
I was honored to give the keynote presentation Standards are About Making Choices at the 2024 European Identity and Cloud Conference (PowerPoint) (PDF). The abstract was:
When building machines, we take for granted being able to use nuts, bolts, wires, light bulbs, and countless other parts made to industry standards. Standards contain choices about dimensions of screw threads, nut sizes, etc., enabling a marketplace of interoperable parts from multiple suppliers. Without these choices, every part would be custom manufactured. The same is true of the identity and security standards we use to build identity systems.
However, the identity and security standards at our disposal differ wildly in the degree to which they do and don’t make choices. Some consistently define ONE way to do things, resulting in everyone doing it that way (interoperability!). Others leave critical choices unmade, passing the buck to implementers and applications (your mileage may vary).
In this talk, I’ll name names and take prisoners, critiquing existing and emerging standards through the lens of the choices they made and failed to make. Hold on to your hats as we examine the pros and cons of the choices made by OAuth, SAML, X.509, OpenID Connect, Verifiable Credentials, DIDs, WebCrypto, JOSE, COSE, and many others through this lens!
I believe you’ll agree with me that making choices matters.
The conference keynote description includes a recording of the presentation.
Thanks to MATTR for providing a designer to work with me on the presentation, enabling the visual design to transcend my usual black-text-on-white-background design style!
I gave the following presentation in the session Using Standards: Some Assembly Required at the 2024 Identiverse conference (PowerPoint) (PDF). The abstract was:
The audience was highly engaged by the process of giving existing and emerging standards letter grades based on the choices they made (or failed to make)!
The 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!
My 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:
Continued reviews and feedback from implementations are requested.
4: Fully-Specified Algorithms for JOSE and COSE. Updates were:
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:
.well-known to the end of the resource identifier to inserting it between the host and path components of itWWW-Authenticate return resource_metadata URL rather than resource identifierIt was decided to start working group last call during the OAuth meeting.
6: COSE “typ” (type) Header Parameter. Updates were:
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:
EC for JOSE and equivalent EC2 for COSE for uncompressed key representationsWe 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:
"alg": "dir" value for HPKE Direct Encryption modeIt 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!
The “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:
We 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!
Ten 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!
The 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:
Tobias 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:
David 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.
Orie 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:
I’ve had two different IETF specifications adopted by two different working groups in the last two days – a pleasant coincidence! Yesterday, the COSE “typ” (type) Header Parameter specification was adopted by the COSE working group. Today, the OAuth 2.0 Protected Resource Metadata specification was adopted by the OAuth working group. Their journeys from individual drafts to working group drafts couldn’t have been more different!
As I was musing with Phil Hunt, who wrote the original individual draft of OAuth 2.0 Protected Resource Metadata with me, I’m pretty sure that this is the longest time from writing an individual draft to it becoming a working group draft in my experience: August 3, 2016 to September 6, 2023 – seven years and a month!
Whereas, the time from the individual draft of COSE “typ” (type) Header Parameter to the first working group draft was only three months: July 8, 2023 to September 5, 2023. Which got me thinking… Is that the fastest progression I’ve had?
It turns out that my fastest time from individual draft to working group draft was for the JWK Thumbprint URI specification which I wrote with Kristina Yasuda. It went from individual draft to working group draft in only two months: November 24, 2021 to January 28, 2022. (And it became RFC 9278 on August 9, 2022 – less than nine months from start to finish, which I believe is also a personal record.)
Ironically, while OAuth 2.0 Protected Resource Metadata took over seven years from individual to working group drafts, a closely-related draft, OAuth 2.0 Discovery (which became RFC 8414) was previously my fastest from individual draft to working group draft: 2.5 months! (The journey to becoming an RFC took 2.5 years.)
The other relative speed demon was Proof-Of-Possession Semantics for JSON Web Tokens (JWTs): 3.5 months from individual draft to working group draft and two years from start to RFC 7800.
What are my takeaways from all these musings about starting things?
Orie Steele and I have written a new specification creating algorithm identifiers for JOSE and COSE that fully specify the cryptographic operations to be performed – something we’d promised to do during our presentation to the JOSE working group at IETF 117. The introduction to the specification (quoted below) describes why this matters.
The IANA algorithm registries for JOSE [IANA.JOSE.Algorithms] and COSE [IANA.COSE.Algorithms] contain two kinds of algorithm identifiers:
RS256 and ES256K in both JOSE and COSE and ES256 in JOSE.EdDSA in both JOSE and COSE and ES256 in COSE.This matters because many protocols negotiate supported operations using only algorithm identifiers. For instance, OAuth Authorization Server Metadata [RFC8414] uses negotiation parameters like these (from an example in the specification):
"token_endpoint_auth_signing_alg_values_supported": ["RS256", "ES256"]
OpenID Connect Discovery [OpenID.Discovery] likewise negotiates supported algorithms using alg and enc values. W3C Web Authentication [WebAuthn] and FIDO Client to Authenticator Protocol (CTAP) [FIDO2] negotiate using COSE alg numbers.
This does not work for polymorphic algorithms. For instance, with EdDSA, you do not know which of the curves Ed25519 and/or Ed448 are supported! This causes real problems in practice.
WebAuthn contains this de-facto algorithm definition to work around this problem:
-8 (EdDSA), where crv is 6 (Ed25519)
This redefines the COSE EdDSA algorithm identifier for the purposes of WebAuthn to restrict it to using the Ed25519 curve – making it non-polymorphic so that algorithm negotiation can succeed, but also effectively eliminating the possibility of using Ed448. Other similar workarounds for polymorphic algorithm identifiers are used in practice.
This specification creates fully-specified algorithm identifiers for all registered polymorphic JOSE and COSE algorithms and their parameters, enabling applications to use only fully-specified algorithm identifiers. It furthermore deprecates the practice of registering polymorphic algorithm identifiers.
The specification is available at:
I 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!
Following a call for adoption by the restarted JSON Object Signing and Encryption (JOSE) Working Group, I’m pleased to report that the three initial working group specifications have been published. They are:
JSON Web Proof, with abstract:
This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) called a JSON Web Proof (JWP). Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay and support binding mechanisms.
JSON Proof Algorithms, with abstract:
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof (JWP) and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.
JSON Proof Token, with abstract:
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs).
Thanks to Jeremie Miller and David Waite for helping us get there!
The First Public Working Draft (FPWD) of the Securing Verifiable Credentials using JSON Web Tokens (VC-JWT) specification has been published. The FPWD milestone is described in the W3C Process document. This draft is another step on the way to a Native JWT Representation for Verifiable Credentials.
Please review the First Public Working Draft of VC-JWT. Thanks especially to Orie Steele for making this happen!
For the first time, there is now a native JSON Web Token (JWT) representation for Verifiable Credentials. This representation uses IANA-registered JWT claims whenever applicable. Among other improvements and simplifications, this means that we finally have a Verifiable Credentials representation that doesn’t require the use of JSON-LD.
The native JWT representation explicitly isn’t a mapping from the VC Data Model. This mapping in the VC 1.1 specification resulted in ambiguities about whether to duplicate VC Data Model claims in the VC-JWT representation (the “in addition to” option) or whether to delete them from the VC Data Model representation (the “instead of” option). These ambiguities harmed interoperability. Rather, the 2.0 VC-JWT representation is its own simpler native JWT data structure.
See the new native JWT VC representation in the Version 2 section of the “Securing Verifiable Credentials using JSON Web Tokens” specification. You can also compare it there to the Version 1.1 representation, which is a mapping from the VC Data Model with the “in addition to” and “instead of” choices.
This accomplishment is the product of the vision, passion, and perseverance of many advocates of simplifying Verifiable Credentials. Foremost among them is Orie Steele – my co-editor for the VC-JWT specification. I’ll also observe that the pull request creating this functionality had an unprecedented fifteen approvers – an indication of the broad support for this direction for Verifiable Credentials. I am proud to have played a role in making it happen.
Powered by WordPress & Theme by Anders Norén