Draft -03 of the Authentication Method Reference Values specification addresses the shepherd comments. It changes the references providing information about specific “amr” values to be informative, rather than normative. A reference to ISO/IEC 29115 was also added. No normative changes were made.
The specification is available at:
An HTML-formatted version is also available at:
The OAuth Token Binding specification has been revised to use the Referred Token Binding ID when performing token binding of access tokens. This was enabled by the Implementation Considerations in the Token Binding HTTPS specification being added to make it clear that Token Binding implementations will enable using the Referred Token Binding ID in this manner. Protected Resource Metadata was also defined.
Thanks to Brian Campbell for clarifications on the differences between token binding of access tokens issued from the authorization endpoint versus those issued from the token endpoint.
The specification is available at:
An HTML-formatted version is also available at:
Draft -02 of the Authentication Method Reference Values specification addresses the Working Group Last Call (WGLC) comments received. It adds an example to the multiple-channel authentication description and moves the “amr” definition into the introduction. No normative changes were made.
The specification is available at:
An HTML-formatted version is also available at:
The initial working group draft of the OAuth Token Binding specification has been published. It has the same content as draft-jones-oauth-token-binding-00, but with updated references. This specification defines how to perform token binding for OAuth access tokens and refresh tokens. Note that the access token mechanism is expected to change shortly to use the Referred Token Binding, per working group discussions at IETF 96 in Berlin.
The specification is available at:
An HTML-formatted version is also available at:
The existing OAuth 2.0 Authorization Server Metadata specification has now been joined by a related OAuth 2.0 Protected Resource Metadata specification. This means that JSON metadata formats are now defined for all the OAuth 2.0 parties: clients, authorization servers, and protected resources.
The most significant addition to the OAuth 2.0 Authorization Server Metadata specification is enabling signed metadata, represented as claims in a JSON Web Token (JWT). This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration. Signed metadata can also be used for protected resource metadata.
For use cases in which the set of protected resources used with an authorization server are enumerable, the authorization server metadata specification now defines the “protected_resources” metadata value to list them. Likewise, the protected resource metadata specification defines an “authorization_servers” metadata value to list the authorization servers that can be used with a protected resource, for use cases in which those are enumerable.
The specifications are available at:
HTML-formatted versions are also available at:
This draft distinguishes between iris and retina scan biometrics, as requested by NIST, and adds a paragraph providing readers more context at the end of the introduction, which was requested by the chairs during the call for adoption. The OpenID Connect MODRNA Authentication Profile 1.0 specification, which uses “amr” values defined by this specification, is now also referenced.
The specification is available at:
An HTML formatted version is also available at:
The only change to the new draft is to use terminology more consistently. Specifically, it changes the terms “issuer URL” and “configuration information location” to “issuer identifier” so that consistent terminology is used for this. (This is the terminology used by OpenID Connect.)
This is being posted in preparation for discussions at the upcoming OAuth Security Workshop in Trier, Germany and the IETF 96 meeting in Berlin.
The specification is available at:
An HTML-formatted version is also available at:
Two new related specifications define syntax and semantics for applying Token Binding to OAuth Access Tokens and Refresh Tokens and to OpenID Connect ID Tokens. draft-jones-oauth-token-binding contains the OAuth portions. openid-connect-token-bound-authentication-1_0 contains the OpenID Connect portions.
These are being submitted now to hopefully enable end-to-end implementations and interop testing of Token Bound Access Tokens, Refresh Tokens, and ID Tokens across multiple platforms before the Token Binding specifications are finalized.
The OAuth specification is available at:
The OpenID Connect specification is available at:
Thanks to Andrei Popov, Yordan Rouskov, John Bradley, and Brian Campbell for reviews of earlier versions of these specifications and to Dirk Balfanz and William Denniss for some earlier discussions providing input to these specifications.
The Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) specification is now RFC 7800 — an IETF standard. The abstract describes the specification as:
This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of-possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.
Thanks to John Bradley, Hannes Tschofenig, and the OAuth working group for their work on this specification.
A new draft of “OAuth 2.0 Token Exchange” has been published addressing review comments on the prior draft. The changes from -03 are listed here:
resource” and “audience” request parameters can be used at the same time (via http://www.ietf.org/mail-archive/web/oauth/current/msg15335.html).Bearer” and “urn:ietf:params:oauth:token-type:access_token” in one of the responses (via http://www.ietf.org/mail-archive/web/oauth/current/msg15335.html).urn:ietf:params:oauth:token-type:id_token, since some use cases perform token exchanges for ID Tokens and no URI to indicate that a token is an ID Token had previously been defined.The specification is available at:
An HTML-formatted version is also available at:
Thanks to Brian Campbell for doing most of the edits for this release.
The OAuth 2.0 Device Flow specification has been tidied up to apply spelling and grammar corrections and add the Document History appendix. No normative changes were made. Again, if you’re using an OAuth device flow, please let us know whether your implementation matches this specification, and if not, let us know how it differs.
The specification is available at:
An HTML-formatted version is also available at:
Thanks to William Denniss for creating the initial working group version of the OAuth 2.0 Device Flow specification. The abstract of the specification is:
The device flow is suitable for OAuth 2.0 clients executing on devices which do not have an easy data-entry method (e.g., game consoles, TVs, picture frames, and media hubs), but where the end-user has separate access to a user-agent on another computer or device (e.g., desktop computer, a laptop, a smart phone, or a tablet).
Note: This version of the document is a continuation of an earlier, long expired draft. The content of the expired draft has been copied almost unmodified. The goal of the work on this document is to capture deployment experience.
If you’re using an OAuth device flow, please let us know whether this specification matches your usage, and if not, how yours differs.
The specification is available at:
An HTML-formatted version is also available at:
In response to working group input, this version of the OAuth Discovery specification has been pared down to its essence — leaving only the features that are already widely deployed. Specifically, all that remains is the definition of the authorization server discovery metadata document and the metadata values used in it. The WebFinger discovery logic has been removed. The relationship between the issuer identifier URL and the well-known URI path relative to it at which the discovery metadata document is located has also been clarified.
Given that this now describes only features that are in widespread deployment, the editors believe that this version is ready for working group last call.
The specification is available at:
An HTML-formatted version is also available at:
This draft of the Authentication Method Reference Values specification incorporates OAuth working group feedback from the call for adoption. The primary change was to remove the “amr_values” request parameter, so that “amr” values can still be returned as part of an authentication result, but cannot be explicitly requested. Also, noted that OAuth 2.0 is inadequate for authentication without employing appropriate extensions and changed the IANA registration procedure to no longer require a specification.
The specification is available at:
An HTML-formatted version is also available at:
We have created the initial working group version of OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative changes.
The specification is available at:
An HTML-formatted version is also available at:
The OAuth Discovery specification has been updated to add metadata values for revocation, introspection, and PKCE. Changes were:
revocation_endpoint_auth_methods_supported” and “revocation_endpoint_auth_signing_alg_values_supported” for the revocation endpoint.introspection_endpoint_auth_methods_supported” and “introspection_endpoint_auth_signing_alg_values_supported” for the introspection endpoint.code_challenge_methods_supported” for PKCE.The specification is available at:
An HTML-formatted version is also available at:
Please check out this important post today on the Active Directory Team Blog: “For Developers: Important upcoming changes to the v2.0 Auth Protocol“. While the title may not be catchy, it’s content is compelling — particularly for developers.
The post describes the converged identity service being developed by Microsoft that will enable people to log in either with an individual account (Microsoft Account) or an organizational account (Azure Active Directory). This is a big deal, because developers will soon have a single identity service that their applications can use for both kinds of accounts.
The other big deal is that the changes announced are a concrete demonstration of Microsoft’s ongoing commitment to interoperability and support for open identity standards — in this case, OpenID Connect. As the post says:
The primary motivation for introducing these changes is to be compliant with the OpenID Connect standard specification. By being OpenID Connect compliant, we hope to minimize differences between integrating with Microsoft identity services and with other identity services in the industry. We want to make it easy for developers to use their favorite open source authentication libraries without having to alter the libraries to accommodate Microsoft differences.
If you’re a developer, please do heed the request in the post to give the service a try now as it approaches General Availability (GA). Enjoy!
John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up Mitigation draft. Changes were:
state” token request parameter.The specification is available at:
An HTML-formatted version is also available at:
Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up. This note announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks covered in the advisory. The abstract of the specification is:
This specification defines an extension to The OAuth 2.0 Authorization Framework that enables an authorization server to provide a client using it with a consistent set of metadata about itself. This information is returned in the authorization response. It can be used by the client to prevent classes of attacks in which the client might otherwise be tricked into using inconsistent sets of metadata from multiple authorization servers, including potentially using a token endpoint that does not belong to the same authorization server as the authorization endpoint used. Recent research publications refer to these as “IdP Mix-Up” and “Malicious Endpoint” attacks.
The gist of the mitigation is having the authorization server return the client ID and its issuer identifier (a value defined in the OAuth Discovery specification) so that the client can verify that it is using a consistent set of authorization server configuration information, that the client ID is for that authorization server, and in particular, that the client is not being confused into sending information intended for one authorization server to a different one. Note that these attacks can only be made against clients that are configured to use more than one authorization server.
Please give the draft a quick read and provide feedback to the OAuth working group. This draft is very much a starting point intended to describe both the mitigations and the decisions and analysis remaining before we can be confident in standardizing a solution. Please definitely read the Security Considerations and Open Issues sections, as they contain important information about the choices made and the decisions remaining.
Special thanks go to Daniel Fett (University of Trier), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Guido Schmitz (University of Trier) for notifying us of the attacks and working with us both on understanding the attacks and on developing mitigations. Thanks too to Hannes Tschofenig for organizing a meeting on this topic last month and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting.
The specification is available at:
An HTML-formatted version is also available at:
Proof-of-Possession Key Semantics for JWTs draft -11 addresses Sec-Dir review comments by Chris Lonvick and ballot comments by Stephen Farrell. This should enable clearing the “point raised” status from yesterday’s IESG telechat and progressing the document to the RFC Editor.
The specification is available at:
An HTML-formatted version is also available at:
Powered by WordPress & Theme by Anders Norén