Musings on Digital Identity

Category: CBOR Page 1 of 5

Fully-Specified Algorithms for JOSE and COSE is now RFC 9864

IETF logoThe “Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)” specification has been published as RFC 9864! I believe that this is the first RFC I’ve worked on that started its journey as a presentation of an idea to the working group without an accompanying draft. The idea was well received by the JOSE Working Group at IETF 117 in July 2023 and so Orie Steele and I took the next step of writing a draft. The work was done in close coordination with the COSE Working Group.

The abstract from the RFC describes its contributions as follows:

This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being “fully specified”. It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being “polymorphic”. This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers.

This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053.

This is one that the world has been wanting and waiting for! There are already normative references to it both from IETF specs and also W3C, FIDO Alliance, and OpenID Foundation specifications.

I’m particularly proud of this one because it not only fixes the real and present problem of polymorphic algorithm identifiers that has plagued implementations and systems; it also ensures that the problem cannot recur, by mandating that only fully-specified algorithm identifiers can henceforth be registered. In my view, this one makes the world better.

JOSE and COSE HPKE specifications updated in preparation for IETF 123

IETF logoThe working group last calls for the JOSE and COSE Hybrid Public Key Encryption (HPKE) specifications resulted in actionable feedback on both specs. Both were updated to incorporate the feedback when the actions to take were clear. That said, I expect substantive discussions to occur on the few remaining issues for both specifications at IETF 123 in Madrid.

The current versions are:

The specifications entering WGLC together were:

Thanks to the work that Orie Steele, Hannes Tschofenig, and Tirumal Reddy put in over the past weeks to get us ready for IETF 123!

“Split Signing Algorithms for COSE” and “ARKG” updated in preparation for IETF 123

IETF logoEmil Lundberg and I have published the Split Signing Algorithms for COSE specification. This is an update to the spec formerly called COSE Algorithms for Two-Party Signing. The new draft incorporates feedback received during IETF 122, preparing for discussions at IETF 123 in Madrid.

As recorded in the History entries, the changes made were:

  • Renamed document from “COSE Algorithms for Two-Party Signing” to “Split signing algorithms for COSE” and updated introduction and terminology accordingly.
  • Dropped definitions for HashML-DSA, as split variants of ML-DSA are being actively discussed in other IETF groups.
  • Changed “Base algorithm” heading in definition tables to “Verification algorithm”.
  • Remodeled COSE_Key_Ref as COSE_Sign_Args.
  • Dropped definitions of reference types for COSE Key Types registry.

Emil also published an update to the Asynchronous Remote Key Generation (ARKG) specification, with some assistance from me. See the History entries there for details of the updates made. Some of the changes made were for alignment with the Split Signing Algorithms specification.

Major updates to JSON Web Proof specifications in preparation for IETF 123

IETF logoDavid Waite and I made significant updates to the JSON Web Proof, JSON Proof Algorithms, and JSON Proof Token and CBOR Proof Token specifications in preparation for presentation and discussions in the JOSE working group at IETF 123 in Madrid. The most significant updates were:

  • Changed the Single Use algorithm representations to use a common presentation proof format for both the Compact and CBOR serializations.
  • Defined a new binary “Presentation Internal Representation” so that the holder signature protects the entire presentation.
  • Changed the MAC algorithm to directly sign the binary Combined MAC Representation rather than convert it to a JWS.
  • Added step-by-step instructions for verification of a presentation.
  • Added CBOR examples.
  • Use JSON Proof Token and CBOR Proof Token terminology.
  • Aligned media type names and added media type suffixes.
  • Removed the JSON Serialization (leaving the Compact Serialization and the CBOR Serialization).
  • Made terminology changes to make the meanings of terms more intuitive.

These changes went into the -09 and -10 drafts of the specifications. See more details in the History entries of each spec.

The current drafts are available at:

Thanks to David Waite for doing the heavy lifting to make the bulk of these architectural changes, and especially for writing the code that makes the examples real!

More SPICEyness

IETF logoIn April, I wrote about several useful developments in the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. I’ve recently contributed to progressing several specifications in preparation for the SPICE working group meeting at IETF 123 in Madrid. Here’s a tour…

I’ve become a contributor to the Selective Disclosure CWT (SD-CWT) specification. The draft we just published in preparation for IETF 123 contains significant enhancements, including better alignment with both SD-JWT and CWT, clearer and simpler specification of the use of encryption, creation of the Verifiable Credential Type Identifiers registry, using a CBOR simple value for redacted claims, and numerous editorial improvements. See the history entry for more details. This was joint work with Rohan Mahy and Orie Steele.

I’ve become an editor of the OpenID Connect Standard Claims Registration for CBOR Web Tokens specification, along with Beltram Maldant. It creates CWT equivalents of the standard JWT claims defined by OpenID Connect. The draft we just published in preparation for IETF 123 aligns the terminology used with OpenID Connect. I believe it’s ready for working group last call.

Brent Zundel and I updated the GLobal Unique Enterprise (GLUE) Identifiers specification to fix some links and update his association to Tradeverifyd. I believe this one is also ready for working group last call.

Finally, Brent and I updated the Traceability Claims specification to tighten up many of the claim definitions. See the history entries for details.

I’m looking forward to continued progress at the SPICE meeting in two weeks!

WGLC for JOSE and COSE HPKE Specifications

IETF logoHybrid Public Key Encryption (HPKE) was standardized by RFC 9180 in February 2022. It is “hybrid” in the sense that it combines public key cryptographic operations to establish a symmetric key with symmetric cryptographic algorithms using the established key to do the content encryption. It has its own set of registries where Key Encapsulation Mechanisms (KEMs), Key Derivation Functions (KDFs), and Authenticated Encryption with Associated Data (AEAD) algorithms used with HPKE are registered. The KEMs registered include post-quantum KEMs.

There’s been a multi-year effort to bring HPKE encryption to applications using JSON Web Encryption (JWE) and COSE encryption. As has been done by other protocols using HPKE, such as MLS, both the JOSE and COSE HPKE specifications made choices about which cryptographic operations make sense together in the specification’s context, as well as which HPKE features to use. Making those choices within the working groups is part of what made these specifications take a while. There’s also been a deliberate effort to keep the specifications aligned where it made sense.

The good news is that both the JOSE and COSE HPKE specifications have matured to the point where Working Group Last Call (WGLC) has started for them. The two WGLCs are intentionally running concurrently because the drafts are closely related and their functionality is intended to be aligned. They run until Friday, June 20, 2025.

Please participate in the WGLCs on either the jose@ietf.org or cose@ietf.org mailing lists, respectively. The messages to reply to are:

The specifications entering WGLC together are:

Finally, I’ll note that a new IETF HPKE working group has recently been formed to make updates to the HPKE specification. Among the chartered updates are adding post-quantum KEMs and hybrid combined KEMs.

Thanks to all in both working groups who helped us reach this point!

W3C Verifiable Credentials 2.0 Specifications are Now Standards

W3C logoAs announced by the W3C, the Verifiable Credentials 2.0 family of specifications is now a W3C Recommendation. The new W3C Recommendations that I was an editor for are:

I joined the VC 2.0 journey in 2022 with the goal of there being a simple, secure, standards-based way to sign W3C Verifiable Credentials. The VC-JOSE-COSE specification accomplishes that – defining how to secure VC Data Model payloads with JOSE, SD-JWT, or COSE signatures. As I wrote when the Proposed Recommendations were published, 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 was committed to there being a solid VC-JOSE-COSE specification so there is a simple, secure, standards-based way to secure these credentials. That goal is now accomplished.

Particular thanks go to my co-editors of VC-JOSE-COSE Gabe Cohen and Mike Prorock, former editor Orie Steele, and working group chair Brent Zundel for the significant work they all both put in throughout the journey. And of course, Manu Sporny and Ivan Herman were always diligent about moving things along.

One of my personal mottos is “Finishing things matters”. This is now finished. As the song says, “What a long, strange trip it’s been”!

Fully-Specified Algorithms are now the Law of the Land

IETF logoI’m thrilled to be able to report that, from now on, only fully-specified algorithms will be registered for JOSE and COSE. Furthermore, fully-specified signature algorithms are now registered to replace the previously registered polymorphic algorithms, which are now deprecated. For example, you can now use Ed25519 and Ed448 instead of the ambiguous EdDSA.

The new IANA JOSE registrations and IANA COSE registrations are now in place, as are the deprecations of the polymorphic signing algorithms. And perhaps most significantly for the long term, the instructions to the designated experts for both registries have been updated so that only fully-specified algorithms will be registered going forward.

Lots of people deserve credit for this significant improvement to both ecosystems. Filip Skokan was the canary in the coal mine, alerting the OpenID Connect working group to the problems with trying to sign with Ed25519 and Ed448 when there were no algorithm identifiers that could be used to specify their use. Similarly, John Bradley alerted the WebAuthn working group to the same problems for WebAuthn and FIDO2, devising the clever and awful workaround that, when used by those specs, EdDSA is to be interpreted as meaning Ed25519. John also supported this work as a JOSE working group chair. Roman Danyliw supported including the ability to specify the use of fully-specified algorithms in the JOSE charter as the Security Area Director then responsible for JOSE. Karen O’Donoghue created the shepherd write-up as JOSE co-chair. Deb Cooley thoroughly reviewed and facilitated advancement of the specification as the Security Area Director currently responsible for JOSE. And of course, Orie Steele, the co-inventor of the fully-specified algorithms idea, and my co-author since our audacious proposal to fix the polymorphic algorithms problem at IETF 117 in July 2023 deserves huge credit for making the proposal a reality!

The specification is now in the RFC Editor Queue. I can’t wait until it pops out the other side as an RFC!

The specification is available at:

Thanks to all who helped make fully-specified algorithms the law of the land!

So you want to use Digital Credentials? You’re now facing a myriad of choices!

EIC 2025 LogoI gave the keynote talk So you want to use Digital Credentials? You’re now facing a myriad of choices! at EIC 2025. I opened by describing engineering choices – credential formats (W3C VCs, ISO mDOCs, SD-JWTs, SD-CWTs, JWPs, X.509 Certificates), issuance and presentation mechanisms (bespoke and standards-based, in-person and remote), mechanisms for choosing them (query languages, user interfaces), and trust establishment mechanisms (trust lists, certificates, and federation).

I then upped the ante by talking about the criticality of usability, the challenges of building ecosystems (something Andrew Nash first explained to me most of two decades ago!), and how digital credentials are not an end in and of themselves; they’re a tool to help us solve real-world problems. And of course, I closed by coming back to my theme Standards are About Making Choices, urging us to come together and make the right choices to enable interoperable use of digital credentials in ways that benefit people worldwide.

View my slides as PowerPoint or PDF. I’ll also post a link to the video of the presentation here once Kuppinger Cole posts it.

EIC 2025 Andrew Nash

Thought Experiment on Trust Establishment

Will people be able to use it and want to?

Standards Are About Making Choices

Thank You to SIROS

Mike Jones Candid

Fully-Specified Algorithms Specification Addressing IESG Feedback

IETF logoOrie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” specification to address feedback received through directorate reviews and from Internet Engineering Steering Group (IESG) members. This prepares us for consideration of the specification by the IESG during its “telechat” on Thursday. This is an important milestone towards progressing the specification to become an RFC.

Changes made since I last wrote about the spec, as summarized in the history entries, are:

-11

  • Stated in the abstract that the specification deprecates some polymorphic algorithm identifiers, as suggested by Éric Vyncke.

-10

  • Provided a complete list of the Recommended column terms for COSE registrations, as suggested by Mohamed Boucadair.
  • Applied suggestions to improve the exposition received during IESG review.

-09

  • Addressed comments from secdir review by Kathleen Moriarty.

-08

  • Updated requested Brainpool algorithm numbers to match those chosen by Sean Turner.
  • Incorporated wording suggestions by Vijay Gurbani.

The specification is available at:

SPICEy Developments

IETF logoThis week saw several useful developments in the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. Two new drafts were adopted and an individual draft was published also intended for later adoption by the working group. Here’s the tour…

  • GLobal Unique Enterprise (GLUE) Identifiers was adopted. The specification’s abstract is:

    This specification establishes an IETF URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. It also establishes an IETF URN namespace for identifiers defined by the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. The GLUE URN namespace is within the SPICE URN namespace.

    I worked closely with Brent Zundel on this one, primarily defining and using the IETF SPICE URN namespace, in which the GLUE namespace now resides.

  • OpenID Connect standard claims registration for CBOR Web Tokens was adopted. The specification’s abstract is:

    This document registers OpenID Connect standards claims already used in JSON Web Tokens for CBOR Web Tokens.

    While I didn’t work on this specification directly, I did suggest changes to the initial version to its author, Beltram Maldant, intended to make the spec ready for working group adoption, in my role as a Designated Expert for the IANA CBOR Web Token (CWT) Claims registry. I’m glad this is happening!

  • Traceability Claims was updated with an eye towards future working group adoption. The specification’s abstract is:

    This document defines claims to support traceability of physical goods across supply chains, focusing on items such as bills of lading, transport modes, and container manifests. These claims standardize the encoding of essential logistics and transport metadata, facilitating enhanced transparency and accountability in global supply chains. These claims are registered for use in both CBOR Web Tokens (CWTs) and JSON Web Tokens (JWTs).

    I worked closely with Mike Prorock on this one, primarily motivating and refining the claim definitions and registering JWT claims in addition to the corresponding CWT claims.

SPICEy indeed!

Fully-Specified Algorithms Specification Addressing Area Director Feedback

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:

COSE Algorithms for Two-Party Signing

IETF logoEmil Lundberg and I have published the COSE Algorithms for Two-Party Signing specification. Its abstract is:

This specification defines COSE algorithm identifiers used when the signing operation is performed cooperatively between two parties. When performing two-party signing, the first party typically hashes the data to be signed and the second party signs the hashed data computed by the first party. This can be useful when communication with the party holding the signing private key occurs over a limited-bandwidth channel, such as NFC or Bluetooth Low Energy (BLE), in which it is infeasible to send the complete set of data to be signed. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification procedure without additional steps to preprocess the signed data.

A motivating use case for this is for WebAuthn/FIDO2 Authenticators to use when signing application data, as described in the proposed WebAuthn signing extension. Parts of this spec’s content were previously in the Asynchronous Remote Key Generation (ARKG) algorithm spec, which we’ve also been updated.

I plan to talk about the spec during IETF 122 in Bangkok. I hope to see many of you there!

The specification is available at:


This work was supported by the SIROS Foundation.

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

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

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

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:

CBOR Web Token (CWT) Claims in COSE Headers is now RFC 9597

IETF logo The CBOR Web Token (CWT) Claims in COSE Headers specification has been published as RFC 9597! This closes a gap for COSE relative to JOSE, adding the ability to use CWT claims in COSE header parameters, just as JWT claims can be used in JOSE header parameters.

The specification abstract is:

This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all.

Special thanks to my co-author Tobias Looker, who had a use case for this functionality and wrote an RFC with me defining it (his first!). It was a pleasure working with Tobias on the draft as we navigated the ins and outs of working group feedback and IETF processes. The spec was refined by the journey we took together. And as with CBOR Object Signing and Encryption (COSE) “typ” (type) Header Parameter (now RFC 9596) that immediately preceded it, I believe the CBOR and COSE ecosystems are better for it.

COSE “typ” (type) Header Parameter is now RFC 9596

IETF logo The CBOR Object Signing and Encryption (COSE) “typ” (type) Header Parameter specification has been published as RFC 9596! This closes a gap for COSE relative to JOSE, adding the ability to use media types to declare the content of the complete COSE object.

The specification abstract is:

This specification adds the equivalent of the JSON Object Signing and Encryption (JOSE) “typ” (type) header parameter to CBOR Object Signing and Encryption (COSE). This enables the benefits of explicit typing (as defined in RFC 8725, “JSON Web Token Best Current Practices”) to be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter.

Special thanks to my co-author Orie Steele, who pointed out the gap and proposed that we close it. He was an active participant and insightful partner in making this RFC happen (his first!). The CBOR and COSE ecosystems are better for it.

Standards are About Making Choices

EIC 2024 LogoI was honored to give the keynote presentation Standards are About Making Choices at the 2024 European Identity and Cloud Conference (EIC) (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

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

Page 1 of 5

Powered by WordPress & Theme by Anders Norén