Connect Work Group proposal

Sat May 22 17:34:55 UTC 2010

>
> Reusing identity from Twitter, Facebook, Google etc. has become a common
> architecture. It is a federated vs internet architecture. It works for
> applications that use one or more of those services. It solves some of the
> social web identity challenges. I think it also seem to paint us into a
> corner and creat significant challenges for solving internet identity.

I don't think that we're reusing identity from those companies, but rather
building on many of their concepts as they've been proven to work. We're
also building on OAuth 2.0 and discovery technologies from the IETF. While
it's possible to view this as creating a new architecture, OpenID 1.0 and
2.0 have given us a lot of deployment experience around discovery and
dynamic associations; so we're building on that as well.

Is the Connect proposal perfect, no. Is it a reasonable starting point for a
near term future version of identity for the web, we certainly think so.

In many cases I think the expression of saying that we're wrong and should
stop only reinforces why we should move forward. Many people told us that
OpenID 1.0 and 2.0 were horrible ideas, that we were ignoring the real
problems, and couldn't possibly be successful. I'm glad that we didn't
listen then as we would have missed out on a great amount of innovation.

--David

On Sat, May 22, 2010 at 10:45 AM, Dick Hardt <dick.hardt at gmail.com> wrote:

>
> See Dan Brickley's email for a discussion of some of the issues.
> http://lists.openid.net/pipermail/openid-specs/2010-May/006938.html
>
> The overall design pattern between OpenID Connect, Artifact Binding, and
> the discussion around v.Next is pretty similar.
>
> While it might seem that building on top of OAuth's success is a great
> idea: OAuth was a standardization of an existing architecture. OpenID is
> introducing a new architecture, and inherently is a tougher architectural
> challenge.
>
> Reusing identity from Twitter, Facebook, Google etc. has become a common
> architecture. It is a federated vs internet architecture. It works for
> applications that use one or more of those services. It solves some of the
> social web identity challenges. I think it also seem to paint us into a
> corner and creat significant challenges for solving internet identity.
>
> Additionally, if you want to shoot for a shorter-timeframe, I think we
> could get a basic version of v.Next in the same time frame as OpenID Connect
> will take -- and we will have the whole community working on one version.
>
> -- Dick
>
>
> On 2010-05-21, at 11:56 PM, Joseph Smarr wrote:
>
> Dick-I'll let David speak to his reasons for forming this group, but here's
> my basic take:
>
> I'm all for v.Next going after the "big vision" of solving identity on the
> web, including smart clients, stored claims, and all the other great ideas
> we've all talked about together. But I think we're also very close to a
> "local maximum" of getting a standard format for the basic web-based
> login+profile+auth pattern that so many sites have built for themselves, and
> that this is too valuable and too near-at-hand to risk stalling while we
> work on those bigger problems in parallel. So I think OpenID Connect is
> trying to solve the problem of providing a simple-to-implement spec that
> Facebook, Twitter, Google, Yahoo, MSFT, and lots of other companies could
> implement ASAP that would largely mirror what they've already built (e.g.
> twitter already has oauth and a user-info API, but the latter is
> twitter-specific, and there's no discovery layer to "pick twitter" vs some
> other compatible provider), and that specifically would provide the
> capability to use an existing account to log in to a new site and prove the
> identity of your existing account while simultaneously providing some basic
> profile info and granting an oauth token to access more capabilities, all in
> a standard, interoperable, and federated way.
>
>
> In other words, it's shooting for "shorter-timeframe,
> fewer-new-capablilities" vs. "let's think about all that v.Next could be". I
> think both are valuable and complementary, and I don't think either one
> alone will subsume the other, which is why I don't mind doing both in
> parallel. But, to be clear, I don't think we can afford to pass up this
> opportunity for simple convergence across so many sites for something as
> core as authN+authZ+profile, so if we could only do one right now, I'd vote
> for Connect, and then v.Next as a follow-on. But I think we can walk and
> chew gum at the same time, which is why doing both in parallel is still my
> preference.
>
>
>
> Thanks, js
>
> On Fri, May 21, 2010 at 4:47 PM, Dick Hardt <dick.hardt at gmail.com> wrote:
>
>> Hi David
>>
>> A couple initial comments:
>>
>> 1)  Please explain what problem(s) you are trying to solve. You list a
>> number of explorations and goals and there are some implicit requirements.
>> It would be useful to explicitly state the requirements so that everyone can
>> understand why this work is important to do. It is unclear how this
>> complements other OIDF WGs per the stated purpose.
>>
>> 2) What is different from the v.Next efforts? If this is a different
>> approach to the same problem, it would seem to make sense to argue the
>> different technical merits in one WG rather then two. Why is this WG is
>> needed in addition to the v.Next work that is starting to spin up? Many
>> members of the community gathered at the OpenID Summit, (a meeting you
>> helped organize David!) and the consensus was the v.Next WGs that were
>> kicked off. If you are unhappy  with the progress there, how about putting
>> effort into moving those along rather than starting a new WG?
>>
>> I have numerous other comments on the Scope section, but would like to
>> deal with the two issues above first.
>>
>> -- Dick
>>
>> On 2010-05-21, at 4:01 PM, David Recordon 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100522/d9e0a437/attachment.html>