If the library is written well, it could be upgraded to take advantage of any client-side hints that become available (with HTML5, or otherwise) without the API changing or the RP needing to do anything special. It can also have a UX that allows for full range of choice of OPs while providing a default set that will probabilistically match the RP's chosen audience -- e.g., if you know that a large % of your users are going to be from Yahoo! due to other integrations, you may well want to feature that prominently and I think that's okay as long as there is also a standard, simple way for non-Yahoos to log in.
Also, high end mobile devices won't have any trouble running your JS library -- actually they'll probably be easier than your desktop base. Lower-end mobile browsers do have special challenges of course; just want to separate these two cases our explicitly, as it may well be the case that the limitations of low end mobile devices necessitate a very different approach anyway. -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer On Mon, Dec 14, 2009 at 8:47 AM, daniel jacobson <[email protected]>wrote: > Fair point about keeping the option with the user - one that I agree with. > My key point here is to demonstrate the need for a library that creates an > easy-to-implement option for RPs that can handle the federated model of > OpenID in a robust way. One of the challenges with giving the user the > choice is in making that process a good user experience, one that is > intuitive and not intimidating. My suggestion about surfacing prominent > providers is really about offering that one-click experience to the user. > The first image in the second post that you provided ( > http://farm4.static.flickr.com/3257/3119473900_55bdc12279.jpg?v=0) > captures the basic idea that I was shooting for... allowing a one-click > option for the user (my idea was that those OPs - AOL, Facebook, Google, > etc. - would be identified by parameters passed through to the library). > -Daniel > > > > > --- On *Mon, 12/14/09, Chris Messina <[email protected]>* wrote: > > > From: Chris Messina <[email protected]> > Subject: Re: Discovery of an OpenID session at an OP > To: "daniel jacobson" <[email protected]> > Cc: "Chris Obdam" <[email protected]>, "[email protected]" > <[email protected]>, [email protected] > Date: Monday, December 14, 2009, 11:35 AM > > > > > On Mon, Dec 14, 2009 at 7:55 AM, daniel jacobson > <[email protected]<http://us.mc1123.mail.yahoo.com/mc/[email protected]> > > wrote: > >> I think the biggest benefit to RPs is to create a library that is >> robust and portable that would allow for them to designate which OPs they >> care about. >> > > I don't want this thread to be taken off course, but for the RP to specify > which OPs it supports greatly diminishes the user-centric element of OpenID. > The point of OpenID is that I, as a user, can decide who I trust to store my > data and provide my identity — rather than having to choose from a specific > subset of providers that the RP decides on. > > This, I suppose, is en vogue today because of Facebook and Twitter Connect, > but if the model is to move towards ever greater consolidation of OPs at the > whim and discretion of RPs, then I believe we have greatly undermined a > fundamental aspect of OpenID. > > . . . > > To your question about how this can be done — and "getting the Facebook > folks involved" — you should read Luke Shepard's post on how Facebook's > accomplishes sign-on with Facebook Connect: > > http://www.sociallipstick.com/?p=86 > http://www.sociallipstick.com/?p=167 > http://www.sociallipstick.com/?p=189 > > Chris > > -- > Chris Messina > Open Web Advocate > > Personal: http://factoryjoe.com > Follow me on Twitter: http://twitter.com/chrismessina > > Citizen Agency: http://citizenagency.com > Diso Project: http://diso-project.org > OpenID Foundation: http://openid.net > > This email is: [ ] shareable [X] ask first [ ] private > > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
