[OpenID] OpenID UX and IIW session

[alavillipraveen at aol.com]

 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.



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081112/2f6aa8f2/attachment-0002.htm>