Mike Jones: self-issued

Musings on Digital Identity

Author: Mike Jones Page 17 of 33

Building the Internet's missing identity layer

Proof-of-Possession Key Semantics for JWTs spec addressing WGLC comments

By

On July 7, 2015

In Claims, Cryptography, OAuth, Specifications

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:

JWK Thumbprint -06 addressing SecDir review comments

By

On June 24, 2015

In Cryptography, JSON, Specifications

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:

JWS Signing Input Options Specification

By

On May 27, 2015

In Cryptography, JSON, Specifications

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:

Tightened Key Managed JWS Spec

By

On May 27, 2015

In Cryptography, JSON, Specifications

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:

JWK Thumbprint -05 draft addressing issues raised in Kathleen Moriarty’s AD review

By

On May 27, 2015

In Cryptography, JSON, Specifications

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:

The OAuth Assertions specs are now RFCs!

By

On May 19, 2015

In Claims, Cryptography, JSON, OAuth, Specifications

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.

JWT and JOSE are now RFCs!

By

On May 19, 2015

In Claims, Cryptography, JSON, OAuth, Specifications

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!

Perspectives on the OpenID Connect Certification Launch

By

On April 30, 2015

In Documentation, Events, Interoperability, OpenID, Software

OpenID Certified logoMany of you were involved in the launch of the OpenID Foundation’s certification program for OpenID Connect Implementations. I believe that OpenID Certification is an important milestone on the road to widely-available interoperable digital identity. It increases the likelihood that OpenID Connect implementations by different parties will “just work” together.

A fair question is “why do we need certification when we already have interop testing?”. Indeed, as many of you know, I was highly involved in organizing five rounds of interop testing for OpenID Connect implementations while the specs were being developed. By all measures, these interop tests were highly effective, with participation by 20 different implementations, 195 members of the interop testing list, and over 1000 messages exchanged among interop participants. Importantly, things learned during interop testing were fed back into the specs, making them simpler, easier to understand, and better aligned with what developers actually need for their use cases. After improving the specs based on the interop, we’d iterate and hold another interop round. Why not stop there?

As I see it, certification adds to the value already provided by interop testing by establishing a set of minimum criteria that certified implementations have been demonstrated meet. In an interop test, by design, you can test the parts of the specs that you want and ignore the rest. Whereas certification raises the bar by defining a set of conformance profiles that certified implementations have been demonstrated to meet. That provides value to implementers by providing assurances that if their code sticks to using features covered by the conformance tests and uses certified implementations, their implementations will seamlessly work together.

The OpenID Foundation opted for self-certification, in which the party seeking certification does the testing, rather than third-party certification, in which a third party is paid to test the submitter’s implementation. Self-certification is simpler, quicker, and less expensive than third-party certification. Yet the results are nonetheless trustworthy, both because the testing logs are made available for public scrutiny as part of the certification application, and because the organization puts its reputation on the line by making a public declaration that its implementation conforms to the profile being certified to.

A successful certification program doesn’t just happen. At least a man-year of work went into creating the conformance profiles, designing and implementing the conformance testing software, testing and refining the tests, testing implementations and fixing bugs found, creating the legal framework enabling self-certification, and putting it all in place. The OpenID Connect Working Group conceived of a vision for a simple but comprehensive self-certification program, created six detailed conformance profiles based on the requirements in the specs, and quickly addressed issues as participants had questions and identified problems during early conformance testing. Roland Hedberg did heroes’ work creating the conformance testing software and responding quickly as issues were found. Don Thibeau shared the vision for “keeping simple things simple” and extended that mantra we employed when designing OpenID Connect to the legal and procedural frameworks enabling self-certification. And many thanks to the engineers from Google, ForgeRock, Ping Identity, NRI, PayPal, and Microsoft who rolled up their sleeves and tested both their code and the tests, improving both along the way. You’ve all made a lasting contribution to digital identity!

I think the comment I most appreciated about the certification program was made by Eve Maler, herself a veteran of valuable certification programs past, who said “You made it as simple as possible so every interaction added value”. High praise!

Here’s some additional perspectives on the OpenID Certification launch:

10 Years of Digital Identity!

By

On April 11, 2015

In Events, People

How time flies! In March 2005 I began working on digital identity. This has by far been the most satisfying phase of my career, both because of the great people I’m working with, and because we’re solving real problems together.

An interesting thing about digital identity is that, by definition, it’s not a problem that any one company can solve, no matter how great their technology is. For digital identity to be “solved”, the solution has to be broadly adopted, or else people will continue having different experiences at different sites and applications. Solving digital identity requires ubiquitously adopted identity standards. Part of the fun and the challenge is making that happen.

Microsoft gets this, backs our work together, and understands that when its identity products work well with others that our customers and partners choose to use, we all win. Very cool.

Those who of you who’ve shared the journey with me have experienced lots of highs and lows. Technologies that have been part of the journey have included Information Cards, SAML, OpenID 2.0, OAuth 2.0, JSON Web Tokens (JWTs), JSON Web Signing and Encryption (JOSE), and OpenID Connect. Work has been done in OASIS, the Information Card Foundation, the OpenID Foundation, the Open Identity Exchange (OIX), the Liberty Alliance, the IETF, the W3C, the FIDO Alliance, and especially lots of places where the right people chose to get together, collaborate, and made good things happen — particularly the Internet Identity Workshop.

It’s worth noting that this past week the Internet Identity Workshop held its 20th meeting. They’ve been held like clockwork every spring and fall for the past 10 years, providing an indispensable, irreplaceable venue for identity practitioners to come together and get things done. My past 10 years wouldn’t have been remotely the same without the past 10 years of IIW. My sincerest thanks to Phil, Doc, and Kaliya for making it happen!

I won’t try to name all the great people I’ve worked with and am working with because no matter how many I list, I’d be leaving more out. You know who you are!

While we’re all busy solving problems together and we know there’s so much more to do, it’s occasionally good to step back and reflect upon the value of the journey. As Don Thibeau recently observed when thanking Phil Windley for 10 years of IIW, “these are the good old days”.

OpenID Connect working group presentation at April 6, 2015 OpenID workshop

By

On April 6, 2015

In Events, OpenID

OpenID logoI’ve posted the OpenID Connect working group presentation that I gave at the April 6, 2015 OpenID Workshop. It covers the current specification approval votes for the OpenID 2.0 to OpenID Connect Migration and OAuth 2.0 Form Post Response Mode specifications, the status of the session management/logout specifications, and OpenID Connect Certification. It’s available as PowerPoint and PDF.

OAuth Proof-of-Possession draft -02 closing open issues

By

On March 9, 2015

In Claims, Cryptography, JSON, OAuth, Specifications

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:

HTTP-Based OpenID Connect Logout Spec

By

On March 6, 2015

In Federation, OpenID, Specifications

OpenID logoA new HTTP-Based OpenID Connect Logout spec has been published at http://openid.net/specs/openid-connect-logout-1_0.html. This can coexist with or be used instead of the current HTML postMessage-based Session Management Spec.

The abstract for the new spec states:

This specification defines an HTTP-based logout mechanism that does not need an OpenID Provider iframe on Relying Party pages. Other protocols have used HTTP GETs to RP URLs that clear cookies and then return a hidden image or iframe content to achieve this. This specification does the same thing. It also reuses the RP-initiated logout functionality specified in Section 5 of OpenID Connect Session Management 1.0 (RP-Initiated Logout).

Special thanks to Brian Campbell, Torsten Lodderstedt, and John Bradley for their insights that led to some of the decisions in the spec.

JWK Thumbprint -04 draft incorporating feedback during second WGLC

By

On March 3, 2015

In Cryptography, JSON, Specifications

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:

Key Managed JSON Web Signature (KMJWS) specification

By

On March 3, 2015

In Cryptography, JSON, Specifications

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 https://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.

JWK Thumbprint -03 draft incorporating additional feedback

By

On February 26, 2015

In Cryptography, JSON, Specifications

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:

JWK Thumbprint -02 draft incorporating WGLC feedback

By

On February 19, 2015

In Cryptography, JSON, Specifications

IETF logoNat Sakimura and I have updated the JSON Web Key (JWK) Thumbprint draft to incorporate feedback receiving during JOSE working group last call. Changes were:

  • No longer register the new JSON Web Signature (JWS) and JSON Web Encryption (JWE) Header Parameters and the new JSON Web Key (JWK) member name jkt (JWK SHA-256 Thumbprint) for holding these values.
  • Added security considerations about the measures needed to ensure that a unique JWK Thumbprint value is produced for a key.
  • Added text saying that a base64url encoded JWK Thumbprint value could be used as a kid (key ID) value.
  • Broke a sentence up that used to be way too long.

The specification is available at:

An HTML formatted version is also available at:

2015 OpenID Foundation Board Election Results

By

On February 5, 2015

In OpenID, People

OpenID logoThanks to those of you who re-elected me to a two-year term on the OpenID Foundation board of directors. As I wrote in my candidate statement, while OpenID is having notable successes, our work is far from done. Taking it to the next level will involve both additional specifications and strategic initiatives by the foundation. I plan to continue taking an active role in making open identity solutions even more successful, valuable, and ubiquitous. Thanks for placing your trust in me!

I’d like to also take this opportunity to congratulate my fellow board members who were also re-elected: Torsten Lodderstedt, John Bradley, and George Fletcher. See the OpenID Foundation’s announcement of the 2015 election results for more information.

JWK Thumbprint -01 draft incorporating feedback from Jim Schaad

By

On January 22, 2015

In Cryptography, JSON, Specifications

IETF logoThe JSON Web Key (JWK) Thumbprint draft has been updated to incorporate feedback received from Jim Schaad, including defining the JWK Thumbprint computation in a manner that allows different hash functions to be used over time. The specification is available at:

An HTML formatted version is also available at:

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

By

On January 16, 2015

In Claims, Cryptography, JSON, OAuth, Specifications

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.

Final pre-RFC JOSE drafts

By

On January 16, 2015

In Cryptography, JSON, Specifications

IETF logoNew versions of the JSON Web Signature (JWS) and JSON Web Key (JWK) drafts have been submitted that address a few more IESG comments that were identified by our area director Kathleen Moriarty during her final review of the documents. Thanks to Richard Barnes for working on wording to address his comment on security considerations for binding attributes to JWKs. See the Document History sections for descriptions of the edits, none of which resulted in data structure changes.

The plan is for these documents to be forwarded to the RFC editor. The other related documents have already been approved.

The specifications are available at:

HTML formatted versions are available at:

Page 17 of 33

Previous

Next

Powered by WordPress & Theme by Anders Norén