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:[email protected]] 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; [email protected]; [email protected]; [email protected] 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 <[email protected]> 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 <[email protected]> (@roessler) > > > > _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
