I’m excited that a new, simpler approach for application-level proof of possession of OAuth access tokens and refresh tokens is being developed by members of the IETF OAuth working group. The effort is led by Daniel Fett, who had previously done formal analysis of the OAuth protocol. I wanted to bring it to your attention now to solicit your early feedback. This approach was designed in discussions at the Fourth OAuth Security Workshop and is captured in a new individual draft specification for Demonstration of Proof-of-Possession (DPoP) intended for the OAuth working group. The abstract of the new specification is:
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 to detect replay attacks with access and refresh tokens.
I’m pleased to report that the IETF COSE Working Group has adopted the specification “COSE and JOSE Registrations for WebAuthn Algorithms”. An abstract of what it does is:
This specification defines how to use several algorithms with COSE [RFC8152] that are used by implementations of the W3C Web Authentication (WebAuthn) [WebAuthn] and FIDO2 Client to Authenticator Protocol (CTAP) [CTAP] specifications. These algorithms are to be registered in the IANA “COSE Algorithms” registry [IANA.COSE.Algorithms] and also in the IANA “JSON Web Signature and Encryption Algorithms” registry [IANA.JOSE.Algorithms], when not already registered there.
The two Security Event Token (SET) delivery specifications have been updated to address working group feedback received, in preparation for discussions at IETF 104 in Prague. The Push Delivery spec went through working group last call (WGLC). It has been updated to incorporate the WGLC comments. Changes made are summarized in the spec change log, the contents of which were also posted to the working group mailing list. Thanks to Annabelle Backman for the edits to the Push Delivery spec.
Responding to feedback from multiple parties that the title “OAuth 2.0 Device Flow for Browserless and Input Constrained Devices” was too much of a mouthful, the title of the specification has been simplified to “OAuth 2.0 Device Authorization Grant”. Likewise, we received feedback that “Device flow” was an insider term that caused more confusion than clarity, so its use has been removed from the specification. Finally, last minute feedback was received that client authorization and error handling were not explicitly spelled out. The specification now says that these occur in the same manner as in OAuth 2.0 [RFC 6749].
Many thanks to William Denniss for performing these edits! Hopefully this will be the draft that is sent to the RFC Editor.
I have written draft-jones-cose-additional-algorithms, which combines these starting points into a single draft, which registers these algorithms in the IANA COSE registries. When not already registered, this draft also registers these algorithms for use with JOSE in the IANA JOSE registries. I believe that this draft is ready for working group adoption to satisfy this deliverable.
The 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.
Key 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 JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the review comments from Security Area Director (AD) Eric Rescorla. Thanks to Eric for the review and to Yaron Sheffer for working on the responses with me.
Note that IETF publication has already been requested. The next step is for the shepherd review to be submitted and responded to.
The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to addresses a few additional Working Group Last Call (WGLC) comments. All of the (few) changes were about improving the clarity of the exposition. I believe that this completes addressing the WGLC comments.
Thanks to Roman Danyliw for helping to categorize the remaining comments that needed to be addressed.
Now that the Security Event Token (SET) specification is RFC 8417, the SecEvent working group is working on defining the SET delivery mechanisms. This week, both the push-based and poll-based SET delivery specs have been updated to simplify their exposition and reduce duplication of text between the drafts. Thanks to Annabelle Backman for doing the bulk of the recent work on the push-based delivery spec. The latest versions of both specs contain these updates:
Addressed problems identified in my 18-Jul-18 review message titled “Issues for both the Push and Poll Specs”.
Changes to align terminology with RFC 8417, for instance, by using the already defined term SET Recipient rather than SET Receiver.
Applied editorial and minor normative corrections.
Updated Marius Scurtescu’s contact information.
In addition, the latest version of the poll delivery spec also contains this update:
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.
The 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.
The 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.
The 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.
The 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.
We’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.
The 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 “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.
The 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.