[step2] Re: OpenID Popup Extension - Draft 0
George Fletcher
gffletch at aol.com
Tue Feb 17 15:18:21 UTC 2009
I'm fine with this as well.
I wonder if a compromise on the SHOULD/MUST is that the OP MUST display
the first page of the UI in the 450 x 500 window. If a secondary page
requires a larger size, they can resize it when needed.
In addition, it doesn't look like the current proposal precludes OpenID
RP SaaS models nor RP UI customizations (two use cases that are very
important to AOL). These use cases are likely dependent on "trusted
resolution" of XRD's and signing of OpenID AuthN requests.
Thanks,
George
Breno wrote:
> Agree with Chris suggestion to start simple.
>
> On Mon, Feb 16, 2009 at 4:02 PM, Chris Messina
> <chris.messina at gmail.com <mailto: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 <mailto: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 <mailto: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
> <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
> <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
> <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
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
>
> --
> Chris Messina
> Citizen-Participant &
> Open Web Advocate-at-Large
>
> factoryjoe.com <http://factoryjoe.com> # diso-project.org
> <http://diso-project.org>
> citizenagency.com <http://citizenagency.com> # vidoop.com
> <http://vidoop.com>
> This email is: [ ] bloggable [X] ask first [ ] private
>
>
>
>
>
> --
> Breno de Medeiros
>
>
> --~--~---------~--~----~------------~-------~--~----~
> 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
> -~----------~----~----~----~------~----~------~--~---
>
More information about the user-experience
mailing list