[step2] Re: OpenID Popup Extension - Draft 0

Allen Tom atom at yahoo-inc.com
Mon Feb 16 20:23:35 UTC 2009


Hi Praveen,

Thanks for jumping in!

Praveen Alavilli wrote:
>
>     *  as an RP when using a popup for login, I prefer knowing the
>       smallest possible window size that the OP can support before
>       hand so I can set the window size accordingly without any
>       assumptions or guesses. So I vote for OP declaring the
>       dimensions of it's "popup" type window in it's XRDS so I know
>       what width and height I should be setting when a user wants to
>       use that OP to login. That makes it possible for the OP to
>       change the size of the popup in future without requiring all RPs
>       to make code changes too.
>

OK, let's just use Breno's suggestion to include multiple <Type> values 
in the OP's XRDS  for the popup. The first value will just indicate 
support for the popup extension, and the subsequent values will indicate 
the dimensions.

<Type>http://specs.openid.net/extensions/ux/popup/1.0</Type>
<Type>http://specs.openid.net/extensions/ux/popup/1.0/popup?width=450&height=500</Type>
<Type>http://specs.openid.net/extensions/ux/popup/1.0/popup?width=300&height=400</Type>
<Type>http://specs.openid.net/extensions/ux/popup/1.0/popup?width=WWW&height=HHH</Type>

As mentioned earlier, this approach seems kind of hackish, but seems to 
be the best way to advertise parameters for an extension.



>     * -1 for allowing OP to resize the window - though it's possible
>       programmatically, it leaves bad user experience as focus will be
>       changed to the popup and if the window resizes after loading the
>       page (because the JS has to load) it looks odd IMO (almost like
>       those popup ads)
>

At the UX Summit, Google, Yahoo, and MySpace indicated a need to resize 
the popup window under certain circumstances. Hopefully, OP does not 
need to resize the window most of the time.

For instance, the OP may need to resize the popup to display a CAPTCHA 
if the user seems suspicious.

Another case for resizing the window is if the user clicks "learn more" 
to get detailed information about what's going on. In this case, the OP 
may want to enlarge the popup to show additional information.


>     * Section4: looks like a typo - it says "When requesting OpenID
>       authentication using the *checkid_immediate* mode, the Relying
>       Party MUST " - I beleive you meant "When requesting OpenID
>       authentication using the *checkid_setup* mode, the Relying Party
>       MUST ". Probably worth mentioning this extension doens't apply
>       for checkid_immediate mode at all.
>
Yup, good catch!


>     * +1 for adding a recommendation for the RP to dim the contents of
>       the parent window while the popup is active and also to provide
>       a status message ("please complete login from the popup
>       window...." or so )  with a "cancel login" and/or "use standard
>       login" options so if the popup doesn't show up or work the way
>       we wanted (since it's JS in a browser - too many possibilities
>       for it to go wrong), the user has an alternative way
>
OK, we'll add some additional text to explain the recommended behavior 
for RPs when spawning the popup.

>     * Section2: I would suggest to remove this "Another optimization
>       is that the OP can close the popup, rather than returning a
>       negative assertion if the user choses cancel the authentication
>       request. " - if a user cancels out of login, then it will be
>       helpful for the RP to know that so it can take some action (for
>       example, if the RP is using something like an IDSelector, it can
>       remove or move down the OP button in the list or show other
>       login options to the user for that session).
>
The RP is going to have to implement logic to detect if the popup was 
closed anyway, because the user might manually close it. My suggestion 
is to reuse the same codepath so that an RP can treat a closed popup 
without a response to be a negative assertion, regardless of whether the 
user or the OP closed the popup.


>    *
>
>
>
> Not sure if it has been discussed at the UX summit last week, but it 
> might be useful for the RP to specify a user-friendly name in it's 
> XRDS file that the OP can use in addition to the realm in the login 
> page. This will be particularly useful when a user tries to login with 
> multiple RPs on the same domain (just a hypothetical example: 
> mail.aol.com <http://mail.aol.com>, pictures.aol.com 
> <http://pictures.aol.com>, journals.aol.com <http://journals.aol.com>, 
> etc..) at the same time using same OP and all popups look exactly same.
>  
>  
Many OPs would require manual review of any text or logos to ensure that 
the RP does not misrepresent itself. It would probably make sense to tie 
the "friendly name" or any logos and descriptions to the RP's OAuth 
Consumer Key, and require the hybrid protocol so that the OP can verify 
that the CK matches the OpenID Realm/ReturnTo and also look up the 
logos/text based on the CK.

Allen

>  
> On Sun, Feb 15, 2009 at 5:10 PM, Allen Tom <atom at yahoo-inc.com 
> <mailto:atom at yahoo-inc.com>> wrote:
>
>     Breno wrote:
>>
>>     Ok. In the interest of expediency, we could at this point define
>>     only ui.mode=popup which is extensible in principle without
>>     introducing any new other use cases at the present.
>>      
>
>     OK, let's just agree that mode=popup implies 450x500, and there
>     may be other modes defined in the future.
>
>     Will this work for your mobile users? The puffypoodles example
>     looks good on my iphone, so I'm thinking that we'll just  use
>     mode=popup for desktop browsers and for advanced smartphones.
>
>
>
>
>>
>>     I agree that we shouldn't have too much going on simultaneously
>>     with the popup. However, it may prove useful for the RP to
>>     provide some context "before the popup opens and the RP screen
>>     goes dim".
>     We can add some text that describes this, however I'm not sure if
>     this is really necessary, and could just make the overall
>     experience heavier and wordier.
>
>
>>      
>>
>>
>>
>>>         Should we also cover the case where the parent window is
>>>         closed before authentication is completed?
>>>
>>         Ah, I hadn't thought of this case.
>>
>>
>>     This can be addressed as follows:
>>
>>     When the user completes the authentication and is returned at the
>>     RP, the RP should proceed as follows:
>>
>>     Check if window.opener.location is defined and within its realm.
>>     If so, it should close the popup after ensure that all
>>     side-effects (set cookies, etc) that follow the login operation
>>     have completed.
>>
>>     If window.opener.location is not defined, not accessible (attempt
>>     to read it throws a security exception, for instance) or not
>>     recognized to be part of the RP's site, then the RP should try to
>>     load its normal landing page for full-page redirects.
>>      
>     Sounds good!
>
>     Allen
>
>
>
>
>     --~--~---------~--~----~------------~-------~--~----~
>     You received this message because you are subscribed to the Google
>     Groups "Step2" group.
>     To post to this group, send email to step2 at googlegroups.com
>     To unsubscribe from this group, send email to
>     step2+unsubscribe at googlegroups.com
>     For more options, visit this group at
>     http://groups.google.com/group/step2?hl=en
>     -~----------~----~----~----~------~----~------~--~---
>

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


More information about the user-experience mailing list