idnits 2.17.1 draft-ietf-websec-framework-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Feb 2013) is 4087 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '11' is defined on line 738, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 799, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 807, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '0' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 5246 (ref. '7') (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '26' -- Possible downref: Non-RFC (?) normative reference: ref. '27' -- Possible downref: Non-RFC (?) normative reference: ref. '28' -- Possible downref: Non-RFC (?) normative reference: ref. '29' -- Possible downref: Non-RFC (?) normative reference: ref. '30' -- Possible downref: Non-RFC (?) normative reference: ref. '31' -- Possible downref: Non-RFC (?) normative reference: ref. '33' -- Possible downref: Non-RFC (?) normative reference: ref. '34' -- Possible downref: Non-RFC (?) normative reference: ref. '35' -- Possible downref: Non-RFC (?) normative reference: ref. '36' -- Possible downref: Non-RFC (?) normative reference: ref. '37' -- Possible downref: Non-RFC (?) normative reference: ref. '38' -- Possible downref: Non-RFC (?) normative reference: ref. '39' -- Possible downref: Non-RFC (?) normative reference: ref. '40' -- Possible downref: Non-RFC (?) normative reference: ref. '41' -- Possible downref: Non-RFC (?) normative reference: ref. '42' -- Possible downref: Non-RFC (?) normative reference: ref. '43' -- Duplicate reference: RFC5246, mentioned in 'RFC5246', was also mentioned in '7'. -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 45 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hodges 3 Internet-Draft PayPal 4 Intended status: Standards Track Feb 2013 5 Expires: August 5, 2013 7 Web Security Framework: Problem Statement and Requirements 8 draft-ietf-websec-framework-reqs-00 10 Abstract 12 Web-based malware and attacks are proliferating rapidly on the 13 Internet. New web security mechanisms are also rapidly growing in 14 number, although in an incoherent fashion. This document provides a 15 brief overview of the present situation and the various seemingly 16 piece-wise approaches being taken to mitigate the threats. It then 17 provides an overview of requirements as presently being expressed by 18 the community in various online and face-to-face discussions. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 5, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Where to Discuss This Draft . . . . . . . . . . . . . . . 4 56 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 5 57 3. Overall Constraints . . . . . . . . . . . . . . . . . . . . . 5 58 4. Overall Requirements . . . . . . . . . . . . . . . . . . . . . 6 59 5. Vulnerabilities, Attacks, and Threats . . . . . . . . . . . . 8 60 5.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Detailed Functional Requirements . . . . . . . . . . . . . . . 11 64 8. Extant Policies to Coalesce . . . . . . . . . . . . . . . . . 15 65 9. Example Concrete Approaches . . . . . . . . . . . . . . . . . 15 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 12. Informative References . . . . . . . . . . . . . . . . . . . . 19 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 70 Appendix B. Discussion References . . . . . . . . . . . . . . . . 21 71 B.1. Source: Attacks and Threats . . . . . . . . . . . . . . . 21 72 B.2. Source: Policy Expression Syntax [1] . . . . . . . . . . . 21 73 B.3. Source: Policy Expression Syntax [2] . . . . . . . . . . . 22 74 B.4. Source: Tooling . . . . . . . . . . . . . . . . . . . . . 22 75 B.5. Source: Performance . . . . . . . . . . . . . . . . . . . 23 76 B.6. Source: Granularity . . . . . . . . . . . . . . . . . . . 23 77 B.7. Source: Notifications and Reporting . . . . . . . . . . . 23 78 B.8. Source: Facilitating Separation of Duties . . . . . . . . 24 79 B.9. Source: Hierarchical Policy Application . . . . . . . . . 24 80 B.10. Source: Framing Policy Hierarchy, cross-origin, 81 granularity . . . . . . . . . . . . . . . . . . . . . . . 24 82 B.11. Source: Policy Delivery [1] . . . . . . . . . . . . . . . 26 83 B.12. Source: Policy Delivery [2] . . . . . . . . . . . . . . . 26 84 B.13. Source: Policy Conflict Resolution . . . . . . . . . . . . 27 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 87 1. Introduction 89 Over the past few years, we have seen a proliferation of AJAX-based 90 web applications (AJAX being shorthand for asynchronous JavaScript 91 and XML), as well as Rich Internet Applications (RIAs), based on so- 92 called Web 2.0 technologies. These applications bring both luscious 93 eye-candy and convenient functionality--e.g. social networking--to 94 their users, making them quite compelling. At the same time, we are 95 seeing an increase in attacks against these applications and their 96 underlying technologies [1]. The latter include (but aren't limited 97 to) Cross-Site-Request Forgery (CSRF) -based attacks [2], content- 98 sniffing cross-site-scripting (XSS) attacks [3], attacks against 99 browsers supporting anti-XSS policies [4], clickjacking attacks [5], 100 malvertising attacks [6], as well as man-in-the-middle (MITM) attacks 101 against "secure" (e.g. Transport Layer Security (TLS/SSL)-based [7]) 102 web sites along with distribution of the tools to carry out such 103 attacks (e.g. sslstrip) [8]. 105 During the same time period we have also witnessed the introduction 106 of new web security indicators, techniques, and policy communication 107 mechanisms sprinkled throughout the various layers of the Web and 108 HTTP. We have a new cookie security flag called HTTPOnly [9]. We 109 have the anti-clickjacking X-Frame-Options HTTP header [10], the 110 Strict-Transport-Security HTTP header [RFC6797], anti-CSRF headers 111 (e.g. Origin) [12], an anti-sniffing header (X-Content-Type-Options: 112 nosniff) [13], various approaches to content restrictions [14] [15] 113 and notably Mozilla Content Security Policy (CSP; conveyed via a HTTP 114 header) [16], the W3C's Cross-Origin Resource Sharing (CORS; also 115 conveyed via a HTTP header) [17], as well as RIA security controls 116 such as the crossdomain.xml file used to express a site's Adobe Flash 117 security policy [18]. There's also the Application Boundaries 118 Enforcer (ABE) [19], included as a part of NoScript [20], a popular 119 Mozilla Firefox security extension. Sites can express their ABE 120 rule-set at a well-known web address for downloading by individual 121 clients [21], similarly to Flash's crossdomain.xml. Amidst this 122 haphazard collage of new security mechanisms at least one browser 123 vendor has even devised a new HTTP header that disables one of their 124 newly created security features: witness the X-XSS-Protection header 125 that disables the new anti-XSS features [22] in Microsoft's Internet 126 Explorer 8 (IE8). 128 Additionally, there are various proposals aimed at addressing other 129 facets of inherent web vulnerabilities, for example: JavaScript 130 postMessage-based mashup communications [23], hypertext isolation 131 techniques [24], and service security policies advertised via the 132 Domain Name System (DNS) [25]. Going even further, there are efforts 133 to redesign web browser architectures [26], of which Google Chrome 134 and IE8 are deployed examples. An even more radical approach is 135 exhibited in the Gazelle Web Browser [27], which features a browser 136 kernel embodied in a multi-principal OS construction providing cross- 137 principal protection and fair sharing of all system resources. 139 Not to be overlooked is the fact that even though there is a plethora 140 of "standard" browser security features--e.g. the Same Origin Policy 141 (SOP), network-related restrictions, rules for third-party cookies, 142 content-handling mechanisms, etc. [28]--they are not implemented 143 uniformly in today's various popular browsers and RIA frameworks 144 [29]. This makes life even harder for web site administrators in 145 that allowances must be made in site security posture and approaches 146 in consideration of which browser a user may be wielding at any 147 particular time. 149 Although industry and researchers collectively are aware of all the 150 above issues, we observe that the responses to date have been issue- 151 specific and uncoordinated. What we are ending up with looks perhaps 152 similar to Frankenstein's monster [30]--a design with noble intents 153 but whose final execution is an almost-random amalgamation of parts 154 that do not work well together. It can even cause destruction on its 155 own [31]. 157 Thus, the goal of this document is to define the requirements for a 158 common framework expressing security constraints on HTTP 159 interactions. Functionally, this framework should be general enough 160 that it can be used to unite the various individual solutions above, 161 and specific enough that it can address vulnerabilities not addressed 162 by current solutions, and guide the development of future mechanisms. 164 Overall, such a framework would provide web site administrators the 165 tools for managing, in a least privilege [33] manner, the overall 166 security characteristics of their web site/applications when realized 167 in the context of user agents. 169 [[ The author(s) understand that many of the references to web 170 security issues are now somewhat dated and more recent work has 171 appeared in the literature. Suggestions of references to use in 172 superseding the ones herein are welcome; references to web security 173 survey papers would be good. ]] 175 1.1. Where to Discuss This Draft 177 Please disscuss this draft on the websec@ietf.org mailing list 178 [WebSec]. 180 2. Document Conventions 182 NOTE: ..is a note to the reader. These are points that should be 183 expressly kept in mind and/or considered. 185 [[TODOn: Things to fix (where "n" in "TODOn" is a number). --JeffH]] 187 We will also be making use of the WebSec WG issue tracker, so use of 188 the TODO marks will evolve accordingly. 190 3. Overall Constraints 192 Regardless of the overall approaches chosen for conveying site 193 security policies, we believe that to be deployed at Internet-scale, 194 and to be as widely usable as possible for both novice and expert 195 alike, the overall solution approach will need to address these three 196 points of tension: 198 Granularity: 200 There has been much debate during the discussion of some policy 201 mechanisms (e.g. CSP) as to how fine-grained such mechanisms 202 should be. The argument against fine-grained mechanisms is 203 that site administrators will cause themselves pain by 204 instantiating policies that do not yield the intended results. 205 E.g. simply copying the expressed policies of a similar site. 206 The claim is that this would occur for various reasons stemming 207 from the mechanisms' complexity [34]. 209 Configurability: 211 Not infrequently, the complexity of underlying facilities, e.g. 212 in server software, is not well-packaged and thus 213 administrators are obliged to learn more about the intricacies 214 of these systems than otherwise might be necessary. This is 215 sometimes used as an argument for "dumbing down" the 216 capabilities of policy expression mechanisms [34]. 218 Usability: 220 Research shows that when security warnings are displayed, users 221 are often given too much information as well as being allowed 222 to relatively easily bypass the warnings and continue with 223 their potentially compromising activity [35] [36] [37] [38] 224 [39]. Thus users have become trained to "click through" 225 security notifications "in order to get work done", though not 226 infrequently rendering themselves insecure and perhaps 227 compromised [40]. 229 In the next section we discuss various high-level requirements 230 derived with the guidance of the latter tension points. 232 4. Overall Requirements 234 1. Policy conveyance: 236 in-band: 238 HTTP header(s) are already presently used to convey policy 239 to user agents. However, devising generalized, extensible 240 HTTP security header(s) such that the on-going "bloat" of 241 the number of disjoint HTTP security headers is mitigated, 242 is a stated requirement by various parties. Also, then 243 there would be a documented framework that can be leveraged 244 as new approaches and/or threats emerge. 246 It may be reasonable to devise distinct sets of headers to 247 convey different classes of policies, e.g., web application 248 content policies (such as [W3C.CR-CSP-20121115]) versus web 249 application network connection policies (such as 250 [RFC6797]). 252 out-of-band: 254 An out-of-band policy communication mechanism must be 255 secure and should have two facets, one for communicating 256 securely out-of-band of the HTTP protocol to allow for 257 secure client policy store bootstrapping. potential 258 approaches are factory-installed web browser configuration, 259 site security policy download a la Flash's crossdomain.xml 260 and Maone's ABE for Web Authors [21], and DNS-based policy 261 advertisement leveraging the security ofthe Secure DNS 262 (DNSSEC) [32]. 264 NOTE: The distinction between in-band and out-of-band signaling 265 is difficult to characterize because some seemingly out- 266 of-band mechanisms rely on the same protocols (HTTP/HTTPS) 267 and infrastructure (e.g., transparent proxy servers) as 268 the protocols they ostensibly protect. 270 2. Granularity: 272 In terms of granularity, vast arrays of stand-alone blog, 273 wiki, hosted web account, and other "simple" web sites could 274 ostensibly benefit from relatively simple, pre-determined 275 policies. However, complex sites--e.g. payment, ecommerce, 276 software-as-a-service, mashup sites, etc.--often differ in 277 various ways, as well as being inherently complex 278 implementation-wise. One-size-fits-all policies will 279 generally not work well for them. 281 Thus, to be effective for a broad array of web site and 282 application types, some derived requirements are: 284 the policy expression mechanism should fundamentally 285 facilitate fine-grained control. For example, CSP 286 [W3C.CR-CSP-20121115] offers such control. 288 In order to address the less complex needs of the more 289 simple classes of web sites, the policy expression 290 mechanism should have some facility for enabling "canned 291 policy profiles". 293 In addition, the configuration facilities of various 294 components of the web infrastructure can be enhanced to 295 provide an appropriately simple veneer over the complexity. 297 3. Configurability: 299 With respect to configurability, development effort should be 300 applied to creating easy-to-use administrative interfaces 301 addressing the simple cases, like those mentioned above, while 302 providing advanced administrators the tools to craft and 303 manage fine-grained multi-faceted policies. Thus more casual 304 or novice administrators can be aided in readily choosing, or 305 be provided with, safe default policies while other classes of 306 sites have the tools to craft the detailed policies they 307 require. Examples of such an approach are Microsoft's 308 "Packaging Wizard" [41] that easily auto-generates a quite 309 complicated service deployment descriptor on behalf of less 310 experienced administrators, and Firefox's simple Preferences 311 dialog [42] as compared to its detailed about:config 312 configuration editor page [43]. In both cases, simple usage 313 by inexperienced users is anticipated and provided for on one 314 hand, while complex tuning of the myriad underlying 315 preferences is provided for on the other. 317 4. Usability: 319 Much has been learned over the last few years about what does 320 and does not work with respect to security indicators in web 321 browsers and web pages, as noted above, these lessons should 322 be applied to the security indicators rendered by new proposed 323 security mechanisms. We believe that in cases of user agents 324 venturing into insecure situations, their response should be 325 to fail the connections by default without user recourse, 326 rather than displaying warnings along with bypass mechanisms, 327 as is current practice. For example, the Strict Transport 328 Security specification [RFC6797] suggests the former so-called 329 "hard-fail" behavior. 331 5. Vulnerabilities, Attacks, and Threats 333 This section enumerates vulnerabilities and attacks of concern, and 334 then illustrates plausible threats that could result from 335 exploitation of the vulnerabilities. The intent is to illustrate 336 threats that ought to be mitigated by a web security policy 337 framework. 339 The definitions of vulnerability, attack, and threat used in this 340 document are based on the definitions from [RFC4949], and are 341 paraphrased here as: 343 Vulnerability: A flaw or weakness in a system's design, 344 implementation, or operation and management that 345 could be exploited. 347 Attack: An intentional act of vulnerability exploitation, 348 usually characterized by one or more of: the method 349 or technique used, and/or the point of initiation, 350 and/or the method of delivery, etc. For example: 351 active attack, passive attack, offline attack, 352 Cross-site Scripting (XSS) attack, SQL injection 353 attack, etc. 355 Threat: Any circumstance or event with the potential to 356 adversely affect a system and its user(s) through 357 unauthorized access, destruction, disclosure, or 358 modification of data, or denial of service. 360 See also Appendix B.1 Source: Attacks and Threats. 362 5.1. Attacks 364 These are some of the attacks which are desirable to mitigate via a 365 web application security framework (see [WASC-THREAT] for a more 366 complete taxonomy of attacks): 368 1. Cross-site-scripting (XSS) [2] [WASC-THREAT-XSS] 370 2. Cross-Site-Request Forgery (CSRF) [WASC-THREAT-CSRF] 372 3. Response Splitting [WASC-THREAT-RESP] 374 4. User Interface Redressing [UIRedress], aka Clickjacking 375 [Clickjacking]. 377 5. Man-in-the-middle (MITM) attacks against "secure" web 378 applications, i.e., ones accessed using TLS/SSL [RFC5246] 379 [WASC-THREAT-TLS] [SSLSTRIP]. 381 6. [[TODO2: more? (e.g. from [WASC-THREAT] ?) --JeffH]] 383 5.2. Threats 385 Via attacks exploiting the vulnerabilities above, an attacker can.. 387 1. Obtain a victim's confidential web application credentials (e.g., 388 via cookie theft), and use the credentials to impersonate the 389 victim and enter into transactions, often with the aim of 390 monetizing the transaction results to the attacker's benefit. 392 2. Insert themselves as a Man-in-the-Middle (MITM) between victim 393 and various services, thus is able to instigate, control, 394 intercept, and attempt to monetize various transactions and 395 interactions with web applications, to the benefit of the 396 attacker. 398 3. Enumerate various user agent information stores, e.g. browser 399 history, facilitating views of the otherwise confidential habits 400 of the victim. This information could possibly be used in 401 various offline attacks against the victim directly. E.g.: 402 blackmail, denial of services, law enforcement actions, etc. 404 4. Use gathered information and credentials to construct and present 405 a falsified persona of the victim (e.g. for character 406 assassination). 408 There is a risk of exfiltration of otherwise confidential victim 409 information with all the threats listed above. 411 6. Use Cases 413 This section outlines various example use cases. 415 1. I'm a web application site administrator. My web app includes 416 static user-supplied content (e.g. submitted from user agents via 417 HTML FORM + HTTP POST), but either my developers don't properly 418 sanitize user-supplied content in all cases or/and content 419 injection vulnerabilities exist or materialize (for various 420 reasons). 422 This leaves my web app vulnerable to cross-site scripting. I 423 wish I could set overall web app-wide policies that prevent user- 424 supplied content from injecting malicious content (e.g. 425 JavaScript) into my web app. 427 2. I'm a web application site administrator. My web application is 428 intended, and configured, to be uniformly served over HTTPS, but 429 my developers mistakenly keep including content via insecure 430 channels (e.g. via insecure HTTP; resulting in so-called "mixed 431 content"). 433 I wish I could set a policy for my web app that prevents user 434 agents from loading content insecurely even if my web app is 435 otherwise telling them to do so. 437 3. I'm a web application site administrator. My site has a policy 438 that we can only include content from certain trusted providers 439 (e.g., our CDN, Amazon S3), but my developers keep adding 440 dependencies on origins I don't trust. I wish I could set a 441 policy for my site that prevents my web app from accidentally 442 loading resources outside my whitelist. 444 4. I'm a web application site administrator. I want to ensure that 445 my web app is never framed by other web apps. 447 5. I'm a developer of a web application which will be included (i.e. 448 framed) by third parties within their own web apps. I would like 449 to ensure that my web app directs user agents to only load 450 resources from URIs I expect it to (possibly even down to 451 specific URI paths), without affecting the containing web app or 452 any other web apps it also includes. 454 6. I'm a web application site administrator. My web app frames 455 other web apps whose behavior, properties, and policies are not 456 100% known or predictable. 458 I need to be able to apply policies that both protect my web app 459 from potential vulnerabilities or attacks introduced by the 460 framed web apps, and that work to ensure that the desired 461 interactions between my web app and the framed apps are securely 462 realized. 464 7. [[TODO3: additional use cases to add? --JeffH]] 466 7. Detailed Functional Requirements 468 Many of the below functional requirements are extracted from a 469 discussion on the [public-web-security] mailing list (in early 2011). 470 Particular messages are cited inline and appropriate quotes extracted 471 and reproduced here. Inline citations are provided for definitions 472 of various terms. 474 The overall functional requirement categories are: 476 1. Policy mechanism scope 478 2. Policy expression syntax 480 3. Tooling 482 4. Performance 484 5. Granularity 486 6. Notifications and reporting 488 7. Facilitating Separation of Duties 490 8. Hierarchical Policy Application 492 9. Policy Delivery 494 10. Policy Conflict Resolution 496 [[TODO4: additional functional requirement categories to add? 497 --JeffH]] 499 These requirements are discussed in more detail below: 501 1. Policy mechanism scope and extensibility: 503 There is a current proliferation of orthogonal atomic 504 mechanisms intended to solve very specific problems. Web 505 developers have a hard enough time with security already 506 without being expected to master a potentially large number 507 of different security mechanisms, each with their own unique 508 threat model, implementation and syntax. Not to mention 509 trying to figure out how they're expected to interact with 510 each other; e.g., how to manage the gaps and intersections 511 between the models. 513 Thus the desire to have an extensible security policy 514 mechanism that could evolve as the web evolves, and the 515 threats that the web faces also evolve. For example, an 516 extensibility model similar to HTML where the security 517 protections could grown over time. 519 See also Appendix B.2 Source: Policy Expression Syntax [1]. 521 2. Policy expression syntax: 523 The policy expression syntax for a web security framework 524 should be declarative [DeclLang] (and extensible, as noted 525 above). This is for simplicity sake, as the alternative to 526 declarative is procedural/functional, e.g., the class of 527 language ECMAscript falls into. 529 See also Appendix B.2 Source: Policy Expression Syntax [1], 530 and, Appendix B.3 Source: Policy Expression Syntax [2]. 532 3. Tooling: 534 We will need tools to (idealy) analyze a web application and 535 generate an initial security policy. 537 See also Appendix B.4 Source: Tooling. 539 4. Performance: 541 Minimizing performance impact is a first-order concern. 543 See also Appendix B.5 Source: Performance. 545 5. Granularity: 547 For example, discriminate between: 549 + "inline" script in versus , or not. 551 + "inline" script and "src=" loaded script. 553 + Classes of "content", e.g. scriptable content, passive 554 multimedia, nested documents, etc. 556 See also Appendix B.6 Source: Granularity. 558 6. Notifications and Reporting: 560 Convey to the user agent an identifier (e.g. a URI) denoting 561 where to send policy violation reports. Could also specify a 562 DOM event to be dedicated for this purpose. 564 An ability to specify that a origin's policies are to be 565 enforced in a "report only" mode will be useful for debugging 566 policies as well as site-policy interactions. E.g. for 567 answering the question: "does my policy 'break' my site?". 569 See also Appendix B.7 Source: Notifications and Reporting. 571 7. Facilitating Separation of Duties: 573 Specifically, allowing for Web Site operations/deployment 574 personnel to apply site policy, rather then having it being 575 encoded in the site implementation code by side developers/ 576 implementors. 578 See also Appendix B.8 Source: Facilitating Separation of 579 Duties. 581 8. Hierarchical Policy Application: 583 The notion that policy emitted by the application's source 584 origin is able to constrain behavior and policies of 585 contained origins. 587 See also Appendix B.9 Source: Hierarchical Policy 588 Application. 590 9. Framing Policy Hierarchy, cross-origin, granularity, 591 auditability, roles: 593 [[TODO5: Need more fully coalesce the source info from 594 appendix into this item. --JeffH]] 596 + "Framing" is a client-side instance notion, where 597 webapp1's client-side instance (aka "document") loads 598 another webapp, "webapp2", into an HTML