Mike Jones: self-issued

Musings on Digital Identity

Month: October 2011

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!

Updated versions of JWT, JWS, JWE, and JWK specs

By

On October 31, 2011

In Claims, Cryptography, JSON, Specifications

I’ve posted updated versions of the JSON Web Token (JWT), JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. No changes should be required to any existing deployments as a result of these updates.

The primary thrust of these changes was updating the JWT spec to describe how to create and process encrypted JWTs. (The previous JWT spec pre-dated publication of the JWE spec.) I also removed duplicate content from the JWT spec describing the steps to sign JWTs and instead simply referenced it in the JWS spec. Numerous suggestions on improving the specifications from the WOES and JOSE lists were also incorporated. The changelog entries are as follows:

draft-jones-json-web-token-06:

  • Reference and use content from [JWS] and [JWE], rather than repeating it here.
  • Simplified terminology to better match JWE, where the terms “JWT Header” and “Encoded JWT Header” are now used, for instance, rather than the previous terms “Decoded JWT Header Segment” and “JWT Header Segment”. Also changed to “Plaintext JWT” from “Unsigned JWT”.
  • Describe how to perform nested encryption and signing operations.
  • Changed “integer” to “number”, since that is the correct JSON type.
  • Changed StringAndURI to StringOrURI.

draft-jones-json-web-signature-03:

  • Simplified terminology to better match JWE, where the terms “JWS Header” and “Encoded JWS Header”, are now used, for instance, rather than the previous terms “Decoded JWS Header Input” and “JWS Header Input”. Likewise the terms “JWS Payload” and “JWS Signature” are now used, rather than “JWS Payload Input” and “JWS Crypto Output”.
  • The jku and x5u URLs are now required to be absolute URLs.
  • Removed this unnecessary language from the kid description: “Omitting this parameter is equivalent to setting it to an empty string”.
  • Changed StringAndURI to StringOrURI.

draft-jones-json-web-encryption-01:

  • Changed type of Ephemeral Public Key (epk) from string to JSON object, so that a JWK Key Object value can be used directly.
  • Specified that the Digest Method for ECDH-ES is SHA-256. (The specification was previously silent about the choice of digest method.)
  • The jku and x5u URLs are now required to be absolute URLs.
  • Removed this unnecessary language from the kid description: “Omitting this parameter is equivalent to setting it to an empty string”.
  • Use the same language as RFC 2616 does when describing GZIP message compression.

draft-jones-json-web-key-02:

  • Editorial changes to have this spec better match the JWT, JWS, and JWE specs. No normative changes.

 

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:

Powered by WordPress & Theme by Anders Norén