Mike Jones: self-issued

Musings on Digital Identity

CBOR Web Token (CWT) Claims in COSE Headers Draft Addressing IETF Last Call Comments

IETF logoTobias Looker and I have published an updated CBOR Web Token (CWT) Claims in COSE Headers specification that addresses the IETF Last Call (WGLC) comments received. Changes made were:

  • Added Privacy Consideration about unencrypted claims in header parameters.
  • Added Security Consideration about detached content.
  • Added Security Consideration about claims that are present both in the payload and the header of a CWT.
  • Changed requested IANA COSE Header Parameter assignment number from 13 to 15 due to subsequent assignments of 13 and 14.
  • Acknowledged last call reviewers.

The specification is available at:

The specification is scheduled for the IESG telechat on November 30, 2023.

JSON Web Proofs specifications updated in preparation for IETF 118

IETF logoDavid Waite and I have updated the “JSON Web Proof”, “JSON Proof Algorithms”, and “JSON Proof Token” specifications in preparation for presentation and discussions in the JOSE working group at IETF 118 in Prague. The primary updates were to align the BBS algorithm text and examples with the current CFRG BBS Signature Scheme draft. We also applied improvements suggested by Brent Zundel and Alberto Solavagione.

The specifications are available at:

Thanks to David Waite for doing the heavy lifting to update the BBS content. Thanks to MATTR for publishing their Pairing Cryptography software, which was used to generate the examples. And thanks to Alberto Solavagione for validating the specifications with his implementation.

OAuth 2.0 Protected Resource Metadata updated in preparation for IETF 118

OAuth logoAaron Parecki and I have updated the “OAuth 2.0 Protected Resource Metadata” specification in preparation for presentation and discussions at IETF 118 in Prague. The updates address comments received during the discussions at IETF 117 and afterwards. As described in the History entry, the changes were:

  • Renamed scopes_provided to scopes_supported
  • Added security consideration for scopes_supported
  • Use BCP 195 for TLS recommendations
  • Clarified that resource metadata can be used by clients and authorization servers
  • Added security consideration recommending audience-restricted access tokens
  • Mention FAPI Message Signing as a use case for publishing signing keys
  • Updated references

The specification is available at:

Fully-Specified Algorithms updated in preparation for IETF 118

IETF logoOrie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” specification in preparation for presentation and discussions at IETF 118 in Prague. The updates address comments received during the discussions at IETF 117 and afterwards. Specifically, this draft adds descriptions of key representations and of algorithms not updated by the specification. See my original post about the spec for why fully-specified algorithms matter.

Hopefully working group adoption will be considered by the JOSE working group during IETF 118.

The specification is available at:

What does Presentation Exchange do and what parts of it do we actually need? (redux)

IIW LogoI convened the session “What does Presentation Exchange do and what parts of it do we actually need?” this week at the Internet Identity Workshop (IIW) to continue the discussion started during two unconference sessions at the 2023 OAuth Security Workshop. I briefly summarized the discussions that occurred at OSW, then we had a vigorous discussion of our own.

Key points made were:

  • There appeared to be rough consensus in the room that Presentation Exchange (PE) is pretty complicated. People had differing opinions on whether the complexity is worth it.
  • A lot of the complexity of PE comes from being able to request multiple credentials at once and to express alternatives.
  • Ultimately, the verifier knows what kinds of credentials it needs and the relationships between them. PE tries to let the verifier express some of that to the wallet.
  • Code running in the verifier making choices about the credentials it needs will always be more powerful than PE, because it has the full decision-making facilities of programming languages – including loops, conditionals, etc.
  • Making a composite request for multiple credentials can have a better UX than a sequence of requests. In some situations, the sequence could result in the person having to scan multiple QR codes. There may be ways to avoid that, while still having a sequence of requests.
  • Some said that they need the ability to request multiple credentials at once.
  • Brent Zundel (a PE author) suggested that while wallets could implement all of PE, verifiers could implement only the parts they need.
  • Not many parties had implemented all of PE. Torsten Lodderstedt suggested that we need feedback from developers.
  • We could create a profile of PE, reducing what implementers have to build and correspondingly reducing its expressive power.

The slides used to summarize the preceding discussions are available as PowerPoint and PDF. There are detailed notes capturing some of the back-and-forth at IIW with attribution.

Thanks to everyone who participated for an informative and useful discussion. My goal was to help inform the profiling and deployment choices ahead of us.

P.S. Since Thursday’s discussion, it occurred to me that a question I wish I’d asked is:

  • When a verifier needs multiple credentials, they may be in different wallets. If the verifier tries to make a PE request for multiple credentials that are spread between wallets, will it always fail because no single wallet can satisfy it?

Fodder for the next discussion…

OpenID Presentations at October 2023 OpenID Workshop and IIW

OpenID logoI gave the following presentation at the Monday, October 9, 2023 OpenID Workshop at CISCO:

I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 10, 2023:

Public Drafts of Third W3C WebAuthn and FIDO2 CTAP Specifications

W3C logoFIDO logoThe W3C WebAuthn and FIDO2 working groups have been actively creating third versions of the W3C Web Authentication (WebAuthn) and FIDO2 Client to Authenticator Protocol (CTAP) specifications. While remaining compatible with the original and second standards, these third versions add features that have been motivated by experience with deployments of the previous versions. Additions include Cross-Origin Authentication within an iFrame, Credential Backup State, the isPasskeyPlatformAuthenticatorAvailable method, Conditional Mediation, Device-Bound Public Keys (since renamed Supplemental Public Keys), requesting Attestations during authenticatorGetAssertion, the Pseudo-Random Function (PRF) extension, the Hybrid Transport, and Third-Party Payment Authentication.

I often tell people that I use my blog as my external memory. I thought I’d post references to these drafts to help me and others find them. They are:

Thanks to John Bradley for helping me compile the list of deltas!

OAuth 2.0 Demonstrating Proof of Possession (DPoP) is now RFC 9449

OAuth logoThe OAuth 2.0 Demonstrating Proof of Possession (DPoP) specification has been published as RFC 9449! As Vittorio Bertocci wrote, “One of the specs with the highest potential for (positive) impact in recent years.” I couldn’t agree more!

The concise abstract says it all:

This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.

As I described in my 2022 Identiverse presentation on DPoP it’s been a Long and Winding Road to get here. Efforts at providing practical proof of possession protection for tokens have included:

  • SAML 2.0 Holder-of-Key Assertion Profile – Not exactly OAuth
  • OAuth 1.0 used PoP – But message signing too complicated
  • OAuth 2.0 MAC draft – Used similarly complicated signing
  • OAuth 2.0 HTTP Signing draft – Abandoned due to complexity
  • TLS Token Binding – Some browsers declined to ship it
  • OAuth 2.0 Mutual TLS – Client certs notoriously difficult to use
  • OAuth 2.0 DPoP – Today’s RFC aimed at simply and practically solving this important problem

As they say, I think this one’s the one! Implement, deploy, and enjoy!

Adoption Time! And Lessons Learned…

IETF logoI’ve had two different IETF specifications adopted by two different working groups in the last two days – a pleasant coincidence! Yesterday, the COSE “typ” (type) Header Parameter specification was adopted by the COSE working group. Today, the OAuth 2.0 Protected Resource Metadata specification was adopted by the OAuth working group. Their journeys from individual drafts to working group drafts couldn’t have been more different!

As I was musing with Phil Hunt, who wrote the original individual draft of OAuth 2.0 Protected Resource Metadata with me, I’m pretty sure that this is the longest time from writing an individual draft to it becoming a working group draft in my experience: August 3, 2016 to September 6, 2023 – seven years and a month!

Whereas, the time from the individual draft of COSE “typ” (type) Header Parameter to the first working group draft was only three months: July 8, 2023 to September 5, 2023. Which got me thinking… Is that the fastest progression I’ve had?

It turns out that my fastest time from individual draft to working group draft was for the JWK Thumbprint URI specification which I wrote with Kristina Yasuda. It went from individual draft to working group draft in only two months: November 24, 2021 to January 28, 2022. (And it became RFC 9278 on August 9, 2022 – less than nine months from start to finish, which I believe is also a personal record.)

Ironically, while OAuth 2.0 Protected Resource Metadata took over seven years from individual to working group drafts, a closely-related draft, OAuth 2.0 Discovery (which became RFC 8414) was previously my fastest from individual draft to working group draft: 2.5 months! (The journey to becoming an RFC took 2.5 years.)

The other relative speed demon was Proof-Of-Possession Semantics for JSON Web Tokens (JWTs): 3.5 months from individual draft to working group draft and two years from start to RFC 7800.


What are my takeaways from all these musings about starting things?

Multiformats Considered Harmful

IETF logoWhile I usually reserve my time and energy for advancing good ideas, I’m making an exception to publicly state the reasons why I believe “multiformats” should not be considered for standardization by the IETF.

1. Multiformats institutionalize the failure to make a choice, which is the opposite of what good standards do. Good standards make choices about representations of data structures resulting in interoperability, since every conforming implementation uses the same representation. In contrast, multiformats enable different implementations to use a multiplicity of different representations for the same data, harming interoperability. https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-03#appendix-D.1 defines 23 equivalent and non-interoperable representations for the same data!

2. The stated purpose of “multibase” is “Unfortunately, it’s not always clear what base encoding is used; that’s where this specification comes in. It answers the question: Given data ‘d’ encoded into text ‘s’, what base is it encoded with?”, which is wholly unnecessary. Successful standards DEFINE what encoding is used where. For instance, https://www.rfc-editor.org/rfc/rfc7518.html#section-6.2.1.2 defines that “x” is base64url encoded. No guesswork or prefixing is necessary or useful.

3. Standardization of multiformats would result in unnecessary and unhelpful duplication of functionality – especially of key representations. The primary use of multiformats is for “publicKeyMultibase” – a representation of public keys that are byte arrays. For instance, the only use of multiformats by the W3C DID spec is for publicKeyMultibase. The IETF already has several perfectly good key representations, including X.509, JSON Web Key (JWK), and COSE_Key. There’s not a compelling case for another one.

4. publicKeyMultibase can only represent a subset of the key types used in practice. Representing many kinds of keys requires multiple values – for instance, RSA keys require both an exponent and a modulus. By comparison, the X.509, JWK, and COSE_Key formats are flexible enough to represent all kinds of keys. It makes little to no sense to standardize a key format that limits implementations to only certain kinds of keys.

5. The “multihash” specification relies on a non-standard representation of integers called “Dwarf”. Indeed, the referenced Dwarf document lists itself as being at http://dwarf.freestandards.org/ – a URL that no longer exists!

6. The “Multihash Identifier Registry” at https://www.ietf.org/archive/id/draft-multiformats-multihash-07.html#mh-registry duplicates the functionality of the IANA “Named Information Hash Algorithm Registry” at https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg, in that both assign (different) numeric identifiers for hash functions. If multihash goes forward, it should use the existing registry.

7. It’s concerning that the draft charter states that “Changing current Multiformat header assignments in a way that breaks backward compatibility with production deployments” is out of scope. Normally IETF working groups are given free rein to make improvements during the standardization process.

8. Finally, as a member of the W3C DID and W3C Verifiable Credentials working groups, I will state that it is misleading for the draft charter to say that “The outputs from this Working Group are currently being used by … the W3C Verifiable Credentials Working Group, W3C Decentralized Identifiers Working Group…”. The documents produced by these working groups intentionally contain no normative references to multiformats or any data structures derived from them. Where they are referenced, it is explicitly stated that the references are non-normative.

Fully-Specified Algorithms for JOSE and COSE

IETF logoOrie Steele and I have written a new specification creating algorithm identifiers for JOSE and COSE that fully specify the cryptographic operations to be performed – something we’d promised to do during our presentation to the JOSE working group at IETF 117. The introduction to the specification (quoted below) describes why this matters.


The IANA algorithm registries for JOSE [IANA.JOSE.Algorithms] and COSE [IANA.COSE.Algorithms] contain two kinds of algorithm identifiers:

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

This matters because many protocols negotiate supported operations using only algorithm identifiers. For instance, OAuth Authorization Server Metadata [RFC8414] uses negotiation parameters like these (from an example in the specification):

"token_endpoint_auth_signing_alg_values_supported": ["RS256", "ES256"]

OpenID Connect Discovery [OpenID.Discovery] likewise negotiates supported algorithms using alg and enc values. W3C Web Authentication [WebAuthn] and FIDO Client to Authenticator Protocol (CTAP) [FIDO2] negotiate using COSE alg numbers.

This does not work for polymorphic algorithms. For instance, with EdDSA, you do not know which of the curves Ed25519 and/or Ed448 are supported! This causes real problems in practice.

WebAuthn contains this de-facto algorithm definition to work around this problem:

-8 (EdDSA), where crv is 6 (Ed25519)

This redefines the COSE EdDSA algorithm identifier for the purposes of WebAuthn to restrict it to using the Ed25519 curve – making it non-polymorphic so that algorithm negotiation can succeed, but also effectively eliminating the possibility of using Ed448. Other similar workarounds for polymorphic algorithm identifiers are used in practice.

This specification creates fully-specified algorithm identifiers for all registered polymorphic JOSE and COSE algorithms and their parameters, enabling applications to use only fully-specified algorithm identifiers. It furthermore deprecates the practice of registering polymorphic algorithm identifiers.


The specification is available at:

The Key Is Not Enough! – OpenID Connect Federation at OSW 2023

OAuth Security WorkshopVladimir Dzhuvinov gave the innovative and informative presentation “The Key Is Not Enough!” on OpenID Connect Federation at the 2023 OAuth Security Workshop in London. This action thriller of a presentation covers history, goals, mechanisms, status, deployments, and possible futures of the work. The comparisons between X.509 certificates and Federation Trust Infrastructure are particularly enlightening!

What does Presentation Exchange do and what parts of it do we actually need?

OAuth Security WorkshopI organized unconference sessions on Wednesday and Thursday at the 2023 OAuth Security Workshop on “What does Presentation Exchange do and what parts of it do we actually need?”. I facilitated primarily by creating an inventory features for discussion in advance, which you’ll find on slide 3. Notes from Wednesday’s session are on slide 4. Thursday we discussed functionality needed and not needed for presenting Verifiable Credentials (with the feature realizations not necessarily tied to Presentation Exchange), which you can find on slide 5. Notes from Thursday’s discussion are on the final two pages.

Thanks to everyone who participated for a great discussion. I think we all learned things!

The slides used as an interactive notepad during our discussions are available as PowerPoint and PDF.

COSE “typ” (type) Header Parameter Specification Addressing Feedback from IETF 117

IETF logoOrie Steele and I have updated the COSE “typ” (type) Header Parameter Specification to address feedback received during IETF 117 in San Francisco. Specifically, the spec now requires that the typ header parameter only be used in the protected header parameters. And we described the implications of the unprotected header parameters changing.

The specification is available at:

We believe that having done this, the spec is now ready for working group adoption.

Yes, I’m an independent consultant now

Michael B. JonesAs many of you know, three months ago I decided to hang out my own shingle and become an independent consultant. I couldn’t be happier! I have a great initial set of clients I’m working with to create things they and I believe in and I have room for a few more.

For all the changes in my life, some things have remained constant: I’m still motivated by Kim Cameron‘s quest to build the Internet’s missing identity layer. I’m still mentoring smart new contributors to the identity space. I’m still contributing to specifications that will get used and make a difference. I’m still thinking about the big picture – especially everything it will take to grow interoperable ecosystems that enable everyday people to get useful things done. I’m still collaborating with fantastic people!

I named my business Self-Issued Consulting. Special thanks to Heather Flanagan, who clearly explained to me why I want to be a consultant at this juncture in my career, and who told me to write a Standards CV before I launched my professional Web site.

Yes, I’m grateful for the 30½ years I had at Microsoft. My career wouldn’t be remotely the same without them. But at the same time, soon after 30 years, I realized that it was time for a change. I’m grateful for all my friends who have helped me chart this next course on my identity journey. You know who you are!

I can’t resist but end with a few musical phrases that have been running through my head during this transition:

  • All things must pass – George Harrison
  • After changes upon changes / We are more or less the same – Simon and Garfunkel
  • Getting so much better all the time – The Beatles

COSE “typ” (type) Header Parameter Specification

IETF logoOrie Steele and I have created a specification to add a typ header parameter to COSE – something increasingly widely used in JOSE but currently missing in COSE. The introduction to the spec tells the story:

CBOR Object Signing and Encryption (COSE) [RFC9052] defines header parameters that parallel many of those defined by the JSON Object Signing and Encryption (JOSE) [RFC7515] [RFC7516] specifications. However, one way in which COSE does not provide equivalent functionality to JOSE is that it does not define an equivalent of the typ (type) header parameter, which is used for declaring the type of the entire JOSE data structure. The security benefits of having typ (type) are described in the JSON Web Token Best Current Practices [RFC8725], which recommends its use for “explicit typing” — using typ values to distinguish between different kinds of objects.

This specification adds the equivalent of the JOSE typ (type) header parameter to COSE so that the benefits of explicit typing can be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter, allowing both integer CoAP Content-Formats [IANA.CoAP.ContentFormats] values and string Media Type [IANA.MediaTypes] values to be used.

The specification is available at:

We plan to socialize this specification at IETF 117 in San Francisco later this month.

OAuth 2.0 Protected Resource Metadata now with WWW-Authenticate

OAuth logoIn collaboration with Aaron Parecki, the ability for OAuth 2.0 protected resource servers to return their resource identifiers via WWW-Authenticate has been added to the OAuth 2.0 Protected Resource Metadata specification. This enables clients to dynamically learn about and use protected resources they may have no prior knowledge of, including learning what authorization servers can be used with them.

This incorporates functionality originally incubated in draft-parecki-oauth-authorization-server-discovery-00. Aaron and I had been asked to merge the functionality of our two drafts during an OAuth working group session at IETF 116. We’re both happy with the result!

The specification is available at:

CBOR Web Token (CWT) Claims in COSE Headers Draft Addressing Working Group Last Call Comments

IETF logoTobias Looker and I have published an updated CBOR Web Token (CWT) Claims in COSE Headers draft that addresses the COSE Working Group Last Call (WGLC) comments received. Changes made were:

  • Added Acknowledgements section.
  • Addressed WGLC feedback. Specifically…
  • Added statement about being able to use the header parameter in any COSE object.
  • Moved statement about verifying that claim values present in both the header and payload are identical from the Security Considerations to the body of the specification.

The specification is available at:

Lifetime Achievement Award at EIC 2023

EIC 2023 LogoI was surprised and deeply honored to receive a Lifetime Achievement Award from Kuppinger Cole at EIC 2023. As I recalled when accepting the award, when Kim Cameron received the same award about a decade ago, he said from the podium “No, don’t do this! My career isn’t over! I’m not done contributing!” Kim always had a wicked wit. ;-)

Coincidentally, I described some of the achievements that led to the award during my keynote Touchstones Along My Identity Journey. After a couple of times of me saying “We won an award for that” during the keynote, I was amused that the audience would break out into laughter each subsequent time that I mentioned another award. Like this award, the audience’s reaction was unexpected and delightful.

EIC 2023 Lifetime Award

Smiling with EIC 2023 Lifetime Award

EIC 2023 Lifetime Award with Martin Kuppinger

EIC 2023 Awards with Rachelle Sellung

Touchstones Along My Identity Journey

EIC 2023 LogoI had the distinct honor of being invited to give a keynote talk at EIC 2023. The result was Touchstones Along My Identity Journey. My talk abstract was:

In 2005, Kim Cameron excitedly told me about digital identity and set my life on a course to “Build the Internet’s missing identity layer”. In this talk I’ll tell key stories from my identity journey — stories of the people, ideas, and lessons learned along the way. I’ll speak of technology and collaboration, usability and business models, solving problems people actually have, and building new ecosystems. Come with me on this journey of exploration, trials, triumphs, and humor as I recount touchstones of the human endeavor that is digital identity.

Kuppinger Cole has posted a video of my keynote on YouTube. I was pleased with how well it went. After the first few sentences, I was in the zone! I hope many of you find the messages in the talk useful.

My slides are also available in (PowerPoint) and PDF.

Special thanks go to the OpenID Foundation for supporting my trip to EIC this year and to designer Alistair Kincaid at MATTR for helping me transcend my usual black-bulleted-text-on-a-white-background presentation style!

EIC 2023 Keynote Photo

EIC 2023 Keynote Photo with Kim Cameron

EIC 2023 Keynote Photo for OAuth

Page 2 of 32

Powered by WordPress & Theme by Anders Norén