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:
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.
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.
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.
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 you who helped make this standard a reality!
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:
The specification is available at:
An HTML-formatted version is also available at:
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 specification is available at:
An HTML-formatted version is also available at:
The 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:
The 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:
Digital identity systems almost universally support end-users logging into applications and many also support logging out of them. But while login is reasonable well understood, there are many different kinds of semantics for “logout” in different use cases and a wide variety of mechanisms for effecting logouts.
I led a discussion on the topic “What Does Logout Mean?” at the 2018 OAuth Security Workshop in Trento, Italy, which was held the week before IETF 101, to explore this topic. The session was intentionally a highly interactive conversation, gathering information from the experts at the workshop to expand our collective understanding of the topic. Brock Allen — a practicing application security architect (and MVP for ASP.NET/IIS) — significantly contributed to the materials used to seed the discussion. And Nat Sakimura took detailed notes to record what we learned during the discussion.
Feedback on the discussion was uniformly positive. It seemed that all the participants learned things about logout use cases, mechanisms, and limitations that they previously hadn’t previously considered.
Materials related to the session are:
The JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to add guidance on how to explicitly type Nested JWTs. Thanks to Brian Campbell for suggesting the addition.
The specification is available at:
An HTML-formatted version is also available at:
The 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:
A new draft of the Security Event Token (SET) specification has published that addresses review comments from the second Working Group Last Call and shepherd comments from Yaron Sheffer. Changes were:
iat” description, as suggested by Annabelle Backman.The specification is available at:
An HTML-formatted version is also available at:
The OAuth Authorization Server Metadata specification has been updated to address feedback received from IESG members. Changes were:
The specification is available at:
An HTML-formatted version is also available at:
A new draft of the OAuth 2.0 Token Exchange specification has been published that addresses feedback from Security Area Director Eric Rescorla. The acknowledgements were also updated. Thanks to Brian Campbell for doing the editing for this version.
The specification is available at:
An HTML-formatted version is also available at:
A new draft of the OAuth 2.0 Token Exchange specification has been published that adds token type URIs for SAML 1.1 and SAML 2.0 assertions. They were added in response to actual developer use cases. These parallel the existing token type URI for JWT tokens.
The specification is available at:
An HTML-formatted version is also available at:
The OAuth Authorization Server Metadata specification has been updated to incorporate feedback received during IETF last call. Thanks to Shwetha Bhandari, Brian Carpenter, Donald Eastlake, Dick Hardt, and Mark Nottingham for their reviews. See the Document History appendix for clarifications applied. No normative changes were made.
The specification is available at:
An HTML-formatted version is also available at:
The OAuth 2.0 Token Binding specification has been updated to enable Token Binding of JWT Authorization Grants and JWT Client Authentication. The discussion of phasing in Token Binding was improved and generalized. See the Document History section for other improvements applied.
The specification is available at:
An HTML-formatted version is also available at:
An update to the closely-related OpenID Connect Token Bound Authentication 1.0 specification was also simultaneously published. Its discussion of phasing in Token Binding was correspondingly updated.
The OpenID Connect Token Binding specification is available in HTML and text versions at:
Thanks to Brian Campbell for doing the bulk of the editing for both sets of revisions.
The OAuth Authorization Server Metadata specification has been updated to incorporate feedback from Security Area Director Eric Rescorla. Thanks to EKR for his useful review. A number of defaults and restrictions are now better specified.
The specification is available at:
An HTML-formatted version is also available at:
I’m happy to announce that the OAuth working group adopted the JSON Web Token Best Current Practices (JWT BCP) draft that Yaron Sheffer, Dick Hardt, and I had worked on, following discussions at IETF 99 in Prague and on the working group mailing list.
The specification is available at:
An HTML-formatted version is also available at:
The JWT BCP draft has been updated to describe the use of explicit typing of JWTs as one of the ways to prevent confusion among different kinds of JWTs. This is accomplished by including an explicit type for the JWT in the “typ” header parameter. For instance, the Security Event Token (SET) specification now uses the “application/secevent+jwt” content type to explicitly type SETs.
The specification is available at:
An HTML-formatted version is also available at:
Powered by WordPress & Theme by Anders Norén