openid implementation advice

[Ben Clemens]

I really appreciate the reply, and I understand the large problems of
breaking a security model; I imagine the ³big button that spawns a pop-up²
solution is where we will have to go. Perhaps I just have to accept the
³least bad² scenario given the limitations that exist, but it is hard to
³embrace.² :) 


On 2/13/09 2:16 PM, "Luke Shepard" <lshepard at facebook.com> wrote:

> First, these mocks look pretty sweet. It¹s clear you¹ve done a lot of thinking
> about the experience of a relying party.
> 
> Steps 1,2, and 4 can all be done on your site, and for step 3, there¹s no need
> to break security policy by using an iframe. I think the providers are working
> on better designs that make it completely clear what¹s happening to the user
> so as to require minimal context from the RP. However, if you really want to
> tell the user what¹s happening before they click, then I suggest making an
> iframe lightbox explaining what¹s happening, then giving them a big fat Google
> button to click on, which spawns the popup. That would seem to accomplish the
> same goals.
> 
> If they weren¹t already, I¹m pretty sure Google and others will start putting
> iframe-busting Javascript to make this kind of thing impossible.
> 
> We are working on putting together a best practices doc on the wiki as a
> result of the UX summit on Tuesday. Any feedback would be appreciated:
> http://wiki.openid.net/Details-of-UX-Best-Practices-for-RPs
> 
> On 2/13/09 1:10 PM, "Ben Clemens" <bclemens at currentmedia.com> wrote:
> 
>> Hi:
>> 
>> I'm a designer working on an OpenID (and FB Connect) implementation for
>> current.com, a social news site from Current TV (a cable TV channel). I've
>> consulted with Chris Messina and wanted to ask this group for advice on the
>> design I have so far.
>> 
>> The largest issue for me has been attempting to do parts of the process in a
>> pop-up window. While the domain of the site the user is providing their
>> credentials to is a gigantic issue of course, the issue of *what exactly
>> current.com will use the account access for* is *even bigger* for users I've
>> talked with. Users do not want to provide access if we will be adding items
>> to their account without their permission, and after a pop-up is launched
>> (or there's a redirect), I have no ability to message the user about what my
>> site will do with the access they are providing. So, this version of the
>> design loads the external auth into an iFrame (now, excuse me while I cower
>> behind a mattress and prepare for the tomatoes and other thrown objects).
>> 
>> Thanks in advance for any feedback, advice, criticism, and an obvious, easy
>> way around these issues :)
>> 
>> http://labs.current.com/openid/currentauth_1_default.png
>> http://labs.current.com/openid/currentauth_2_openid_identity.png
>> http://labs.current.com/openid/currentauth_3_openid_auth.png
>> http://labs.current.com/openid/currentauth_4_openid_link.png
>> 
>> Ben Clemens
>> current.com
>> 
>> _______________________________________________
>> user-experience mailing list
>> user-experience at openid.net
>> http://openid.net/mailman/listinfo/user-experience
>> 
> 
> 
> _______________________________________________
> user-experience mailing list
> user-experience at openid.net
> http://openid.net/mailman/listinfo/user-experience

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20090213/aac95b75/attachment-0002.htm>