Musings on Digital Identity

Category: Claims Page 2 of 13

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!

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.

JWK Thumbprint URI Draft Addressing IETF Last Call Comments

OAuth logoKristina Yasuda and I have published a new JWK Thumbprint URI draft that addresses the IETF Last Call comments received. Changes made were:

  • Clarified the requirement to use registered hash algorithm identifiers.
  • Acknowledged IETF Last Call reviewers.

The specification is available at:

Two new COSE- and JOSE-related Internet Drafts with Tobias Looker

IETF logoThis week, Tobias Looker and I submitted two individual Internet Drafts for consideration by the COSE working group.

The first is “Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE“, the abstract of which is:


This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott (BLS), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key).

These curves are used in Zero-Knowledge Proof (ZKP) representations for JOSE and COSE, where the ZKPs use the CFRG drafts “Pairing-Friendly Curves” and “BLS Signatures“.

The second is “CBOR Web Token (CWT) Claims in COSE Headers“, the abstract of which is:


This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. This functionality helps to facilitate applications that wish to make use of CBOR Web Token (CWT) claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload.

JWTs define a mechanism for replicating claims as header parameter values, but CWTs have been missing the equivalent capability to date. The use case is the same as that which motivated Section 5.3 of JWT “Replicating Claims as Header Parameters” – encrypted CWTs for which you’d like to have unencrypted instances of particular claims to determine how to process the CWT prior to decrypting it.

We plan to discuss both with the COSE working group at IETF 113 in Vienna.

OAuth 2.0 JWT-Secured Authorization Request (JAR) is now RFC 9101

IETF logoThe OAuth 2.0 JWT-Secured Authorization Request (JAR) specification has been published as RFC 9101. Among other applications, this specification is used by the OpenID Financial-grade API (FAPI). This is another in the series of RFCs bringing OpenID Connect-defined functionality to OAuth 2.0. Previous such RFCs included “OAuth 2.0 Dynamic Client Registration Protocol” [RFC 7591] and “OAuth 2.0 Authorization Server Metadata” [RFC 8414].

The abstract of the RFC is:


The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.


This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.

Thanks to Nat Sakimura and John Bradley for persisting in finishing this RFC!

OAuth 2.0 JWT Secured Authorization Request (JAR) sent back to the RFC Editor

OAuth logoAs described in my last post about OAuth JAR, after it was first sent to the RFC Editor, the IESG requested an additional round of IETF feedback. I’m happy to report that, having addressed this feedback, the spec has now been sent back to the RFC Editor.

As a reminder, this specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and does so without introducing breaking changes. This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].

The specification is available at:

An HTML-formatted version is also available at:

OAuth 2.0 JWT Secured Authorization Request (JAR) updates addressing remaining review comments

OAuth logoAfter the OAuth 2.0 JWT Secured Authorization Request (JAR) specification was sent to the RFC Editor, the IESG requested an additional round of IETF feedback. We’ve published an updated draft addressing the remaining review comments, specifically, SecDir comments from Watson Ladd. The only normative change made since the 28 was to change the MIME Type from “oauth.authz.req+jwt” to “oauth-authz-req+jwt“, per advice from the designated experts.

As a reminder, this specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and does so without introducing breaking changes. This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].

The specification is available at:

An HTML-formatted version is also available at:

OAuth 2.0 JWT Secured Authorization Request (JAR) sent to the RFC Editor

OAuth logoCongratulations to Nat Sakimura and John Bradley for progressing the OAuth 2.0 JWT Secured Authorization Request (JAR) specification from the working group through the IESG to the RFC Editor. This specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and intentionally does so without introducing breaking changes.

This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].

The specification is available at:

An HTML-formatted version is also available at:

Again, congratulations to Nat and John and the OAuth Working Group for this achievement!

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) is now RFC 8747

IETF logoI’m pleased to report that Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) is now RFC 8747. The abstract of the specification is:

This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)” (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).

This is one of a series of specifications, including CWT [RFC 8392] — which mirrors JWT [RFC 7519], in which we are intentionally bringing functionality that is available in JSON to the CBOR and IoT world.

JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

OAuth logoThe JSON Web Token Best Current Practices specification is now RFC 8725 and BCP 225. The abstract of the specification is:

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.

The JSON Web Token (JWT) specification [RFC 7519] was approved in May 2015, almost five years ago, and has been in production use since at least 2013. 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. Importantly, the BCP introduces no breaking changes to the JWT specification and does not require changes to existing deployments.

The BCP came about as JWTs were starting to be used in new families of protocols and applications, both in the IETF and by others. For instance, JWTs are being used by the IETF STIR working group to enable verification of the calling party’s authorization to use a particular telephone number for an incoming call, providing verified Caller ID to help combat fraudulent and unwanted telephone calls. The advice in the BCP can be used by new JWT profiles and applications to take advantage of what’s been learned since we created the JSON Web Token (JWT) specification over a half decade ago.

JWTs helping combat fraudulent and unwanted telephone calls

IETF logoI wanted to bring two excellent articles by the IETF on work by the STIR working group to combat fraudulent and unwanted telephone calls to your attention:

Abstract: Providers of voice over IP in the United States will be required to implement the IETF’s Secure Telephony Identity Revisited (STIR) protocol as a result of recently enacted legislation to address some of the root causes of illegal robocalling on the telephone network.

Abstract: Recently, the output of the IETF Secure Telephony Identity Revisited (STIR) working group has received considerable attention from service providers, regulators, and the press because it addresses some of the root causes of the illegal robocalling which has crippled the telephone network.

I love this work for two reasons. First, like the rest of you, I receive a huge volume of unwanted and often fraudulent phone calls. I love that engineers and regulators are partnering to take concrete steps to reduce the volume of these illegal and annoying calls.

Second, I love it that the STIR protocols are using JSON Web Tokens (JWTs) under the covers as the format to represent verifiable statements about legitimate uses of telephone numbers, enabling verifiable Caller ID. It’s often said that one sign of a standard having succeeded is that it’s used for things that the inventors never imagined. This is certainly such a case! I’m proud that the JSON Web Token, which we originally designed with digital identity use cases in mind, is now being used in a completely different context to solve a real problem experienced by people every day.

OpenID eKYC and Identity Assurance Working Group Formed

OpenID logoI’m pleased to report that the OpenID eKYC and Identity Assurance Working Group is up and running. The new working group is now the home for the OpenID Connect for Identity Assurance specification. This specification defines a representation for verified claims about end-users. This enables real-world use cases such as electronic driver’s licenses and digitally satisfying Know Your Customer (KYC) requirements.

See the post OpenID Connect for Identity Assurance now has a dedicated home for more information about the working group, including the working group call schedule.

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) sent to the RFC Editor

OAuth logoI’m pleased to report that the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification is now technically stable and will shortly be an RFC — an Internet standard. Specifically, it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specification with confidence that that breaking changes will not occur as it is finalized.

The abstract of the specification is:

This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)” (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).

Thanks to the ACE working group for completing this important specification.

The specification is available at:

An HTML-formatted version is also available at:

JSON Web Token Best Current Practices sent to the RFC Editor

OAuth logoI’m pleased to report that the JSON Web Token (JWT) Best Current Practices (BCP) specification is now technically stable and will shortly be an RFC — an Internet standard. Specifically, it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specification with confidence that that breaking changes will not occur as it is finalized.

The abstract of the specification is:

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs.

Thanks to the OAuth working group for completing this important specification.

The specification is available at:

An HTML-formatted version is also available at:

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing Gen-ART and SecDir reviews

IETF logoA new version of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been published addressing the Gen-ART and SecDir review comments. Thanks to Christer Holmberg and Yoav Nir, respectively, for these useful reviews.

The specification is available at:

An HTML-formatted version is also available at:

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing remaining Area Director comments

IETF logoA new version of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been published to address the remaining Area Director review comments by Benjamin Kaduk. Thanks to Ludwig Seitz for doing the bulk of the editing for this version.

The specification is available at:

An HTML-formatted version is also available at:

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing Area Director review comments

IETF logoThe Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to address the Area Director review comments by Benjamin Kaduk. Thanks to Ludwig Seitz and Hannes Tschofenig for their work on resolving the issues raised.

The specification is available at:

An HTML-formatted version is also available at:

OAuth 2.0 Token Exchange specification sent to the RFC Editor

OAuth logoI’m very pleased to report that the OAuth 2.0 Token Exchange specification is now technically stable and will shortly be an RFC — an Internet standard. Specifically, it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specification with confidence that that breaking changes will not occur as it is finalized.

The abstract of the specification is:

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

Thanks to the OAuth working group for completing this important specification. And thanks to Brian Campbell for taking point in making the recent updates to get us here.

The specification is available at:

An HTML-formatted version is also available at:

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec fixing nits

IETF logoThe Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to address issues identified by Roman Danyliw while writing his shepherd review. Thanks to Samuel Erdtman for fixing an incorrect example.

The specification is available at:

An HTML-formatted version is also available at:

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec adding Key ID considerations

IETF logoKey ID confirmation method considerations suggested by Jim Schaad have been added to the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification. Per discussions in the working group meeting in Bangkok, it’s now time for the shepherd review.

The specification is available at:

An HTML-formatted version is also available at:

Page 2 of 13

Powered by WordPress & Theme by Anders Norén