Musings on Digital Identity

Author: Mike Jones Page 25 of 33

Building the Internet's missing identity layer

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

JSON Web Key (JWK) Specification

I’ve posted the JSON Web Key (JWK) specification for representing public keys as JSON objects based on the decisions made at the last IIW. The introduction to the spec reads:

A JSON Web Key (JWK) is a JSON data structure that represents a set of public keys as a JSON object. The JWK format is used to represent bare keys; representing certificate chains is an explicit non-goal of this specification. JSON Web Keys are referenced in JSON Web Signatures (JWSs) using the jku (JSON Key URL) header parameter.

An example from the spec is:

{"keyvalues":
  [
    {"algorithm":"ECDSA",
     "curve":"P-256",
     "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
     "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
     "keyid":"1"},

    {"algorithm":"RSA",
     "modulus": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "exponent":"AQAB",
     "keyid":"2011-04-29"}
  ]
}

The specification is available at these locations:

I also updated the description of the JSON Web Signature (JWS) header parameter “jku” (JSON Key URL) to reference the JWK spec in draft -02.

The Emerging JSON-Based Identity Protocol Suite

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!

AD FS 2.0 Interop Step-By-Step Guide: IBM Tivoli Federated Identity Manager

Microsoft has published the fifth in a series of step-by-step guides on configuring AD FS 2.0 to interoperate with partner products. This guide describes how to configure AD FS 2.0 and IBM Tivoli Federated Identity Manager to federate using the SAML 2.0 protocol. The guide is available in HTML format and soon also Word and PDF. Thanks again to author Dave Martinez for making this series a reality!

OAuth 2.0 Bearer Token Specification draft -04

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:

JSON Web Token (JWT) Draft -04

Draft -04 of the JSON Web Token (JWT) specification is available. It corrects a typo found by John Bradley in -03.

The draft is available at these locations:

JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs

As promised, I have split the contents of the JWT spec draft-jones-json-web-token-01 into two simpler specs:

These should have introduced no semantic changes from the previous spec.

I then applied the feedback that I received since JWT -01 and created revised versions of the split specs:

The only breaking change introduced was that x5t (X.509 Certificate Thumbprint) is now a SHA-1 hash of the DER-encoded certificate, rather than a SHA-256 has, as SHA-1 is the prevailing existing practice for certificate thumbprint calculations. See the Document History sections for details on each change made.

.txt and .xml versions are also available. I plan to publish these as IETF drafts once the submission window re-opens on Monday. Feedback welcome!

P.S. Yes, work on the companion encryption spec is now under way…

Join me at the Internet Identity Workshop

IIW Banner

Come be part of moving Internet identity forward! The early bird discount is available through Friday, March 25th. And as always, Microsoft will be sponsoring a workshop dinner. See you at IIW!

Page 25 of 33

Powered by WordPress & Theme by Anders Norén