Archive for the 'Claims' Category

November 23, 2016
Security Event Token (SET) Specification and IETF Security Events Working Group

IETF logoAs those of you who have been following the id-event@ietf.org mailing list or attended the inaugural meeting of the new IETF Security Events working group know, Phil Hunt and co-authors (including myself) have been working on a Security Event Token (SET) specification. A SET is a JSON Web Token (JWT) with an “events” claim that contains one or more event identifiers (which are URIs) that say what event the SET describes.

This work isn’t being done in isolation. Among others, the OpenID Risk and Incident Sharing and Coordination (RISC) working group, the OpenID Back-Channel Logout specification, and the SCIM Provisioning Events work intend to use the Security Event Token format.

To make this concrete, the claims in an example OpenID Connect Back-Channel Logout token (which is a SET) are:

{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "iat": 1471566154,
  "jti": "bWJq",
  "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
  "events": {
    "http://schemas.openid.net/event/backchannel-logout": {}
  }
}

You’ll see that this a normal JWT, with the issuer, subject, and session ID identifying the target of the logout, and the “events” value identifying the JWT as a logout SET.

Today, we published an updated SET spec based on discussions at IETF 97, which simplifies the SET parsing. Thanks to Phil Hunt or Oracle, William Denniss of Google, Morteza Ansari of Cisco, and the numerous other contributors who’ve gotten us to this point. We now believe that this specification is ready for adoption by the Security Events working group.

The specification is available at:

An HTML-formatted version is also available at:

The OpenID Connect Back-Channel Logout specification should be updated soon (after the US Thanksgiving holiday) to utilize the simplified SET syntax. Happy Thanksgiving, everyone!

November 13, 2016
“amr” Values specification addressing area director comments

OAuth logoDraft -04 of the Authentication Method Reference Values specification addresses comments by our security area director Kathleen Moriarty. Changes were:

  • Added “amr” claim examples with both single and multiple values.
  • Clarified that the actual credentials referenced are not part of this specification to avoid additional privacy concerns for biometric data.
  • Clarified that the OAuth 2.0 Threat Model [RFC6819] applies to applications using this specification.

The specification is available at:

An HTML-formatted version is also available at:

October 14, 2016
“amr” Values specification addressing shepherd comments

OAuth logoDraft -03 of the Authentication Method Reference Values specification addresses the shepherd comments. It changes the references providing information about specific “amr” values to be informative, rather than normative. A reference to ISO/IEC 29115 was also added. No normative changes were made.

The specification is available at:

An HTML-formatted version is also available at:

September 9, 2016
“amr” Values specification addressing WGLC comments

OAuth logoDraft -02 of the Authentication Method Reference Values specification addresses the Working Group Last Call (WGLC) comments received. It adds an example to the multiple-channel authentication description and moves the “amr” definition into the introduction. No normative changes were made.

The specification is available at:

An HTML-formatted version is also available at:

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:

Next »