Dick Hardt's idea which i will quote below looks like a good idea to me. On Sat, May 22, 2010 at 10:15 PM, Dick Hardt <dick.ha...@gmail.com> wrote:
> > 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 > > -- http://hi.im/santosh
_______________________________________________ specs mailing list sp...@lists.openid.net http://lists.openid.net/mailman/listinfo/openid-specs
