Posts Tagged ‘spec’
Posted at 6:41 am on December 23, 2011 by John Bradley
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. 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
- signing the contribution agreement at http://openid.net/intellectual-property/ to join the AB+Connect working group,
- joining the working group mailing list at http://lists.openid.net/mailman/listinfo/openid-specs-ab, and
- sending your feedback on that list.
Tags: Implementer's Draft, OpenID Connect, spec, specification, vote
This entry was posted
on Friday, December 23rd, 2011 at 6:41 am and is filed under Foundation, News, Specs.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Posted at 10:50 am on September 12, 2011 by Nat Sakimura
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
This entry was posted
on Monday, September 12th, 2011 at 10:50 am and is filed under News, Specs, Summit Events.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Posted at 5:00 pm on July 15, 2011 by Nat Sakimura
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
This entry was posted
on Friday, July 15th, 2011 at 5:00 pm and is filed under News, Specs.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Posted at 11:04 am on May 20, 2011 by jfe
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
Tags: connect, openid, spec
This entry was posted
on Friday, May 20th, 2011 at 11:04 am and is filed under Foundation, Specs.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.