Posts Tagged ‘connect’
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.
Posted at 5:54 pm on April 29, 2011 by John Bradley
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.
We have created bindings for several of the
OAuth flows.
These include:
- Artifact, a optimized flow for mobile devices that have URL length limitations.
- Web App/Code Grant, a strait forward and simple binding for web servers.
- Smart Client, a binding for Smart user agents (in development)
JSON Web Token is used by Core. It has Four parts:
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.
Outstanding Issues
We are hoping to use our face 2 face time around IIW to resolve some of the outstanding issues:
- Claimed ID type. We have two proposals, one for a single URL and another for a two part identifier where the user_ID and the IdP/OP identifier are separate.
- An extension for PAPE/Authentication Context. This will be required for government and other higher security applications.
- A formal spec for the User Info Endpoint and defining the base attribute schema.
- Defining how other extensions can be added.
- Defining a syntax for requesting sets of claims from trusted sources.
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
This entry was posted
on Friday, April 29th, 2011 at 5:54 pm and is filed under 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.