Archive for the 'JSON' Category

August 28, 2015
Proof-of-Possession Key Semantics for JWTs spec addressing remaining comments

OAuth logoProof-of-Possession Key Semantics for JWTs draft -04 addresses the remaining working group comments received – both a few leftover WGLC comments and comments received during IETF 93 in Prague. The changes were:

  • Allowed the use of “jwk” for symmetric keys when the JWT is encrypted.
  • Added the “jku” (JWK Set URL) member.
  • Added privacy considerations.
  • Reordered sections so that the “cnf” (confirmation) claim is defined before it is used.
  • Noted that applications can define new claim names, in addition to “cnf”, to represent additional proof-of-possession keys, using the same representation as “cnf”.
  • Applied wording clarifications suggested by Nat Sakimura.

The updated specification is available at:

An HTML formatted version is also available at:

August 21, 2015
“amr” values “rba” and “sc”

OAuth logoAuthentication Method Reference Values draft -02 changed the identifier for risk-based authentication from “risk” to “rba”, by popular acclaim, and added the identifier “sc” (smart card).

The specification is available at:

An HTML formatted version is also available at:

August 13, 2015
“amr” Values spec updated

OAuth logoI’ve updated the Authentication Method Reference Values spec to incorporate feedback received from the OAuth working group. Changes were:

  • Added the values “mca” (multiple-channel authentication), “risk” (risk-based authentication), and “user” (user presence test).
  • Added citations in the definitions of Windows integrated authentication, knowledge-based authentication, risk-based authentication, multiple-factor authentication, one-time password, and proof-of-possession.
  • Alphabetized the values.
  • Added Tony Nadalin as an author and added acknowledgements.

The specification is available at:

An HTML formatted version is also available at:

August 9, 2015
JWS Unencoded Payload Option specification

IETF logoThe former JWS Signing Input Options specification has been renamed to JWS Unencoded Payload Option to reflect that there is now only one JWS Signing Input option defined in the spec – the “b64″:false option. The “sph” option was removed by popular demand. I also added a section on unencoded payload content restrictions and an example using the JWS JSON Serialization.

The specification is available at:

An HTML formatted version is also available at:

July 23, 2015
JWS Signing Input Options initial working group draft

IETF logoThe initial working group version of JWS Signing Input Options has been posted. It contains no normative changes from draft-jones-jose-jws-signing-input-options-00.

Let the working group discussions begin! I particularly call your attention to Martin Thomson’s review at http://www.ietf.org/mail-archive/web/jose/current/msg05158.html, Nat Sakimura’s review at http://www.ietf.org/mail-archive/web/jose/current/msg05189.html, and Matias Woloski’s review at http://www.ietf.org/mail-archive/web/jose/current/msg05191.html to start things off.

The specification is available at:

An HTML formatted version is also available at:

July 22, 2015
Authentication Method Reference Values Specification

OAuth logoPhil Hunt and I have posted a new draft that defines some values used with the “amr” (Authentication Methods References) claim and establishes a registry for Authentication Method Reference values. These values include commonly used authentication methods like “pwd” (password) and “otp” (one time password). It also defines a parameter for requesting that specific authentication methods be used in the authentication.

The specification is available at:

An HTML formatted version is also available at:

July 21, 2015
Lots of great data about JWT and OpenID Connect adoption!

JWT logoCheck out the post Json Web Token (JWT) gets a logo, new website and more by Matias Woloski of Auth0. I particularly love the data in the “Numbers speak for themselves” section and the graph showing the number of searches for “JSON Web Token” crossing over the number of searches for “SAML Token”.

Also, be sure to check out http://jwt.io/, where you can interactively decode, verify, and generate JWTs. Very cool!

July 13, 2015
JWK Thumbprint -08 approved by IESG

IETF logoThe IESG has approved JWK Thumbprint draft -08, meaning that it will now progress to the RFC Editor. Draft -08 added IANA instructions in response to an IESG comment by Barry Leiba.

The specification is available at:

An HTML formatted version is also available at:

July 9, 2015
OAuth 2.0 Dynamic Client Registration Protocol is now RFC 7591

OAuth logoThe OAuth 2.0 Dynamic Client Registration Protocol specification is now RFC 7591 – an IETF standard. The abstract describes it as follows:

This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.

This specification extracts the subset of the dynamic client registration functionality defined by OpenID Connect Dynamic Client Registration 1.0 that is applicable to any OAuth 2.0 deployment. It is intentionally completely compatible with the OpenID Connect registration spec, yet is also now usable as a basis for dynamic client registration by other OAuth 2.0 profiles.

My personal thanks to Justin Richer, John Bradley, Maciej Machulak, Phil Hunt, and Nat Sakimura for their work on this specification and its precursors. Thanks also to members of the OpenID Connect working group and members of the OAuth working group, as well as its chairs, area directors, and other IETF members who contributed to this specification.

July 7, 2015
OAuth 2.0 Token Exchange -02 enabling use of any token type

OAuth logoDraft -02 of the OAuth 2.0 Token Exchange specification has been published, making the functionality token type independent. Formerly, only JSON Web Tokens (JWTs) could be used in some contexts. This was a change requested by working group participants during IETF 92 in Dallas.

The specification is available at:

An HTML formatted version is also available at:

June 24, 2015
JWK Thumbprint -06 addressing SecDir review comments

IETF logoA new JWK Thumbprint draft has been posted addressing the IETF Security Directorate (SecDir) comments from Adam Montville. The changes clarify aspects of the selection and dissemination of the hash algorithm choice and update the instructions to the Designated Experts when registering JWK members and values.

The specification is available at:

An HTML formatted version is also available at:

May 27, 2015
JWS Signing Input Options Specification

IETF logoThere’s been interest being able to not base64url-encode the JWS Payload under some circumstances by a number of people. I’ve occasionally thought about ways to accomplish this, and prompted again by discussions with Phillip Hallam-Baker, Martin Thomson, Jim Schaad, and others at IETF 92 in Dallas, recollections of conversations with Matt Miller and Richard Barnes on the topic, and with Anders Rundgren on the JOSE mailing list, I decided to write down a concrete proposal while there’s still a JOSE working group to possibly consider taking it forward. The abstract of the spec is:

JSON Web Signature (JWS) represents the payload of a JWS as a base64url encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url-encode the payload.

Also, JWS includes a representation of the JWS Protected Header and a period (‘.’) character in the JWS Signature computation. While this cryptographically binds the protected Header Parameters to the integrity protected payload, some of have described use cases in which this binding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not include a representation of the JWS Protected Header and a period (‘.’) character in the JWS Signing Input.

These options are intended to broaden the set of use cases for which the use of JWS is a good fit.

The specification is available at:

An HTML formatted version is also available at:

May 27, 2015
Tightened Key Managed JWS Spec

IETF logoThe -01 version of draft-jones-jose-key-managed-json-web-signature tightened the semantics by prohibiting use of “dir” as the “alg” header parameter value so a second equivalent representation for content integrity-protected with a MAC with no key management isn’t introduced. (A normal JWS will do just fine in this case.) Thanks to Jim Schaad for pointing this out. This version also adds acknowledgements and references the now-final JOSE RFCs.

This specification is available at:

An HTML formatted version is also available at:

May 27, 2015
JWK Thumbprint -05 draft addressing issues raised in Kathleen Moriarty’s AD review

IETF logoThis JWK Thumbprint draft addresses issues raised in Kathleen Moriarty’s AD review of the -04 draft. This resulted in several useful clarifications. This version also references the now-final JOSE RFCs.

The specification is available at:

An HTML formatted version is also available at:

May 19, 2015
The OAuth Assertions specs are now RFCs!

OAuth logoThe OAuth Assertions specifications are now standards – IETF RFCs. They are:

  • RFC 7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
  • RFC 7522: Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
  • RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

This completes the nearly 5 year journey to create standards for using security tokens as OAuth 2.0 authorization grants and for OAuth 2.0 client authentication. Like the JWT and JOSE specs that are now also RFCs, these specifications have been in widespread use for a number of years, enabling claims-based use of OAuth 2.0. My personal thanks to Brian Campbell and Chuck Mortimore for getting the ball rolling on this and seeing it through to completion, to Yaron Goland for helping us generalize what started as a SAML-only authorization-grant-only spec to a framework also supporting client authentication and JWTs, and to the OAuth working group members, chairs, area directors, and IETF members who contributed to these useful specifications.

May 19, 2015
JWT and JOSE are now RFCs!

IETF logoThe JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE) specifications are now standards – IETF RFCs. They are:

This completes a 4.5 year journey to create a simple JSON-based security token format and underlying JSON-based cryptographic standards. The goal was always to “keep simple things simple” – making it easy to build and deploy implementations solving commonly-occurring problems using whatever modern development tools implementers chose. We took an engineering approach – including features we believed would be commonly used and intentionally leaving out more esoteric features, to keep the implementation footprint small. I’m happy to report that the working groups and the resulting standards stayed true to this vision, with the already widespread adoption and an industry award being testaments to this accomplishment.

The origin of these specifications was the realization in the fall of 2010 that a number of us had created similar JSON-based security token formats. Seemed like it was time for a standard! I did a survey of the choices made by the different specs and made a convergence proposal based on the survey. The result was draft-jones-json-web-token-00. Meanwhile, Eric Rescorla and Joe Hildebrand had independently created another JSON-based signature and encryption proposal. We joined forces at IETF 81, incorporating parts of both specs, with the result being the -00 versions of the JOSE working group specs.

Lots of people deserve thanks for their contributions. Nat Sakimura, John Bradley, Yaron Goland, Dirk Balfanz, John Panzer, Paul Tarjan, Luke Shepard, Eric Rescorla, and Joe Hildebrand created the precursors to these RFCs. (Many of them also stayed involved throughout the process.) Richard Barnes, Matt Miller, James Manger, and Jim Schaad all provided detailed input throughout the process that greatly improved the result. Brian Campbell, Axel Nennker, Emmanuel Raviart, Edmund Jay, and Vladimir Dzhuvinov all created early implementations and fed their experiences back into the spec designs. Sean Turner, Stephen Farrell, and Kathleen Moriarty all did detailed reviews that added ideas and improved the specs. Matt Miller also created the accompanying JOSE Cookbook – RFC 7520. Chuck Mortimore, Brian Campbell, and I created the related OAuth assertions specs, which are now also RFCs. Karen O’Donoghue stepped in at key points to keep us moving forward. Of course, many other JOSE and OAuth working group and IETF members also made important contributions. Finally, I want to thank Tony Nadalin and others at Microsoft for believing in the vision for these specs and consistently supporting my work on them.

I’ll close by remarking that I’ve been told that the sign of a successful technology is that it ends up being used in ways that the inventors never imagined. That’s certainly already true here. I can’t wait to see all the ways that people will continue to use JWTs and JOSE to build useful, secure applications!

March 9, 2015
OAuth Proof-of-Possession draft -02 closing open issues

OAuth logoAn updated OAuth Proof-of-Possession draft has been posted that address the open issues identified in the previous draft. Changes were:

  • Defined the terms Issuer, Presenter, and Recipient and updated their usage within the document.
  • Added a description of a use case using an asymmetric proof-of-possession key to the introduction.
  • Added the “kid” (key ID) confirmation method.

Thanks to Hannes Tschofenig for writing text to address the open issues.

This specification is available at:

An HTML formatted version is also available at:

March 3, 2015
JWK Thumbprint -04 draft incorporating feedback during second WGLC

IETF logoThe latest JWK Thumbprint draft addresses review comments on the -03 draft by Jim Schaad, which resulted in several clarifications and some corrections to the case of RFC 2119 keywords.

The specification is available at:

An HTML formatted version is also available at:

March 3, 2015
Key Managed JSON Web Signature (KMJWS) specification

IETF logoI took a little time today and wrote a short draft specifying a JWS-like object that uses key management for the MAC key used to integrity protect the payload. We had considered doing this in JOSE issue #2 but didn’t do so at the time because of lack of demand. However, I wanted to get this down now to demonstrate that it is easy to do and specify a way to do it, should demand develop in the future – possibly after the JOSE working group has been closed. See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature-00.html.

This spec reuses key management functionality already present in the JWE spec and MAC functionality already present in the JWS spec. The result is essentially a JWS with an Encrypted Key value added, and a new “mac” Header Parameter value representing the MAC algorithm used. (Like JWE, the key management algorithm is carried in the “alg” Header Parameter value.)

I also wrote this now as possible input into our thinking on options for creating a CBOR JOSE mapping. If there are CBOR use cases needing managed MAC keys, this could help us reason about ways to structure the solution.

Yes, the spec name and abbreviation are far from catchy. Better naming ideas would be great.

Feedback welcomed.

February 26, 2015
JWK Thumbprint -03 draft incorporating additional feedback

IETF logoA new JWK Thumbprint draft has been posted that addresses additional review comments by James Manger and Jim Schaad. Changes included adding a discussion on the relationship of JWK Thumbprints to digests of X.509 values. No normative changes resulted.

The specification is available at:

An HTML formatted version is also available at:

Next »