RE: Frame embedding: One problem, three possible specs?

The latest draft of the WebAppSec charter includes a secure cross-domain framing mechanism as a distinct deliverable from the CSP, it's relation is only in proposing re-use of same browsing context capability grammar as CSP.  So retaining option #1 is not in conflict with dropping frame-ancestors from CSP v1.

#2 and #3 (and frame-ancestors in the current CSP draft) allow expression of similar policies: "This content can only be framed/embedded by these origins."  I think it makes sense to consolidate these going forward.

#1 in the new WebAppSec WG draft charter is different.  While there isn't a strawman yet, it seeks to allow expression of a policy like: "Anyone can frame this content, but it must allow X, Y and Z."  or maybe, "This frame is non-interactive unless X, Y and Z."  (where X, Y and Z might be: an unobstructed canvas, allowed to execute script, allowed to top-nav, top z-order, minimum display size, etc...) 

I think both approaches can co-exist and that #1 can proceed without conflict for now.  If the proposal that emerges is determined to be best transported as additional semantics for X-Frame-Options or From-Origin, the WebAppSec WG is already chartered to do the necessary coordination.

-Brad


-----Original Message-----
From: Adam Barth [mailto:w3c@adambarth.com] 
Sent: Thursday, July 07, 2011 3:24 PM
To: Thomas Roessler
Cc: Tobias Gondrom; Arthur Barstow; Hill, Brad; Eric Rescorla; Alexey Melnikov; David Ross; Anne van Kesteren; Adrian Bateman; Brandon Sterne; Charles McCathieNevile; Maciej Stachowiak; Peter Saint-Andre; Michael(tm) Smith; Mark Nottingham; Hodges, Jeff; public-web-security@w3.org; public-webapps@w3.org; websec@ietf.org
Subject: Re: Frame embedding: One problem, three possible specs?

My sense from talking with folks is that there isn't a lot of enthusiasm for supporting this use case in CSP at the present time.
We're trying to concentrate on a core set of directives for the first iteration.  If it helps reduce complexity, you might consider dropping option (1) for the time being.

Adam


On Thu, Jul 7, 2011 at 2:11 PM, Thomas Roessler <tlr@w3.org> wrote:
> (Warning, this is cross-posted widely. One of the lists is the IETF 
> websec mailing list, to which the IETF NOTE WELL applies: 
> http://www.ietf.org/about/note-well.html)
>
>
> Folks,
>
> there appear to be at least three possible specifications addressing this space, with similar but different designs:
>
> 1. A proposed deliverable in the WebAppSec group to take up on X-Frame-Options and express those in CSP:
>  http://www.w3.org/2011/07/appsecwg-charter.html
>
> (We expect that this charter might go to the W3C AC for review as soon 
> as next week.)
>
> 2. The "From-Origin" draft (aka "Cross-Origin Resource Embedding Exclusion") currently considered for publication as an FPWD in the Webapps WG:
>  
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0088.htm
> l
>
> This draft mentions integration into CSP as a possible path forward.
>
> 3. draft-gondrom-frame-options, an individual I-D mentioned to websec:
>  https://datatracker.ietf.org/doc/draft-gondrom-frame-options/
>  http://www.ietf.org/mail-archive/web/websec/current/msg00388.html
>
>
> How do we go about it?  One path forward might be to just proceed as currently planned and coordinate when webappsec starts working.
>
> Another path forward might be to see whether we can agree now on what forum to take these things forward in (and what the coordination dance might look like).
>
> Thoughts welcome.
>
> Regards,
> --
> Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)
>
>
>
>

Received on Thursday, 7 July 2011 23:32:37 UTC