Musings on Digital Identity

Category: Federation Page 2 of 4

OpenID Connect EAP ACR Values specification

OpenID logoThe OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 specification has been submitted to the OpenID Enhanced Authentication Profile (EAP) working group. Per the abstract:

This specification enables OpenID Connect Relying Parties to request that specific authentication context classes be applied to authentications performed and for OpenID Providers to inform Relying Parties whether these requests were satisfied. Specifically, an authentication context class reference value is defined that requests that phishing-resistant authentication be performed and another is defined that requests that phishing-resistant authentication with a hardware-protected key be performed. These policies can be satisfied, for instance, by using W3C scoped credentials or FIDO authenticators.

The specification is glue that ties together OpenID Connect, W3C Web Authentication, and FIDO Authenticators, enabling them to be seamlessly used together.

The specification is available at:

OpenID Connect Back-Channel Logout Specification

OpenID logoA new back-channel OpenID Connect Logout spec has been published at http://openid.net/specs/openid-connect-backchannel-1_0.html. This can coexist with or be used instead of the front-channel-based Session Management and HTTP-Based Logout specifications.

The abstract for the new specification states:

This specification defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out; this differs from front-channel logout mechanisms, which communicate logout requests from the OP to RPs via the User Agent.

This completes publication of the three planned OpenID Connect logout mechanisms: two that communicate on the front-channel through the User Agent (browser) and this one that communicates on the back-channel, without involving the User Agent. See the Introduction for a discussion of the upsides and downsides of the different logout approaches. As much as we’d like there to be a single logout solution, both experience and extensive discussions led us to the conclusion that there isn’t a feasible one-size-fits-all approach.

Reviews of the new (and existing!) specifications are welcomed.

Thanks to John Bradley, Pedro Felix, Nat Sakimura, Brian Campbell, and Todd Lainhart for their contributions to the creation of the specification.

HTTP-Based OpenID Connect Logout Spec

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.

Growing list of OpenID Connect libraries available

OpenID logoAs described in today’s openid.net post, a growing list of OpenID Connect and JWT/JOSE libraries are available. Check them out at http://openid.net/developers/libraries/.

OpenID Connect Specifications are Final!

OpenID logoThe OpenID Connect Core, OpenID Connect Discovery, OpenID Connect Dynamic Registration, and OAuth 2.0 Multiple Response Types specifications are now final! These are the result of almost four years of intensive work, both by specification writers including myself, and importantly, by developers who built, deployed, and interop tested these specifications throughout their development, significantly improving the quality of both the specs and their implementations as a result.

Throughout the development of OpenID Connect, we applied the design philosophy “keep simple things simple”. While being simple, OpenID Connect is also flexible enough to enable more complex things to be done, when necessary, such as encrypting claims, but this flexibility doesn’t come at the cost of keeping simple things simple. Its simplicity is intended to make it much easier for deployers to adopt than previous identity protocols. For instance, it uses straightforward JSON/REST data structures and messages, rather than XML/SOAP or ASN.1.

I want to take this opportunity to thank several key individuals without whose enthusiastic participation and expertise OpenID Connect wouldn’t have come into being. Nat Sakimura and John Bradley were there every step of the way, both motivating the features included and providing their insights into how to make the result both highly secure and very usable. Breno de Medeiros and Chuck Mortimore were also key contributors, bringing their practical insights informed by their implementation and deployment experiences throughout the process. I want to acknowledge Don Thibeau’s leadership, foresight, wisdom, and perseverance in leading the OpenID Foundation throughout this effort, bringing us to the point where today’s completed specifications are a reality. Numerous people at Microsoft deserve credit for believing in and supporting my work on OpenID Connect. And finally, I’d like to thank all the developers who built OpenID Connect code, told us what they liked and didn’t, and verified that what was specified would actually work well for them in practice.

Of course, final specifications are really just the beginning of the next journey. I look forward to seeing how people will use them to provide the Internet’s missing identity layer, making people’s online experiences, both on the Web and on their devices, easier, safer, and more satisfying!

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!

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.

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.

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:

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!

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!

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!

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!

An update on our war against account hijackers

I recommend reading Google’s post An update on our war against account hijackers. It describes the kinds of measures taken by professionally-run Identity Providers to defend against account takeover.

A message not stated but implied is that consumers and Web sites are far better off depending upon identities provided by organizations with the resources and dedication to successfully fight takeover attempts. Sites with their own username/password login systems without these defenses are vulnerable, and would be better off using federated identities from professionally-run Identity Providers.

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!

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.

Page 2 of 4

Powered by WordPress & Theme by Anders Norén