<div> <font face="Arial, Helvetica, sans-serif">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. <br>
<br>
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. <br>
<br>
"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.<br>
</font><font face="Arial, Helvetica, sans-serif"><br>
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.</font><br>
<font face="Arial, Helvetica, sans-serif"><br>
So I think we should be more specific on the redirect mechanisms - for example a few </font><font face="Arial, Helvetica, sans-serif">g</font>eneral guidelines for implementing Redirects for OpenID Providers<b><font face="Arial, Helvetica, sans-serif"> </font></b><font face="Arial, Helvetica, sans-serif">should </font><font face="Arial, Helvetica, sans-serif">be</font><b><font face="Arial, Helvetica, sans-serif"> </font></b><font face="Arial, Helvetica, sans-serif">some thing like</font><b><br>
</b>
<ul><li>
<div style="margin-bottom: 0in;"><font face="Arial, Helvetica, sans-serif">Immediate requests</font></div>
<ol type="i"><li>
<div style="margin-bottom: 0in;"><font face="Arial, Helvetica, sans-serif">OP MUST use standard HTTP
redirect mechanism (HTTP Status code 302 ) to redirect the user
back to RP’s return_to url.</font></div>
</li><li>
<div style="margin-bottom: 0in;"><font face="Arial, Helvetica, sans-serif">OP MAY use Javascript code to
initiate the redirect back to RP’s return_to url but it MUST
not break IFRAMEs.</font></div>
<ol><li>
<div style="margin-bottom: 0in;"><font face="Arial, Helvetica, sans-serif">Ex. Use document.location =
return_to url or document.location.replace(return_to url)</font></div>
</li></ol>
</li></ol>
</li><li>
<div style="margin-bottom: 0in;"><font face="Arial, Helvetica, sans-serif">Non-immediate requests</font></div>
<ol type="i"><li>
<div style="margin-bottom: 0in;"><font face="Arial, Helvetica, sans-serif">OP MUST use standard HTTP
redirect mechanism (HTTP Status code 302) to redirect the user
back to RP’s return_to url.</font></div>
</li><li>
<div style="margin-bottom: 0in;"><font face="Arial, Helvetica, sans-serif">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.</font></div>
<ol><li>
<div style="margin-bottom: 0in;"><font face="Arial, Helvetica, sans-serif">Ex. Use parent.location =
return_to url or parent.location.replace(return_to url) or
top.location.href = return_to url
</font></div>
</li></ol>
</li></ol>
</li></ul>
<font face="Arial, Helvetica, sans-serif"><br>
<br>
</font></div>
<div> <font face="Arial, Helvetica, sans-serif">- Praveen</font><br>
</div>
<div> <br>
</div>
-----Original Message-----<br>
From: Carl Howells <chowells@janrain.com><br>
To: Praveen Alavilli <AlavilliPraveen@aol.com><br>
Cc: OpenID General <general@openid.net><br>
Sent: Tue, 11 Nov 2008 5:22 pm<br>
Subject: Re: [OpenID] OpenID UX and IIW session<br>
<br>
<div id="AOLMsgPart_0_fa6edfff-3b1a-423b-a95b-7f338cc09d68" style="margin: 0px; font-family: Tahoma,Verdana,Arial,Sans-Serif; font-size: 12px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<pre style="font-size: 9pt;"><tt>Praveen,<br>
<br>
A compliant OP, when receiving a checkid_immedate request, will never<br>
render an html page. It will *only* issue redirects.<br>
<br>
Given that, I fail to see how frame breaking comes into play.<br>
<br>
On Tue, Nov 11, 2008 at 3:19 PM, Praveen Alavilli<br>
<<a __removedlink__1346268960__href="mailto:AlavilliPraveen@aol.com">AlavilliPraveen@aol.com</a>> wrote:<br>
> One of the big problems with using checkid_immediate is that several<br>
> OPs break iframes - so there is no reliable way of doing async with<br>
> checks with out doing a redirect inside the same browser window or in<br>
> a popup.<br>
</tt></pre>
</div>
<!-- end of AOLMsgPart_0_fa6edfff-3b1a-423b-a95b-7f338cc09d68 -->
<div id='MAILCIAMB042-92bd491a7c7b3b5' class='aol_ad_footer'><BR/><FONT style="color: black; font: normal 10pt ARIAL, SAN-SERIF;"><HR style="MARGIN-TOP: 10px"></HR>Instant access to the latest & most popular FREE games while you browse with the Games Toolbar - <a href="http://pr.atwola.com/promoclk/100000075x1212904500x1200818240/aol?redir=http://toolbar.aol.com/games/download.html?ncid=emlweusdown00000004">Download Now!</a> </div>