[step2] Re: OpenID Popup Extension - Draft 0
Praveen Alavilli
praveen.alavilli at gmail.com
Mon Feb 16 04:22:23 UTC 2009
sorry for joining late but couple from me:
- 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.
- -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)
- 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.
- +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
- 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).
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, pictures.aol.com,
journals.aol.com, etc..) at the same time using same OP and all popups look
exactly same.
On Sun, Feb 15, 2009 at 5:10 PM, Allen Tom <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 <step2%2Bunsubscribe 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/20090215/f796ae4e/attachment-0002.htm>
More information about the user-experience
mailing list