Hi Tobias -- thanks for working on this spec, it will be good to get this all
more formally documented.
It appears that the -01 rev of draft-gondrom-frame-options takes into account
the apparently present X-Frame-Options documentation here..
[2] Combating ClickJacking With X-Frame-Options
EricLaw [MSFT]
30 Mar 2010 2:42 PM
<http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx>
..which apparently supersedes the prior nominal documentation..
[1] IE8 Security Part VII: ClickJacking Defenses
ieblog
27 Jan 2009 9:40 PM
<http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx>
..and which draft-gondrom-frame-options-00 appears to have been based on.
As Dave Ross earlier today noted in..
Re: [websec] FYI: New draft draft-gondrom-frame-options-01
http://www.ietf.org/mail-archive/web/websec/current/msg00388.html
..the -01 spec rev differs from [2] in that it allows for declaring an origin
list as a value for the ALLOW-FROM directive.
Also, the header name is declared as "Frame-Options" rather than what's
presently implemented and deployed: "X-FRAME-OPTIONS".
Why don't we (WebSec) first simply document present X-FRAME-OPTIONS practice
and get that more formally nailed down before we begin enhancing/altering it ?
After all, it's apparently implemented in most all major browsers, and (I hear)
emitted by a fair number of web applications. Plus, there's always the question
of how closely all those implementations today conform to the present de jure
specification, especially the "new" ALLOW-FROM directive in [2].
This would be in the same spirit as the RFC6265 "HTTP State Management" (aka
Cookies) effort where we (hopefully unambiguously) documented the present
implemented and deployed cookie subprotocol.
thanks,
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
