Archive for the 'Claims' Category

August 3, 2016
OAuth Metadata Specifications Enhanced

OAuth logoThe existing OAuth 2.0 Authorization Server Metadata specification has now been joined by a related OAuth 2.0 Protected Resource Metadata specification. This means that JSON metadata formats are now defined for all the OAuth 2.0 parties: clients, authorization servers, and protected resources.

The most significant addition to the OAuth 2.0 Authorization Server Metadata specification is enabling signed metadata, represented as claims in a JSON Web Token (JWT). This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration. Signed metadata can also be used for protected resource metadata.

For use cases in which the set of protected resources used with an authorization server are enumerable, the authorization server metadata specification now defines the “protected_resources” metadata value to list them. Likewise, the protected resource metadata specification defines an “authorization_servers” metadata value to list the authorization servers that can be used with a protected resource, for use cases in which those are enumerable.

The specifications are available at:

HTML-formatted versions are also available at:

July 8, 2016
“amr” Values specification distinguishing between iris and retina scan biometrics

OAuth logoThis draft distinguishes between iris and retina scan biometrics, as requested by NIST, and adds a paragraph providing readers more context at the end of the introduction, which was requested by the chairs during the call for adoption. The OpenID Connect MODRNA Authentication Profile 1.0 specification, which uses “amr” values defined by this specification, is now also referenced.

The specification is available at:

An HTML formatted version is also available at:

July 7, 2016
IANA Considerations added to CBOR Web Token (CWT)

IETF logoThe CBOR Web Token (CWT) specification now establishes the IANA CWT Claims registry and registers the CWT claims defined by the specification. The application/cwt CoAP content type is now also registered.

This version adds Samuel Erdtman as an editor in recognition of his already significant contributions to the specification.

The specification is available at:

An HTML-formatted version is also available at:

May 20, 2016
Initial ACE working group CBOR Web Token (CWT) specification

IETF logoWe have created the initial working group version of the CBOR Web Token (CWT) specification based on draft-wahlstroem-ace-cbor-web-token-00, with no normative changes. 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.

Changes requested during the call for adoption will be published in the -01 version but we first wanted to publish a clean -00 working group draft.

The specification is available at:

An HTML-formatted version is also available at:

March 4, 2016
OAuth 2.0 Token Exchange draft -04

OAuth logoA new draft of “OAuth 2.0 Token Exchange” has been published addressing review comments on the prior draft. The changes from -03 are listed here:

The specification is available at:

An HTML-formatted version is also available at:

Thanks to Brian Campbell for doing most of the edits for this release.

February 17, 2016
OAuth Discovery spec pared down to its essence

OAuth logoIn response to working group input, this version of the OAuth Discovery specification has been pared down to its essence – leaving only the features that are already widely deployed. Specifically, all that remains is the definition of the authorization server discovery metadata document and the metadata values used in it. The WebFinger discovery logic has been removed. The relationship between the issuer identifier URL and the well-known URI path relative to it at which the discovery metadata document is located has also been clarified.

Given that this now describes only features that are in widespread deployment, the editors believe that this version is ready for working group last call.

The specification is available at:

An HTML-formatted version is also available at:

February 11, 2016
Authentication Method Reference Values spec incorporating adoption feedback

OAuth logoThis draft of the Authentication Method Reference Values specification incorporates OAuth working group feedback from the call for adoption. The primary change was to remove the “amr_values” request parameter, so that “amr” values can still be returned as part of an authentication result, but cannot be explicitly requested. Also, noted that OAuth 2.0 is inadequate for authentication without employing appropriate extensions and changed the IANA registration procedure to no longer require a specification.

The specification is available at:

An HTML-formatted version is also available at:

February 9, 2016
Initial OAuth working group Discovery specification

OAuth logoWe have created the initial working group version of OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative changes.

The specification is available at:

An HTML-formatted version is also available at:

January 28, 2016
OAuth Discovery metadata values added for revocation, introspection, and PKCE

OAuth logoThe OAuth Discovery specification has been updated to add metadata values for revocation, introspection, and PKCE. Changes were:

  • Added “revocation_endpoint_auth_methods_supported” and “revocation_endpoint_auth_signing_alg_values_supported” for the revocation endpoint.
  • Added “introspection_endpoint_auth_methods_supported” and “introspection_endpoint_auth_signing_alg_values_supported” for the introspection endpoint.
  • Added “code_challenge_methods_supported” for PKCE.

The specification is available at:

An HTML-formatted version is also available at:

December 18, 2015
Proof-of-Possession Key Semantics for JWTs spec addressing remaining comments

OAuth logoProof-of-Possession Key Semantics for JWTs draft -11 addresses Sec-Dir review comments by Chris Lonvick and ballot comments by Stephen Farrell. This should enable clearing the “point raised” status from yesterday’s IESG telechat and progressing the document to the RFC Editor.

The specification is available at:

An HTML-formatted version is also available at:

December 17, 2015
Proof-of-Possession Key Semantics for JWTs spec for IESG telechat

OAuth logoProof-of-Possession Key Semantics for JWTs draft -10 was published for consideration on the IESG telechat later today. All changes were editorial and addressed ballot comments by Barry Leiba.

The specification is available at:

An HTML-formatted version is also available at:

December 15, 2015
Authentication Method Reference Values coordination with OpenID MODRNA

OAuth logoAuthentication Method Reference Values draft -04 added the values “face” (facial recognition), “geo” (geolocation), “hwk” (proof-of-possession of a hardware-secured key), “pin” (Personal Identification Number or pattern), and “swk” (proof-of-possession of a software-secured key), and removed the value “pop” (proof-of-possession), based on input from members of the OpenID Foundation MODRNA working group.

The specification is available at:

An HTML formatted version is also available at:

December 14, 2015
OAuth 2.0 Token Exchange: An STS for the REST of Us

OAuth logoI’m happy to report that a substantially revised OAuth 2.0 Token Exchange draft has been published that enables a broad range of use cases, while still remaining as simple as possible. This draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working group input from the in-person discussions in Prague and mailing list discussions. Thanks to all for your interest in and contributions to OAuth Token Exchange! Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this draft.

The core functionality remains token type independent. That said, new claims are also defined to enable representation of delegation actors in JSON Web Tokens (JWTs). Equivalent claims could be defined for other token types by other specifications.

See the Document History section for a summary of the changes made. Please check it out!

The specification is available at:

An HTML-formatted version is also available at:

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:

Next »