Posts Tagged ‘specification’
Posted at 10:11 pm on February 16, 2012 by Nat Sakimura
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:
- Approve (86 votes)
- Disapprove (1 vote)
- Abstain (2 votes)
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
This entry was posted
on Thursday, February 16th, 2012 at 10:11 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 10:29 pm on January 24, 2012 by Mike Jones
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
This entry was posted
on Tuesday, January 24th, 2012 at 10:29 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 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 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.
Posted at 4:56 am on December 31, 2008 by Mike Jones
The OpenID Foundation membership has approved OpenID Provider Authentication Policy Extension 1.0 as an OpenID specification by a vote of forty-two to three, with seven abstentions. This is a significant development for the OpenID community for two reasons: First, this is the first new specification to be developed under the OpenID Foundation’s IPR policies and procedures, which ensure that all are free to use it (like the existing approved specifications) – paving the way for additional specifications to come. Second, the PAPE specification provides an important security enhancement to OpenID Authentication, which can be used with both OpenID 1.1 and OpenID 2.0.
Specifically, the PAPE Specification enables Relying Parties to request that OpenID Providers employ specified authentication policies when authenticating users and for OpenID Providers to inform the Relying Parties which policies were actually used. With PAPE, for instance, a Relying Party can request that the OpenID Provider employ a phishing-resistant authentication method for authenticating the user, and know whether such a method was used or not. The specification can also be used to request multi-factor authentication and to learn what NIST level (or other levels) the authentication conforms to.
At the time of this writing, the working group is aware of at least four implementations of the specification: PHP, Ruby, and Python development versions from OpenID Enabled and a .NET version from the DotNetOpenID project.
The PAPE working group looks forward to seeing use of the specification help make OpenID interactions more secure in the real world!
– Mike Jones, for the PAPE Working Group
Tags: pape, security, specification
This entry was posted
on Wednesday, December 31st, 2008 at 4:56 am and is filed under News.
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.