Musings on Digital Identity

Archive for July, 2012

I’ve made a minor release of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications to support the working group discussions at IETF 84 in Vancouver, BC. This release incorporates working group feedback since the minor release on July 16th and updates the lists of open issues in the JWE and JWA specifications.

Support both direct encryption using a shared or agreed upon symmetric key, and the use of a shared or agreed upon symmetric key to key wrap the CMK. Specifically, added the alg values dir, ECDH-ES+A128KW, and ECDH-ES+A256KW to finish filling in this set of capabilities.

I’ve made a minor release of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) working group specifications and the JWS and JWE JSON Serialization (JWS-JS, JWE-JS) individual submission specifications in preparation for IETF 84 in Vancouver, BC. These versions incorporate feedback from working group members since the major release on July 6th, and update the lists of open issues in preparation for discussions in Vancouver (and on the working group mailing lists).

One significant addition is that the JWT and JWE-JS specs both now contain complete, testable examples with encrypted results. No normative changes were made.

New versions of the OAuth Core and Bearer specs have been published that are intended to address all outstanding issues. (Although see Dick Hardt’s forwarded note from Charles Honton, which may result in an additional issue.)

Added “MUST” to “A public client that was not issued a client password MUST use the client_id request parameter to identify itself when sending requests to the token endpoint” and added text explaining why this must be so.

Added that the authorization server MUST “ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request”.

I renamed the JSON Serialization specifications so that they now have “jose” in the document name. Jim Schaad tells me that then they’ll automatically be added to the JOSE Related Documents list at http://datatracker.ietf.org/wg/jose/. No normative changes were made.

These documents use the JWS and JWE crypto calculations, but enable multiple parallel signatures and multiple recipients.

I’ve updated the Simple Web Discovery (SWD) specification to incorporate editorial improvements suggested by Julian Reschke and to apply applicable editorial improvements also recently made to the JOSE specifications. No normative changes were made.

Changed “requests use the x-www-form-urlencoded format” to “requests use query parameters” and changed “an x-www-form-urlencoded form” to “a form encoded using the application/x-www-form-urlencoded encoding algorithm”, both at the suggestion of Julian Reschke.

Updated examples to use “urn:example:” URNs rather than “urn:example.org:” URNs, also at Julian’s suggestion.

New versions of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications have been released. These versions incorporate numerous suggestions from working group members and developers that clarify the intent of the specifications and make them easier to read and implement. In particular, the JWE spec now includes encryption and key derivation examples for a number of algorithms that have been verified in multiple independent implementations.

I’ve worked to close out all the former “TBD” items in the specs, bringing them up to an editorially complete state, in preparation for working group last call. As with previous releases, see the “Open Issues” sections for a small number of discussion points that I believe merit working group attention.

I also applied the changes made to the JOSE specs to the related individual submission JWS JSON Serialization and JWE JSON Serialization specs, which enable multiple recipients.

Added the cty (content type) header parameter for declaring type information about the secured content, as opposed to the typ (type) header parameter, which declares type information about this object.

Added “Collision Resistant Namespace” to the terminology section.

Reference ITU.X690.1994 for DER encoding.

Added an example JWS using ECDSA P-521 SHA-512. This has particular illustrative value because of the use of the 521 bit integers in the key and signature values. This is also an example in which the payload is not a base64url encoded JSON object.

Added an example x5c value.

No longer say “the UTF-8 representation of the JWS Secured Input (which is the same as the ASCII representation)”. Just call it “the ASCII representation of the JWS Secured Input”.

Added Registration Template sections for defined registries.

Added Registry Contents sections to populate registry values.

Changed name of the JSON Web Signature and Encryption “typ” Values registry to be the JSON Web Signature and Encryption Type Values registry, since it is used for more than just values of the typ parameter.

Reordered encryption steps so that the Encoded JWE Header is always created before it is needed as an input to the AEAD “additional authenticated data” parameter.

Added the cty (content type) header parameter for declaring type information about the secured content, as opposed to the typ (type) header parameter, which declares type information about this object.

Moved description of how to determine whether a header is for a JWS or a JWE from the JWT spec to the JWE spec.

Added complete encryption examples for both AEAD and non-AEAD algorithms.