Discovery of an OpenID session at an OP
John Panzer
jpanzer at google.com
Mon Dec 14 17:22:53 UTC 2009
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
jpanzer at google.com / abstractioneer.org / @jpanzer
On Mon, Dec 14, 2009 at 8:47 AM, daniel jacobson <fragment37 at yahoo.com>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 <chris.messina at gmail.com>* wrote:
>
>
> From: Chris Messina <chris.messina at gmail.com>
> Subject: Re: Discovery of an OpenID session at an OP
> To: "daniel jacobson" <fragment37 at yahoo.com>
> Cc: "Chris Obdam" <chris.obdam at holder.nl>, "openid-specs at lists.openid.net"
> <openid-specs at lists.openid.net>, santrajan at gmail.com
> Date: Monday, December 14, 2009, 11:35 AM
>
>
>
>
> On Mon, Dec 14, 2009 at 7:55 AM, daniel jacobson <fragment37 at yahoo.com<http://us.mc1123.mail.yahoo.com/mc/compose?to=fragment37@yahoo.com>
> > 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
> 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/20091214/eef9baf1/attachment.htm>
More information about the specs
mailing list