OpenID Connect Technology Meeting will be held on Oct. 22, 2012 at Google, Mountain View.
Bluewater Tech Talk Room
Google Building 1220
1220 Charleston Road
Mountain View, CA
Lunch is at 11:30am and the meeting starts at 12:30pm.
Non Members are welcome to attend, but must be aware of the OIDF IPR policy.
You can find the details and register at: http://connect-wg-oct-2012.eventbrite.com
Today at the European Identity and Cloud Conference it was announced that OpenID Connect has won the 2012 European Identity and Cloud Award for “Best Innovation / New Standard”. The OpenID Foundation and the Connect working group members want to thank Kuppinger Cole for this prestigious award and their vote of confidence in the significance of OpenID Connect.
Dave Kearns of Kuppinger Cole said this about the award:
“I’m pleased that Kuppinger Cole has granted OpenID Connect the award for Best Innovation/New Standard this year. What’s most impressive is that this elegantly simple design resulted from the cooperation of such a diverse global set of contributors. I expect OpenID Connect to have a substantial positive impact on usable, secure identity solutions both for traditional computing platforms and mobile devices. My congratulations to the OpenID Foundation!”
The application presented by the OpenID Foundation that resulted in the award follows.
| Project company: | OpenID Foundation |
| Award category: | Best Innovation / New Standard in Information Security |
1) Name of the Standard
OpenID Connect
2) Brief description of the Standard
OpenID Connect is a simple JSON/REST-based interoperable identity protocol built on top of the OAuth 2.0 family of specifications. Its design philosophy is “make simple things simple and make complicated things possible”.
While OAuth 2.0 is a generic access authorization delegation protocol, thus enabling the transfer of arbitrary data, it does not define ways to authenticate users or communicate information about them. OpenID Connect provides a secure, flexible, and interoperable identity layer on top of OAuth 2.0 so that digital identities can be easily used across sites and applications. While enabling a default set of common claims about the user (such as name, e-mail address, and a user identifier enabling SSO) to be easily employed, OpenID Connect also enables participants to exchange any claims relevant to their application using simple JSON-based data structures.
As it is based in OAuth 2.0, OpenID Connect reaches beyond the Web. OpenID Connect brings identity interactions to “apps” and “native applications” on both smart phones and traditional computing devices, in addition to Web sites.
From a security perspective, OpenID Connect was built to be able to gracefully range from the low security levels typically employed for social networks to medium security levels needed for business applications to high security requirements needed for many government applications. OpenID Connect spans this wide range of applications by using JSON-based digital signature and encryption standards.
From a privacy perspective, OpenID Connect allows the selective sharing of attributes with user consent. It also enables the use of pairwise pseudonymous identifiers, thereby avoiding correlations as appropriate.
From a business perspective, OpenID Connect meets business needs for the use of claims from multiple Claims Providers in a single context (rather than a single Identity Provider being the source of all claims for any given interaction). It enables the use of Aggregated Claims, where signed claim values can be collected and passed on by OpenID Providers and the use of Distributed Claims, where claims are passed by reference, rather than by value, and dynamically retrieved by Relying Parties.
From a design perspective, OpenID Connect’s modular design enables flexible deployments. Implementations can use only the components they need, while still remaining interoperable. For instance, “Discovery” and “Dynamic Client Registration” can used in deployments where OpenID Providers can be chosen dynamically, whereas they aren’t needed if the site or application uses only a fixed set of OpenID Providers.
Unlike the previous version of OpenID, user identities can be e-mail addresses that people already have and know, rather than being URLs that most people have difficulty using.
3) Who is contributing to the standard?
OpenID Connect was developed in an OpenID Foundation working group. OpenID working groups are open to all free of charge who sign the IPR Contribution agreement. Contributors include a diverse international representation of industry and independent technology leaders: AOL, Deutsche Telecom, Facebook, Google, Microsoft, Mitre Corporation, mixi, Nomura Research Institute, PayPal, Salesforce, Yahoo! Japan, and others.
4) When is it expected to be finalized?
OpenID Connect is in the Implementer’s Draft review period. That stage is similar to the DIS (Draft International Standard) phase of the ISO process. The approval vote will complete on February 15, 2012. The OpenID Connect specifications are expected to be competed in the second half of 2012.
5) What are the key Identity management objectives?
6) Does the standard exceed key objectives?
Yes.
7) Are there live deployments?
Yes. e.g., Google, Gakunin (Japanese Universities Network), Nikkei Newspaper, etc.
Mature deployments are under way by working group participants.
8) Does the deployment touch customers/consumers/citizens? If so, what benefit(s) is the application delivering to customers/consumers/citizens?
9) Does the deployment successfully address one of more of the following identity issues? If so, please provide brief examples.
10) Why should this standard win the European Identity/Cloud Award?
OpenID Connect is a significant advance in digital identity that:
OpenID Connect is an important contribution to a safer, privacy protecting, and easy to use computing environment that spans the cloud, the Web, enterprises, and mobile applications and has broad industry backing. For these reasons, OpenID Connect merits the 2012 European Identity/Cloud Award.
Tags: #eic12, European Identity and Cloud Conference, European Identity Award, OpenID Connect
The OpenID membership has approved the following specifications as OpenID Implementer’s Drafts in the vote held from February 7th to 15th, 2012:
• Basic Client Profile – Simple self-contained specification for a web-based Relying Party. (This spec contains a subset of the information in Messages and Standard.)
• Discovery – Defines how user and provider endpoints can be dynamically discovered.
• Dynamic Registration – Defines how clients can dynamically register with OpenID Providers.
• Messages – Defines all the messages that are used in OpenID Connect. (These messages are used by the Standard binding.)
• Standard – Complete HTTP binding of the Messages, for both Relying Parties and OpenID Providers.
• Multiple Response Type Encoding – Registers OAuth 2.0 response_type values used by OpenID Connect.
The voting results were:
Total Votes: 89 (out of 363 members = 25% > 20% quorum requirement)
An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification.
The specifications are posted at these locations:
• http://openid.net/specs/openid-connect-basic-1_0-15.html
• http://openid.net/specs/openid-connect-discovery-1_0-07.html
• http://openid.net/specs/openid-connect-registration-1_0-08.html
• http://openid.net/specs/openid-connect-messages-1_0-07.html
• http://openid.net/specs/openid-connect-standard-1_0-07.html
• http://openid.net/specs/oauth-v2-multiple-response-types-1_0-03.html
A description of OpenID Connect can be found at http://openid.net/connect/.
The working group page is http://openid.net/wg/connect/.
Tags: Implementer's Draft, openid, OpenID Connect, specification
Link: https://openid.net/foundation/members/polls/62
The OpenID AB+Connect Working Group recommends approval of the following specifications as OpenID Implementer’s Drafts:
• Basic Client Profile – Simple self-contained specification for a web-based Relying Party. (This spec contains a subset of the information in Messages and Standard.)
• Discovery – Defines how user and provider endpoints can be dynamically discovered.
• Dynamic Registration – Defines how clients can dynamically register with OpenID Providers.
• Messages – Defines all the messages that are used in OpenID Connect. (These messages are used by the Standard binding.)
• Standard – Complete HTTP binding of the Messages, for both Relying Parties and OpenID Providers.
• Multiple Response Type Encoding – Registers OAuth 2.0 response_type values used by OpenID Connect.
An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification.
The specifications are posted at these locations:
• http://openid.net/specs/openid-connect-basic-1_0-15.html
• http://openid.net/specs/openid-connect-discovery-1_0-07.html
• http://openid.net/specs/openid-connect-registration-1_0-08.html
• http://openid.net/specs/openid-connect-messages-1_0-07.html
• http://openid.net/specs/openid-connect-standard-1_0-07.html
• http://openid.net/specs/oauth-v2-multiple-response-types-1_0-03.html
A description of OpenID Connect can be found at http://openid.net/connect/. The working group page ishttp://openid.net/wg/connect/.
Please vote at: https://openid.net/foundation/members/polls/62
The vote is open between Feb. 7 to 15.
Tags: Implementer's Draft, OpenID Connect, vote
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.
Tags: specification
The OpenID AB+Connect Working Group recommends approval of the following specifications as OpenID Implementer’s Drafts:
An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification. This note starts the 45 days public review period for the specification drafts in accordance with the OpenID Foundation IPR policies and procedures. This review period will end on Monday, February 6, 2012.
Unless issues are identified during the review that the working group believes must be addressed by revising the drafts, this review period will be followed by a seven day voting period during which OpenID Foundation members will vote on whether to approve these drafts as OpenID Implementer’s Drafts.
The specifications are posted at these locations:
A description of OpenID Connect can be found at http://openid.net/connect/. The working group page is http://openid.net/wg/connect/.
Information on joining the OpenID Foundation can be found at https://openid.net/foundation/members/registration. Foundation members will be asked to vote on approving these specifications as Implementer’s Drafts.
You can send feedback on the specifications in a way that enables the working group to act on your feedback by
Tags: Implementer's Draft, OpenID Connect, spec, specification, vote
Since we posted in July about the availability of preliminary OpenID Connect specifications, developers have been building implementations and submitting feedback on the specs. The specs have been revised to incorporate their feedback. A new map of the specs is as follows:
The biggest difference you’ll notice is that there is now only one spec to implement for “Minimal” clients (rather than previously three). A number of people had asked that there be a single, simple, self-contained spec that basic relying parties could implement. That spec is the OpenID Connect Basic Client Profile. That’s all you need for a web-based relying party utilizing a pre-configured set of OpenID Providers.
For “Dynamic” configurations, where the set of OpenID Providers is not pre-configured, Discovery and Dynamic Client Registration capabilities are added to enable RPs to discover OP endpoints and to connect with the OP selected. This functionality is needed for “open” OpenID Connect interactions.
OpenID Providers, native client applications, and clients needing more functionality than that provided by the Basic Client Profile implement the OpenID Connect Standard binding for the OpenID Connect Messages. Finally, OPs and RPs needing session management capabilities, including logout, also implement OpenID Connect Session Management.
As you can see, the current organization remains highly modular, where implementations can build and deploy only what they need. Now that modularity is even better reflected in the way that the specs are written – particularly that there is a single, self-contained basic client specification.
In closing, we’d like to thank developers for the valuable feedback provided to date. Your input has both improved the technical content of OpenID Connect, and possibly even more importantly, made the specs simpler and easier to understand.
Tags: connect, interop, spec, specification
There is now a set of functionally complete specifications for OpenID Connect. The diagram below shows the relationships between the current specs and contains links to each of them. These specifications are ready for early developer feedback and prototype implementation work. Please send feedback on them to the OpenID Artifact Binding Working Group Mailing List.
OpenID Connect uses the best practices of widely used OAuth/REST/JSON based APIs to define a standard and interoperable way to authenticate users. Developers should care because rather than having to learn an new and slightly different version of essentially the same API every time they want to integrate with a different identity provider, they can just do it in a standard way using a consistent interface. In the long run, OpenID Connect will make the web more interoperable, because it makes it easier for developers to integrate with multiple services.
FYI, the working group *is* planning to reorganize the specs to have the minimal set of OpenID Connect functionality be contained in a single document, although this will likely not be in place for a few weeks. Even before that is done, we wanted to make people aware of this set of specs now so early implementation work and technical feedback can occur. Remaining edits to the specs should consist of corrections, clarifications, and reorganization, rather than additions of significant new functionality. For now, developers should start with the (admittedly awkwardly named) OpenID Connect HTTP Redirect Binding spec.
Let the feedback and prototyping begin! [*1]
[*1] The easiest way to do is to join the AB list at http://lists.openid.net/mailman/listinfo/openid-specs-ab, submit the contribution agreement from http://openid.net/intellectual-property/ (which you can now do online!), and then send comments to the openid-specs-ab@lists.openid.net .
Tags: connect, developer, openid, spec, specification
Many in the open standards community have a “what have you done for me lately” chip implanted deep in their programming souls. It’s logical to want the evolution of OpenID technology to keep up with the rate of its adoption. We all want the pace of technology improvement to map onto the promise of what has become the most popular decentralized single-sign-on protocol on the web. Some of the most impatient include members of the Board of the OpenID Foundation who aren’t satisfied with hanging an “over a billion served” on the OpenID Foundation website.
The “co-evolution” of OAuth and OpenID
Late last year, the members of the OpenID Artifact Binding and OpenID Connect Working Groups joined forces to develop a simple, common specification. The result had been informally referred to as “OpenID Artifact Binding/Connect” or “OpenID ABC”. Key contributors from both working groups have been working on a core specification ever since. Weekly specification calls have methodically focused on identifying and closing open issues. A key milestone was reached at IIW earlier this month: the remaining open issues were identified, tradeoffs debated, and all issues closed – with consensus decisions recorded in the Artifact Binding mailing list archives. The working group is now refining the specifications to reflect those decisions, as well as tracking the evolution of closely related specifications like OAuth 2.0.
Having passed this gate, the OpenID board decided to brand the result “OpenID Connect” and solicit as wide and diverse feedback as possible. The OpenID Retail Summit at PayPal, the “Security” Summit at Symantec, and last week’s OpenID Summit in Munich at the European Identity Conference all featured detailed briefings and feedback on OpenID Connect. While still a work in progress, OpenID Connect has achieved the levels of participation and consensus needed to advance to the next phase: interoperability testing for multiple use cases in several venues worldwide. We’ll continue to engage developers and potential deployers about OpenID Connect at upcoming OpenID Summits, including the next summit on July 19 in Colorado sponsored by Ping Identity, in to better understand, critique, refine, test, and ready OpenID Connect for prime time.
A look under the hood of OpenID Connect:
- web and developer friendly, building upon OAuth 2.0 and JSON
- simple site registration functionality (the “Connect” part)
- works well on mobile phones (the “Artifact Binding” part)
- simple JSON-based claims model
- reuses claims definitions from existing Portable Contacts specification
- can achieve a range of security characteristics, spanning use cases from social networks to those needing higher levels of assurance
- modular specifications, so deployers need only implement the functionality their applications need.
The strength of the open standards is the ongoing scrutiny from a global community of supporters and skeptics. Progress depends on those with the “courage of the first draft.” Our special thanks go to OpenID Board members Mike Jones, Nat Sakimura, and John Bradley, together with Breno de Medeiros from Google and Chuck Mortimore from Salesforce: working group participants whose dedication and perspectives were critical to building consensus, closing the open issues, and setting the stage for OpenID’s next act.
Don Thibeau
Executive Director
IIW is rapidly approaching.
We plan to take advantage of face to face discussions on the around the next version of openID.
For those attending and others I want to point to the various potions of the spec work so that people have that in hand for IIW.
One of the changes from openID 2.0 is that the new specification is more modular.
The following diagram illustrates the components and links to the specs:
(Click on the diagram to see each specifications.)
Everything is built on top of OAuth 2.0 and the Bearer Token Profile of OAuth.
We are supporting multiple OAuth Flows for different device types.
The heart of OpenID Connect is the Core spec that describes the abstract protocol.
Discovery of user identifiers such as email for URI is performed by a profile of Simple Web Discovery
Session Management is currently a separate spec, however it may be folded into Core.
Revised: Core 1.0d03 incorporates the session management endpoints and eliminates some duplication.
We are hoping to use our face 2 face time around IIW to resolve some of the outstanding issues:
We will be producing a implementers guide to make it easier for people to build clients without having to wade through all of the separate specs.
Expect an update after IIW in May.
John B.
Tags: abc, attribute, authentication, authorization, claims, connect, distributed, openid, specification, technology