Musings on Digital Identity

Author: Mike Jones Page 20 of 33

Building the Internet's missing identity layer

Vote to Approve Final OpenID Connect Specifications Under Way

OpenID logoThe vote to approve final OpenID Connect Core, OpenID Connect Discovery, OpenID Connect Dynamic Registration, and OAuth 2.0 Multiple Response Types specifications is now under way, as described at http://openid.net/2014/02/11/vote-for-final-openid-connect-specifications-and-implementers-drafts-is-open/. The OpenID Connect Session Management and OAuth 2.0 Form Post Response Mode specifications are also being approved as Implementer’s Drafts. Voting closes on Tuesday, February 25, 2014.

Please vote now!

Working Group Versions of Refactored OAuth Dynamic Client Registration Specs

OAuth logo
There are now OAuth working group versions of the refactored OAuth Dynamic Client Registration specifications:

  • OAuth 2.0 Dynamic Client Registration Core Protocol
  • OAuth 2.0 Dynamic Client Registration Metadata
  • OAuth 2.0 Dynamic Client Registration Management Protocol

These versions address review comments by Phil Hunt and Tony Nadalin. Phil is now also an author. The data structures and messages used are the same as the previous versions.

The drafts are available at:

HTML formatted versions are also available at:

Congratulations to Torsten Lodderstedt on his election to the OpenID Board

OpenID logoMy congratulations to Torsten Lodderstedt on his election to the OpenID Board on behalf of Deutsche Telekom. And my thanks to Lasse Andresen of ForgeRock and Chuck Mortimore of Salesforce for also being willing to serve. I look forward to serving on the board with Torsten and agree with Chuck’s comment that any of these candidates would do a fine job!

Refactored OAuth Dynamic Client Registration Specs

OAuth logoI’ve posted an updated set of OAuth Dynamic Client Registration specifications that refactors the previous single specification into three specs:

  • OAuth 2.0 Dynamic Client Registration Core Protocol
  • OAuth 2.0 Dynamic Client Registration Metadata
  • OAuth 2.0 Dynamic Client Registration Management Protocol

This refactoring was the result of discussions at IETF 88 in Vancouver, BC. These refactored specifications are compatible with the previous single specification.

The Core specification contains only the definitions needed to perform dynamic registrations. It contains a completely rewritten Use Cases appendix, intended to clarify the different ways that dynamic registration can be performed. It also adds the Software Statement abstraction invented by Phil Hunt — enabling assertions to be made and used about the client software being registered.

The Metadata specification defines useful client metadata values that are nonetheless not essential to the core, such as “client_name“, “logo_uri“, and “software_id“. These were previously defined in the single dynamic registration spec.

The Management specification defines the client management operations Read, Update, and Delete, and addresses client secret rotation. These were previously defined in the single dynamic registration spec.

The drafts are available at:

HTML formatted versions are also available at:

These versions build upon prior restructuring work done by both Justin Richer and Phil Hunt.

JOSE -20 drafts intended for Working Group Last Call

IETF logoJSON Object Signing and Encryption (JOSE) -20 drafts have been published that incorporate the changes agreed to on last week’s JOSE working group call. Hopefully this brings us to the point of Working Group Last Call.

The only normative changes were to change the name of the “use_details” JWK member to “key_ops” and to clarify that “use” is meant for public key use cases, “key_ops” is meant for use cases in which public, private, or symmetric keys may be present, and that “use” and “key_ops” should not be used together.

The drafts, including JSON Web Token (JWT), now also reference draft-ietf-json-rfc4627bis, rather than RFC 4627.

The drafts are available at:

HTML formatted versions are also available at:

JOSE -19 drafts intended for Working Group Last Call

IETF logoJSON Object Signing and Encryption (JOSE) -19 drafts have been published that address all my remaining to-do items for the open issues. I believe the remainder of the issues are either ready to close because of actions already taken in the drafts (the majority of them), require further input to identify any specific remaining proposed actions, if any (a few of them), or will be considered during Working Group Last Call (a few of them). Only editorial changes and one addition were made — no breaking changes.

In short, I believe I have addressed everything needed to bring us to Working Group Last Call for the JWS, JWE, JWK, and JWA specs.

The one addition was to add the optional “use_details” JWK field, as discussed on the JOSE list and the WebCrypto list. While I realize that this proposal hasn’t gotten much review yet (I believe due to the holidays), I wanted to get it in so people can review it in context, and as a concrete step towards meeting a perceived need for additional JWK functionality from the WebCrypto working group. It’s cleanly separable from the rest of the spec, so if the JOSE WG ends up hating it, we can always take it back out and possibly move it to a separate spec. But at least we have a concrete write-up of it now to review.

I also made a one-paragraph change to the JSON Web Token (JWT) spec to reference text in JWE, rather than duplicating it in JWT.

See the History entries for details of the (small number of) changes made.

The drafts are available at:

HTML formatted versions are also available at:

Public review of proposed Final OpenID Connect Specifications has begun

OpenID logoI’m thrilled that OpenID Connect is significantly closer to being done today. Proposed final specifications were published yesterday and the 60 day public review period, which leads up a membership vote to approve the specifications, began today. Unless recall-class issues are found during the review, this means we’ll have final OpenID Connect specifications on Tuesday, February 25, 2014!

My sincere thanks to all of you who so generously shared your vision, expertise, judgment, and time to get us to this point — both those of you who worked on the specs and those who implemented and deployed them and tested your code with one another. I consider myself privileged to have done this work with you and look forward to what’s to come!

Fourth and possibly last Release Candidates for final OpenID Connect specifications and Notice of 24 hour review period

OpenID logoThe fourth and possibly last set of release candidates for final OpenID Connect specifications is now available. Per the decision on today’s working group call, this message starts a 24 hour final working group review period before starting the 60 day public review period. Unless significant issues are raised during the 24 hour review period, we will announce that these specifications are being proposed as Final Specifications by the working group.

The release candidates for Final Specification status are:

Accompanying release candidates for Implementer’s Draft status are:

Accompanying Implementer’s Guides are:

Third Release Candidates for final OpenID Connect specifications

OpenID logoThe third set of release candidates for final OpenID Connect specifications is now available. The changes since the second release candidates have mostly been to incorporate review comments on the Discovery, Dynamic Registration, and Multiple Response Types specifications. All known review comments have now been applied to the specifications.

The release candidates for Final Specification status are:

Accompanying release candidates for Implementer’s Draft status are:

Accompanying Implementer’s Guides are:

Second Release Candidates for final OpenID Connect specifications

OpenID logoThe second set of release candidates for final OpenID Connect specifications is now available. The updates to these specs since the first set of release candidates are the result of the most extensive reviews that the OpenID Connect specifications have ever undergone — including 10 complete reviews of the OpenID Connect Core spec. Thanks to all of you who helped make these the clearest, easiest to use OpenID Connect specifications ever!

The release candidates for Final Specification status are:

Accompanying release candidates for Implementer’s Draft status are:

Accompanying Implementer’s Guides are:

Please do a final review of the OpenID Connect Core specification now, because the results of all review comments have now been applied to it. A small number of review comments to the other specs remain, and will be addressed in the next few days, at which point a third and hopefully final set of release candidates will be released.

JOSE -18 and JWT -13 drafts continuing to address open issues

IETF logoJSON Object Signing and Encryption (JOSE) -18 and JSON Web Token (JWT) -13 drafts have been published. The JOSE drafts contain changes to address 34 of the 43 currently open issues. The JWT draft addresses several of the working group last call (WGLC) comments. No breaking changes were made to any of the specifications. The most visible change is that all registries now include Description fields — a change that was requested in JWT WGLC.

See the Document History appendices for more details on the changes made and issues addressed.

The drafts are available at:

HTML formatted versions are also available at:

First Release Candidates for final OpenID Connect specifications

OpenID logoI’m pleased to announce that the first release candidate versions for final OpenID Connect specifications have been published. The complete set of specifications has been updated to resolve all issues that had been filed against the specs being finished.

Please review these this week, in time for the in-person working group meeting on Monday. Besides publishing the specs in the usual formats, I’ve also created a Word version of the core spec with tracked changes turned on to facilitate people marking it up with specific proposed text changes. If you’re in the working group, please download it and make any corrections or changes you’d like to propose for the final specification.

The release candidate spec versions are:

Also, two implementer’s guides are also available to serve as self-contained references for implementers of basic Web-based Relying Parties:

Thanks to Nat Sakimura for the early feedback. The structure of Core has been changed somewhat since -13 to adopt some of his suggestions.

OpenID Connect Specs Nearing Completion

OpenID logoBased on feedback from developers, the OpenID Connect working group decided to replace the OpenID Connect Messages and OpenID Connect Standard specifications with a new OpenID Connect Core specification that combines the contents from both of them before finishing OpenID Connect. The content has also been restructured to separate Authentication from other features such as Claims and to have separate Authentication sections for the different OAuth 2.0 flows. No changes to the protocol were made. The publication of this new spec is another major step towards finishing OpenID Connect.

Please review this and the other OpenID Connect specifications in the coming week. While a few local changes will still be made this week to address issues that have been identified since the approval of the Implementer’s Drafts, I fully expect that the working group will decide at the in-person working group meeting just over a week from now that it’s time to publish proposed final specifications.

Thanks to Nat Sakimura for producing a proof-of-concept document restructuring that the structure of the current OpenID Connect Core spec is based upon. And thanks to Torsten Lodderstedt for convincing us that the specs will be clearer by better separating the descriptions of logically distinct features while combining previously separate descriptions of highly interrelated functionality.

JOSE -17 and JWT -12 drafts reducing duplicated text

IETF logoJSON Object Signing and Encryption (JOSE) -17 and JSON Web Token (JWT) -12 drafts have been published with editorial changes that reduce duplicated text between the JOSE specs. Also, the “typ” and “cty” header parameters were revised to always refer to media type values. The text about which serializations are mandatory to implement was updated. Finally, thanks to Matt Miller for supplying an encryption example using PBES2.

See the Document History appendices for more details on the changes made and issues addressed.

The drafts are available at:

HTML formatted versions are also available at:

WebFinger is now RFC 7033!

IETF logoI’m pleased to announce that the WebFinger specification has now been published as an RFC — RFC 7033. WebFinger enables discovery of information about a user or resource at a host using an HTTP query to a well-known https endpoint, with the discovered information being returned in a simple JSON structure. For instance, OpenID Connect uses WebFinger to discover the location of a user’s OpenID Connect server.

Thanks particularly go to Paul Jones, who tirelessly edited the spec, ably navigating the sometimes thankless task of addressing the numerous and sometimes conflicting comments and suggestions that were made, and in the end, resolving them to everyone’s satisfaction, and in a high-quality manner. Thanks a bunch, Paul!

I’ll also take the occasion to thank Yaron Goland for inventing the Simple Web Discovery specification. I believe that the simplicity of the approved WebFinger specification is a direct result of the influence that Simple Web Discovery had upon WebFinger.

I look forward to seeing all the useful things that will be accomplished using WebFinger!

JOSE -16 drafts addressing 45 editorial and minor issues

IETF logoJSON Object Signing and Encryption (JOSE) -16 drafts have been published that address 45 editorial and minor issues. See the Document History sections for lists of the specific issues addressed. Thanks to Jim Schaad for again meeting with me in person to go over proposed text changes in my working drafts before these specifications were published.

One breaking change was made: When doing ECDH-ES key agreement, the AlgorithmID value used in the KDF computation now has a length prefix. So for instance, the representation of the “enc” value “A128GCM” is now prefixed by the number 7, represented as a 32-bit big-endian value, when used as the AlgorithmID value. (Such prefixes were already in place for the other variable-length KDF parameters.)

The drafts are available at:

HTML formatted versions are also available at:

JOSE -15 drafts addressing 37 editorial and minor issues

IETF logoJSON Object Signing and Encryption (JOSE) -15 drafts have been published that address 37 editorial and minor issues filed by Jim Schaad. See the Document History sections for lists of the specific issues addressed. Thanks to Jim for meeting with me in person to go over proposed text changes in my working drafts before these specifications were published. We also agreed on a number of additional proposed resolutions that will be addressed in the next set of drafts published.

The one substantive change worth noting is that when multiple signatures or encryption recipients are present, it is now up to the application whether to reject the entire JWS or JWE when some, but not all of the signature or encryption validations fail. (Previously, if any validation failed, the entire JWS or JWE was always rejected.)

The drafts are available at:

HTML formatted versions are also available at:

WebFinger Specification Ready for RFC Editor

IETF logoThe WebFinger specification enables discovery of information about a user or resource at a host using an HTTP query to a well-known https endpoint, with the discovered information being returned in a simple JSON structure. For instance, OpenID Connect uses WebFinger to discover the location of a user’s OpenID Connect server.

I’m pleased to report that WebFinger has now completed working group last call, IETF last call, and IESG review. The next step is for the draft to be sent to the RFC Editor for publication as an RFC. The current draft is available at:

Those of you who have been following WebFinger probably realize that I have been an active contributor in moving WebFinger forward as a standard and keeping it simple. WebFinger, as it exists today, was directly influenced by the Simple Web Discovery spec that Yaron Goland and I wrote earlier. I have reviewed every IETF draft and provided comments as well as specific text to the authors. I am grateful to authors Paul Jones and Gonzalo Salgueiro for deciding to add me as a co-author, in recognition of my participation as a de-facto co-author behind the scenes.

Second OpenID Connect Implementer’s Drafts Approved

OpenID logoThe OpenID Foundation members have voted to approve a second set of OpenID Connect Implementer’s Drafts. The working group intends for the final specifications to be compatible with these Implementer’s Drafts.

Implementer’s Drafts are stable versions of specifications intended for trial implementations and deployments that provide specific IPR protections to those using them. Implementers and deployers are encouraged to continue providing feedback to the working group on these specifications based upon their experiences using them.

OpenID Connect Server in a Nutshell

OpenID logoNat Sakimura has written a valuable post describing how to write an OpenID Connect server in three simple steps. It shows by example how simple it is for OAuth servers to add OpenID Connect functionality. This post is a companion to his previous post OpenID Connect in a Nutshell, which described how simple it is to build OpenID Connect clients. If you’re involved in OpenID Connect in any way, or are considering becoming involved, these posts are well worth reading.

Page 20 of 33

Powered by WordPress & Theme by Anders Norén