Musings on Digital Identity

Category: Specifications Page 2 of 22

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.

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:

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

Initial Reanimiated JOSE Working Group Specifications Published

IETF logoFollowing a call for adoption by the restarted JSON Object Signing and Encryption (JOSE) Working Group, I’m pleased to report that the three initial working group specifications have been published. They are:

JSON Web Proof, with abstract:

This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) called a JSON Web Proof (JWP). Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay and support binding mechanisms.

JSON Proof Algorithms, with abstract:

The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof (JWP) and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.

JSON Proof Token, with abstract:

JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs).

Thanks to Jeremie Miller and David Waite for helping us get there!

OAuth DPoP specification is in the hands of the RFC Editor

OAuth logoThe OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) specification was approved by the IESG and is now in the hands of the RFC Editor in preparation for publication as an RFC. In a related development, the multiple IANA registrations requested by the specification are already in place.

As Vittorio Bertocci wrote, “One of the specs with the highest potential for (positive) impact in recent years.” I couldn’t agree more!

The latest version of the specification is available at:

Implement and deploy early and often!

First Public Working Draft of Securing Verifiable Credentials using JSON Web Tokens

W3C logoThe First Public Working Draft (FPWD) of the Securing Verifiable Credentials using JSON Web Tokens (VC-JWT) specification has been published. The FPWD milestone is described in the W3C Process document. This draft is another step on the way to a Native JWT Representation for Verifiable Credentials.

Please review the First Public Working Draft of VC-JWT. Thanks especially to Orie Steele for making this happen!

OAuth DPoP Nearing Completion

OAuth logoFollowing the IETF-wide publication request, we’ve published another DPoP draft that addresses additional review comments received to date. This version is destined for the IESG Telechat on April 13, 2023.

Recent changes as described in the history log are:

  • Add sec considerations sub-section about binding to client identity
  • Explicitly say that nonces must be unpredictable
  • Change to a numbered list in ‘Checking DPoP Proofs’
  • Editorial adjustments
  • Incorporated HTTP header field definition and RFC 8792 ‘\’ line wrapping suggestions by Mark Nottingham

The specification is available at:

Native JWT Representation for Verifiable Credentials

W3C logoFor the first time, there is now a native JSON Web Token (JWT) representation for Verifiable Credentials. This representation uses IANA-registered JWT claims whenever applicable. Among other improvements and simplifications, this means that we finally have a Verifiable Credentials representation that doesn’t require the use of JSON-LD.

The native JWT representation explicitly isn’t a mapping from the VC Data Model. This mapping in the VC 1.1 specification resulted in ambiguities about whether to duplicate VC Data Model claims in the VC-JWT representation (the “in addition to” option) or whether to delete them from the VC Data Model representation (the “instead of” option). These ambiguities harmed interoperability. Rather, the 2.0 VC-JWT representation is its own simpler native JWT data structure.

See the new native JWT VC representation in the Version 2 section of the “Securing Verifiable Credentials using JSON Web Tokens” specification. You can also compare it there to the Version 1.1 representation, which is a mapping from the VC Data Model with the “in addition to” and “instead of” choices.

This accomplishment is the product of the vision, passion, and perseverance of many advocates of simplifying Verifiable Credentials. Foremost among them is Orie Steele – my co-editor for the VC-JWT specification. I’ll also observe that the pull request creating this functionality had an unprecedented fifteen approvers – an indication of the broad support for this direction for Verifiable Credentials. I am proud to have played a role in making it happen.

JSON Object Signing and Encryption (JOSE) Working Group Reanimated

IETF logoI’m thrilled that the IETF has restarted the JSON Object Signing and Encryption (JOSE) Working Group. It’s chartered to work on JSON- and CBOR-based representations for Zero-Knowledge Proofs (ZKPs), selective disclosure enabling minimal disclosure, and non-correlatable presentation. The representations are planned to use the three-party model of Issuer, Holder, and Verifier utilized by Verifiable Credentials.

See the newly approved JOSE charter at https://datatracker.ietf.org/doc/charter-ietf-jose/03/. The working group will be chaired by Karen O’Donoghue, John Bradley, and John Mattsson, with the assigned area director being Roman Danyliw.

I believe this is a great outcome because the JOSE working group participants already have expertise creating simple, widely-adopted JSON-based cryptographic formats, such as JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK). The new formats will be peers to JWS, JWE, and COSE, reusing elements that make sense, while enabling use of new cryptographic algorithms whose inputs and outputs are not representable in the existing JOSE and COSE formats.

If you’re interested in the work, please join the JOSE mailing list at https://www.ietf.org/mailman/listinfo/jose if you’re not already a member. Also, plan to participate in IETF 116 Yokohama, where we should be able to have the first meeting of the reconstituted working group. I hope to see you there!

As background, the first step in the JOSE rechartering was the JSON Web Proofs (JWP) BoF at IETF 114 in Philadelphia sponsored by Security Area Director Roman Danyliw and chaired by Karen O’Donoghue and John Bradley, during which Jeremie Miller, Kristina Yasuda, Tobias Looker, and I presented. That was follwed by a Virtual Interim JWP BoF in October, 2022, review on the ietf-announce mailing list, and multiple IESG discussions.

All of which brings us back to the (now recurring!) question: “What Would JOSE Do?” Join us and be part of answering it!

What Would Jose Do?

OAuth DPoP Specification Addressing Area Director Review Comments

OAuth logoThis week Brian Campbell published an updated OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) draft addressing the Area Director review comments received. Thanks to Roman Danyliw for his useful review!

As Brian wrote, updates in this version of the specifiation were:

  • Updates from Roman Danyliw’s AD review
  • DPoP-Nonce now included in HTTP header field registration request
  • Fixed section reference to URI Scheme-Based Normalization
  • Attempt to better describe the rationale for SHA-256 only and expectations for how hash algorithm agility would be achieved if needed in the future
  • Elaborate on the use of multiple WWW-Authenticate challenges by protected resources
  • Fix access token request examples that were missing a client_id

The specification is available at:

The OpenID Connect Logout specifications are now Final Specifications

OpenID logoThanks to all who helped us reach this important milestone! This was originally announced on the OpenID blog. These now Final specifications are:

Don’t just sign in. Also sign out!

Page 2 of 22

Powered by WordPress & Theme by Anders Norén