Mike Jones: self-issued

Musings on Digital Identity

Category: JSON Page 1 of 13

Fully-Specified Algorithms Specification Addressing Area Director Feedback

By

On March 7, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

IETF logoOrie Steele and I want to thank Deb Cooley for her Area Director review of the “Fully-Specified Algorithms for JOSE and COSE” specification. Addressing it simplified the exposition, while preserving the essence of what the draft accomplishes.

Specifically, the resulting draft significantly simplified the fully-specified encryption description and removed the appendix on polymorphic ECDH algorithms. We also stated that HSS-LMS is not fully specified, as suggested by John Preuß Mattsson.

The draft has now completed IETF last call, with the two resulting reviews stating that the draft is ready for publication.

The specification is available at:

Proposed Candidate Recommendation for Controlled Identifiers

By

On February 4, 2025

In Cryptography, JSON, Specifications, W3C

W3C logoThe W3C Verifiable Credentials Working Group has published a Snapshot Candidate Recommendation of the Controlled Identifiers specification. This follows the five Candidate Recommendation Snapshots published by the working group in December 2024. Two of these specifications, including Securing Verifiable Credentials using JOSE and COSE, depend upon the Controlled Identifiers spec. The planned update to the W3C DID specification also plans to take a dependency upon it.

A W3C Candidate Recommendation Snapshot is intended to become a W3C Candidate Recommendation after required review and approval steps.

Thanks to my co-editor Manu Sporny and working group chair Brent Zundel for their work enabling us to reach this point.

Twenty Years of Digital Identity!

By

On February 2, 2025

In Events, IETF, JSON, OAuth, OpenID, People

Kim Cameron first told me what Digital Identity is on February 1, 2005. He said that the Internet was created without an identity layer. He encouraged me “You should come help build it with me.” I’ve been at it ever since!

What I wrote about digital identity a decade ago remains as true today:

An interesting thing about digital identity is that, by definition, it’s not a problem that any one company can solve, no matter how great their technology is. For digital identity to be “solved”, the solution has to be broadly adopted, or else people will continue having different experiences at different sites and applications. Solving digital identity requires ubiquitously adopted identity standards. Part of the fun and the challenge is making that happen.

I’m not going to even try to list all the meaningful identity and security initiatives that I’ve had the privilege to work on with many of you. But I can’t resist saying that, in my view, OpenID Connect, JSON Web Token (JWT), and OAuth 2.0 are the ones that we knocked out of the park. I tried to distill the lessons learned from many of the initiatives, both successes and failures, during my 2023 EIC keynote Touchstones Along My Identity Journey. And there’s a fairly complete list of the consequential things I’ve gotten to work on in my Standards CV.

I’ll also call attention to 2025 marking twenty years of the Internet Identity Workshop. I attended the first one, which was held in Berkeley, California in October 2005, and all but one since. What a cast of characters I met there, many of whom I continue working with to this day!

As a personal testament to the value of IIW, it’s where many of the foundational decisions about what became JWS, JWE, JWK, JWT, and OpenID Connect were made. Particularly, see my post documenting decisions made at IIW about JWS, including the header.payload.signature representation of the JWS Compact Serialization and the decision to secure the Header Parameters. And see the posts following it on JWE decisions, naming decisions, and JWK decisions. IIW continues playing the role of enabling foundational discussions for emerging identity technologies today!

It’s been a privilege working with all of you for these two decades, and I love what we’ve accomplished together! There’s plenty of consequential work under way and I’m really looking forward to what comes next.

Mike Jones Kim with Coffee

Images are courtesy of Doc Searls. Each photo links to the original.

Proposed Second Candidate Recommendation for Securing Verifiable Credentials using JOSE and COSE

By

On January 2, 2025

In CBOR, Claims, Cryptography, JSON, Specifications, W3C

W3C logoThe W3C Verifiable Credentials Working Group published the Snapshot Second Candidate Recommendation of the Securing Verifiable Credentials using JOSE and COSE specification just before the holidays. This was one of five Candidate Recommendation Snapshots published by the working group at the same time, including for the Verifiable Credentials Data Model 2.0, which I’m also an editor of. A W3C Candidate Recommendation Snapshot is intended to become a W3C Candidate Recommendation after required review and approval steps.

As I wrote about the First Candidate Recommendation, VC-JOSE-COSE secures VC Data Model payloads with JOSE, SD-JWT, or COSE signatures. And while I’m admittedly not a fan of JSON-LD, to the extent that Verifiable Credentials using the JSON-LD-based VC Data Model are in use, I’m committed to there being a solid VC-JOSE-COSE specification so there is a simple, secure, standards-based way to sign these credentials.

One significant change since the First Candidate Recommendation was splitting the Controller Document text out into its own specification called Controlled Identifier Document 1.0. Publishing a Candidate Recommendation Snapshot for it is planned for next week. Part of why it became its own specification is so that it can be referenced by the planned update to the W3C DID specification.

Thanks to my co-editor Gabe Cohen and working group chair Brent Zundel for the significant work they both put in to help us reach this point!

Fully-Specified Algorithms Specification Addressing Feedback from IETF 120

By

On August 2, 2024

In CBOR, Cryptography, IETF, JSON, Specifications

IETF logoOrie 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:

Fully-Specified Algorithms Specification Addressing Working Group Last Call Comments

By

On July 11, 2024

In CBOR, Cryptography, IETF, JSON, Specifications

IETF logoOrie 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:

Celebrating Ten Years of OpenID Connect at Identiverse and EIC

By

On June 11, 2024

In Claims, Events, Federation, History, JSON, OAuth, OpenID, Specifications

EIC 2024 LogoIdentiverse LogoWe 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!

Standards are About Making Choices

By

On June 9, 2024

In CBOR, Claims, Cryptography, Events, FIDO, IETF, Interoperability, JSON, OAuth, OpenID, Phishing Resistance, Specifications, W3C

EIC 2024 LogoI 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!

Using Standards: Some Assembly Required

By

On May 30, 2024

In CBOR, Claims, Cryptography, Events, FIDO, IETF, Interoperability, JSON, OAuth, OpenID, Phishing Resistance, Specifications, W3C

Identiverse LogoI gave the following presentation in the session Using Standards: Some Assembly Required at the 2024 Identiverse conference (PowerPoint) (PDF). The abstract was:

  • Standards are about making choices. 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 the Identity Engine. 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 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)!

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

By

On April 28, 2024

In CBOR, Claims, Cryptography, JSON, Specifications, W3C

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!

Eight Specifications Published in Preparation for IETF 119

By

On March 20, 2024

In CBOR, Claims, Cryptography, Events, IETF, JSON, Specifications

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!

Fully-Specified Algorithms adopted by JOSE working group

By

On January 31, 2024

In CBOR, Cryptography, IETF, JSON, Specifications

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

By

On January 20, 2024

In Claims, Events, Federation, History, JSON, OAuth, OpenID, Specifications

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

By

On December 19, 2023

In Claims, Federation, History, JSON, OAuth, OpenID, Specifications

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!

Hybrid Public Key Encryption (HPKE) for JOSE

By

On October 31, 2023

In Cryptography, IETF, JSON, Specifications

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:

BLS Key Representations for JOSE and COSE updated for IETF 118

By

On October 24, 2023

In CBOR, Claims, IETF, JSON, Privacy, Specifications

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:

JSON Web Proofs specifications updated in preparation for IETF 118

By

On October 22, 2023

In Claims, Cryptography, IETF, JSON, Privacy, Specifications

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.

Fully-Specified Algorithms updated in preparation for IETF 118

By

On October 20, 2023

In CBOR, Cryptography, IETF, JSON, Specifications

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:

Adoption Time! And Lessons Learned…

By

On September 6, 2023

In CBOR, IETF, JSON, OAuth, Specifications

IETF logoI’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?

Fully-Specified Algorithms for JOSE and COSE

By

On August 29, 2023

In CBOR, Cryptography, IETF, JSON, Specifications

IETF logoOrie 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:

  • Fully Specified: Those that fully determine the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc. Examples are RS256 and ES256K in both JOSE and COSE and ES256 in JOSE.
  • Polymorphic: Those requiring information beyond the algorithm identifier to determine the cryptographic operations to be performed. Such additional information could include the actual key value and a curve that it uses. Examples are 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:

Page 1 of 13

Next

Powered by WordPress & Theme by Anders Norén