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:
Author: Mike Jones Page 15 of 33
Building the Internet's missing identity layer
The W3C approved the Web Authentication Working Group charter today and announced the first working group meeting, which will be on March 4, 2016 in San Francisco. The initial input to the working group was the member submission of FIDO 2.0 Platform Specifications.
The OAuth Discovery specification has been updated to add metadata values for revocation, introspection, and PKCE. Changes were:
- Added “
revocation_endpoint_auth_methods_supported” and “revocation_endpoint_auth_signing_alg_values_supported” for the revocation endpoint. - Added “
introspection_endpoint_auth_methods_supported” and “introspection_endpoint_auth_signing_alg_values_supported” for the introspection endpoint. - Added “
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:
- Simplified by no longer specifying the signed JWT method for returning the mitigation information.
- Simplified by no longer depending upon publication of a discovery metadata document.
- Added the “
state” token request parameter. - Added examples.
- Added John Bradley as an editor.
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:
JWS Unencoded Payload Option draft -09 addresses Stephen Farrell’s IESG review. In particular, the use of “crit” is now required with “b64“. This should be the version that is sent to the RFC Editor.
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:
JWS Unencoded Payload Option draft -08 was published for consideration on the IESG telechat later today. The changes addressed Gen-Art review comments by Robert Sparks, Ops-Dir review comments by Stefan Winter, and ballot comments by Benoit Claise and Ben Campbell. Normative text was added describing the use of “crit” with “b64“.
The specification is available at:
An HTML-formatted version is also available at:
Proof-of-Possession Key Semantics for JWTs draft -10 was published for consideration on the IESG telechat later today. All changes were editorial and addressed ballot comments by Barry Leiba.
The specification is available at:
An HTML-formatted version is also available at:
Authentication Method Reference Values draft -04 added the values “face” (facial recognition), “geo” (geolocation), “hwk” (proof-of-possession of a hardware-secured key), “pin” (Personal Identification Number or pattern), and “swk” (proof-of-possession of a software-secured key), and removed the value “pop” (proof-of-possession), based on input from members of the OpenID Foundation MODRNA working group.
The specification is available at:
An HTML formatted version is also available at:
I’m happy to report that a substantially revised OAuth 2.0 Token Exchange draft has been published that enables a broad range of use cases, while still remaining as simple as possible. This draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working group input from the in-person discussions in Prague and mailing list discussions. Thanks to all for your interest in and contributions to OAuth Token Exchange! Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this draft.
The core functionality remains token type independent. That said, new claims are also defined to enable representation of delegation actors in JSON Web Tokens (JWTs). Equivalent claims could be defined for other token types by other specifications.
See the Document History section for a summary of the changes made. Please check it out!
The specification is available at:
An HTML-formatted version is also available at:
Draft -07 of the JWS Unencoded Payload Option specification addresses Gen-Art review comments by Robert Sparks and Sec-Dir review comments by Benjamin Kaduk. Thanks to both of you for your useful reviews!
The specification is available at:
An HTML-formatted version is also available at:
After input from many interested people, IETF Security Area Director Kathleen Moriarty decided that the right place for the CBOR Web Token (CWT) work is the ACE working group. Today Erik Wahlström posted a new draft of the CBOR Web Token (CWT) specification that is intended for ACE.
This version of the spec references the JSON Web Token (JWT) claim definitions, rather than repeating them, and intentionally only includes equivalents of the claims defined by the JWT spec. Other CWT claims, including those needed by ACE applications, will be defined by other specs and registered in the CWT claims registry.
The specification is available at:
An HTML-formatted version is also available at:
Authentication Method Reference Values draft -03 adds the criterion to the IANA registration instructions that the value being registered be in actual use.
The specification is available at:
An HTML formatted version is also available at:
Proof-of-Possession Key Semantics for JWTs draft -08 addresses additional Area Director review comments. A security consideration about utilizing audience restriction in combination with proof-of-possession was added. Thanks to John Bradley for working on the additional wording with me.
The specification is available at:
An HTML formatted version is also available at:
I’m pleased to announce that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery specification. This fills a hole in the current OAuth specification set that is necessary to achieve interoperability. Indeed, the Interoperability section of OAuth 2.0 states:
In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery). Without these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate.
This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.
This specification enables discovery of both endpoint locations and authorization server capabilities.
This specification is based upon the already widely deployed OpenID Connect Discovery 1.0 specification and is compatible with it, by design. The OAuth Discovery spec removes the portions of OpenID Connect Discovery that are OpenID specific and adds metadata values for Revocation and Introspection endpoints. It also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User, and Issuer to their OAuth underpinnings, respectively Authorization Server, Client, Resource Owner, and the newly introduced Configuration Information Location. Some identifiers with names that appear to be OpenID specific were retained for compatibility purposes; despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific to OpenID Connect.
The specification is available at:
An HTML-formatted version is also available at:
Proof-of-Possession Key Semantics for JWTs draft -07 addresses review comments by our Area Director, Kathleen Moriarty, as well as comments by Hannes Tschofenig and Justin Richer. This should hopefully enable IETF last call.
The specification is available at:
An HTML formatted version is also available at:
Draft -06 of the JWS Unencoded Payload Option specification addresses review comments by our Area Director, Kathleen Moriarty. This should hopefully enable IETF last call.
The specification is available at:
An HTML formatted version is also available at:
Draft -05 of the JWS Unencoded Payload Option specification reworked the security considerations text on preventing confusion between encoded and unencoded payloads.
The specification is available at:
An HTML formatted version is also available at: