[OpenID] OpenID UX and IIW session

Wed Nov 12 18:16:07 UTC 2008

 with fairly good P3P policy from OP and with medium level privacy settings in all browsers, cookies are passed in outgoing requests. So this shouldn't be a problem unless the OP is trying to set some cookies in the response.

Btw - I forgot which OPs that we found as breaking the frames early this year. So I will do some tests again and will send a list of OPs that are breaking iframes in checkid_immediate (and also not breaking frames in case of checkid_setup).

- Praveen

-----Original Message-----
From: John Panzer <jpanzer at acm.org>
To: alavillipraveen at aol.com
Cc: general at openid.net
Sent: Wed, 12 Nov 2008 8:49 am
Subject: Re: [OpenID] OpenID UX and IIW session

What are the security rules around cookies and 3rd party domains used
in iframes?  (My understanding is that there are some issues especially
around IE, but I can never remember what they are exactly; if there are
issues, then presumably cookie based OP sessions will have an issue
with using an asynchronous iframe to do checkid_immediate; if there are
workarounds, they'd need to be documented for UX implementors.)

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

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general

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