In http://tools.ietf.org/html/draft-gondrom-frame-options-02 we're introducing a new HTTP header called Frame-Options. Is there a particular reason to create yet-another-HTTP-header for carrying this security policy? Rather than inventing a new HTTP header, we can use the extensible Content-Security-Policy header.
== Proposed in draft-gondrom-frame-options == Frame-Options: XYZ Where XYZ is the Frame-Options policy. == Using Content-Security-Policy == Content-Security-Policy: frame-options XYZ There are added benefits to using a common policy header. For example, Content-Security-Policy has a report-uri directive that web sites can use to learn when their security policies are violated: Content-Security-Policy: frame-options XYZ; report-uri /csp-reports.cgi Note: Content-Security-Policy 1.0 is very close to WGLC in the W3C WebAppSec working group. You can find the current draft at <http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html>. The WebAppSec working group is soliciting proposals for CSP 1.1: http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version_1.1 In particular, we have an item on the wiki about coordinating with this working group about frame-options. It's entirely possible to define the frame-options directive in this working group and to have CSP 1.1 refer to whatever document this working group produces. In the long term, we'll probably want an IANA registry for CSP directives, but we haven't quite reached that level of technology yet. :) Kind regards, Adam _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
