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.ha...@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 - davidrecor...@facebook.com (editor)
> > Allen Tom - a...@yahoo-inc.com
> > Chuck Mortimore - cmortim...@salesforce.com
> > Chris Messina - mess...@google.com
> > Eran Hammer-Lahav - bl...@yahoo-inc.com
> > Joseph Smarr - jsm...@google.com
> > Luke Shepard - lshep...@facebook.com
> > Martin Atkins - matk...@sixapart.com
> > Max Engel - m...@gravity.com
> > Thomas Huhn - thomas.h...@gmail.com
> >
> > 3) Anticipated contributions: OpenID Connect proposal
> > (http://openidconnect.com) under the OpenID Foundation's IPR Policy.
> > _______________________________________________
> > specs mailing list
> > sp...@lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs
>
> _______________________________________________
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
_______________________________________________
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs
