The 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:
No Comments » Posted under CBOR & Claims & Cryptography & IETF & Specifications
The OAuth Device Flow specification (recently renamed to be the OAuth 2.0 Device Authorization Grant specification) is now RFC 8628. The abstract describes the specification as:
The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.
This specification standardizes an already widely-deployed pattern in production use by Facebook, ForgeRock, Google, Microsoft, Salesforce, and many others. Thanks to all of you who helped make this existing practice an actual standard!
No Comments » Posted under IETF & OAuth & Specifications
I’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:
No Comments » Posted under Claims & IETF & JSON & OAuth & Specifications
The two Security Event Token (SET) delivery specifications have been updated to address working group feedback received, in preparation for discussions at IETF 105 in Montreal. Only minor terminological updates were made to the Push Delivery spec following the working group last call (WGLC) changes in the previous recent revisions. Thanks to Annabelle Backman for the edits to the Push Delivery spec.
The changes to the Poll Delivery spec further aligned it with the Push spec, referencing shared functionality, rather than duplicating it. I believe that the Poll spec is now ready for working group last call.
The specifications are available at:
HTML-formatted versions are also available at:
No Comments » Posted under IETF & Safety & Specifications
The “COSE and JOSE Registrations for WebAuthn Algorithms” specification has been updated to address feedback received since working group adoption. The one breaking change is changing the secp256k1 curve identifier for JOSE from “P-256K” to “secp256k1”, for reasons described by John Mattsson. The draft now also specifies that the SHA-256 hash function is to be used with “ES256K” signatures – a clarification due to Matt Palmer.
The specification is available at:
An HTML-formatted version is also available at:
No Comments » Posted under CBOR & Cryptography & IETF & JSON & Specifications & W3C
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.
The specification is still an early draft and undergoing active development, but I believe the approach shows a lot of promise and is likely to be adopted by the OAuth working group soon. It works by creating a proof-of-possession signature over an access token or refresh token that would otherwise be a bearer token. And there’s already one implementation that I’m aware of – by Filip Skokan of Auth0. Let us know what you think of this new work!
The specification is available at:
An HTML-formatted version is also available at:
No Comments » Posted under IETF & OAuth & Specifications
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 algorithms registered are RSASSA-PKCS1-v1_5 with four different hash functions and signing with the secp256k1 curve. Note that there was consensus in the working group meeting not to work on registrations for the Elliptic Curve Direct Anonymous Attestation (ECDAA) algorithms “ED256” and “ED512”, both because of issues that have been raised with them and because they are not in widespread use.
The -01 version will address the review comments received on the mailing list from Jim Schaad and John Mattsson.
The specification is available at:
An HTML-formatted version is also available at:
No Comments » Posted under CBOR & Cryptography & IETF & JSON & Specifications & W3C
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.
It’s worth noting that the Push Delivery spec and the Security Event Token (SET) are now being used in early Risk and Incident Sharing and Coordination (RISC) deployments, including between Google and Adobe. See the article about these deployments by Mat Honan of BuzzFeed.
Changes to the Poll Delivery spec are also summarized in that spec’s change log, which contains:
maxEvents and returnImmediately.The specifications are available at:
HTML-formatted versions are also available at:
No Comments » Posted under IETF & OpenID & Safety & Specifications
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.
The specification is available at:
An HTML-formatted version is also available at:
No Comments » Posted under IETF & OAuth & Specifications
The new COSE working group charter includes this deliverable:
4. Define the algorithms needed for W3C Web Authentication for COSE using draft-jones-webauthn-cose-algorithms and draft-jones-webauthn-secp256k1 as a starting point (Informational).
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 specification is available at:
An HTML-formatted version is also available at:
No Comments » Posted under CBOR & Cryptography & IETF & JSON & Specifications & W3C
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.
The specification is available at:
An HTML-formatted version is also available at:
No Comments » Posted under CBOR & Claims & Cryptography & IETF & Specifications
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 specification is available at:
An HTML-formatted version is also available at:
No Comments » Posted under CBOR & Claims & Cryptography & IETF & Specifications
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 specification is available at:
An HTML-formatted version is also available at:
No Comments » Posted under Claims & Cryptography & IETF & JSON & OAuth & Specifications
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.
The specification is available at:
An HTML-formatted version is also available at:
No Comments » Posted under CBOR & Claims & Cryptography & IETF & Specifications
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:
In addition, the latest version of the poll delivery spec also contains this update:
The specifications are available at:
HTML-formatted versions are also available at:
No Comments » Posted under IETF & Specifications
The IETF Token Binding working group has completed the core Token Binding specifications. These new standards are:
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 this done!
I likewise look forward to timely completion of related Token Binding specifications, which enable use of Token Binding with TLS 1.3, with OAuth 2.0, and with OpenID Connect.
No Comments » Posted under IETF & OAuth & OpenID & Specifications & Token Binding
Check out Alex Simons’ and Pamela Dingle’s blog post “It’s Time for Token Binding”. Now that the IETF Token Binding specs are essentially done, it’s time to ask those who write TLS software you use to ship Token Binding support soon, if they haven’t already done so.
Token Binding in a nutshell: When an attacker steals a bearer token sent over TLS, he can use it; when an attacker steals a Token Bound token, it’s useless to him.
No Comments » Posted under IETF & OAuth & OpenID & Specifications & Token Binding
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.
Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.
This document is a companion document to The Token Binding Protocol.
This is a huge step towards cryptographically protecting data structures that had previously been bearer tokens, such as browser cookies, refresh tokens, access tokens, ID Tokens, etc., so that they can only be used by the intended party. Congratulations especially to the editors Andrei Popov, Dirk Balfanz, and Jeff Hodges, as well as the chairs John Bradley and Leif Johansson for getting us to this important milestone!
The three specifications are:
No Comments » Posted under Cryptography & IETF & Phishing Resistance & Specifications
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.
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 Events working group for making this standard a reality!
No Comments » Posted under Claims & IETF & JSON & OpenID & Specifications
A new draft of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been published that addresses the Working Group Last Call (WGLC) comments received. Changes were:
Thanks to Samuel Erdtman and Hannes Tschofenig for contributing to the editing for this version and to Jim Schaad and Roman Danyliw for their review comments.
The specification is available at:
An HTML-formatted version is also available at:
No Comments » Posted under CBOR & Claims & Cryptography & IETF & Specifications
