HTTP Header Field X-Frame-Options
draft-ietf-websec-x-frame-options-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-10-10
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-09-24
|
12 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-09-21
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-08-28
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-08-28
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-08-28
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-08-28
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-08-28
|
12 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-08-28
|
12 | (System) | IANA Action state changed to In Progress |
2013-08-28
|
12 | (System) | RFC Editor state changed to EDIT |
2013-08-28
|
12 | (System) | Announcement was received by RFC Editor |
2013-08-28
|
12 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-08-28
|
12 | Amy Vezza | IESG has approved the document |
2013-08-28
|
12 | Amy Vezza | Closed "Approve" ballot |
2013-08-28
|
12 | Amy Vezza | Ballot approval text was generated |
2013-08-27
|
12 | Barry Leiba | Notification list changed to : websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org |
2013-08-27
|
12 | Barry Leiba | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-08-27
|
12 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-12.txt |
2013-08-27
|
11 | Richard Barnes | [Ballot Position Update] Position for Richard Barnes has been changed to Yes from Discuss |
2013-08-26
|
11 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-11.txt |
2013-08-22
|
10 | Robert Sparks | Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks. |
2013-08-19
|
10 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2013-08-19
|
10 | Richard Barnes | [Ballot discuss] (D1) The privacy considerations make no sense to me. To whom is data being leaked? To the browser? To random people who send … [Ballot discuss] (D1) The privacy considerations make no sense to me. To whom is data being leaked? To the browser? To random people who send a request to a URI? Do you mean that X-Frame-Options leaks information about who the site authorizes? That's true, but also true of things like CORS. If this is the concern, you should recommend a mitigation that's basically the same as what CORS does, namely varying the value of X-Frame-Options based on the Referer or Origin header. (D2) It seems like this is a value that browsers might cache, to avoid unnecessary requests if the same page is framed in the future. If this is something browsers do today, please say so. (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other words, what does it mean to send "X-Frame-Options: ALLOW-FROM https://example.com/this/is/a/path?query#fragment"? |
2013-08-19
|
10 | Richard Barnes | Ballot discuss text updated for Richard Barnes |
2013-08-17
|
10 | Tobias Gondrom | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-08-17
|
10 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-10.txt |
2013-08-16
|
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Joseph Salowey. |
2013-08-15
|
09 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-08-14
|
09 | Joel Jaeggli | [Ballot comment] support richards discussion, the security/privacy considerations could use some wordsmithing. |
2013-08-14
|
09 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-08-14
|
09 | Richard Barnes | [Ballot discuss] (D1) The privacy considerations make no sense to me. To whom is data being leaked? To the browser? To random people who send … [Ballot discuss] (D1) The privacy considerations make no sense to me. To whom is data being leaked? To the browser? To random people who send a request to a URI? Do you mean that X-Frame-Options leaks information about who the site authorizes? That's true, but also true of things like CORS. If this is the concern, you should recommend a mitigation that's basically the same as what CORS does, namely varying the value of X-Frame-Options based on the Referer or Origin header. (D2) It seems like this is a value that browsers might cache, to avoid unnecessary requests if the same page is framed in the future. If this is something browsers do today, please say so. (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other words, what does it mean to send "X-Frame-Options: ALLOW-FROM https://example.com/this/is/a/path?query#fragment"? (D3) In the ALLOW-FROM: what does "top level context" mean? Do you really mean the top level here, as opposed to the next one up? For example, suppose A loads B in an iframe, and B loads C, and then C sends an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin compared to B or A? In either case, you should also note the attacks that remain. For example, if the answer is B, then B needs to use X-Frame-Options as well, or else, A can maliciously frame A within B. Or if the answer is A, then C is trusting A not to load any malicious intermediate frames B. |
2013-08-14
|
09 | Richard Barnes | [Ballot comment] (C1) In the Introduction, the phrase "secure web page" would seem to imply that this mechanism only applies to pages delivered over HTTPS, … [Ballot comment] (C1) In the Introduction, the phrase "secure web page" would seem to imply that this mechanism only applies to pages delivered over HTTPS, which I'm pretty sure isn't true. Suggest just deleting "secure". (C2) In Section 2.1, the sentence starting "And the algorithm" seems to imply that ALLOW-FROM allows SAMEORIGIN requests as well, which I think you actually mean something like: """ And the algorithm to compare origins from [RFC6454] SHOULD be used to verify that a referring page is of the same origin as the content (in the case of SAMEORIGIN) or that the referring page's origin is identical with the ALLOW-FROM URI (in the case of ALLOW-FROM). """ |
2013-08-14
|
09 | Richard Barnes | [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes |
2013-08-14
|
09 | Stephen Farrell | [Ballot comment] (Personal opinion only, no change requested unless it resonates with folks.) I would prefer that this not say that NoScript impairs broswer utility. … [Ballot comment] (Personal opinion only, no change requested unless it resonates with folks.) I would prefer that this not say that NoScript impairs broswer utility. I find it fine. Other than that, this is a fine draft, thanks. |
2013-08-14
|
09 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2013-08-14
|
09 | Pete Resnick | [Ballot comment] Why is this document not on the standards track? |
2013-08-14
|
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-08-14
|
09 | Ted Lemon | [Ballot comment] The introduction of the concept of origins in 2.1 is a bit clumsy—the term is used under the SAMEORIGIN heading without being defined, … [Ballot comment] The introduction of the concept of origins in 2.1 is a bit clumsy—the term is used under the SAMEORIGIN heading without being defined, and is later defined as a constraint specific only to ALLOW-FROM. Text about browser implementations for SAMEORIGIN and ALLOW-FROM is repeated here and in later sections. It would be better to simply refer to the later section. If I were to clean up this section, I would do something like the following: DENY A browser receiving content with this header MUST NOT display this content in any frame. SAMEORIGIN A browser receiving content with this header field MUST NOT display this content in any frame from a page of different origin than the content itself. If a browser or plugin can not reliably determine whether the origin of the content and the frame have the same origin, this MUST be treated as "DENY". Section 2.3.2.2 documents variations in the handling of this header field by different browsers. ALLOW-FROM (followed by a URI [RFC3986] of a trusted origin) A browser receiving content with this header MUST NOT display this content in a frame from any page with a top-level browsing context of different origin than the specified origin. While this can expose the page to risks by the trusted origin, in some cases it may be necessary to allow the framing by content from other domains. The meaning of the term "origin" is given in [RFC6454]. If the ALLOW-FROM value is used, it MUST be followed by a valid URI. Any data beyond the domain address (i.e. any data after the "/" separator) is to be ignored. And the algorithm to compare origins from [RFC6454] SHOULD be used to verify that a referring page is of the same origin as the content or that the referring page's origin is identical with the ALLOW-FROM URI. Though in conflict with [RFC6454], current implementations do not consider the port as a defining component of the origin. I also noticed that in another exchange about this document, someone said that this document is not intended to give advice to browser vendors. If that's the case, what is the above SHOULD doing in the text? Is there uncertainty as to what implementations do? If so, it would be better to express that uncertainty, if indeed you are documenting browser behavior. Also, with respect to this text: Though in conflict with [RFC6454], current implementations do not consider the port as a defining component of the origin. Does this mean that http://www.foo.com and http://www.foo.com:8080 are considered equivalent, or that http://www.foo.com and http://www.foo.com:80 are _not_ considered equivalent? What about http://www.foo.com and https://www.foo.com? The following text is incomprehensible to me as a non-domain-expert: The criteria for the SAMEORIGIN option is not evaluated unanimously either: one implementation may evaluate the SAMEORIGIN option based on the origin of the framed page and the framing page, while another may evaluate based on the framed page and the top-level browsing- context. What is the distinction between "top-level browsing context" and "origin of the framing page?" A reference here would be helpful. Thanks for documenting this. |
2013-08-14
|
09 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-08-14
|
09 | Sean Turner | [Ballot discuss] It's interesting to note that this draft says there's a problem with folks not checking the origins of the entire ancestor tree of … [Ballot discuss] It's interesting to note that this draft says there's a problem with folks not checking the origins of the entire ancestor tree of names of the framing resource - but then doesn't say that sounds like a good idea do it. I can see the argument that might be made that this draft is just documenting what's done now, but shouldn't we take the opportunity to do more and recommend something along the lines of "The entire ancestor tree of names of the framing resource SHOULD be checked to mitigate the risk of attacks in multiple-nested scenarios" or something like that? |
2013-08-14
|
09 | Sean Turner | [Ballot comment] I'd ask about how RFC 6648 applies to this, but I bet this header was out long before the drafts that lead to … [Ballot comment] I'd ask about how RFC 6648 applies to this, but I bet this header was out long before the drafts that lead to RFC 6648. s1 (penultimate paragraph): r/script/Javascript ? s4.1: Is Figure 1 missing or is that the registration template? ;) s5: r/all kinds of these attack vectors/these kind of attack vectors r/, ...)/) Appendix A: Is this a guarantee that x-frame-options/frame-options will be supported henceforth until the end of time in those browsers? Basically, I'm not sure Appendix A is needed. |
2013-08-14
|
09 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2013-08-14
|
09 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-08-13
|
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-08-13
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-08-13
|
09 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-09.txt |
2013-08-12
|
08 | Spencer Dawkins | [Ballot comment] I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing. I … [Ballot comment] I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing. I have one fairly fundamental comment, which I think can be easily addressed, and a few nits. My comment: This specification starts out like a normal header field specification until you get to 1. Introduction This specification provides informational documentation about the current use and definition of the X-Frame-Options HTTP header field. Given that the "X-" construction is deprecated [RFC6648], the X -Frame-Options header field will in the future be replaced by the Frame-Options directive in the Content Security Policy Version 1.1 [CSP-1-1]. That's still KIND of OK (no indication that anything is wrong with X-FRAME-OPTIONS functionality, just a heads-up that implementations that include X-FRAME-OPTIONS will have work to do in the future), but when we get to 2.3.2.2. Variation in current browser behaviour There are currently variations in the implementation of the X-FRAME- OPTIONS header. we discover unambiguously that current implmentations don't all work the same way, so your ability to rely on X-FRAME-OPTIONS is not entirely clear. I wonder if the set of technical details are asperational, saying "this is what X-FRAME-OPTIONS could have been, and what the next header field in this space should be". I think it's fine to publish this specification, especially as Informational, even if it's not clear to me that *any* of the functionality described in this specification is implemented the same way in all major browsers. I would be more comfortable with a clear statement in the Introduction that the biggest problem with X-FRAME-OPTIONS is *not* the leading "X-", but that today's implementations don't all provide the same options with the same behaviors, so relying on this specification as a predictor of what will happen to your frames is not a good idea. One sentence that puts the reader on notice would be sufficient. My nits, just so editors don't have to find them again: Is there a reason why sometimes X-FRAME-OPTIONS is in all caps, and other times not? I'm not an APP guy, so I'm asking. In Section 2.3.2.2. Variation in current browser behaviour These variations in the evaluation of the header by different implementations impair the useage and reliability of this http header. A revised version of x-frame-options in the form of a frame- options directive in the CSP 1.1[CSP-1-1] will unify the behaviour and it is expected that newer implementations will use it rather than the mechanisms documented here" The trailing quote mark should be a period, I suppose? 5.1. Privacy Considreations should be "Considerations". In B.2. Online Shop Confirm Purchase Page The "Confirm Purchase"" The doubled trailing quote marks should be one quote mark, perhaps? |
2013-08-12
|
08 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2013-08-12
|
08 | Spencer Dawkins | [Ballot comment] I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing. I … [Ballot comment] I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing. I have one fairly fundamental comment, which I think can be easily addressed, and a few nits. My comment: This specification starts out like a normal header field specification until you get to 1. Introduction This specification provides informational documentation about the current use and definition of the X-Frame-Options HTTP header field. Given that the "X-" construction is deprecated [RFC6648], the X -Frame-Options header field will in the future be replaced by the Frame-Options directive in the Content Security Policy Version 1.1 [CSP-1-1]. That's still KIND of OK (no indication that anything is wrong with X-FRAME-OPTIONS functionality, just a heads-up that implementations that include X-FRAME-OPTIONS will have work to do in the future), but when we get to 2.3.2.2. Variation in current browser behaviour There are currently variations in the implementation of the X-FRAME- OPTIONS header. we discover unambiguously that current implmentations don't all work the same way, so your ability to rely on X-FRAME-OPTIONS is not entirely clear. I wonder if the set of technical details are asperational, saying "this is what X-FRAME-OPTIONS could have been, and what the next header field in this space should be". I think it's fine to publish this specification, especially as Informational, even if it's not clear to me that *any* of the functionality described in this specification is implemented the same way in all major browsers. I would be more comfortable with a clear statement in the Introduction that the biggest problem with X-FRAME-OPTIONS is *not* the leading "X-", but that today's implementations don't all provide the same options with the same behaviors, so relying on this specification as a predictor of what will happen to your frames is not a good idea. One sentence that puts the reader on notice would be sufficient. My nits, just so editors don't have to find them again: In Section 2.3.2.2. Variation in current browser behaviour These variations in the evaluation of the header by different implementations impair the useage and reliability of this http header. A revised version of x-frame-options in the form of a frame- options directive in the CSP 1.1[CSP-1-1] will unify the behaviour and it is expected that newer implementations will use it rather than the mechanisms documented here" The trailing quote mark should be a period, I suppose? 5.1. Privacy Considreations should be "Considerations". In B.2. Online Shop Confirm Purchase Page The "Confirm Purchase"" The doubled trailing quote marks should be one quote mark, perhaps? |
2013-08-12
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-08-12
|
08 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-08-12
|
08 | Barry Leiba | Ballot has been issued |
2013-08-12
|
08 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2013-08-12
|
08 | Barry Leiba | Created "Approve" ballot |
2013-08-12
|
08 | Barry Leiba | Ballot writeup was changed |
2013-08-12
|
08 | Barry Leiba | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-08-12
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-08-11
|
08 | Tobias Gondrom | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-08-11
|
08 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-08.txt |
2013-08-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2013-08-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2013-08-08
|
07 | Robert Sparks | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Robert Sparks. |
2013-08-08
|
07 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Withdrawn' |
2013-08-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2013-08-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2013-08-08
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-08-08
|
07 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-websec-x-frame-options-07. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-websec-x-frame-options-07. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that there is a single action required to be completed upon approval of this document. In the Permanent Message Header Field Names subregistry of the Message Headers registry located at: http://www.iana.org/assignments/message-headers a new message header field name is to be registered as follows: Header Field Name: X-Frame-Option Template: Protocol: http Status: informational Reference: [ RFC-to-be ] NOTE: We will initiate a request and send this to the designated expert for review. We will inform you the review result accordingly. We understand that this is the only action required upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2013-08-02
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2013-08-02
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2013-08-02
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2013-08-02
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2013-07-29
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-07-29
|
07 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (HTTP Header Field X-Frame-Options) to … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (HTTP Header Field X-Frame-Options) to Informational RFC The IESG has received a request from the Web Security WG (websec) to consider the following document: - 'HTTP Header Field X-Frame-Options' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-08-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract To improve the protection of web applications against Clickjacking, this specification describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-07-29
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-07-29
|
07 | Barry Leiba | Notification list changed to : websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org |
2013-07-29
|
07 | Barry Leiba | Placed on agenda for telechat - 2013-08-15 |
2013-07-29
|
07 | Barry Leiba | Last call was requested |
2013-07-29
|
07 | Barry Leiba | Last call announcement was generated |
2013-07-29
|
07 | Barry Leiba | Ballot approval text was generated |
2013-07-29
|
07 | Barry Leiba | State changed to Last Call Requested from AD Evaluation |
2013-07-29
|
07 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-07.txt |
2013-07-28
|
06 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-06.txt |
2013-07-15
|
05 | Amy Vezza | Summary ======= Yoav Nir is the Document Shepherd. Barry Leiba is the Responsible Area Director. This informational document serves to document the existing use and … Summary ======= Yoav Nir is the Document Shepherd. Barry Leiba is the Responsible Area Director. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. To improve the protection of web applications against Clickjacking, this specification describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. Review and Consensus ==================== In 2009 and 2010 many browser vendors introduced the use of a non- standard HTTP header field "X-Frame-Options" to protect against Clickjacking. There have been differences between the various implementations which may cause security and interoperability concerns. This draft has been produced as informational by the websec working group to document the current use and also to function as a baseline for the future unified standard as part of the currently produced Content Security Policy 1.1 (by WebAppSec at the W3C) - and to get rid of the deprecated "X-" (see RFC6648). The review process took sufficient time and involved a medium amount of people with deep browser security knowledge. During the review process no major controversies came up, which is not too surprising as the draft is intended as informational and documenting. Intellectual Property ===================== Each author has confirmed conformance with BCPs 78 and 79. Tobias confirmed. David has also confirmed. Other Points ============ None. |
2013-07-15
|
05 | Barry Leiba | State changed to AD Evaluation from Publication Requested |
2013-07-15
|
05 | Barry Leiba | Ballot writeup was changed |
2013-07-15
|
05 | Barry Leiba | Ballot writeup was generated |
2013-07-15
|
05 | Barry Leiba | Notification list changed to : websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org |
2013-07-15
|
05 | Barry Leiba | State changed to Publication Requested from AD is watching |
2013-07-15
|
05 | Barry Leiba | Changed consensus to Yes from Unknown |
2013-07-15
|
05 | Yoav Nir | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2013-07-15
|
05 | Yoav Nir | Annotation tag Revised I-D Needed - Issue raised by WGLC cleared. |
2013-07-15
|
05 | Yoav Nir | Changed document writeup |
2013-07-15
|
05 | Yoav Nir | Changed document writeup |
2013-07-15
|
05 | Yoav Nir | Document shepherd changed to Yoav Nir |
2013-07-15
|
05 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-05.txt |
2013-06-28
|
04 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-04.txt |
2013-06-21
|
03 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-03.txt |
2013-02-25
|
02 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-02.txt |
2012-11-16
|
01 | Barry Leiba | State Change Notice email list changed to websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, alexey.melnikov@isode.com |
2012-11-16
|
01 | Barry Leiba | Intended Status changed to Informational |
2012-11-16
|
01 | Barry Leiba | IESG process started in state AD is watching |
2012-11-16
|
01 | (System) | Earlier history may be found in the Comment Log for draft-gondrom-x-frame-options |
2012-11-08
|
01 | Alexey Melnikov | IETF state changed to In WG Last Call from WG Document |
2012-11-08
|
01 | Alexey Melnikov | Annotation tag Revised I-D Needed - Issue raised by WGLC set. |
2012-11-08
|
01 | Alexey Melnikov | WGLC ends on November 16th as per email from Yoav |
2012-11-08
|
01 | Alexey Melnikov | Changed shepherd to Alexey Melnikov |
2012-10-22
|
01 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-01.txt |
2012-07-03
|
00 | Tobias Gondrom | New version available: draft-ietf-websec-x-frame-options-00.txt |