[OpenID] OpenID UX and IIW session

Wed Nov 12 22:43:55 UTC 2008

On Wed, Nov 12, 2008 at 10:16 AM,  <alavillipraveen at aol.com> wrote:
> 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,

Note that all code for breaking iframes can be disabled in IE. See:

http://msdn.microsoft.com/en-us/library/ms534622.aspx

>
> - 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
>
>
> ________________________________
> 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)