Hi all,
sorry for the late answer, a flu and some other duties kept me from
answering so far.
I agree with Thomas, Adam and David, so please go ahead with the
webappsecwg charter.
The current plan for #3 is to be adopted in websec (as http headers
should be done in IETF) and proceed within
So, looking at this thread, here's what I suggest for the webappsecwg charter:
We keep the deliverable in there, but make it very clear that the group should
liaise particularly closely with websec "and other IETF work around framing
policy" (or some such), explicitly to avoid conflicting or com
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-ancestor
#3 is a narrowly scoped effort to standardize something that works pretty well
today in practice (X-FRAME-OPTIONS). A conflict with CSP would be bad, but per
Adam it seems like overlap is looking less likely. So proceeding down the
current path on #3 sounds good to me.
David Ross
dr...@micros
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 bein
(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:
