Archive for the 'Claims' Category

December 4, 2015
CBOR Web Token (CWT) spec for the ACE working group

IETF logoAfter input from many interested people, IETF Security Area Director Kathleen Moriarty decided that the right place for the CBOR Web Token (CWT) work is the ACE working group. Today Erik Wahlström posted a new draft of the CBOR Web Token (CWT) specification that is intended for ACE.

This version of the spec references the JSON Web Token (JWT) claim definitions, rather than repeating them, and intentionally only includes equivalents of the claims defined by the JWT spec. Other CWT claims, including those needed by ACE applications, will be defined by other specs and registered in the CWT claims registry.

The specification is available at:

An HTML-formatted version is also available at:

December 4, 2015
Authentication Method Reference Values Registration Instructions

OAuth logoAuthentication Method Reference Values draft -03 adds the criterion to the IANA registration instructions that the value being registered be in actual use.

The specification is available at:

An HTML formatted version is also available at:

November 30, 2015
Proof-of-Possession Key Semantics for JWTs spec addressing additional AD comments

OAuth logoProof-of-Possession Key Semantics for JWTs draft -08 addresses additional Area Director review comments. A security consideration about utilizing audience restriction in combination with proof-of-possession was added. Thanks to John Bradley for working on the additional wording with me.

The specification is available at:

An HTML formatted version is also available at:

November 25, 2015
OAuth Discovery

OAuth logoI’m pleased to announce that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery specification. This fills a hole in the current OAuth specification set that is necessary to achieve interoperability. Indeed, the Interoperability section of OAuth 2.0 states:

In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery). Without these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate.

This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.

This specification enables discovery of both endpoint locations and authorization server capabilities.

This specification is based upon the already widely deployed OpenID Connect Discovery 1.0 specification and is compatible with it, by design. The OAuth Discovery spec removes the portions of OpenID Connect Discovery that are OpenID specific and adds metadata values for Revocation and Introspection endpoints. It also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User, and Issuer to their OAuth underpinnings, respectively Authorization Server, Client, Resource Owner, and the newly introduced Configuration Information Location. Some identifiers with names that appear to be OpenID specific were retained for compatibility purposes; despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific to OpenID Connect.

The specification is available at:

An HTML-formatted version is also available at:

November 24, 2015
Proof-of-Possession Key Semantics for JWTs spec addressing Area Director comments

OAuth logoProof-of-Possession Key Semantics for JWTs draft -07 addresses review comments by our Area Director, Kathleen Moriarty, as well as comments by Hannes Tschofenig and Justin Richer. This should hopefully enable IETF last call.

The specification is available at:

An HTML formatted version is also available at:

November 24, 2015
JWS Unencoded Payload Option spec addressing Area Director comments

IETF logoDraft -06 of the JWS Unencoded Payload Option specification addresses review comments by our Area Director, Kathleen Moriarty. This should hopefully enable IETF last call.

The specification is available at:

An HTML formatted version is also available at:

November 12, 2015
CBOR Web Token (CWT)

IETF logoI know that some of you have been following the IETF’s work on the CBOR Object Signing and Encryption (COSE) Working group on creating a Concise Binary Object Representation (CBOR) equivalent of the JSON-based cryptographic data formats produced by the JSON Object Signing and Encryption (JOSE) Working group. I’m happy to announce that work has now started on a CBOR Web Token (CWT) specification: a CBOR mapping of the JSON Web Token (JWT) security token format that was built using the JOSE specifications. While I expect JSON and the JOSE/JWT specs to continue be used in most Web, PC, phone, tablet, cloud, and enterprise contexts, the COSE specs and now CWT are designed for use in constrained environments, such as those for some Internet of Things (IoT) devices.

Just as it was important to have a JSON-based security token format for applications using JSON, it will be important to have a CBOR-based security token format for applications using CBOR. CBOR Web Token (CWT) fills that role. Note that what is actually defined is a general cryptographically secured CBOR data structure, enabling CWTs to be used as general application payloads for CBOR-based applications.

The abstract of the specification is:

CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. CWT is a profile of the JSON Web Token (JWT) that is optimized for constrained devices. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value.

My thanks to Erik Wahlström and Hannes Tschofenig for helping to make this happen!

Finally, I’ll note that just as the suggested pronunciation of JWT is the same as the English word “jot”, the suggested pronunciation of CWT is the same as the English word “cot”. So welcome to “cots”!

The specification is available at:

An HTML formatted version is also available at:

November 4, 2015
Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

OAuth logoProof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining document shepherd comment – adding use case diagrams to the introduction.

The updated specification is available at:

An HTML formatted version is also available at:

October 19, 2015
Proof-of-Possession Key Semantics for JWTs spec addressing document shepherd comments

OAuth logoProof-of-Possession Key Semantics for JWTs draft -05 addresses Kepeng Li’s document shepherd comments (other than adding some use case diagrams in the introduction, which will happen soon).

The updated specification is available at:

An HTML formatted version is also available at:

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:

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 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:

July 7, 2015
JWK Thumbprint -07 draft addressing Gen-ART review comment

IETF logoJWK Thumbprint draft -07 has been published, addressing a Gen-ART review comment by Joel Halpern. Beyond updating the acknowledgements, the only change was replacing this sentence:

“Only if multiple parties will be reproducing the JWK Thumbprint calculation for some reason, will parties other than the original producer of the JWK Thumbprint need to know which hash function was used.”

with these two:

“However, in some cases, multiple parties will be reproducing the JWK Thumbprint calculation and comparing the results. In these cases, the parties will need to know which hash function was used and use the same one.”

The specification is available at:

An HTML formatted version is also available at:

July 7, 2015
Proof-of-Possession Key Semantics for JWTs spec addressing WGLC comments

OAuth logoThe editors have published draft-ietf-oauth-proof-of-possession-03, which addresses the working group last call comments received. Thanks to all of you who provided feedback. The changes were:

  • Separated the jwk and jwe confirmation members; the former represents a public key as a JWK and the latter represents a symmetric key as a JWE encrypted JWK.
  • Changed the title to indicate that a proof-of-possession key is being communicated.
  • Updated language that formerly assumed that the issuer was an OAuth 2.0 authorization server.
  • Described ways that applications can choose to identify the presenter, including use of the iss, sub, and azp claims.
  • Harmonized the registry language with that used in JWT [RFC 7519].
  • Addressed other issues identified during working group last call.
  • Referenced the JWT and JOSE RFCs.

The updated 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!

« Prev - Next »