Mike Jones: self-issued

Musings on Digital Identity

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.

OpenID Presentations at October 2025 OpenID Workshop and IIW

By

On October 21, 2025

In Events, OpenID

OpenID logoAs has become traditional, I gave the following presentation at the Monday, October 20, 2025 OpenID Workshop at Cisco:

I also gave this invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 21, 2025:

OpenID Federation draft 44 Incorporating Features Motivated by Swedish Government Use Cases

By

On October 16, 2025

In Federation, OpenID, Specifications

OpenID logoDraft 44 of the OpenID Federation specification has been published. The draft contains improved descriptions of a number of features. The one breaking change made is that Trust Mark Status responses are now signed.

Some of the changes made are intended to facilitate implementation of features needed for some Swedish government use cases. In particular, extension points were added to make it easier to use OpenID Federation for trust establishment for systems where existing entities may already be deployed, and may not be able to be modified.

The changes made in -44 are detailed in the Document History section.

Thanks all for the continued progress towards finishing the specification!

Why I Joined Hawcx

By

On August 27, 2025

In Consulting, Phishing Resistance

Hawcx logo(This is a repost of the original post Why I Joined Hawcx – Dr. Michael B. Jones.)

Hawcx and I share a vision for secure, seamless, passwordless authentication. We are working to see it widely deployed to make life better for people worldwide.

I have put years of my life into the WebAuthn and FIDO2 standards efforts trying to make this happen. It’s a partial success but still very much a work in progress in terms of adoption and security guarantees. Hawcx is fully aware of both the achievements of the FIDO approach and the impediments to its adoption.

It’s attractive to me that Hawcx is innovating in the passwordless arena, incorporating learnings from FIDO, but also employing innovative approaches where they add value. Hawcx wants to create both a great user experience and a highly secure infrastructure. There’s a freshness to this approach that I admire.

Hawcx has created a passwordless login solution that doesn’t have many of the downsides that we’ve been struggling with in FIDO for years. No synced passkeys. No AirDropping them – including no AirDropping them to phishers. Deployments are not dependent on the security of the “sync fabrics” operated by the platforms and password managers. Instead, each device has its own secured private key used at the RP that is never exported or shared.

While it’s not often said this directly, one factor limiting FIDO and WebAuthn is that the browser vendors are gatekeepers to innovation in the Web platform. Unless two and ideally all of them decide to build something, the initiative is dead in the water. Follow the journey of the Device-Bound Public Keys (a.k.a. Supplemental Public Keys) extension, which would have let RPs know if a new device was being used. It was in the spec, not built by the browser vendors, and then out of the spec as a result. In a world of synced passkeys, this was critical for higher-value sites to be able to meet their compliance and security requirements. But we’ve been stuck for years. In comparison, the Hawcx approach is browser and platform agnostic and not gated on choices made by Apple, Google, Microsoft, and Mozilla.

No, I’m not giving up on standards. I’ve poured my professional life into them, and Hawcx fully supports me in this. I have a track record of credibility from consistently speaking the truth and achieving outcomes that benefit the entire industry. I will bring that same credibility and ethos to my standards engagements on behalf of Hawcx. Hawcx plans to positively influence the Web platform based on their experience for the betterment of all, through WebAuthn and FIDO.

I’m excited about this new journey!

Updates to Audience Values for OAuth 2.0 Authorization Servers

By

On July 22, 2025

In IETF, JSON, OAuth, OpenID, Security, Specifications

OAuth logoA new version of the Updates to Audience Values for OAuth 2.0 Authorization Servers specification has been published that incorporates feedback from the OAuth working group during IETF 122. I look forward to a vigorous and useful discussion of the specification at IETF 123 in Madrid.

This specification updates a set of existing OAuth specifications to address a security vulnerability identified during formal analysis of a previous version of the OpenID Federation specification. The vulnerability resulted from ambiguities in the treatment of the audience values of tokens intended for the authorization server. The updates to these specifications close that vulnerability in the affected OAuth specifications – especially JWT client authentication in RFC 7523. In parallel, the OpenID Foundation has also updated affected OpenID specifications, including OpenID Federation and FAPI 2.0.

As summarized in the history entries, the changes in this draft were:

  • Focused RFC 7523 updates on JWT client authentication case.
  • Described client responsibilities for the audience value of authorization grants. No longer mandate that the audience for authorization grants be the issuer identifier, so as to make a minimum of breaking changes.
  • Deprecated the use of SAML assertions for client authentication.

Finally, Filip Skokan was added as an author, in recognition of his significant contributions to the work. Thanks to Filip and Brian Campbell for their work with me on this specification.

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!

More SPICEyness

By

On July 9, 2025

In CBOR, Claims, IETF, Specifications

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!

OpenID Connect RP Metadata Choices is an Implementer’s Draft

By

On July 9, 2025

In Federation, JSON, OpenID, Specifications

OpenID logoI’m happy to report that the OpenID Connect Relying Party Metadata Choices specification has been approved by the OpenID Foundation membership as an Implementer’s Draft. An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification.

The need for this was independently identified by Roland Hedberg and Stefan Santesson while implementing OpenID Federation. The contents of the specification were also validated by Filip Skokan, who implemented it. Filip has been added as an author.

The abstract of the specification is:

This specification extends the OpenID Connect Dynamic Client Registration 1.0 specification to enable RPs to express a set of supported values for some RP metadata parameters, rather than just single values. This functionality is particularly useful when Automatic Registration, as defined in OpenID Federation 1.0, is used, since there is no registration response from the OP to tell the RP what choices were made by the OP. This gives the OP the information that it needs to make choices about how to interact with the RP in ways that work for both parties.

Thanks to all who contributed to reaching this milestone!

Final OpenID Connect EAP ACR Values Specification

By

On June 17, 2025

In OpenID, Phishing Resistance, Specifications

OpenID logoThe OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 specification has been approved as a Final Specification by the OpenID Foundation membership.

As I wrote at the start of the review period, the specification is glue that ties together OpenID Connect, W3C Web Authentication, and FIDO Authenticators, enabling them to be seamlessly used together.

There are three useful normative definitions in the spec – two ACR values and one AMR value, all used in ID Token claims.

The two ACR values defined by the specification are:

  • phr:
    Phishing-Resistant. An authentication mechanism where a party potentially under the control of the Relying Party cannot gain sufficient information to be able to successfully authenticate to the End User’s OpenID Provider as if that party were the End User. (Note that the potentially malicious Relying Party controls where the User-Agent is redirected to and thus may not send it to the End User’s actual OpenID Provider). NOTE: These semantics are the same as those specified in [OpenID.PAPE].
  • phrh:
    Phishing-Resistant Hardware-Protected. An authentication mechanism meeting the requirements for phishing-resistant authentication above in which additionally information needed to be able to successfully authenticate to the End User’s OpenID Provider as if that party were the End User is held in a hardware-protected device or component.

The AMR value defined by the specification is:

  • pop:
    Proof-of-possession of a key. Unlike the existing hwk and swk methods, it is unspecified whether the proof-of-possession key is hardware-secured or software-secured.

I believe this approval completes the work of the EAP working group.

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 [email protected] or [email protected] 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!

OpenID Federation draft 43 Incorporating Feedback from Interop Event

By

On June 3, 2025

In Federation, Interoperability, OpenID, Specifications

OpenID logoDraft 43 of the OpenID Federation specification has been published. A number of features in draft 42 were discussed during the recent OpenID Federation interop event and the changes made in draft 43 are largely a result of conclusions reached there and resulting discussions that followed.

Before the interop, there were 40 open issues. As a result of the progress made at SUNET, and the ongoing engagement of interop participants since then, we’re now down to 17 open issues. And 9 of those propose extension specifications, post-final work, or reviewing the text.

The changes made in -43 are detailed in the Document History section.

Thanks all for the significant progress towards finishing the specification!

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.

OpenID Federation Interop Event at SUNET in Stockholm

By

On May 16, 2025

In Events, Federation, Interoperability, OpenID, People, Specifications

OpenID logoAt the end of April, I had the privilege of gathering in Stockholm with 30 participants to perform interoperability testing among 14 different OpenID Federation implementations. Leif Johansson and SUNET were fabulous hosts for the meeting at their offices in Stockholm. People from 15 countries participated, coming from as far as Australia and New Zealand! We performed eight different classes of tests between the implementations plus tested the OpenID Certification tests being developed for OpenID Federation.

It was great to have many of the core contributors to OpenID Federation come together and meet one another, most in-person, a few virtually, many for the first time. The sense of community and shared mission in the room was palpable! Besides testing, we also took time for architectural discussions, addressing open issues, and of course, socializing over drinks and dinners.

I must say that the OpenID Foundation staff who helped organize the meeting did a bang-up job! Stephanie Meli and Gareth Narinesingh both pitched in in numerous ways, resulting in a flawless and fun event! I’d normally be the one blogging and posting to capture the essence of the event, but they already more than covered that base. Their posts are full of facts, anecdotes, and photos. Check them out…

I thought I’d add a few more photos and graphics to capture the spirit of the interop.

In-Person Participants at SUNET

Logos of Participating Organizations

Roland Hedberg

OpenID Federation Browser View of KIT Federation

Celebrating in Stockholm

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!

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

By

On May 9, 2025

In CBOR, Claims, Events, Federation, IETF, Interoperability, JSON, OpenID, Privacy, Specifications

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

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:

Page 1 of 35

Next

Powered by WordPress & Theme by Anders Norén