The core Token Binding specs are now RFCs 8471, 8472, and 8473

IETF logoThe IETF Token Binding working group has completed the core Token Binding specifications. These new standards are:

  • RFC 8471: The Token Binding Protocol Version 1.0
  • RFC 8472: Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
  • RFC 8473: Token Binding over HTTP

As Alex Simons recently wrote, it’s time for token binding. Especially now that the core specs are done, now’s the time for platforms and applications to deploy Token Binding. This will enable replacing bearer tokens, which can be stolen and reused, with Token Bound tokens, which are useless if stolen. This is a huge security benefit applicable to any tokens used over TLS, including browser cookies, OAuth access tokens and refresh tokens, and OpenID Connect ID Tokens.

Congratulations especially to the editors Andrei Popov, Dirk Balfanz, Jeff Hodges, Magnus Nyström, and Nick Harper and the chairs John Bradley and Leif Johansson for getting Continue reading "The core Token Binding specs are now RFCs 8471, 8472, and 8473"

IETF Token Binding specifications sent to the RFC Editor

IETF logoThe three core IETF Token Binding Specifications have been sent to the RFC Editor, which means that their normative content will no longer change. It’s time to move implementations to version 1.0! The abstract of the Token Binding over HTTP specification describes Token Binding as:

This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.

We describe both first-party and federated scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.

Federated token bindings, on the other hand, allow Continue reading "IETF Token Binding specifications sent to the RFC Editor"

Security Event Token (SET) is now RFC 8417

IETF logoThe Security Event Token (SET) specification is now RFC 8417. The abstract describes the specification as:

This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.

SETs are already in use to represent OpenID Connect Back-Channel Logout tokens and to represent Risk and Incident Sharing and Coordination (RISC) events. Thanks to my co-editors, members of the IETF ID Events mailing list, and members of the IETF Security Continue reading "Security Event Token (SET) is now RFC 8417"

OAuth 2.0 Authorization Server Metadata is now RFC 8414

OAuth logoThe OAuth 2.0 Authorization Server Metadata specification is now RFC 8414. The abstract describes the specification as:

This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.

The specification defines a JSON metadata representation for OAuth 2.0 authorization servers that is compatible with OpenID Connect Discovery 1.0. This specification is a true instance of standardizing existing practice. OAuth 2.0 deployments have been using the OpenID Connect metadata format to describe their endpoints and capabilities for years. This RFC makes this existing practice a standard.

Having a standard OAuth metadata format makes it easier for OAuth clients to configure connections to OAuth authorization servers. See https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata for the initial set of registered metadata values.

Thanks to all of Continue reading "OAuth 2.0 Authorization Server Metadata is now RFC 8414"

OAuth Device Flow spec addressing initial IETF last call feedback

OAuth logoThe OAuth Device Flow specification (full name “OAuth 2.0 Device Flow for Browserless and Input Constrained Devices”) has been updated to address comments received to date from the IETF last call. Thanks to William Denniss for taking the pen for this set of revisions. Changes were:

  • Added a missing definition of access_denied for use on the token endpoint.
  • Corrected text documenting which error code should be returned for expired tokens (it’s “expired_token”, not “invalid_grant”).
  • Corrected section reference to RFC 8252 (the section numbers had changed after the initial reference was made).
  • Fixed line length of one diagram (was causing xml2rfc warnings).
  • Added line breaks so the URN grant_type is presented on an unbroken line.
  • Typos fixed and other stylistic improvements.

The specification is available at:

An HTML-formatted version is also available at:

Security Event Token (SET) updates addressing IESG feedback

IETF logoWe’ve updated the Security Event Token (SET) specification to address feedback received from Internet Engineering Steering Group (IESG) members. We’ve actually published three versions in quick succession in preparation for tomorrow’s evaluation by the IESG.

Draft -11 incorporated feedback from Security Area Director Eric Rescorla and IANA Designated Expert Ned Freed. Changes were:

  • Clarified “iss” claim language about the SET issuer versus the security subject issuer.
  • Changed a “SHOULD” to a “MUST” in the “sub” claim description to be consistent with the Requirements for SET Profiles section.
  • Described the use of the “events” claim to prevent attackers from passing off other kinds of JWTs as SETs.
  • Stated that SETs are to be signed by an issuer that is trusted to do so for the use case.
  • Added quotes in the phrase ‘”token revoked” SET to be issued’ in the Timing Issues section.
  • Added section number references to the media type Continue reading "Security Event Token (SET) updates addressing IESG feedback"

JWT BCP updates addressing WGLC feedback

OAuth logoThe JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the Working Group Last Call (WGLC) feedback received. Thanks to Neil Madden for his numerous comments and to Carsten Bormann and Brian Campbell for their reviews.

Assuming the chairs concur, the next step should be to request publication.

The specification is available at:

An HTML-formatted version is also available at:

“CBOR Web Token (CWT)” is now RFC 8392

IETF logoThe “CBOR Web Token (CWT)” specification is now RFC 8392 – an IETF standard. The abstract for the specification is:

CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.

Special thanks to Erik Wahlström for starting this work and to Samuel Erdtman for doing most of the heavy lifting involved in creating correct and useful CBOR and COSE examples.

Next up – finishing “Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)”, Continue reading "“CBOR Web Token (CWT)” is now RFC 8392"

Additional RSA Algorithms for COSE Messages Registered by W3C WebAuthn

W3C logoThe WebAuthn working group has published the “COSE Algorithms for Web Authentication (WebAuthn)” specification, which registers COSE algorithm identifiers for RSASSA-PKCS1-v1_5 signature algorithms with SHA-2 and SHA-1 hash algorithms. RSASSA-PKCS1-v1_5 with SHA-256 is used by several kinds of authenticators. RSASSA-PKCS1-v1_5 with SHA-1, while deprecated, is used by some Trusted Platform Modules (TPMs). See https://www.iana.org/assignments/cose/cose.xhtml#algorithms for the actual IANA registrations.

Thanks to John Fontana, Jeff Hodges, Tony Nadalin, Jim Schaad, Göran Selander, Wendy Seltzer, Sean Turner, and Samuel Weiler for their roles in registering these algorithm identifiers.

The specification is available at:

An HTML-formatted version is also available at:

Security Event Token (SET) spec addressing additional SecDir review comments

IETF logoAn updated Security Event Token (SET) specification has published to address recent review comments received. Changes were:

  • Incorporated wording improvements resulting from Russ Housley’s additional SecDir comments.
  • Registered +jwt structured syntax suffix.

The specification is available at:

An HTML-formatted version is also available at:

Late-breaking changes to OAuth Token Exchange syntax

OAuth logoThe syntax of two JWT claims registered by the OAuth Token Exchange specification has been changed as a result of developer feedback. Developers pointed out that the OAuth Token Introspection specification [RFC 7662] uses a “scope” string to represent scope values, whereas Token Exchange was defining an array-valued “scp” claim to represent scope values. The former also uses a “client_id” element to represent OAuth Client ID values, whereas the latter was using a “cid” claim for the same purpose.

After consulting with the working group, the OAuth Token Exchange claim names have been changed to “scope” and “client_id”. Thanks to Torsten Lodderstedt for pointing out the inconsistencies and to Brian Campbell for seeking consensus and making the updates.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Device Flow spec addressing Area Director comments

OAuth logoThe OAuth 2.0 Device Flow for Browserless and Input Constrained Devices specification has been updated to address feedback by Security Area Director Eric Rescorla about the potential of a confused deputy attack. Thanks to John Bradley for helping work out the response to Eric and to William Denniss for reviewing and publishing the changes to the draft.

The specification is available at:

An HTML-formatted version is also available at:

Security Event Token (SET) spec addressing SecDir review comments

IETF logoA new draft of the Security Event Token (SET) specification has published that addresses comments from Russ Housley, who reviewed the spec for the IETF Security Directorate (SecDir). Changes were:

  • Incorporated wording improvements resulting from Russ Housley’s SecDir comments.
  • Acknowledged individuals who made significant contributions.

The specification is available at:

An HTML-formatted version is also available at:

CBOR Web Token (CWT) spec for the RFC Editor

IETF logoOne more clarification to the CBOR Web Token (CWT) specification has been made to address a comment by IESG member Adam Roach. This version is being sent to the RFC Editor in preparation for its publication as an RFC. The change was:

  • Added section references when the terms “NumericDate” and “StringOrURI” are used, as suggested by Adam Roach.

Special thanks to Security Area Director Kathleen Moriarty for helping get this across the finish line!

The specification is available at:

An HTML-formatted version is also available at:

CBOR Web Token (CWT) spec addressing IESG comments

IETF logoThe CBOR Web Token (CWT) specification has been updated to address comments received from Internet Engineering Steering Group (IESG) members. Changes were:

  • Cleaned up the descriptions of the numeric ranges of claim keys being registered in the registration template for the “CBOR Web Token (CWT) Claims” registry, as suggested by Adam Roach.
  • Clarified the relationships between the JWT and CWT “NumericDate” and “StringOrURI” terms, as suggested by Adam Roach.
  • Eliminated unnecessary uses of the word “type”, as suggested by Adam Roach.
  • Added the text “IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list” from RFC 7519, as suggested by Amanda Baber of IANA, which is also intended to address Alexey Melnikov’s comment.
  • Removed a superfluous comma, as suggested by Warren Kumari.
  • Acknowledged additional reviewers.

Special thanks to Security Area Director Kathleen Moriarty for helping get this across Continue reading "CBOR Web Token (CWT) spec addressing IESG comments"

CBOR Web Token (CWT) draft addressing IETF last call comments

IETF logoThe CBOR Web Token (CWT) specification has been updated to address IETF last call comments received to date, including GenArt, SecDir, Area Director, and additional shepherd comments. Changes were:

  • Clarified the registration criteria applied to different ranges of Claim Key values, as suggested by Kathleen Moriarty and Dan Romascanu.
  • No longer describe the syntax of CWT claims as being the same as that of the corresponding JWT claims, as suggested by Kyle Rose.
  • Added guidance about the selection of the Designated Experts, as suggested by Benjamin Kaduk.
  • Acknowledged additional reviewers.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Authorization Server Metadata spec addressing additional IESG feedback

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to address additional IESG feedback. The only change was to clarify the meaning of “case-insensitive”, as suggested by Alexey Melnikov.

The specification is available at:

An HTML-formatted version is also available at: