Archive for the 'Claims' Category

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:

January 16, 2015
The JWT, JOSE, and OAuth Assertions drafts have all been sent to the RFC Editor

IETF logoAll of these 9 drafts have now been approved and sent to the RFC Editor:

  1. draft-ietf-jose-json-web-signature
  2. draft-ietf-jose-json-web-encryption
  3. draft-ietf-jose-json-web-key
  4. draft-ietf-jose-json-web-algorithms
  5. draft-ietf-oauth-json-web-token
  6. draft-ietf-jose-cookbook
  7. draft-ietf-oauth-assertions
  8. draft-ietf-oauth-saml2-bearer
  9. draft-ietf-oauth-jwt-bearer

That means that their content is now completely stable and they’ll soon become Internet standards – RFCs. Thanks for all of your contributions in creating, reviewing, and most importantly, using these specifications. Special thanks go to the other spec editors Nat Sakimura, John Bradley, Joe Hildebrand, Brian Campbell, Chuck Mortimore, Matt Miller, and Yaron Goland.

December 9, 2014
JOSE -38 and JWT -32 drafts addressing the last of the IESG review comments

IETF logoSlightly updated JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) drafts have been published that address the last of the IESG review comments, which were follow-up comments by Stephen Farrell and Pete Resnick. All DISCUSS comments had already been addressed by the previous drafts. The one normative change is that implementations must now discard RSA private keys with an “oth” parameter when the implementation does not support private keys with more than two primes. The remaining changes were editorial improvements suggested by Pete.

The specifications are available at:

HTML formatted versions are available at:

November 21, 2014
A JSON-Based Identity Protocol Suite

quillMy article A JSON-Based Identity Protocol Suite has been published in the Fall 2014 issue of Information Standards Quarterly, with this citation page. This issue on Identity Management was guest-edited by Andy Dale. The article’s abstract is:

Achieving interoperable digital identity systems requires agreement on data representations and protocols among the participants. While there are several suites of successful interoperable identity data representations and protocols, including Kerberos, X.509, SAML 2.0, WS-*, and OpenID 2.0, they have used data representations that have limited or no support in browsers, mobile devices, and modern Web development environments, such as ASN.1, XML, or custom data representations. A new set of open digital identity standards have emerged that utilize JSON data representations and simple REST-based communication patterns. These protocols and data formats are intentionally designed to be easy to use in browsers, mobile devices, and modern Web development environments, which typically include native JSON support. This paper surveys a number of these open JSON-based digital identity protocols and discusses how they are being used to provide practical interoperable digital identity solutions.

This article is actually a follow-on progress report to my April 2011 position paper The Emerging JSON-Based Identity Protocol Suite. While standards can seem to progress slowly at times, comparing the two makes clear just how much has been accomplished in this time and shows that what was a prediction in 2011 is now a reality in widespread use.

November 19, 2014
JOSE -37 and JWT -31 drafts addressing remaining IESG review comments

IETF logoThese JOSE and JWT drafts contain updates intended to address the remaining outstanding IESG review comments by Pete Resnick, Stephen Farrell, and Richard Barnes, other than one that Pete may still provide text for. Algorithm names are now restricted to using only ASCII characters, the TLS requirements language has been refined, the language about integrity protecting header parameters used in trust decisions has been augmented, we now say what to do when an RSA private key with “oth” is encountered but not supported, and we now talk about JWSs with invalid signatures being considered invalid, rather than them being rejected. Also, added the CRT parameter values to example JWK RSA private key representations.

The specifications are available at:

HTML formatted versions are available at:

October 24, 2014
JOSE -36 and JWT -30 drafts addressing additional IESG review comments

IETF logoThese JOSE and JWT drafts incorporate resolutions to some previously unresolved IESG comments. The primary change was adding flattened JSON Serialization syntax for the single digital signature/MAC and single recipient cases. See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-36#appendix-A.7 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36#appendix-A.5 for examples. See the history entries for details on the few other changes. No breaking changes were made.

The specifications are available at:

HTML formatted versions are available at:

October 17, 2014
JOSE -35 and JWT -29 drafts addressing AppsDir review comments

IETF logoI’ve posted updated JOSE and JWT drafts that address the Applications Area Directorate review comments. Thanks to Ray Polk and Carsten Bormann for their useful reviews. No breaking changes were made.

The specifications are available at:

HTML formatted versions are available at:

October 14, 2014
JOSE -34 and JWT -28 drafts addressing IESG review comments

IETF logoUpdated JOSE and JWT specifications have been published that address the IESG review comments received. The one set of normative changes was to change the implementation requirements for RSAES-PKCS1-V1_5 from Required to Recommended- and for RSA-OAEP from Optional to Recommended+. Thanks to Richard Barnes, Alissa Cooper, Stephen Farrell, Brian Haberman, Ted Lemon, Barry Leiba, and Pete Resnick for their IESG review comments, plus thanks to Scott Brim and Russ Housley for additional Gen-ART review comments, and thanks to the working group members who helped respond to them. Many valuable clarifications resulted from your thorough reviews.

The specifications are available at:

HTML formatted versions are available at:

September 25, 2014
JOSE -33 and JWT -27 drafts addressing Stephen Kent’s JWK comments

IETF logoUpdated JOSE and JWT drafts have been published that address JSON Web Key (JWK) secdir review comments by Stephen Kent that were inadvertently not addressed in the previous versions. Most of the changes were to the JWK draft. A few changes also had to be made across the other drafts to keep them in sync. I also added acknowledgements to several additional contributors. No breaking changes were made.

The specifications are available at:

Differences since the previous drafts can be viewed at:

HTML formatted versions are available at:

September 23, 2014
JOSE -32 and JWT -26 drafts addressing IETF Last Call comments

IETF logoNew versions of the JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) specifications have been published incorporating feedback received in IETF Last Call comments. Thanks to Russ Housley and Roni Even for their Gen-ART reviews, to Tero Kivinen, Scott Kelly, Stephen Kent, Charlie Kaufman, and Warren Kumari for their secdir reviews, to Tom Yu for his individual review, and to James Manger and Chuck Mortimore who provided feedback based on deployment experiences, as well as to the many JOSE and OAuth working group members who pitched in to discuss resolutions. Many clarifications resulted. No breaking changes were made.

The specifications are available at:

HTML formatted versions are available at:

September 10, 2014
General Availability of Microsoft OpenID Connect Identity Provider

Microsoft has announced that the Azure Active Directory OpenID Connect Identity Provider has reached general availability. Read about it in Alex Simons’ release announcement. The OpenID Provider supports discovery of the provider configuration information as well as session management (logout). The team participated in public OpenID Connect interop testing prior to the release. Thanks to all of you who performed interop testing with us.

August 21, 2014
Working Group Draft for OAuth 2.0 Act-As and On-Behalf-Of

OAuth logoThere’s now an OAuth working group draft of the OAuth 2.0 Token Exchange specification, which provides Act-As and On-Behalf-Of functionality for OAuth 2.0. This functionality is deliberately modelled on the same functionality present in WS-Trust.

Here’s a summary of the two concepts in a nutshell: Act-As indicates that the requestor wants a token that contains claims about two distinct entities: the requestor and an external entity represented by the token in the act_as parameter. On-Behalf-Of indicates that the requestor wants a token that contains claims only about one entity: the external entity represented by the token in the on_behalf_of parameter.

This draft is identical to the previously announced token exchange draft, other than that is a working group document, rather than an individual submission.

This specification is available at:

An HTML formatted version is also available at:

August 20, 2014
Microsoft JWT and OpenID Connect RP libraries updated

This morning Microsoft released updated versions of its JSON Web Token (JWT) library and its OpenID Connect RP library as part of today’s Katana project release. See the Microsoft.Owin.Security.Jwt and Microsoft.Owin.Security.OpenIdConnect packages in the Katana project’s package list. These are .NET 4.5 code under an Apache 2.0 license.

For more background on Katana, you can see this post on Katana design principles and this post on using claims in Web applications. For more on the JWT code, see this post on the previous JWT handler release.

Thanks to Brian Campbell of Ping Identity for performing OpenID Connect interop testing with us prior to the release.

August 14, 2014
The Increasing Importance of Proof-of-Possession to the Web

W3C  logoMy submission to the W3C Workshop on Authentication, Hardware Tokens and Beyond was accepted for presentation. I’ll be discussing The Increasing Importance of Proof-of-Possession to the Web. The abstract of my position paper is:

A number of different initiatives and organizations are now defining new ways to use proof-of-possession in several kinds of Web protocols. These range from cookies that can’t be stolen and reused, identity assertions only usable by a particular party, password-less login, to proof of eligibility to participate. While each of these developments is important in isolation, the pattern of all of them concurrently emerging now demonstrates the increasing importance of proof-of-possession to the Web.

It should be a quick and hopefully worthwhile read. I’m looking forward to discussing it with many of you at the workshop!

August 5, 2014
OAuth Dynamic Client Registration specs addressing remaining WGLC comments

OAuth logoAn updated OAuth Dynamic Client Registration spec has been published that finished applying clarifications requested during working group last call (WGLC). The proposed changes were discussed during the OAuth working group meeting at IETF 90 in Toronto. See the History section for details on the changes made.

The OAuth Dynamic Client Registration Management was also updated to change it from being Standards Track to Experimental.

The updated specifications are available at:

HTML formatted versions are also available at:

July 23, 2014
OAuth Assertions specs describing Privacy Considerations

OAuth logoBrian Campbell updated the OAuth Assertions specifications to add Privacy Considerations sections, responding to area director feedback. Thanks, Brian!

The specifications are available at:

HTML formatted versions are also available at:

July 4, 2014
JWT Proof-of-Possession draft updated for IETF 90

OAuth logoIn preparation for IETF 90 in Toronto, I’ve updated the JWT Proof-of-Possession specification. The changes are mostly editorial in nature, plus a few changes that hadn’t received adequate review prior to inclusion in the -01 draft were reverted.

This specification is available at:

An HTML formatted version is also available at:

July 4, 2014
Act-As and On-Behalf-Of for OAuth 2.0

OAuth logoIn preparation for IETF 90 in Toronto, I’ve updated the OAuth Token Exchange draft to allow JWTs to be unsigned in cases where the trust model permits it. This draft also incorporates some of the review feedback received on the -00 draft. (Because I believe it deserves more working group discussion to determine the right resolutions, John Bradley’s terminology feedback was not yet addressed. This would be a good topic to discuss in Toronto.)

This specification is available at:

An HTML formatted version is also available at:

Next »