Mike Jones: self-issued

Musings on Digital Identity

Category: JSON Page 12 of 14

JSON Private Key Specification

By

On August 15, 2012

In Cryptography, JSON, Specifications

IETF logoW3C logoThe W3C WebCrypto working group recently made an inquiry to the IETF JOSE working group about the possibility of defining a JSON representation for private keys. To facilitate discussion of this topic by both working groups, I created a draft JSON Private Key specification. The specification is very simple; it just defines two additional members for the JWK structure for representing the private parts of Elliptic Curve and RSA keys.

The specification is available at:

A HTML-formatted version of the specification is available at:

IETF 84 versions of JOSE and JWT specifications

By

On July 31, 2012

In Claims, Cryptography, JSON, Specifications

IETF logoI’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.

The 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-05

  • Added statement that “StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied”.
  • Indented artwork elements to better distinguish them from the body text.

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

  • 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.
  • Added statement that “StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied”.
  • Updated open issues.
  • Indented artwork elements to better distinguish them from the body text.

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

  • Indented artwork elements to better distinguish them from the body text.

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

  • 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.
  • Updated open issues.

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03

  • Added statement that “StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied”.
  • Indented artwork elements to better distinguish them from the body text.

HTML-formatted versions are available at:

Pre-IETF 84 versions of JOSE and JWT specifications

By

On July 16, 2012

In Claims, Cryptography, JSON, Specifications

IETF logoI’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.

The working group specifications are available at:

The individual submission 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-04

  • Completed JSON Security Considerations section, including considerations about rejecting input with duplicate member names.
  • Completed security considerations on the use of a SHA-1 hash when computing x5t (x.509 certificate thumbprint) values.
  • Refer to the registries as the primary sources of defined values and then secondarily reference the sections defining the initial contents of the registries.
  • Normatively reference XML DSIG 2.0 [W3C.CR xmldsig core2 20120124] for its security considerations.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Reference draft-jones-jose-jws-json-serialization instead of draft-jones-json-web-signature-json-serialization.
  • Described additional open issues.
  • Applied editorial suggestions.

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

  • Refer to the registries as the primary sources of defined values and then secondarily reference the sections defining the initial contents of the registries.
  • Normatively reference XML Encryption 1.1 [W3C.CR xmlenc core1 20120313] for its security considerations.
  • Reference draft-jones-jose-jwe-json-serialization instead of draft-jones-json-web-encryption-json-serialization.
  • Described additional open issues.
  • Applied editorial suggestions.

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

  • Refer to the registries as the primary sources of defined values and then secondarily reference the sections defining the initial contents of the registries.
  • Normatively reference XML DSIG 2.0 [W3C.CR xmldsig core2 20120124] for its security considerations.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Described additional open issues.
  • Applied editorial suggestions.

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

  • Added text requiring that any leading zero bytes be retained in base64url encoded key value representations for fixed-length values.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Described additional open issues.
  • Applied editorial suggestions.

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-02

  • Added an example of an encrypted JWT.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Applied editorial suggestions.

http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-01

  • Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs).

http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-01

  • Added a complete JWE-JS example.
  • Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs).

HTML-formatted versions are available at:

JSON Serialization Specifications Renamed

By

On July 9, 2012

In Cryptography, JSON, Specifications

IETF logoI 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.

The new versions are:

HTML formatted versions are available at:

Updated Simple Web Discovery (SWD) Specification

By

On July 6, 2012

In JSON, Specifications

IETF logoI’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.

The updated specification is available at:

Changes made were:

  • 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.
  • Applied applicable editorial improvements from JOSE specs to SWD.
  • Updated references to related specifications.

An HTML formatted version is available at:

Updated JWT Bearer Token Profiles for OAuth 2.0

By

On July 6, 2012

In Claims, JSON, OAuth, Specifications

OAuth logoI’ve updated the OAuth JWT Profile document to track minor changes to some of the underling documents. No normative changes were made.

The updated specification is available at:

Changes made were:

  • Tracked specification name changes: “The OAuth 2.0 Authorization Protocol” to “The OAuth 2.0 Authorization Framework” and “OAuth 2.0 Assertion Profile” to “Assertion Framework for OAuth 2.0”.
  • Merged in changes between draft-ietf-oauth-saml2-bearer-11 and draft-ietf-oauth-saml2-bearer-13. All changes were strictly editorial.

An HTML formatted version is available at:

Updated versions of JOSE and JWT specifications

By

On July 6, 2012

In Claims, Cryptography, JSON, Specifications

IETF logoNew 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.

The working group specifications are available at:

The individual submission 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-03

  • 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.
  • Moved registries JSON Web Signature and Encryption Header Parameters and JSON Web Signature and Encryption Type Values to the JWS specification.
  • Numerous editorial improvements.

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

  • Added the kdf (key derivation function) header parameter to provide crypto agility for key derivation. The default KDF remains the Concat KDF with the SHA-256 digest function.
  • 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.
  • Added complete key derivation examples.
  • Added “Collision Resistant Namespace” to the terminology section.
  • Reference ITU.X690.1994 for DER encoding.
  • Added Registry Contents sections to populate registry values.
  • Numerous editorial improvements.

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

  • Clarified that kid values need not be unique within a JWK Set.
  • Moved JSON Web Key Parameters registry to the JWK specification.
  • Added “Collision Resistant Namespace” to the terminology section.
  • Changed registration requirements from RFC Required to Specification Required with Expert Review.
  • Added Registration Template sections for defined registries.
  • Added Registry Contents sections to populate registry values.
  • Numerous editorial improvements.

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

  • Always use a 128 bit “authentication tag” size for AES GCM, regardless of the key size.
  • Specified that use of a 128 bit IV is REQUIRED with AES CBC. It was previously RECOMMENDED.
  • Removed key size language for ECDSA algorithms, since the key size is implied by the algorithm being used.
  • Stated that the int key size must be the same as the hash output size (and not larger, as was previously allowed) so that its size is defined for key generation purposes.
  • Added the kdf (key derivation function) header parameter to provide crypto agility for key derivation. The default KDF remains the Concat KDF with the SHA-256 digest function.
  • Clarified that the mod and exp values are unsigned.
  • Added Implementation Requirements columns to algorithm tables and Implementation Requirements entries to algorithm registries.
  • Changed AES Key Wrap to RECOMMENDED.
  • Moved registries JSON Web Signature and Encryption Header Parameters and JSON Web Signature and Encryption Type Values to the JWS specification.
  • Moved JSON Web Key Parameters registry to the JWK specification.
  • Changed registration requirements from RFC Required to Specification Required with Expert Review.
  • Added Registration Template sections for defined registries.
  • Added Registry Contents sections to populate registry values.
  • 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 “Collision Resistant Namespace” to the terminology section.
  • Numerous editorial improvements.

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01

  • 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. This significantly simplified nested JWTs.
  • Moved description of how to determine whether a header is for a JWS or a JWE from the JWT spec to the JWE spec.
  • Changed registration requirements from RFC Required to Specification Required with Expert Review.
  • Added Registration Template sections for defined registries.
  • Added Registry Contents sections to populate registry values.
  • Added “Collision Resistant Namespace” to the terminology section.
  • Numerous editorial improvements.

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

  • Tracked editorial changes made to the JWS spec.

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

  • Updated examples to track updated algorithm properties in the JWA spec.
  • Tracked editorial changes made to the JWE spec.

HTML formatted versions are available at:

Special thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund Jay for validating the JWE examples!

Initial Standards Track JSON Web Token (JWT) Specifications

By

On May 23, 2012

In Claims, JSON, OAuth, 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:

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

By

On May 14, 2012

In Claims, Cryptography, JSON, Specifications

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:

JSON Web Token (JWT) Specification Draft -09

By

On May 8, 2012

In Claims, JSON, Specifications

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:

OAuth 2.0 JWT Bearer Token Profiles Specification Draft -04

By

On April 26, 2012

In Claims, JSON, OAuth, Specifications

OAuth logoDraft 04 of the OAuth 2.0 JWT Bearer Token Profiles Specification has been published. This version tracks changes in the OAuth 2.0 Assertion Profile and SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 specifications made in response to working group last call comments, as announced by Brian Campbell.

Changes made were:

  • Merged in changes between draft-ietf-oauth-saml2-bearer-09 and draft-ietf-oauth-saml2-bearer-11.
  • Added the optional iat (issued at) claim, which was already present in the JWT spec.

The draft is available at:

An HTML-formatted version is available at:

OpenID Connect has won the 2012 European Identity Award

By

On April 18, 2012

In Claims, Events, JSON, OAuth, Specifications

OpenID logoI’m thrilled to report that OpenID Connect has won the 2012 European Identity Award for Best Innovation/New Standard. I appreciate the recognition of what we’ve achieved to date with OpenID Connect and its potential to significantly change digital identity for the better. As Dave Kearns wrote in the OpenID Foundation announcement about the award:

I’m pleased that Kuppinger Cole has granted OpenID Connect the award for Best Innovation/New Standard this year. What’s most impressive is that this elegantly simple design resulted from the cooperation of such a diverse global set of contributors. I expect OpenID Connect to have a substantial positive impact on usable, secure identity solutions both for traditional computing platforms and mobile devices. My congratulations to the OpenID Foundation!

My thanks to all who have contributed to the OpenID Connect specifications to date and especially to the developers who have implemented draft versions, providing essential feedback needed to refine the specs on the road to final standards. I look forward to seeing what people will accomplish with OpenID Connect!

April 10, 2012 OpenID Connect Update Release

By

On April 13, 2012

In Claims, JSON, OAuth, OpenID, Specifications

OpenID logoThe OpenID Connect working group has released an update to the OpenID Connect specifications that continues incorporating significant developer feedback received, while maintaining as much compatibility with the implementer’s drafts as possible. The Connect specs have also been updated to track updates to the OAuth and JOSE specs, which they use. The primary normative changes are as follows:

  • Make changes to allow path in the issuer_identifier, per issue #513
  • Add hash and hash check of access_token and code to id_token, per issue #510
  • Split encrypted response configurations into separate parameters for alg, enc, int
  • Added optional id_token to authorization request parameters, per issue #535
  • Now requested claims add to those requested with scope values, rather than replacing them, per issue #547
  • Added error interaction_required and removed user_mismatched, per issue #523
  • Changed invalid_request_redirect_uri to invalid_redirect_uri, per issue #553
  • Removed “embedded” display type, since its semantics were not well defined, per issue #514

A significant non-normative addition is:

  • Add example JS code for Basic client

Implementers are particularly encouraged to build and provide feedback on the new and modified features.

The new versions are available from http://openid.net/connect/ or at:

JSON Web Token (JWT) Specification Draft -08

By

On March 12, 2012

In Claims, JSON, Specifications

IETF logoDraft 08 of the JSON Web Token (JWT) specification has been published. It uses the -01 versions of the JOSE specifications and also contains these changes:

  • Removed language that required that a JWT must have three parts. Now the number of parts is explicitly dependent upon the representation of the underlying JWS or JWE.
  • Moved the “alg”:”none” definition to the JWS spec.
  • Registered the application/jwt MIME Media Type.
  • Clarified that the order of the creation and validation steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.
  • Corrected the Magic Signatures and Simple Web Token (SWT) references.

This specification is available at:

An HTML formatted version is available at:

Draft -01 of JSON Crypto Specs: JWS, JWE, JWK, JWA, JWS-JS, JWE-JS

By

On March 12, 2012

In Cryptography, JSON, Specifications

IETF logoNew versions of the IETF JSON Object Signing and Encryption (JOSE) specifications are now available that incorporate working group feedback since publication of the initial versions. 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

The most important changes are:

  • Added a separate integrity check for encryption algorithms without an integral integrity check.
  • Defined header parameters for including JWK public keys and X.509 certificate chains directly in the header.

See the Document History section in each specification for a more detailed list of changes.

Corresponding versions of the JSON Serialization specs, which use these JOSE drafts, are also available. Besides using JSON Serializations of the cryptographic results (rather than Compact Serializations using a series of base64url encoded values), these specifications also enable multiple digital signatures and/or HMACs to applied to the same message and enable the same plaintext to be encrypted to multiple recipients. They are:

  • JSON Web Signature JSON Serialization (JWS-JS)
  • JSON Web Encryption JSON Serialization (JWE-JS)

These specifications are available at:

HTML formatted versions are available at:

JSON Serializations for JWS and JWE

By

On March 5, 2012

In Cryptography, JSON, Specifications

IETF logoParticipants in the JOSE working group have described use cases where a JSON top-level representation of digitally signed, HMAC’ed, or encrypted content is desirable. They have also described use cases where multiple digital signatures and/or HMACs need to applied to the same message and where the same plaintext needs to be encrypted to multiple recipients.

Responding to those use cases and working group input, I have created two new brief specifications:

  • JSON Web Signature JSON Serialization (JWS-JS)
  • JSON Web Encryption JSON Serialization (JWE-JS)

These use the same cryptographic operations as JWS and JWE, but serialize the results into a JSON objects, rather than a set of base64url encoded values separated by periods (as is done for JWS and JWE to produce compact, URL-safe representations).

These drafts are available at:

HTML-formatted versions are available at:

Feedback welcome!

OpenID Connect Interop in Progress

By

On February 17, 2012

In Claims, Events, Interoperability, JSON, OAuth, OpenID, Specifications

OSIS logoOpenID logoThe Third OpenID Connect Interop is currently under way — this time based upon approved Implementer’s Drafts. Currently 7 implementations are being tested, with I believe more to be added. The interop is designed to enable people to test the implementations they’ve built against other implementations and verify that specific features that they’ve built are working correctly. This has several benefits: it helps debug implementations, it helps debug the specifications, and it results in greater interoperability among OpenID Connect implementations.

As background, like the other OSIS interops, the OpenID Connect interop is an opportunity for implementers to try their code against one another’s in a systematic way. It is not a conformance test; participants do not “pass” or “fail”. There is no requirement that you must support particular features to participate or that you must participate in all aspects of the interop.

If you’d like to participate in the interop, join the OpenID Connect Interop mailing list and send us a note there saying who your interop contact person will be, the name of your organization (can be an individual), the name of your implementation (can be your name), and a list of the online testing endpoints for your implementation. Testing is performed online on your schedule, with results recorded on the interop wiki. That being said, an in-person meeting of interop participants will also be held on Friday, March 2 in San Francisco (the week of RSA) for those who are able to attend.

OpenID Connect Implementer’s Drafts Approved

By

On February 17, 2012

In Claims, JSON, OAuth, OpenID, Specifications

OpenID logoThe OpenID Foundation members have overwhelmingly voted to approve the OpenID Connect specifications as Implementer’s Drafts. This is an important milestone in the process of completing the OpenID Connect specifications.

Implementer’s Drafts are stable versions of specifications intended for trial implementations and deployments that provide specific IPR protections to those using them. Implementers and deployers are encouraged to continue to provide timely feedback to the working group on the specifications based upon their experiences with them.

Vote to Approve OpenID Connect Implementer’s Drafts Under Way

By

On February 8, 2012

In Claims, JSON, OAuth, OpenID, Specifications

OpenID logoThe vote to approve six OpenID Connect specification drafts as OpenID Foundation Implementer’s Drafts is under way. To vote, go to https://openid.net/foundation/members/polls/62 and log in using your OpenID by the morning of Wednesday, February 15th. For more information about OpenID Connect, visit http://openid.net/connect/.

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:

Page 12 of 14

Previous

Next

Powered by WordPress & Theme by Anders Norén