Mike Jones: self-issued

Musings on Digital Identity

Category: Cryptography Page 1 of 12

Post-Quantum Presentation at TDI 2026

By

On April 27, 2026

In Cryptography, Events, IETF

FBK logoI gave the presentation “The Post-Quantum Apocalypse Is Already Upon Us” at the 4th International Workshop on Trends in Digital Identity (TDI 2026) in Verona, Italy. My talk abstract was:

“The future is already here — it’s just not evenly distributed” is an apt description of the impact of quantum computers on cryptography and its use in our identity systems. We all know that quantum computers are predicted to be able to break the cryptographic algorithms used in today’s identity systems (RSA, Elliptic Curve, etc.) at some unknown point in the future. But this possibility has huge implications right now. “Disruptive” is an understatement. Every piece of software using cryptography has to be updated before Cryptographically Relevant Quantum Computers (CRQCs) are created (and we don’t know when that will be). “Store now — decrypt later” attacks require action now, not later. Are you using software and protocols that may never be updated for the post-quantum world (such as SAML)? Are you comfortable with your migration path to fully quantum-safe software? This presentation will help you evaluate what you need to do when and how and why to avoid being a victim of the Post-Quantum Apocalypse.

This resulted in an active and useful discussion on what the practical barriers are to updating our computing environments to be secure in the advent of Cryptographically Relevant Quantum Computers (CRQCs), and why it’s critical to start now. Topics included cryptographic algorithms, standards, updating software, and possibly the most difficult thing of all – acting in the presence of uncertainty.

See the presentation deck I used (pptx) (pdf).

Thanks to the FBK Center for Cybersecurity for the great event!

Post-Quantum Presentation at TDI 2026

FIDO2 CTAP 2.3 standard and Server Requirements published

By

On April 15, 2026

In Cryptography, FIDO, Phishing Resistance, Privacy, Specifications, W3C

FIDO logoThe FIDO Alliance has published the CTAP 2.3 Specification. No breaking changes were introduced between CTAP 2.2 and CTAP 2.3. Implementations of CTAP 2.2 are thus conformant to CTAP 2.3, therefore, a decision was made to provide certification of CTAP 2.3 implementations and not have a separate certification category for CTAP 2.2 implementations.

These are the features added and refined in CTAP 2.3:

  • Multiple Data Transfer Channels for Hybrid Interactions: CTAP 2.3 adds support for multiple data transfer channels for Hybrid interactions. Specifically, QR-Initiated transactions can now specify the data transfer channel to use. The default is Websockets (which was supported by CTAP 2.2). The new data transfer channel that can be specified is Bluetooth Low Energy.
  • Long Touch for Reset: CTAP 2.3 adds support for Long Touch for Reset. This feature allows the authenticator to communicate to the platform that the authenticator reset ceremony requires a long touch.
  • Added “FIDO_2_3” to Supported Versions List: The value “FIDO_2_3” was added to the list of supported versions in authenticatorGetInfo to indicate support for CTAP 2.3. Note that no value was created to indicate support for CTAP 2.2.
  • ISO7816 (NFC) Evidence of User Interaction: Clarified intended behaviors providing Evidence of User Interaction for authenticators supporting the ISO7816 contact interface or the ISO14443 contactless interface (NFC) without a method to collect a user gesture inside the authenticator boundary other than through a power on gesture.
  • setMinPINLength: Clarified in authenticatorGetInfo that setMinPINLength may be used when the Authenticator supports PIN entry via built-in User Verification.
  • authenticatorReset: Stated that either authenticatorReset SHOULD be supported or the authenticator MUST provide an alternate way to reset of the device back to a factory default state.
  • pinComplexityPolicy and setMinPINLength: The description of the interactions between pinComplexityPolicy and setMinPINLength was refined.
  • smart-card: smart-card was added to the list of FIDO Interfaces.
  • FIDO Applet Selection: Prohibited the authenticator from allowing the FIDO Applets to be implicitly selected or enabled.
  • NFCCTAP_GETRESPONSE: Refined NFCCTAP_GETRESPONSE timeout behaviors.

A corresponding version of the Server Requirements document was also published: Server Requirements (WebAuthn Level 3 and CTAP2.3). Recent server requirements additions are:

More good working moving passkeys forward!

COSE HPKE Spec Aligned with JOSE HPKE Spec

By

On December 15, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

IETF logoThe “Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)” specification has been updated to align with pertinent changes recently applied to the JOSE HPKE specification. Changes in draft 19 are:

  • Utilize distinct algorithm identifiers for the use of HPKE for Integrated Encryption and HPKE for Key Encryption.
  • Adds HPKE-7 algorithms.
  • Defines use of the RFC 9052 Enc_structure for COSE HPKE.

The next draft of COSE HPKE should update the examples to correspond to these changes. After that, I believe the next step is to hold another set of concurrent working group last calls (WGLCs) for both specifications.

Design Team Decisions Applied to JOSE HPKE Specification

By

On November 30, 2025

In Cryptography, IETF, JSON, Specifications

IETF logoA design team formed and met after the JOSE working group meeting at IETF 124 in Montreal to discuss possible next steps for the JOSE HPKE specification. As recorded in the PR applying the decisions made, the design team produced these recommendations:

  • Not use "enc" when performing Integrated Encryption.
  • Define one new Key Management Mode for Integrated Encryption.
  • Integrate the new mode into the Message Encryption and Message Decryption instructions from RFC 7516 and replace them.
  • Utilize distinct algorithm identifiers for the use of HPKE for Integrated Encryption and HPKE for Key Encryption.
  • Only use the Recipient_structure when doing Key Encryption and not when doing Integrated Encryption.

Draft 15 has now been published, which incorporates these decisions. Note that the title of the specification has been changed to “Use of Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE)” to more precisely describe what it does.

Those attending the design team were Karen O’Donoghue, John Bradley, Hannes Tschofenig, Filip Skokan, Brian Campbell, Leif Johansson, Paul Bastian, and myself – with it all being kicked off by Deb Cooley.

Special thanks to Filip Skokan for creating the examples used in the specification.

Brian and I celebrated our deliberations together with a mostly failed attempt at ping pong, the design team meeting having been held in the Ping Pong room.

Ping Pong between Brian Campbell and Mike Jones

I believe the next steps are to apply the same decisions to the COSE HPKE specification and then hold another set of concurrent working group last calls (WGLCs) for both specifications.

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

By

On October 30, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

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

By

On July 9, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

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

By

On July 9, 2025

In CBOR, Cryptography, IETF, Specifications

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

By

On July 9, 2025

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

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!

WGLC for JOSE and COSE HPKE Specifications

By

On June 5, 2025

In CBOR, Cryptography, IETF, JSON, 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!

Ten Years of JSON Web Token (JWT) and Preparing for the Future

By

On May 25, 2025

In Claims, Cryptography, IETF, JSON, OAuth, OpenID, Specifications

IETF logoTen years ago this week, in May 2015, the JSON Web Token (JWT) became RFC 7519. This was the culmination of a 4.5 year journey to create a simple JSON-based security token format and underlying JSON-based cryptographic standards. The full set of RFCs published together was:

  • RFC 7515: JSON Web Signature (JWS)
  • RFC 7516: JSON Web Encryption (JWE)
  • RFC 7517: JSON Web Key (JWK)
  • RFC 7518: JSON Web Algorithms (JWA)
  • RFC 7519: JSON Web Token (JWT)
  • RFC 7520: Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)
  • RFC 7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
  • RFC 7522: Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
  • RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

It’s certainly the case that we co-designed JWT and its underpinnings with OpenID Connect, while also attempting to create general-purpose, widely useful standards. Given the adoption that’s ensued, it seems that we succeeded.

As I wrote in my post JWTs helping combat fraudulent and unwanted telephone calls, “It’s often said that one sign of a standard having succeeded is that it’s used for things that the inventors never imagined.” I’m gratified that this applies to JWT and the related specifications. As was written in the post Essential Moments in the OAuth and OpenID Connect Timeline, it’s now hard to imagine an online security world without these standards.

That said, there’s work underway to keep JWTs and the use of them secure for the next decade. Five years ago, the JSON Web Token Best Current Practices specification was created. As I wrote then:

This Best Current Practices specification contains a compendium of lessons learned from real JWT deployments and implementations over that period. It describes pitfalls and how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise arise.

My coauthors Yaron Sheffer and Dick Hardt and I are now updating the JWT BCP to describe additional threats and mitigations that have become known in the last five years. See the updated JSON Web Token Best Current Practices specification.

Similarly, my coauthors Brian Campbell and Chuck Mortimore of the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants are updating it and related specifications to address vulnerabilities caused by ambiguities in the audience values of tokens sent to the authorization server. See the RFC7523bis specification.

I’m truly grateful that my coauthors John Bradley and Nat Sakimura and I created something useful and widely used ten years ago, of course with substantial contributions from the OAuth, JOSE, and OpenID Connect working groups. I look forward to what the next decade will bring!

Essential Moments in the OAuth and OpenID Timeline

By

On May 20, 2025

In Claims, Cryptography, Interoperability, JSON, OAuth, OpenID, Security, Specifications

OpenID logoOAuth logoDuende Software just posted an insightful piece titled Essential Moments in the OAuth and OpenID Connect Timeline. It’s a trip down memory lane, recounting significant developments in the identity and security standards repertoire that we now take for granted.

It reminds us that all of this has come about in the last 15 years. These standards didn’t happen by accident. They were all created to meet specific needs that we understood at the time. Fortunately, they’ve also largely stood the test of time. I’m proud to have been involved in creating many of them – of course, always in close collaboration with others.

W3C Verifiable Credentials 2.0 Specifications are Now Standards

By

On May 15, 2025

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

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

By

On May 13, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

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!

Fully-Specified Algorithms Specification Addressing IESG Feedback

By

On May 6, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

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:

Hybrid Public Key Encryption (HPKE) for JOSE incorporating feedback from IETF 122

By

On April 25, 2025

In Cryptography, IETF, JSON, Specifications

IETF logoThe “Use of Hybrid Public-Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE)” specification has updated to incorporate feedback from IETF 122 in Bangkok.

Per the History entries, the changes were:

  • Use "enc":"int" for integrated encryption.
  • Described the reasons for excluding authenticated HPKE.
  • Stated that mutually known private information MAY be used as the HPKE info value.

At this point, the authors have closed all the issues and PRs that we believe there’s consensus to address. I would normally suggest that we’re ready for working group last call at this point, but I’d like us to take the extra step to verify that the spec is aligned with the COSE HPKE spec first. Both as an author of the JOSE HPKE spec and as a COSE chair interested in the COSE HPKE spec, I’d request that members of both working groups review the specs together and send their feedback.

Third Version of FIDO2 Client to Authenticator Protocol (CTAP 2.2) Now a Standard

By

On March 18, 2025

In Cryptography, FIDO, Phishing Resistance, Privacy, Specifications, W3C

FIDO logoThe FIDO Alliance has completed the CTAP 2.2 Specification. The closely-related third version of the W3C Web Authentication (WebAuthn) specification is also nearing final status; this WebAuthn Level 3 working draft is currently going through the review steps to become a W3C Recommendation.

So what’s new in the third versions?

Changes between CTAP 2.1 and CTAP 2.2 are:

Changes between WebAuthn Level 2 and the WebAuthn Level 3 working draft are described in the document’s Revision History.

Completing these V3 specifications represents important progress in our quest to free us from the password!

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:

COSE Algorithms for Two-Party Signing

By

On March 3, 2025

In CBOR, Cryptography, FIDO, IETF, Specifications, W3C

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

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!

Page 1 of 12

Next

Powered by WordPress & Theme by Anders Norén