Archive for the 'OpenID' Category
A 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!
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!
I’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!
As 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.
The election for community (individual) OpenID board members is under way at https://openid.net/foundation/members/elections/14. 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 https://openid.net/foundation/members/registration 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.
I’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 “
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 “
- 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:
sub_jwk(used in self-issued ID Tokens)
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!
I 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 protocol – not 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.
New 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:
See the Document History section of each specification for more details about the changes made.
The new specification versions are:
The 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.)
OAuth 2.0 (a.k.a. RFC 6749) has an extension point for defining additional
response_type values beyond the
token values defined within the specification. The OAuth 2.0 Multiple Response Type Encoding Practices specification uses this extension point to define the additional
none, as well as values for the combinations of
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:
I’ve updated the Simple Web Discovery (SWD) specification to incorporate a means of performing discovery on domains for which it may not be possible to create a .well-known endpoint. This can often be the case for hosted domains, where it is common for e-mail to be provided but no web server. This solution was developed in discussions by the OpenID Connect working group.
This draft is being published now to facilitate discussions of the need to enable discovery for hosted domains and possible solutions for doing so at the IETF Applications Area working group meeting at IETF 85 in Atlanta.
The updated specification is available at:
Changes made were:
- Specified that the SWD server for a domain may be located at the
simple-web-discoverysubdomain of the domain and that SWD clients must first try the endpoint at the domain and then the endpoint at the subdomain.
- Removed the
SWD_service_redirectresponse, since redirection can be accomplished by pointing the
simple-web-discoverysubdomain to a different location than the domain’s host.
mailto:from examples in favor of bare e-mail address syntax.
- Specified that SWD servers may also be run on ports other than 443, provided they use TLS on those ports.
An HTML formatted version is available at:
The OpenID Connect working group has released an update to the OpenID Connect specifications that continues incorporating significant developer feedback received, while maintaining as much compatibility with the implementer’s drafts as possible. The Connect specs have also been updated to track updates to the OAuth and JOSE specs, which they use. The primary normative changes are as follows:
- Make changes to allow path in the issuer_identifier, per issue #513
- Add hash and hash check of access_token and code to id_token, per issue #510
- Split encrypted response configurations into separate parameters for alg, enc, int
- Added optional id_token to authorization request parameters, per issue #535
- Now requested claims add to those requested with scope values, rather than replacing them, per issue #547
- Added error interaction_required and removed user_mismatched, per issue #523
- Changed invalid_request_redirect_uri to invalid_redirect_uri, per issue #553
- Removed “embedded” display type, since its semantics were not well defined, per issue #514
A significant non-normative addition is:
- Add example JS code for Basic client
Implementers are particularly encouraged to build and provide feedback on the new and modified features.
The new versions are available from http://openid.net/connect/ or at:
The Third OpenID Connect Interop is currently under way – this time based upon approved Implementer’s Drafts. Currently 7 implementations are being tested, with I believe more to be added. The interop is designed to enable people to test the implementations they’ve built against other implementations and verify that specific features that they’ve built are working correctly. This has several benefits: it helps debug implementations, it helps debug the specifications, and it results in greater interoperability among OpenID Connect implementations.
As background, like the other OSIS interops, the OpenID Connect interop is an opportunity for implementers to try their code against one another’s in a systematic way. It is not a conformance test; participants do not “pass” or “fail”. There is no requirement that you must support particular features to participate or that you must participate in all aspects of the interop.
If you’d like to participate in the interop, join the OpenID Connect Interop mailing list and send us a note there saying who your interop contact person will be, the name of your organization (can be an individual), the name of your implementation (can be your name), and a list of the online testing endpoints for your implementation. Testing is performed online on your schedule, with results recorded on the interop wiki. That being said, an in-person meeting of interop participants will also be held on Friday, March 2 in San Francisco (the week of RSA) for those who are able to attend.
The OpenID Foundation members have overwhelmingly voted to approve the OpenID Connect specifications as Implementer’s Drafts. This is an important milestone in the process of completing the OpenID Connect specifications.
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 to provide timely feedback to the working group on the specifications based upon their experiences with them.
My congratulations to Greg Keegstra and Axel Nennker for their election to the OpenID Board of Directors. Greg brings strong marketing chops and his can-do spirit to the board. Axel returns with his mix of deep technical expertise and common sense. I’m looking forward to serving with both of you!
The vote to approve six OpenID Connect specification drafts as OpenID Foundation Implementer’s Drafts is under way. To vote, go to https://openid.net/foundation/members/polls/62 and log in using your OpenID by the morning of Wednesday, February 15th. For more information about OpenID Connect, visit http://openid.net/connect/.
Nat Sakimura has written a valuable post describing OpenID Connect in a nutshell. It shows by example how simple it is for relying parties to use basic OpenID Connect functionality. If you’re involved in OpenID Connect in any way, or are considering becoming involved, his post is well worth reading.
OpenID Connect is a simple identity layer built on top of OAuth 2.0. It enables clients to verify the identity of and to obtain basic profile information about an end-user. It uses RESTful protocols and JSON data structures to provide a low barrier to entry. The design philosophy behind OpenID Connect is “make simple things simple and make complex things possible”.
OpenID Connect is designed to cover a range of scenarios and use cases including Internet, enterprise, cloud, and mobile, to span security & privacy requirements from non-sensitive information to highly secure, and to span sophistication of claims usage, from basic default claims to specific requested claims to aggregated and distributed claims. It maximizes the simplicity of implementations by reusing existing OAuth 2.0, JWT, and SWD specs and employing a modular structure, allowing deployments to utilize only the pieces they need.
OpenID Connect has a number of key differences from OpenID 2.0. Among them are: support for native client applications, identifiers using e-mail address format, standard UserInfo endpoint for retrieving basic claims about the end-user, being designed to work well on mobile phones, use of JSON/REST rather than XML, support for encryption and higher LoAs, and support for distributed and aggregated claims.
Today marks a milestone in the OpenID Connect specification development: the OpenID Foundation announced that the current set of drafts is being reviewed for approval as Implementer’s Drafts. 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 drafts are the product of incorporating months of feedback from implementers and reviewers of earlier specification drafts, including feedback resulting from interop testing. Thanks to all of you who contributed to the development of OpenID Connect!
A new set of open identity protocols is emerging that utilizes JSON data representations and simple REST-based communication patterns. These protocols and data formats are intentionally designed to be easy to use in browsers and modern web development environments.
I hope you’ll find it worthwhile reading. I’m looking forward to discussing it with many of you at the workshop!