Mike Jones: self-issued

Musings on Digital Identity

Category: OAuth Page 11 of 12

Vote to Approve OpenID Connect Implementer’s Drafts Under Way

By

On February 8, 2012

In Claims, JSON, OAuth, OpenID, Specifications

OpenID logoThe vote to approve six OpenID Connect specification drafts as OpenID Foundation Implementer’s Drafts is under way. To vote, go to https://openid.net/foundation/members/polls/62 and log in using your OpenID by the morning of Wednesday, February 15th. For more information about OpenID Connect, visit http://openid.net/connect/.

OAuth 2.0 Bearer Token Specification Draft -16

By

On January 30, 2012

In OAuth, Specifications

OAuth logoDraft 16 of the OAuth 2.0 Bearer Token Specification has been published. This version contains a proposed resolution to the auth-param syntax issue that has been reviewed by Julian Reschke, Mark Nottingham, and the OAuth WG chairs. It also addresses the Gen-ART review comments by Alexey Melnikov.

It contains the following changes:

  • Use the HTTPbis auth-param syntax for Bearer challenge attributes.
  • Dropped the sentence “The realm value is intended for programmatic use and is not meant to be displayed to end users”.
  • Reordered form-encoded body parameter description bullets for better readability.
  • Added [USASCII] reference.

The draft is available at:

An HTML-formatted version is available at:

OpenID Connect Implementer’s Draft Review

By

On December 23, 2011

In Claims, Federation, JSON, OAuth, OpenID, Specifications

OpenID logoOpenID Connect is a simple identity layer built on top of OAuth 2.0. It enables clients to verify the identity of and to obtain basic profile information about an end-user. It uses RESTful protocols and JSON data structures to provide a low barrier to entry. The design philosophy behind OpenID Connect is “make simple things simple and make complex things possible”.

OpenID Connect is designed to cover a range of scenarios and use cases including Internet, enterprise, cloud, and mobile, to span security & privacy requirements from non-sensitive information to highly secure, and to span sophistication of claims usage, from basic default claims to specific requested claims to aggregated and distributed claims. It maximizes the simplicity of implementations by reusing existing OAuth 2.0, JWT, and SWD specs and employing a modular structure, allowing deployments to utilize only the pieces they need.

OpenID Connect has a number of key differences from OpenID 2.0. Among them are: support for native client applications, identifiers using e-mail address format, standard UserInfo endpoint for retrieving basic claims about the end-user, being designed to work well on mobile phones, use of JSON/REST rather than XML, support for encryption and higher LoAs, and support for distributed and aggregated claims.

Today marks a milestone in the OpenID Connect specification development: the OpenID Foundation announced that the current set of drafts is being reviewed for approval as Implementer’s Drafts. An Implementer’s Draft is a stable version of a specification intended for implementation and deployment that provides intellectual property protections to implementers of the specification. These drafts are the product of incorporating months of feedback from implementers and reviewers of earlier specification drafts, including feedback resulting from interop testing. Thanks to all of you who contributed to the development of OpenID Connect!

OAuth 2.0 Bearer Token Specification Draft -15

By

On December 18, 2011

In OAuth, Specifications

OAuth logoDraft 15 of the OAuth 2.0 Bearer Token Specification has been published. It contains the following changes:

  • Clarified that form-encoded content must consist entirely of ASCII characters.
  • Added TLS version requirements.
  • Applied editorial improvements suggested by Mark Nottingham during the APPS area review.

The draft is available at:

An HTML-formatted version is available at:

SWD, JWT, JWS, JWE, JWK, and OAuth JWT Profile specs updated

By

On December 14, 2011

In Claims, Cryptography, JSON, OAuth, Specifications

OAuth logoNew versions of the SWD, JWT, JWS, JWE, JWK, and OAuth JWT Profile specs have been posted. They address a number of comments received on the JOSE list and at the JOSE WG meeting in Taipei and make a number of clarifications, corrections, and editorial improvements.

The only breaking change made was to use short names in the JWK spec, as suggested during the WG meeting in Taipei, since JWK Key Object values are used as JWE Ephemeral Public Keys, and so compactness matters. This also required corresponding changes in the JWE spec.

This checkin moves the definitions of the “prn” (principal) and “jti” (JSON Token ID) claims from other specs into the JWT spec, as both of these claims enable general token functionality that is likely to be used in many contexts.

This checkin is intended to be the last set of individual submissions of the JWS, JWE, and JWK drafts before they are refactored and submitted to the JOSE WG as working group drafts. The primary changes requested by the JOSE WG but not yet done are to break the algorithm profiles and identifiers out into a new spec and to rework the terminology in the signature spec to use different terms for digital signature and HMAC integrity operations.

See the Document History sections of each document for a detailed description of the changes made. These documents are available at:

HTML-formatted versions are available at:

Special thanks to Jim Schaad for his detailed comments on the JWS and JWE specs, many of which were incorporated into these drafts.

OAuth 2.0 JWT Bearer Token Profiles Specification Draft -02

By

On November 15, 2011

In Claims, JSON, OAuth, Specifications

OAuth logoDraft 02 of the OAuth 2.0 JWT Bearer Token Profiles Specification has been published. It contains the following changes:

  • Removed remaining vestiges of normative text talking about SAML that remained from the SAML Profile draft.
  • Replaced all references where the reference is used as if it were part of the sentence (such as “defined by [I-D.whatever]”) with ones where the specification name is used, followed by the reference (such as “defined by Whatever [I-D.whatever]”).

The draft is available at these locations:

OAuth 2.0 Bearer Token Specification Draft -14

By

On November 11, 2011

In OAuth, Specifications

OAuth logoDraft 14 of the OAuth 2.0 Bearer Token Specification has been published. It contains the following changes:

  • Changes made in response to review comments by Security Area Director Stephen Farrell. Specifically:
  • Strengthened warnings about passing an access token as a query parameter and more precisely described the limitations placed upon the use of this method.
  • Clarified that the realm attribute MAY included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [I D.ietf httpbis p7 auth].
  • Normatively stated that “the token integrity protection MUST be sufficient to prevent the token from being modified”.
  • Added statement that “TLS is mandatory to implement and use with this specification” to the introduction.
  • Stated that TLS MUST be used with “a ciphersuite that provides confidentiality and integrity protection”.
  • Added “As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources” to the Threat Mitigation section.
  • Clarified that putting a validity time field inside the protected part of the token is one means, but not the only means, of limiting the lifetime of the token.
  • Dropped the confusing phrase “for instance, through the use of TLS” from the sentence about confidentiality protection of the exchanges.
  • Reference RFC 6125 for identity verification, rather than RFC 2818.
  • Stated that the token MUST be protected between front end and back end servers when the TLS connection terminates at a front end server that is distinct from the actual server that provides the resource.
  • Stated that bearer tokens MUST not be stored in cookies that can be sent in the clear in the Threat Mitigation section.
  • Replaced sole remaining reference to [RFC2616].
  • Replaced all references where the reference is used as if it were part of the sentence (such as “defined by [I-D.whatever]”) with ones where the specification name is used, followed by the reference (such as “defined by Whatever [I-D.whatever]”).
  • Other on-normative editorial improvements.

The draft is available at these locations:

Updated OAuth JWT Bearer Token Profile and OAuth Assertion Profile specs

By

On October 31, 2011

In Claims, JSON, OAuth, Specifications

OAuth logoI updated the OAuth JWT Bearer Token Profile spec to track the changes made in the OAuth SAML Bearer Token Profile spec. Changes were:

draft-jones-oauth-jwt-bearer-01:

  • Merged in changes from draft-ietf-oauth-saml2-bearer-09. In particular, this draft now uses draft-ietf-oauth-assertions, rather than being standalone. It also now defines how to use JWT bearer tokens both for Authorization Grants and for Client Authentication.

Meanwhile, Chuck Mortimore updated the OAuth Assertion Profile spec to incorporate working group feedback. In particular, the client_id parameter is now optional, as in some cases it may be carried in the assertion, rather than as a parameter.

The specs are available in the standard places. The HTML versions can be found at these locations:

Feedback welcome!

OAuth 2.0 Bearer Token Specification Draft -13

By

On October 31, 2011

In OAuth, Specifications

OAuth logoDraft 13 of the OAuth 2.0 Bearer Token Specification has been published. It contains one change:

  • At the request of Hannes Tschofenig, made ABNF changes to make it clear that no special WWW-Authenticate response header field parsers are needed. The scope, error-description, and error-uri parameters are all now defined as quoted-string in the ABNF (as error already was). Restrictions on these values that were formerly described in the ABNFs are now described in normative text instead.

Hopefully this is *really* the last set of changes before IESG review!

The draft is available at these locations:

OAuth 2.0 Bearer Token Specification Draft -12

By

On October 27, 2011

In OAuth, Specifications

OAuth logoDraft 12 of the OAuth 2.0 Bearer Token Specification has been published. I believe that the chairs will be submiting this version to the IESG. It contains the following changes:

  • Made non-normative editorial changes that Hannes Tschofenig requested be applied prior to forwarding the specification to the IESG.
  • Added rationale for the choice of the b64token syntax.
  • Added rationale stating that receivers are free to parse the scope attribute using a standard quoted-string parser, since it will correctly process all legal scope values.
  • Added additional active working group contributors to the Acknowledgements section.

The draft is available at these locations:

OAuth 2.0 Bearer Token Specification Draft -11

By

On October 25, 2011

In OAuth, Specifications

OAuth logoDraft 11 of the OAuth 2.0 Bearer Token Specification has been published. This version is intended for submission to the IESG. It contains the following change:

  • Replaced uses of <"> with DQUOTE to pass ABNF syntax check.

The draft is available at these locations:

OAuth 2.0 Bearer Token Specification Draft -10

By

On October 20, 2011

In OAuth, Specifications

OAuth logoDraft 10 of the OAuth 2.0 Bearer Token Specification has been published, which incorporates consensus decisions reached since Working Group Last Call feedback. It closes all open issues. It contains the following changes:

  • Removed the #auth-param option from Authorization header syntax (leaving only the b64token syntax).
  • Restricted the scope value character set to %x21 / %x23-5B / %x5D-7E (printable ASCII characters excluding double-quote and backslash). Indicated that scope is intended for programmatic use and is not meant to be displayed to end users.
  • Restricted the character set for error_description strings to SP / VCHAR and indicated that they are not meant to be displayed to end users.
  • Included more description in the Abstract, since Hannes Tschofenig indicated that the RFC editor would require this.
  • Changed “Access Grant” to “Authorization Grant”, as was done in the core spec.
  • Simplified the introduction to the Authenticated Requests section.

The draft is available at these locations:

OAuth 2.0 Bearer Token Specification Draft -09

By

On September 23, 2011

In OAuth, Specifications

OAuth logoDraft 09 of the OAuth 2.0 Bearer Token Specification has been published, which incorporates Working Group Last Call feedback. It contains the following changes:

  • Use definitions from [I-D.ietf-httpbis-p7-auth] rather than [RFC2617].
  • Update credentials definition to conform to [I-D.ietf-httpbis-p7-auth].
  • Further clarified that query parameters may occur in any order.
  • Specify that error_description is UTF-8 encoded (matching the core specification).
  • Registered “Bearer” Authentication Scheme in Authentication Scheme Registry defined by [I-D.ietf-httpbis-p7-auth].
  • Updated references to oauth-v2, httpbis-p1-messaging, and httpbis-p7-auth drafts.
  • Other wording improvements not introducing normative changes.

The draft is available at these locations:

OAuth 2.0 Bearer Token Specification draft -08

By

On July 27, 2011

In OAuth, Specifications

OAuth logoI’ve published draft 08 of the OAuth Bearer Token Specification. It contains the following changes:

  • Updated references to oauth-v2 and httpbis drafts.
  • Added missing comma in error response example.

It contains no normative changes. This draft is the subject of working group last call.

The draft is available at these locations:

OAuth 2.0 Bearer Token Specification draft -06

By

On June 22, 2011

In OAuth, Specifications

OAuth logoI’ve published draft 06 of the OAuth Bearer Token Specification. It contains the following changes:

  • Changed parameter name bearer_token to access_token, per working group consensus.
  • Changed HTTP status code for invalid_request error code from HTTP 401 (Unauthorized) back to HTTP 400 (Bad Request), per input from HTTP working group experts.

It doesn’t change the use of 403 (Forbidden) to (401) Unauthorized as had been discussed as a possibility, also due to input from the same HTTP working group experts.

The draft is available at these locations:

OAuth 2.0 Bearer Token Specification draft -05

By

On May 21, 2011

In OAuth, Specifications

OAuth logoIn preparation for the OAuth working group meeting on Monday, I’ve published draft 05 of the OAuth Bearer Token Specification, incorporating input received from the OAuth design team. The changes in this draft are:

  • Removed OAuth Errors Registry, per design team input.
  • Changed HTTP status code for invalid_request error code from HTTP 400 (Bad Request) to HTTP 401 (Unauthorized) to match HTTP usage [[ change pending working group consensus ]].
  • Added missing quotation marks in error-uri definition.
  • Added note to add language and encoding information to error_description if the core specification does.
  • Explicitly reference the Augmented Backus-Naur Form (ABNF) defined in [RFC5234].
  • Use auth-param instead of repeating its definition, which is ( token “=” ( token / quoted-string ) ).
  • Clarify security considerations about including an audience restriction in the token and include a recommendation to issue scoped bearer tokens in the summary of recommendations.

The draft is available at these locations:

The Emerging JSON-Based Identity Protocol Suite

By

On April 28, 2011

In Claims, Cryptography, Documentation, Events, JSON, OAuth, OpenID, Specifications

W3C logoMy submission to the W3C Workshop on Identity in the Browser discusses The Emerging JSON-Based Identity Protocol Suite. The abstract is:

A new set of open identity protocols is emerging that utilizes JSON data representations and simple REST-based communication patterns. These protocols and data formats are intentionally designed to be easy to use in browsers and modern web development environments.

I hope you’ll find it worthwhile reading. I’m looking forward to discussing it with many of you at the workshop!

OAuth 2.0 Bearer Token Specification draft -04

By

On March 31, 2011

In OAuth, Specifications

OAuth logoI’ve published draft 04 of the OAuth Bearer Token Specification. All changes were in response to working group last call feedback on draft 03. The changes in this draft were:

  • Added Bearer Token definition in Terminology section.
  • Changed parameter name “oauth_token” to “bearer_token”.
  • Added realm parameter to “WWW-Authenticate” response to comply with [RFC2617].
  • Removed “[ RWS 1#auth-param ]” from “credentials” definition since it did not comply with the ABNF in [I-D.ietf-httpbis-p7-auth].
  • Removed restriction that the “bearer_token” (formerly “oauth_token”) parameter be the last parameter in the entity-body and the HTTP request URI query.
  • Do not require WWW-Authenticate Response in a reply to a malformed request, as an HTTP 400 Bad Request response without a WWW-Authenticate header is likely the right response in some cases of malformed requests.
  • Removed OAuth Parameters registry extension.
  • Numerous editorial improvements suggested by working group members.

The draft is available at these locations:

OAuth JWT Bearer Token Profile

By

On March 16, 2011

In Claims, JSON, OAuth, Specifications

OAuth logoI’ve just published an OAuth JWT Bearer Token Profile. It defines a means of using a JSON Web Token (JWT) bearer token to request an OAuth 2.0 access token. This profile is intentionally strongly based upon the SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 by Brian Campbell and Chuck Mortimore; it borrows some text from the SAML profile with their permission. Thanks Brian and Chuck, for supporting the writing of this profile and for your reviews of preliminary drafts.

The profile draft is available at these locations:

https://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.html
https://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.txt
https://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.xml
https://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html (will point to new versions as they are posted)
https://self-issued.info/docs/draft-jones-oauth-jwt-bearer.txt (will point to new versions as they are posted)
https://self-issued.info/docs/draft-jones-oauth-jwt-bearer.xml (will point to new versions as they are posted)
http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available)

I will also submit this as a formal Internet draft after the IETF tool re-opens for submissions (on March 28th).

OAuth 2.0 Bearer Token Specification draft -03

By

On February 25, 2011

In OAuth, Specifications

OAuth logoI’ve published draft 03 of the OAuth Bearer Token Specification. It contains one breaking change relative to draft 02 that was voted on by the working group: changing the “OAuth2” OAuth access token type name to “Bearer”. The full set of changes in this draft is:

  • Restored the WWW-Authenticate response header functionality deleted from the framework specification in draft 12 based upon the specification text from draft 11.
  • Augmented the OAuth Parameters registry by adding two additional parameter usage locations: “resource request” and “resource response”.
  • Registered the “oauth_token” OAuth parameter with usage location “resource request”.
  • Registered the “error” OAuth parameter.
  • Created the OAuth Error registry and registered errors.
  • Changed the “OAuth2” OAuth access token type name to “Bearer”.

The draft is available at these locations:

Your feedback is solicited.

Page 11 of 12

Previous

Next

Powered by WordPress & Theme by Anders Norén