Archive for the 'OpenID' Category

October 15, 2013
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.

October 13, 2013
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.

July 31, 2013
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.

July 30, 2013
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.

July 28, 2013
OpenID Connect Presentation at IETF 87

OpenID logoI’ve posted the OpenID Connect presentation that I gave at the OpenID Workshop at IETF 87. Besides giving an overview of the specification status, unsurprisingly given the setting at IETF 87, it also talks about the relationship between OpenID Connect and the IETF specifications that it depends upon. It’s available as PowerPoint and PDF.

July 8, 2013
OpenID Connect Update Presentation at CIS 2013

OpenID logoI’ve posted the OpenID Connect Update presentation that I gave today during the OpenID Workshop at the Cloud Identity Summit 2013. I’ve trimmed down the presentation to be lighter on the “how” and focus more on the “what” and “why”, relative to the one I gave at EIC in May. It’s available in PowerPoint and PDF formats.

June 7, 2013
Proposed Second OpenID Connect Implementer’s Drafts Published

OpenID logoToday marks another significant milestone towards completing the OpenID Connect standard. The OpenID Foundation has announced that the 45 day review period for the second set of proposed Implementer’s Drafts has begun. The working group believes that these are stable and complete drafts. They are being proposed as Implementer’s Drafts, rather than Final Specifications at this time, because of the dependencies on some IETF specifications that are still undergoing standardization – primarily the JSON Web Token (JWT) specification and the JSON Object Signing and Encryption (JOSE) specifications underlying it.

An Implementer’s Draft is a stable version of a specification intended for implementation and deployment that provides intellectual property protections to implementers of the specification. These updated drafts are the product of incorporating months of feedback from implementers and reviewers on earlier specification drafts, starting with the previous Implementer’s Drafts, including feedback resulting from several rounds of interop testing. Thanks to all of you who have been working towards the completion of OpenID Connect!

These specifications are available at:

May 14, 2013
OpenID Connect Update Presentation

OpenID logoI’ve posted the OpenID Connect Update presentation that I gave today during the OpenID Workshop at the European Identity and Cloud Conference. It’s available in PowerPoint and PDF formats.

May 4, 2013
Fourth Release Candidates for OpenID Connect Implementer’s Drafts

OpenID logoA fourth set of release candidates for the upcoming OpenID Connect Implementer’s Drafts has been released. Changes since the third release candidates mostly consist of editorial improvements. There were only two changes that will result in changes to implementations. The first was replacing the “updated_time” claim, which used a textual date format, with the “updated_at” claim, which uses the same numeric representation as the other OpenID Connect date/time claims. The second was replacing the “PKIX” JWK key type with the “x5c” JWK key member (a change actually made this week by the JOSE working group).

These are ready for discussion at Monday’s in-person OpenID Connect working group meeting. All issues filed have been addressed.

The updated specifications are:

These specifications did not change:

Thanks to all who continued reviewing and implementing the specifications, resulting in the improvements contained in this release. I’ll look forward to seeing many of you on Monday!

April 9, 2013
Tim Bray on ID Tokens

OpenID logoTim Bray has written a post giving his take on what ID Tokens are and why they’re valuable, both for OpenID Connect and beyond. Full of geeky identity goodness…

March 27, 2013
Third Release Candidates for OpenID Connect Implementer’s Drafts

OpenID logoA third set of Release Candidates for the pending OpenID Connect Implementer’s Drafts have been released. Like the first set, the second set of Release Candidates, which were published earlier this month, also received thorough review, resulting in a smaller set of additional refinements. The changes primarily made some the claim definitions more precise and provided more guidance on support for multiple languages and scripts.

Were it not for a set of pending changes about to be made to the JSON Object Signing and Encryption (JOSE) specifications, this set of specifications would likely actually be the Implementer’s Drafts. However, the OpenID Connect working group made the decision to have those (non-breaking) JOSE changes be applied before we declare that the Implementer’s Drafts are done. Expect announcements about both the JOSE updates and the OpenID Connect Implementer’s Drafts soon.

The new specifications are:

See the History entries in the specs for more details on the changes made.

Thanks again to all who reviewed and implemented the recent drafts!

March 15, 2013
The Emerging JSON/REST-Based Identity Protocol Suite

IETF logo Last week at the Japan Identity and Cloud Symposium I gave a presentation on this topic: A new set of simple, open identity protocols is emerging that utilize JSON data representations and REST-based communication patterns, including OAuth, JSON Web Token (JWT), JSON Object Signing and Encryption (JOSE), and WebFinger. I’ve posted PowerPoint and PDF versions of the presentation.

Thanks again to the organizers of JICS 2013 for a great event!

March 6, 2013
Second Release Candidates for OpenID Connect Implementer’s Drafts

OpenID logoI’m pleased to announce that a second set of Release Candidates for the upcoming OpenID Connect Implementer’s Drafts have been released. The first set of Release Candidates received thorough review, resulting in quite a bit of detailed feedback. The current specs incorporate the feedback received, making them simpler, more consistent, and easier to understand.

Please review these this week – especially if you had submitted feedback. The working group plans to decide whether we’re ready to declare Implementer’s Drafts during the OpenID Meeting before IETF 86 on Sunday.

The new specifications are:

See the History entries in the specs for details on the changes made.

Thanks again to all who did so much to get us to this point, including the spec writers, working group members, and especially the implementers!

February 14, 2013
Thanks for Voting in the OpenID Board Election

OpenID logoAs you may have seen, the results of the 2013 OpenID Board Election have been announced. Thanks to all of you who participated and thank you for entrusting me with a seat on the board for the next two years. My congratulations to my fellow board community members as well. I intend to make the most of this opportunity to continue making people’s online interactions more seamless, secure, and valuable.

January 25, 2013
Please Vote Now in the OpenID Board Election

OpenID logoThe election for community (individual) OpenID board members is under way at I encourage all of you to vote now. (Don’t wait until the morning of Wednesday, February 6th!) If you’re not already an OpenID Foundation member, you can join for USD $25 at and participate in the election.

I’m running for the board this time and would appreciate your vote. My candidate statement, which is also posted on the election site, follows.

OpenID has the potential to make people’s online interactions seamless, secure, and more valuable. I am already working to make that a reality.

First, a bit about my background with OpenID… I’ve been an active contributor to OpenID since early 2007, including both specification work and serving the foundation. My contributions to the specification work have included: an author and editor of the OpenID Provider Authentication Policy Extension (PAPE) specification, editor of the OAuth 2.0 bearer token specification (now RFC 6750), an author and editor of the JSON Web Token (JWT) specification and the JSON Object Signing and Encryption (JOSE) specifications, which are used by OpenID Connect, and an active member of the OpenID Connect working group.

I’ve also made substantial contributions to the foundation and its mission, including: In 2007 I worked with the community to create a legal framework for the OpenID Foundation enabling both individuals and corporations to be full participants in developing OpenID specifications and ensuring that the specifications may be freely used by all; this led to the patent non-assertion covenants that now protect implementers of OpenID specifications. I served on the board representing Microsoft in 2008 and 2009, during which time I was chosen by my fellow board members to serve as secretary; you’ve probably read some of the meeting minutes that I’ve written. I’ve served on the board as an individual since 2011. I have helped organize numerous OpenID summits and working group meetings. I chaired the election committee that developed the foundation’s election procedures and software, enabling you to vote with your OpenID. I co-chaired the local chapters committee that developed the policies governing the relationships between local OpenID chapters around the world and the OpenID Foundation. I also serve on the marketing committee and am a member of the Account Chooser working group.

I’d like to continue serving on the OpenID board, because while OpenID has had notable successes, its work is far from done. Taking it to the next level will involve both enhanced specifications and strategic initiatives by the foundation. Through OpenID Connect, we are in the process of evolving OpenID to make it much easier to use and deploy and to enable it to be used in more kinds of applications on more kinds of devices. The Account Chooser work is making it easier to use identities that you already have across sites. I’m also pleased that the Backplane Exchange work is happening in the foundation – clear evidence of the increasing value provided by the OpenID Foundation. Yet, as a foundation, we need to continue building a broader base of supporters and deployers of OpenID, especially internationally. We need to form closer working relationships with organizations and communities doing related work. And we need continue to safeguarding OpenID’s intellectual property and trademarks so they are freely available for all to use.

I have a demonstrated track record of serving OpenID and producing results. I want to continue being part of making open identity solutions even more successful and ubiquitous. That’s why I’m running for a community board seat in 2013.

Mike Jones

January 23, 2013
Release Candidates for OpenID Connect Implementer’s Drafts

OpenID logoI’m pleased to announce that release candidate versions of the soon-to-come OpenID Connect Implementer’s Drafts have been released. All the anticipated breaking changes to the protocol are now in place, including switching Discovery over from using Simple Web Discovery to WebFinger and aligning Registration with the OAuth Dynamic Client Registration draft. While several names changed for consistency reasons, the changes to Discovery and Registration were the only architectural changes.

Please thoroughly review these drafts this week and report any issues that you believe need to be addressed before we release the Implementer’s Draft versions.

Normative changes since the December 27th, 2012 release were:

  • Use WebFinger for OpenID Provider discovery instead of Simple Web Discovery. This also means that account identifiers using e-mail address syntax are prefixed by the acct: scheme when passed to WebFinger.
  • Aligned Registration parameters with OAuth Dynamic Registration draft.
  • Added Implementation Considerations sections to all specifications, which specify which features are mandatory to implement.
  • Removed requirement that the “c_hash” and “at_hash” be computed using SHA-2 algorithms (for crypto agility reasons).
  • Refined aspects of using encrypted ID Tokens.
  • Finished specifying elements of key management for self-issued OPs.
  • Added “display_values_supported”, “claim_types_supported”, “claims_supported”, and “service_documentation” discovery elements.
  • Defined REQUIRED, RECOMMENDED, and OPTIONAL discovery elements.
  • Refined Session Management specification, including descriptions of OP and RP iframe behaviors.
  • Deleted “javascript_origin_uris”, which is no longer present in Session Management.
  • Added new “session_state” parameter to the authorization response for Session Management.
  • Added new “post_logout_redirect_url” registration parameter for Session Management.

Also, renamed these identifiers for naming consistency reasons:

  • user_jwk -> sub_jwk (used in self-issued ID Tokens)
  • token_endpoint_auth_type -> token_endpoint_auth_method
  • token_endpoint_auth_types_supported -> token_endpoint_auth_methods_supported
  • check_session_iframe_url -> check_session_iframe
  • end_session_endpoint_url -> end_session_endpoint
  • type -> operation (in Registration)
  • associate -> register (in Registration)
  • application_name -> client_name
  • check_session_endpoint -> check_session_iframe

See the History entries in the specifications for more details.

The new specification versions are at:

Thanks to all who did so much to get us to this point, including the spec writers, working group members, and implementers!

January 2, 2013
OAuth 2.0 and Sign-In

OAuth logoI highly recommend a piece that my friend Vittorio Bertocci wrote on the relationship between OAuth 2.0 and sign-in/federation protocols. While OAuth 2.0 can be used to sign in users and the term “OAuth” is often bandied about in identity contexts, as he points out, there’s a lot of details to fill in to make that possible. That’s because OAuth 2.0 is a resource authorization protocolnot an authentication protocol.

Read his post for a better understanding of how OAuth 2.0 relates to sign-in protocols, including a useful discussion of how OpenID Connect fills in the gaps to enable people to sign in with OAuth 2.0 in an interoperable manner.

December 28, 2012
December 27, 2012 OpenID Connect Release

OpenID logoNew versions of the OpenID Connect specifications have been released resolving numerous open issues raised by the working group. The most significant change is changing the name of the “user_id” claim to “sub” (subject) so that ID Tokens conform to the OAuth JWT Bearer Profile specification, and so they can be used as OAuth assertions. (Also, see the related coordinated change to the OAuth JWT specifications.) A related enhancement was extending our use of the “aud” (audience) claim to allow ID Tokens to have multiple audiences. Also, a related addition was defining the “azp” (authorized party) claim to allow implementers to experiment with this proposed functionality. (This is a slightly more general form of the “cid” claim that Google and Nat Sakimura had proposed.)

Other updates were:

  • The “offline_access” scope value was defined to request that a refresh token be returned when using the code flow that can be used to obtain an access token granting access to the user’s UserInfo endpoint even when the user is not present.
  • A new “tos_url” registration parameter was added so that the terms of service can be specified separately from the usage policy.
  • Clarified that “jwk_url” and “jwk_encryption_url” refer to documents containing JWK Sets – not single JWK keys.

Implementers need to apply these name changes to their code:

  • user_id -> sub
  • prn -> sub
  • user_id_types_supported -> subject_types_supported
  • user_id_type -> subject_type
  • acrs_supported -> acr_values_supported
  • alg -> kty (in JWKs)

See the Document History section of each specification for more details about the changes made.

This release is part of a coordinated release of JOSE, OAuth, and OpenID Connect specifications. You can read about the other releases here: JOSE Release Notes, OAuth Release Notes.

The new specification versions are:

December 6, 2012
2013 OpenID Board Election Announcement

OpenID logoThe OpenID Foundation has announced the upcoming OpenID community board member election. Board members play an important role in safeguarding and advancing OpenID technologies and doing the work of the Foundation on a day-to-day basis. If you’re considering running, I’d be glad to discuss my experiences serving on the board with you.

Watch the OpenID blog and this space for updates on the election over the next few months.

(And yes, I plan to stand for re-election.)

November 19, 2012
OAuth 2.0 Multiple Response Type Encoding Practices

IETF logoOAuth 2.0 (a.k.a. RFC 6749) has an extension point for defining additional response_type values beyond the code and token values defined within the specification. The OAuth 2.0 Multiple Response Type Encoding Practices specification uses this extension point to define the additional response_type values id_token and none, as well as values for the combinations of code, token, and id_token. These response_type values are used by OpenID Connect, as well as other systems using OAuth 2.0.

I’m writing this now because I just updated the Multiple Response Types spec to add an IANA Considerations section to make IANA’s job easier when registering these additional response_type values. No normative changes were made.

The specification is available at:

« Prev - Next »