[OpenID] OpenID UX and IIW session

[Breno de Medeiros]

We believe that the Google OP currently has the required behavior
described below for functionality with checkid_immediate. We would
appreciate feedback from RPs that try to implement this.

Breno (Google).

On Tue, Nov 11, 2008 at 10:49 PM,  <alavillipraveen at aol.com> wrote:
> Well, the problem is with the redirect mechanism used (certain JS redirect
> functions break frames) and in some cases I think it's the OP's left over
> frame busting code from their standard login (checkid_setup) flow.
>
> Breaking iframes is a problem because it breaks UX - the RP instead of just
> updating the user login status asynchronously, it has to handle a return
> redirect from the OP, set it's auth session ( and cookies) and redirect back
> to the site in authenticated state. Users will notice a quick
> flash-through-empty page (based on their connection speed)  and of course
> add the click-click sounds in IE when JS based redirects are used. Compare
> this to when HTTP status codes 301/302 are used to do the redirects - RP can
> insert a hidden iframe loading the checkid_immediate url behind the scenes
> to get user's authentication status and update the user's authentication
> status on the web site accordingly without actually doing any more
> redirects.
>
> "checkid_immediate" is essentially the way to detect user's authentication
> status. Without it being iframe friendly, there is no way to provide good UX
> like FBConnect to display your authentication status automatically at sites
> where you already gave consent to.
>
> Another problem with using non 302 redirects is with the unnecessary
> addition of the authentication urls in the browser's history thus making it
> hard for the users to go back to the original site from where they started
> from - but again this is only an issue if the redirects are done in full
> browser window instead of in an iframe.
>
> So I think we should be more specific on the redirect mechanisms - for
> example a few general guidelines for implementing Redirects for OpenID
> Providers should be some thing like
>
> Immediate requests
>
> OP MUST use standard HTTP redirect mechanism (HTTP Status code 302 ) to
> redirect the user back to RP's return_to url.
> OP MAY use Javascript code to initiate the redirect back to RP's return_to
> url but it MUST not break IFRAMEs.
>
> Ex. Use document.location = return_to url or
> document.location.replace(return_to url)
>
> Non-immediate requests
>
> OP MUST use standard HTTP redirect mechanism (HTTP Status code 302) to
> redirect the user back to RP's return_to url.
> OP MAY use Javascript code to break IFRAMEs but it MUST overwrite it's own
> url with the RP's return_to url to preserve browser back button
> functionality.
>
> Ex. Use parent.location = return_to url or parent.location.replace(return_to
> url) or top.location.href = return_to url
>
> - Praveen
>
> -----Original Message-----
> From: Carl Howells <chowells at janrain.com>
> To: Praveen Alavilli <AlavilliPraveen at aol.com>
> Cc: OpenID General <general at openid.net>
> Sent: Tue, 11 Nov 2008 5:22 pm
> Subject: Re: [OpenID] OpenID UX and IIW session
>
> Praveen,
>
>
>
> A compliant OP, when receiving a checkid_immedate request, will never
>
> render an html page.  It will *only* issue redirects.
>
>
>
> Given that, I fail to see how frame breaking comes into play.
>
>
>
> On Tue, Nov 11, 2008 at 3:19 PM, Praveen Alavilli
>
> <AlavilliPraveen at aol.com> wrote:
>
>> One of the big problems with using checkid_immediate is that several
>
>> OPs break iframes - so there is no reliable way of doing async with
>
>> checks with out doing a redirect inside the same browser window or in
>
>> a popup.
>
>
> ________________________________
> Instant access to the latest & most popular FREE games while you browse with
> the Games Toolbar - Download Now!
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)