Mike Jones: self-issued – Musings on Digital Identity

FIDO2 CTAP 2.3 standard and Server Requirements published

On April 15, 2026

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

The 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:

ML-DSA Algorithms: The ML-DSA algorithms ML-DSA-44, ML-DSA-65, and ML-DSA-87 were added as Recommended.
Fully-Specified Algorithms: The fully-specified algorithms ESP256, ESP384, ESP512, and Ed25519 were added.

More good working moving passkeys forward!

Final OpenID Connect RP Metadata Choices Specification

On March 31, 2026

In Federation, JSON, OpenID, Specifications

The OpenID Connect Relying Party Metadata Choices 1.0 specification has been approved as a Final Specification by the OpenID Foundation membership. The declarations enabled by this specification give an OpenID Provider the information needed to successfully interact with a Relying Party that has not previously registered with it.

As I wrote when this became an Implementer’s Draft, the need for this was independently identified by Roland Hedberg and Stefan Santesson while implementing OpenID Federation. The contents of the specification were validated by Filip Skokan, who implemented it, and who is 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.

Finishing things matters. Thanks to all who contributed to this achievement!

The Journey to OpenID Federation 1.0 is Complete

On February 17, 2026

In Federation, OpenID, People, Specifications

The final OpenID Federation 1.0 specification was published today. This marks the end of a nearly decade-long journey and the beginning of new ones.

At the 2016 TNC conference, Lucy Lynch challenged Roland Hedberg, saying “If there is someone who should be able to bring the eduGAIN identity federation into the new world of OpenID Connect, it is you.” That was the starting point for the work.

Originally, the specification was titled “OpenID Connect Federation 1.0” and the mission was exactly that – to enable multi-lateral federation when using OpenID Connect. Over time, we realized that the core trust establishment framework defined by the specification could be applied to any protocol and the spec was therefore renamed to “OpenID Federation 1.0”. Indeed, for a while, people had been clamoring to separate the protocol-independent trust establishment framework from the protocol-specific features for OpenID Connect and OAuth 2.0. I made that split after OpenID Federation 1.0 entered final review, and the resulting OpenID Federation 1.1 specifications also entered review for final status today.

Like OpenID Connect, OpenID Federation benefited from multiple rounds of interop testing while it was being developed. Interops were held at NORDUnet 2017, SURFnet 2018, TNC/REFEDS 2019, Internet2/REFEDS 2019, three virtual interops in 2020, SUNET in 2025, and TIIME in 2026. Each time, we listened to the developer feedback and used it to improve the specification.

The early and enthusiastic support from the Research and Education community was foundational. They already knew what a multilateral federation is and why it’s useful. They patiently explained what they needed and why they needed it.

Many people contributed to the journey, but I want to call out the contributions of my co-authors in particular. Andreas Åkre Solberg was an early contributor and the inventor of Automatic Registration, which greatly simplifies deployments. John Bradley brought his practical security and deployment insights to the work. Giuseppe De Marco spearheaded production deployment for multiple Italian national federations and the Italian EUDI Wallet, informing the specification with real-world experience – particularly with the use of Trust Marks. Vladimir Dzhuvinov was an early implementer and brought his rigorous thinking about metadata operators and establishing trust to the effort.

Feedback from early implementations was critical to shaping the protocol. They included those by Authlete, Connect2ID, Raidiam, SimpleSamlPHP, DIGG, Sphereon, SPID/CIE in Italy, Shibboleth, GÉANT, SUNET, SURF, GRNET, eduGAIN/GARR, and of course Roland’s own implementation.

Demand for using OpenID Federation for protocols other than OpenID Connect and OAuth 2.0 informed our thinking as the specification developed. It is used for open finance in Australia. It is used for digital wallets in Italy. It is used for healthcare and national identity in Sweden. Each deployment brought insights to the effort that shaped the result for the better.

A team of security researchers at the University of Stuttgart performed a security analysis of the last implementer’s draft in 2024. They found an actionable security vulnerability applying to multiple protocols that we promptly fixed. Thanks to Dr. Ralf Küsters, Tim Würtele, and Pedram Hosseyni for their substantial contributions both to OpenID Federation and also to OpenID Connect, FAPI, and OAuth 2.0.

Multiple organizations played important roles in supporting this work. Special thanks to GÉANT, Connect2ID, and the SIROS Foundation for their significant financial support and encouragement. Multiple organizations hosted meetings at which significant discussions occurred, including NORDUnet, SUNET, SURF, GÉANT, and Internet2.

While this is the end of the journey for OpenID Federation 1.0, it is equally a step in important journeys under way. Multiple extensions to OpenID Federation are being developed, including OpenID Federation for Wallet Architectures 1.0 and OpenID Federation Extended Subordinate Listing 1.0. These provide important enhancements to the federation framework defined by the core specification needed for particular use cases.

Ecosystem building, adoption, and deployment is always a long journey and one we’re in the midst of. National use cases in Europe and Australia are leading the way.

I am confident that the inherent benefits of the scalable and modular OpenID Federation approach will continue to win adherents the world over. For instance, it is scalable and easily managed in a way that large-scale PKI trust bridges will never be.

Watch this space from more stories from these journeys as they develop!

Finally, my most significant thanks go to my friend and collaborator Roland Hedberg. He did the very hard thing – starting from a blank sheet of paper and on it creating a new, useful, and elegant invention. My sincerest congratulations, Roland! It’s been a privilege to be on this journey with you!

Roland Hedberg

OpenID Federation Interop Event at TIIME 2026 in Amsterdam

On February 16, 2026

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

Implementers of OpenID Federation gathered at the 2026 Trust and Internet Identity Meeting Europe (TIIME) unconference in Amsterdam on Friday, February 13, 2026 to test their implementations with one another. 12 people with 9 implementations and from 9 countries performed interop tests together. Participants were from Croatia, Finland, Greece, Italy, Netherlands, Poland, Serbia, Sweden, and the US.

The interop was organized by Niels van Dijk of SURF and Davide Vaghetti of GARR. Davide ran the interop, including assembing the test federation with the participants. Giuseppe De Marco’s OpenID Federation Browser was a useful tool for visualizing and understanding the test federation. The test federation remains assembled and I’ve observed that some participants have continued to test with one another in the days since the in-person interop at TIIME.

Here’s some photos and graphics to capture the spirit of the interop.

Davide Running TIIME Interop

OpenID Federation Browser View of GARR Federation

TIIME 2026 Interop Participants

SURF Trust Anchor

Davide Presenting Trust Mark Request

OpenID Federation Presentation at 2026 TIIME Unconference

On February 13, 2026

In Events, Federation, OpenID, Specifications

I had the pleasure of presenting an overview of OpenID Federation during the 2026 Trust and Internet Identity Meeting Europe (TIIME) unconference in Amsterdam. It was the opening talk in a day dedicated to OpenID Federation – Friday, February 13, 2026. There were ~90 practitioners in attendance. They asked great practical questions, including about how to decide what Federations to trust and the use of Trust Marks.

See the deck I used titled “OpenID Federation Overview” (pptx) (pdf).

I’m really looking forward to what I’ll learn during the discussions today. Many deployments are being described, including the GÉANT eduGAIN OpenID Federation pilot. Plus, there’s a “TechHUB” interop event today during which people will test their OpenID Federation implementations with one another.

My Federation Keynote at TIIME 2026

Initial Drafts of 1.1 OpenID Federation Specs

On January 2, 2026

In Federation, OpenID, Specifications

The OpenID Federation 1.0 specification contains two kinds of functionality:

Protocol-independent federation functionality used for establishing trust and applying policies in multilateral federations, and
Protocol-specific federation functionality that can be used by OpenID Connect and OAuth 2.0 deployments to apply the protocol-independent federation functionality.

At the urging of implementers and working group members, I’ve created new specifications splitting the two kinds of functionality apart. I’m pleased to announce that initial editor’s drafts of both split specifications are now available for your reviewing pleasure. They are:

OpenID Federation 1.1 (protocol-independent)
OpenID Federation for OpenID Connect 1.1 (protocol-specific)

Together, they are equivalent to OpenID Federation 1.0, by design. No functionality is added or removed from that present in 1.0. Rather, it’s factored into protocol-independent and protocol-specific specifications.

Reading every line of the 1.0 spec to perform the split had the additional benefit of identifying editorial improvements to apply to the 1.0 spec before it becomes final. I intentionally started the split while 1.0 is still in the 60-day review to become final exactly so improvements identified could be applied both to the original and the split specs.

As background for this work, several people had suggested splitting the two apart into separate specifications – particularly once the core federation functionality started being used with protocols other than OpenID Connect, such as with digital credentials. There was a discussion about this possibility at the Internet Identity Workshop in the Fall of 2024. During the April 2025 Federation Interop event at SUNET, there was consensus to do the split after finishing OpenID Federation 1.0. Starting the work to perform the split was proposed to both Pacific-friendly and Atlantic-friendly OpenID Connect working group calls in December 2025 after the 60-day review had started, with no opposition to proceeding.

Now it’s your turn! Please review both OpenID Federation 1.0 and the OpenID Federation 1.1 and OpenID Federation for OpenID Connect 1.1 specifications derived from it. Please send any issues found to the OpenID Connect Working Group mailing list, or file GitHub issues in the respective repositories: OpenID Federation 1.0 repository, OpenID Federation 1.1 repository, and OpenID Federation for OpenID Connect 1.1 repository. Please review for both the readability and correctness of the specs and whether you believe aspects of the split should have been done differently. In particular, please consider the examples in Appendix A, which contain both protocol-independent and protocol-specific content.

Hopefully this split will make the OpenID Federation content easier to navigate and understand for those using it and considering it. Happy New Year 2026!

Note: I updated this post on January 20, 2026 to link to the now-released versions of the 1.1 specs, rather than the editors’ drafts. Also, since the initial post, OpenID Connect Federation 1.1 was renamed to OpenID Federation for OpenID Connect 1.1.

COSE HPKE Spec Aligned with JOSE HPKE Spec

On December 15, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

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

OpenID Federation Discussion at 2025 TechEx

On December 12, 2025

In Events, Federation, OpenID, Specifications

I was encouraged by Pål Axelsson to hold an unconference discussion giving an overview of OpenID Federation during the 2025 Internet2 Technology Exchange conference in Denver. So I did so with a receptive and engaged group of participants yesterday, Thursday, December 11, 2025. See the notes from the Thursday session by Phil Smart, which include links to multiple Federation pilots.

Afterwards, several people told me that they were sorry to have missed it. So I reprised the discussion today, Friday, December 12, 2025, with a second equally engaged and mostly non-overlapping set of participants. See the notes from the Friday session by James Cramton, which captures both the breadth of participation and some of the key points made. Mihály Héder from Hungary is prototyping and was particularly engaged.

See the deck I used to queue up discussion points titled “OpenID Federation Overview” (pptx) (pdf).

The participants were some of the world’s experts in multi-lateral federation. It was great spending time with them and learning from them!

My Unplanned Multi-Platform Passkey Adventure

On December 4, 2025

In FIDO, People

I am my wife Becky’s password manager. I keep all of her passwords (and mine) in an encrypted Excel spreadsheet – something I’ve done since before password manager applications existed.

Yesterday I had reason to log into her Amazon account to help her place an order for puppy food and encountered a surprise. The password I’d diligently saved in my spreadsheet (and which Firefox had also helpfully saved for me) didn’t work. Instead, Amazon told me the password was invalid and suggested that I log in with a passkey.

So I asked Becky if she’d created a passkey for Amazon. She didn’t know. She looked in the passwords application on her iPhone, and sure enough, she had a passkey saved for amazon.com.

I knew it should be possible to use the passkey on her iPhone from Firefox on Windows 11 to sign into amazon.com, but I’d never actually tried it myself. I work on this stuff after all, so I thought I’d give it a go. Here was my experience, to the best of my recollection…

When trying to sign into Becky’s Amazon account in Firefox on Windows 11 – something I’d done many times before, amazon.com told me that the password for Becky’s account was invalid. (It was the same password she’d always had and she hadn’t changed it.) It then asked if I wanted to sign in with a passkey.
Having confirmed with Becky that she had a passkey for amazon.com on her iPhone, I clicked the “Sign in with a passkey” button.
I was asked whether my passkey was in Windows Hello or on an iPhone or iPad or Android device. I clicked the “iPhone or iPad or Android device” button.
I was told to scan a QR code that Windows presented. We scanned it with Becky’s iPhone. The iPhone asked a confirmation question about whether we wanted to release the passkey to another device (the details of which I can’t recall). I said “Yes”.
Apple (or maybe Amazon?) sent her iPhone a text message with a 6-digit code that we had to enter to confirm that we wanted to release the passkey. We did that.
Sometime during this process, Windows brought up dialog box that told me my Bluetooth was off and asked me if I wanted to turn it on. I said “Yes” and it helpfully took me to another dialog that let me turn it on. I’ll note that it didn’t explain why I would want to turn Bluetooth on. (I knew, because I worked on the FIDO Hybrid flow, but that makes me highly unusual.) I suspect that to most people, that would be a mystery and probably a non sequitur. Many might have said “No”.
Soon after that, Windows (or maybe Amazon?) asked me if wanted to duplicate the passkey to this device. I said “Yes”.
And voila, I was logged into Becky’s Amazon account in Firefox on Widows 11!
At this point I decided to go for broke. I logged out of Amazon. And tried to log back in.
After entering her e-mail address as the username, Amazon prompted me to log in with a passkey. I did that, only this time no QR code was presented, we didn’t use her phone at all, and I was apparently logged in using a passkey saved in Windows Hello.
So I was once again back to a state where I could log into Amazon as Becky on my Windows machine in Firefox, just like I previously could with a password.
This user experience left me with a question: Was the passkey on her iPhone truly duplicated to Windows or did Amazon create a different passkey? (I suspected the latter.) Visiting the Your Account / Login & Security / Passkey page at Amazon (which required entering another 6-digit code) gave me the answer:

Amazon Passkeys

Observations and Conclusions

It all worked. I didn’t know that it would – especially since it involved four vendors: Amazon, Microsoft, Mozilla, and Apple. That, in and of itself, was impressive.
There were a lot of steps to navigate, some of them unexplained. I knew the right answers to make it work. I wasn’t deterred when I was told the password was wrong. I turned Bluetooth on when prompted. I scanned the QR code. I agreed to release the passkey to another device. I agreed to duplicate the passkey to this device. Others might not have achieved the same outcomes. (I’d love to see the results of a user study among a representative population trying to do the same thing. Can anyone point me to something like that?)
Congratulations to all the engineers at all these platforms who have put in the significant effort to make this all work together! It’s a testament both to the interoperability made possible by the standards and to your implementations of them.

I’d be interested in hearing about others’ passkey adventures.

Finishing the OpenID Federation 1.0 Specification

On December 4, 2025

In Federation, OpenID, Specifications

The OpenID Federation 1.0 specification has started its 60-day review to become an OpenID Final Specification. Draft 46 of the specification, which was published today, is the target of the 60-day review.

Thanks to all who participated in the Working Group Last Call (WGLC) review, which was based on Draft 45. Your feedback resulted in a number of clarifications and editorial improvements. The changes made in -46 are detailed in the Document History section.

Almost there!

Design Team Decisions Applied to JOSE HPKE Specification

On November 30, 2025

In Cryptography, IETF, JSON, Specifications

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

Working Group Last Call for OpenID Federation

On November 20, 2025

In Federation, OpenID, Specifications

Today the OpenID Connect Working Group started a two-week Working Group Last Call (WGLC) for the OpenID Federation 1.0 specification. During the two weeks ending on December 4, 2025, working group members will identify any issues that they believe should be addressed before it becomes final. Of course, responses of the form “It’s ready to go as it is” are welcome too!

Draft 45 of the OpenID Federation specification, which was published today, is the target of the WGLC review. It adds two features motivated by the security analysis of the last Implementer’s Draft. They are:

peer_trust_chain header parameter: This enables an RP to provide a Trust Chain from the OP it is establishing trust with to the Trust Anchor that it selected at registration time. This works with both Automatic Registration and Explicit Registration and can be used in other trust establishment regimes. When a Trust Chain is also provided from the RP to the same Trust Anchor, together these enable a property called Federation Integrity, which is described in How to link an application protocol to an OpenID Federation 1.0 trust layer.
trust_anchor_hints claim: This enables Entities to publish the Trust Anchors that they are configured to trust. This can facilitate determining what Trust Anchors are shared between parties.

It also contains several important editorial improvements, including organizing the Entity Statement claims by where they may and may not appear. The changes made in -45 are detailed in the Document History section.

Thanks to all who helped us reach this point! Nearly done…

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

On October 30, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

The “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

On October 21, 2025

In Events, OpenID

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

OpenID Connect Working Group Update (PowerPoint) (PDF)

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

Introduction to OpenID Connect (PowerPoint) (PDF)

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

On October 16, 2025

In Federation, OpenID, Specifications

Draft 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

On August 27, 2025

In Consulting, Phishing Resistance

(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

On July 22, 2025

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

OAuth logo A 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

On July 9, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

The 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

On July 9, 2025

In CBOR, Cryptography, IETF, Specifications

Emil 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

On July 9, 2025

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

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

Powered by WordPress & Theme by Anders Norén