OpenID Hybrid v2 Proposal (formerly known OpenID Connect)

John Bradley ve7jtb at ve7jtb.com
Tue May 25 21:55:30 UTC 2010


I don't doubt that a Facebook Connect like authentication standard built on top of oAuth 2.0 will happen.

In some ways I am glad that the proponents of this have come to the OIDF rather than doing something separately at the IETF or elsewhere.

I do think there is market pressure to adopt something that can be used to access both Facebook and other IdP with a single API.

I don't think telling RP to wait for vNext is going to work.   They are likely to adopt FB Connect at the expense of openID.

If we bring them into the tent we have the opportunity to influence the openID connect specification.

As Eran and others have stated asymmetric signatures and other features need to be supported by oAuth as well as other improvements that can be extensions for specific use cases.

You know I will want to have some sort of PPID identifier selectable by a scope,  so that this can also be used at sites that require that.
A LoA scope would be nice as well:)

I would also want to see some sort of mechanism for TFP like OIX to create a federation of RP's that agree to standard TOS (Say Gov ones) so that not every RP needs to pre-register with every provider.

openID Connect is about single social network login as opposed to openID 2.0's more traditional Single Signon.

I can see any large IdP who may already have this deployed being cautious of wholesale changes to a deployed protocol.
So we need to be respectful of that.

If we do this inside the OIDF I think that an appropriate name can be found for it.   openID connect is not that bad. 

There are issues about migration and how OP would provide both openID 2.0 and Connect in parallel.

I am concerned however that along with directed funding at the board level by Corporate members, and opening openID up to multiple specifications we are creating a place where companies will bring there "standards" for approval.

I know openID connect is built on open standards and is wonderful and kind to small animals.   The question is once we do this where is the line?

OpenID connect is a profile of oAuth 2.0.  The question is should the OIDF be in the business of producing one or more identity related profiles for oAuth 2.0.

If we can answer that question then I think we can move forward one way or the other.

Regards
John B.

On 2010-05-25, at 5:11 PM, Chris Messina wrote:

> If it indeed brings clarity to the situation, I'm not opposed, though one reason for using the "Connect" moniker is that "hybrid" means nothing outside of the OpenID community (since Hybrid really means combining authn and authz in a single protocol -- only relevant if your authn isn't tied to your authz in the first place!).
> 
> So, internally and for the WG name, I'm fine with going with OpenID Hybrid 2.0 WG -- but from an external marketing perspective I'd still prefer to have a *product* called OpenID Connect which would essentially be the hybrid 2.0 technology -- with additional guidance (perhaps) for optimizing UI flows. Thus to implement OpenID Connect would be to implement the hybrid 2.0 protocol with a series of contextually-optimized user interfaces -- with a cherry on top that looks like a "Connect" button.
> 
> Chris
> 
> Sent from my iPhone 2G
> 
> On May 25, 2010, at 2:56 PM, Allen Tom <atom at yahoo-inc.com> wrote:
> 
>> Hi All,
>> 
>> A better way to look at OpenID Connect is to just think of it as revised
>> version of the OpenID Hybrid. The purpose of the Hybrid WG was to find a way
>> to combine OpenID Authentication with the approval of an Oauth access token
>> into a single request/response.
>> 
>> There are a several ways that OpenID Authentication can be combined with
>> Oauth - the current draft of the Hybrid spec defines one possible
>> implementation, however, based on the experience that we've had actually
>> implementing Hybrid, perhaps we can go about doing it differently.
>> 
>> Renaming the OpenID Connect WG to be the OpenID Hybrid v2 WG could possibly
>> clarify the goals of the WG, and reduce confusion within the community.
>> Afterall - Hybrid is intended for the case where the user's IdP is also the
>> SP, so the Connect proposal is really a revised Hybrid proposal, rather than
>> a proposal for OpenID v.Next
>> 
>> Thoughts?
>> Allen
>> 
>> 
>> 
>> On 5/21/10 4:01 PM, "David Recordon" <recordond at gmail.com> wrote:
>> 
>>> Per the OpenID Foundation's IPR Process, below is a Work Group Charter
>>> proposal for consideration by the Specifications Council.
>>> 
>>> Thanks,
>>> --David
>>> 
>>> 
>>> Charter:
>>> 1) Working Group name: Connect
>>> 
>>> 2) Purpose: Develop a version of the OpenID protocol optimized for use
>>> on the web by building on top of OAuth 2.0 and discovery technologies
>>> such as host-meta while complementing other active OpenID Foundation
>>> Working Groups.
>>> 
>>> 3) Scope:
>>> - Explore building on top of OAuth 2.0
>>> (http://wiki.oauth.net/OAuth-2.0) from the IETF for the user
>>> authorization flows and extension mechanism
>>> - Explore using the Web Host Metadata specification
>>> (http://tools.ietf.org/html/draft-hammer-hostmeta) and Well Known URIs
>>> (http://tools.ietf.org/html/rfc5785) via SSL for discovery
>>> - Explore the ability for a rich client (such as a browser) to
>>> discover and interact with the website on the user's behalf
>>> - Explore making user identifiers OAuth 2.0 protected resources which
>>> return profile information and links to other API endpoints possibly
>>> using JRD (http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/)
>>> assuming it is submitted to the IETF
>>> - Explore the optimal migration path for implementors of OpenID 2.0
>>> - Explore how the functionality provided by existing OpenID 2.0
>>> extensions could be re-imagined on top of OpenID Connect
>>> - Explore how the concept of delegation should evolve
>>> 
>>> - Support for simultaneously authenticating the user while also
>>> authorizing other OAuth 2.0 protected resources that the server is
>>> able to issue access tokens for
>>> - Support users explicitly choosing a server or typing in a variety
>>> of URLs and email addresses for discovery
>>> - Separate the user identifier from the user's human consumable
>>> profile URL such that it is hosted via HTTPS, globally unique, and
>>> never reassigned
>>> - Drastically reduce the complexity of discovery
>>> - Reduce the complexity of the verification processes possibly by
>>> comparing the subdomain of the user identifier and token endpoint
>>> - Support optional static verification of the token response via a
>>> signature using symmetric keys
>>> - Support user interfaces optimized for a variety of screen sizes,
>>> devices, and languages by learning from the OpenID User Experience
>>> extension
>>> - Support the ability to login to non-web browser applications such
>>> as desktop applications
>>> - Support dynamic registration of clients
>>> - Define a standard mechanism and basic set of attributes for servers
>>> to share basic user profile data with clients
>>> 
>>> - Do not prevent the use of asymmetric keys throughout the protocol
>>> such that it may scale into more security conscious use cases
>>> 
>>> 4) Proposed specifications: OpenID Connect 1.0.
>>> 
>>> 5) Anticipated audience or users: Implementors of OpenID providers,
>>> relying parties, web browsers, and other non-browser applications.
>>> 
>>> 6) Language: English
>>> 
>>> 7) Method of work: E-mail discussions on the working group mailing
>>> list, working group conference calls, and face-to-face meetings at the
>>> Internet Identity Workshop and OpenID Foundation hosted summits.
>>> 
>>> 8) Basis for determining when the work is completed: Rough consensus
>>> and running code. The work will be completed once it is apparent that
>>> maximal consensus on the draft has been achieved, consistent with the
>>> purpose and scope.
>>> 
>>> 
>>> Background information:
>>> 1) Related work: OpenID Authentication 2.0 and related specifications,
>>> including Attribute Exchange (AX), Contract Exchange (CX), Provider
>>> Authentication Policy Extension (PAPE), and the draft User Interface
>>> (UI) Extension. OAuth 2.0. Web Host Metadata, Well Known URIs, LRDD,
>>> XRD, and JRD. OpenID v.Next Working Group proposals. Mozilla Account
>>> Manager. Google "EasyHybrid". The Connect Working Group is needed to
>>> explore how many of these related technologies can be used to build an
>>> open identity system for the web while remaining consistant with the
>>> principals behind OpenID 1.0 and OpenID 2.0. The Proposers have strong
>>> relationships in many of these communities and do not anticipate the
>>> need of formal liaisons.
>>> 
>>> 2) Proposers:
>>> David Recordon - davidrecordon at facebook.com (editor)
>>> Allen Tom - atom at yahoo-inc.com
>>> Chuck Mortimore - cmortimore at salesforce.com
>>> Chris Messina - messina at google.com
>>> Eran Hammer-Lahav - blade at yahoo-inc.com
>>> Joseph Smarr - jsmarr at google.com
>>> Luke Shepard - lshepard at facebook.com
>>> Martin Atkins - matkins at sixapart.com
>>> Max Engel - max at gravity.com
>>> Thomas Huhn - thomas.huhn at gmail.com
>>> 
>>> 3) Anticipated contributions: OpenID Connect proposal
>>> (http://openidconnect.com) under the OpenID Foundation's IPR Policy.
>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100525/dd82246b/attachment-0001.bin>


More information about the specs mailing list