Mike Jones: self-issued

Musings on Digital Identity

Category: Specifications Page 23 of 25

Initial IETF JOSE Specs: JWS, JWE, JWK, JWA

By

On January 18, 2012

In Cryptography, JSON, Specifications

IETF logoThe initial versions of the IETF JSON Object Signing and Encryption (JOSE) specifications are now available. They are:

  • JSON Web Signature (JWS) — Digital signature/HMAC specification
  • JSON Web Encryption (JWE) — Encryption specification
  • JSON Web Key (JWK) — Public key specification
  • JSON Web Algorithms (JWA) — Algorithms and identifiers specification

They are refactored from the previous individual submission versions to move algorithms and identifiers into the separate JSA specification, per the working group charter. Also, per the working group’s input, the terminology usage has been changed to no longer call both digital signatures and HMACs “signatures”. The JOSE versions contain no normative changes from the individual submission versions.

These specifications are available at:

HTML formatted versions are 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!

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:

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:

JSON Web Encryption (JWE) draft -00

By

On September 6, 2011

In Claims, JSON, Specifications

I’m pleased to announce the publication of the first draft of the JSON Web Encryption (JWE) specification. It enables JSON-based encryption of content in a parallel manner to how the JSON Web Signature (JWS) specification enables JSON-based signing of content.

My thanks to John Bradley, Nat Sakimura, Eric Rescorla, and Joe Hildebrand for helping make this initial version a reality!

The specification 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:

JSON Web Key (JWK) draft -01

By

On July 25, 2011

In Cryptography, JSON, Specifications

I’ve published JSON Web Key (JWK) draft -01. It contains the following changes:

  • Changed “algorithm” member value for Elliptic Curve keys from “ECDSA” to “EC”, since Elliptic Curve keys can be used with more algorithms than just the Elliptic Curve Digital Signature Algorithm (ECDSA).
  • Added OPTIONAL “use” member to identify intended key usage, especially since the same Elliptic Curve key should not be used for both signing and encryption operations.

The specification is available at these locations:

JSON Web Token (JWT) Draft -05

By

On July 11, 2011

In Claims, JSON, Specifications

I posted JSON Web Token (JWT) draft -05 today, with the only change being to define an optional “nbf” (not before) claim that is distinct from the “iat” (issued at) claim. (This more closely parallels the capabilities of SAML tokens, where there are NotBefore, NotAfter, and IssueInstant values.) The “nbf” and “exp” claims should be used for bounding the token validity period, whereas “iat” should be used to determine token age.

The draft is available at these locations:

Simple Web Discovery (SWD) Refresh

By

On July 11, 2011

In JSON, Specifications

I posted Simple Web Discovery (SWD) draft -01 today because -00 was about to expire. No normative changes were made.

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:

Page 23 of 25

Previous

Next

Powered by WordPress & Theme by Anders Norén