[step2] Re: OpenID Popup Extension - Draft 0

Tue Feb 17 08:16:05 UTC 2009

+1 --  even better if we can use "MUST" in the wording than a "SHOULD"

On Mon, Feb 16, 2009 at 4:02 PM, Chris Messina <chris.messina at gmail.com>wrote:

> I do worry about the direction of this thread — we're getting overly
> complicated to solve a pretty simple problem... namely, what size should the
> popup start out as?
> The more we can standardize on ONE size that works in MOST contexts, the
> better for overall user experience, as this popup size should become
> recognized by users as being a window with a specific purpose.
>
> The more we offer custom size options, the more we'll see meaningless
> variation to serve subjective tastes, without really adding anything to
> usability. I certainly understand that not all OPs will want to use the same
> size popup, but it seems to me that we start by supporting ONE size and then
> if we get REAL resistance in the wild, then we consider updating the DRAFT
> spec.
>
> In other words, let's produce DRAFT ONE of the spec with support for ONE
> size, and one size only. And then let's see what [real] problems emerge.
>
> One of the reasons why FB Connect is so popular is that it answers trivial
> questions like this consistently. It barely matters what the decision they
> make, only that they've made one. I think we should decide what the standard
> size for the popup should be and then ship it.
>
> We can iterate/debate later.
>
> Thus, in Section 4, why don't we use this language:
>
>  The recommended default values for openid.popup.width SHOULD be 450px
>>  and openid.popup.height SHOULD be 500px for consistency. OPs SHOULD design
>> their authentication screens to match these dimensions.
>>
>
> Let's keep it simple here at least to start.
>
> Chris
>
> On Mon, Feb 16, 2009 at 2:42 PM, Praveen Alavilli <
> praveen.alavilli at gmail.com> wrote:
>
>> hmm I would rather prefer getting the width and height of the "popup" from
>> some attributes defined in XRDS than parsing multiple popup urls and
>> extracting the width and height to figure out which one I want to use. I am
>> not very familiar with the XRDS schema - but can the "otherattribute" be
>> used to specify the width and height for the popup type service element?
>>
>> If we are going down this route of letting OP specify multiple urls with
>> different width & height in the urls, then I don't see the value of
>> specifying a new "type" for popup ui. The OPs can as well set multple urls
>> for the "<Type>http://specs.openid.net/auth/2.0/signon</Type>" with each
>> containing the UI width and height and it's upto the RPs to chose the one
>> that they think will fit in their popup window.
>>
>> IMHO - providing the new type for popup with just one url along with width
>> and height as some attributes really makes it less confusing for the
>> developers.  Just look at the way RPs use FBConnect popups.
>>
>>
>> As far as resizing of the window is considered - it seems to be broken if
>> the OP cannot always support the same size of the window. If the OP needs to
>> do additional challenges or display more information, there are several
>> other ways to do it without resizing the window. They would have to do it
>> anyway for smart phones (iphone) since they cannot just resize the window.
>>
>>
>> thanks
>> Praveen
>>
>>
>>
>> On Mon, Feb 16, 2009 at 12:23 PM, Allen Tom <atom at yahoo-inc.com> wrote:
>>
>>> 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, pictures.aol.com,
>>> 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> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Chris Messina
> Citizen-Participant &
>  Open Web Advocate-at-Large
>
> factoryjoe.com # diso-project.org
> citizenagency.com # vidoop.com
> This email is:   [ ] bloggable    [X] ask first   [ ] private
>
> --~--~---------~--~----~------------~-------~--~----~
> 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/20090217/fba06f17/attachment-0002.htm>