[websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)

[=JeffH <[e-mail]>]

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