Archive for May, 2012

May 23, 2012
Initial Standards Track JSON Web Token (JWT) Specifications

IETF logoThe JSON Web Token (JWT) specification and the OAuth 2.0 JWT Bearer Token Profiles specification are now IETF standards track documents in the OAuth working group. These versions are based upon the individual submission versions draft-jones-json-web-token-10 and draft-jones-oauth-jwt-bearer-04 with no normative changes. The JWT specification builds upon the JWS, JWE, JWK, and JWA specifications in the JOSE working group.

These specifications are available at:

HTML formatted versions are available at:

May 14, 2012
JSON Crypto Specs Draft -02: JWS, JWE, JWK, JWA and JSON Web Token (JWT) Draft -10

IETF logoJSON Crypto Specs Draft -02: JWS, JWE, JWK, JWA and JSON Web Token (JWT) Draft -10

New -02 versions of the JSON Object Signing and Encryption (JOSE) specifications are now available that incorporate working group decisions made since the previous versions, including decisions made at IETF 83 in Paris and in follow-up discussions on the JOSE working group list. The drafts contain numerous clarifications, refinements, and editorial improvements. 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

Also, Draft -10 of the JSON Web Token (JWT) specification has been published. It uses the -02 versions of the JOSE specifications and contains parallel editorial changes to those applied to the JOSE specs.

These specifications are available at:

The document history entries (also in the specifications) are as follows:

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02:

  • Clarified that it is an error when a kid value is included and no matching key is found.
  • Removed assumption that kid (key ID) can only refer to an asymmetric key.
  • Clarified that JWSs with duplicate Header Parameter Names MUST be rejected.
  • Clarified the relationship between typ header parameter values and MIME types.
  • Registered application/jws MIME type and “JWS” typ header parameter value.
  • Simplified JWK terminology to get replace the “JWK Key Object” and “JWK Container Object” terms with simply “JSON Web Key (JWK)” and “JSON Web Key Set (JWK Set)” and to eliminate potential confusion between single keys and sets of keys. As part of this change, the header parameter name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
  • Added suggestion on defining additional header parameters such as x5t#S256 in the future for certificate thumbprints using hash algorithms other than SHA-1.
  • Specify RFC 2818 server identity validation, rather than RFC 6125 (paralleling the same decision in the OAuth specs).
  • Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
  • Reformatted to give each header parameter its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02:

  • When using AEAD algorithms (such as AES GCM), use the “additional authenticated data” parameter to provide integrity for the header, encrypted key, and ciphertext and use the resulting “authentication tag” value as the JWE Integrity Value.
  • Defined KDF output key sizes.
  • Generalized text to allow key agreement to be employed as an alternative to key wrapping or key encryption.
  • Changed compression algorithm from gzip to DEFLATE.
  • Clarified that it is an error when a kid value is included and no matching key is found.
  • Clarified that JWEs with duplicate Header Parameter Names MUST be rejected.
  • Clarified the relationship between typ header parameter values and MIME types.
  • Registered application/jwe MIME type and “JWE” typ header parameter value.
  • Simplified JWK terminology to get replace the “JWK Key Object” and “JWK Container Object” terms with simply “JSON Web Key (JWK)” and “JSON Web Key Set (JWK Set)” and to eliminate potential confusion between single keys and sets of keys. As part of this change, the header parameter name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
  • Added suggestion on defining additional header parameters such as x5t#S256 in the future for certificate thumbprints using hash algorithms other than SHA-1.
  • Specify RFC 2818 server identity validation, rather than RFC 6125 (paralleling the same decision in the OAuth specs).
  • Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
  • Reformatted to give each header parameter its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02:

  • Simplified JWK terminology to get replace the “JWK Key Object” and “JWK Container Object” terms with simply “JSON Web Key (JWK)” and “JSON Web Key Set (JWK Set)” and to eliminate potential confusion between single keys and sets of keys. As part of this change, the top-level member name for a set of keys was changed from jwk to keys.
  • Clarified that values with duplicate member names MUST be rejected.
  • Established JSON Web Key Set Parameters registry.
  • Explicitly listed non-goals in the introduction.
  • Moved algorithm-specific definitions from JWK to JWA.
  • Reformatted to give each member definition its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02:

  • For AES GCM, use the “additional authenticated data” parameter to provide integrity for the header, encrypted key, and ciphertext and use the resulting “authentication tag” value as the JWE Integrity Value.
  • Defined minimum required key sizes for algorithms without specified key sizes.
  • Defined KDF output key sizes.
  • Specified the use of PKCS #5 padding with AES-CBC.
  • Generalized text to allow key agreement to be employed as an alternative to key wrapping or key encryption.
  • Clarified that ECDH-ES is a key agreement algorithm.
  • Required implementation of AES-128-KW and AES-256-KW.
  • Removed the use of A128GCM and A256GCM for key wrapping.
  • Removed A512KW since it turns out that it’s not a standard algorithm.
  • Clarified the relationship between typ header parameter values and MIME types.
  • Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
  • Established registries: JSON Web Signature and Encryption Header Parameters, JSON Web Signature and Encryption Algorithms, JSON Web Signature and Encryption “typ” Values, JSON Web Key Parameters, and JSON Web Key Algorithm Families.
  • Moved algorithm-specific definitions from JWK to JWA.
  • Reformatted to give each member definition its own section heading.

http://tools.ietf.org/html/draft-jones-json-web-token-10:

  • Clarified the relationship between typ header parameter values, typ claim values, and MIME types.
  • Clarified that JWTs with duplicate Header Parameter Names or Duplicate Claim names MUST be rejected.
  • Required implementation of AES-128-KW and AES-256-KW when the implementation provides encryption capabilities.
  • Registered “JWT” typ header parameter value.
  • Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
  • Reformatted to give each claim definition and header parameter its own section heading.

HTML formatted versions are available at:

May 8, 2012
JSON Web Token (JWT) Specification Draft -09

IETF logoDraft 09 of the JSON Web Token (JWT) specification has been published. It contains this change:

  • Changed “http://openid.net/specs/jwt/1.0″ to “urn:ietf:params:oauth:token-type:jwt” in preparation for OAuth WG draft.

This specification is available at:

An HTML formatted version is available at: