From 321356f94ed7b7366ce641d75d16fece1541071e Mon Sep 17 00:00:00 2001 From: Wendy Seltzer Date: Tue, 29 Nov 2016 18:25:55 -0500 Subject: [PATCH] add an initial draft of Charter 2017 --- admin/webappsec-charter-2017.html | 464 ++++++++++++++++++++++++++++++ 1 file changed, 464 insertions(+) create mode 100644 admin/webappsec-charter-2017.html diff --git a/admin/webappsec-charter-2017.html b/admin/webappsec-charter-2017.html new file mode 100644 index 00000000..60f21ab6 --- /dev/null +++ b/admin/webappsec-charter-2017.html @@ -0,0 +1,464 @@ + + + + + + DRAFT 2017 Web Application Security Working Group + + + + + +
+ + +

W3C

+ +

DRAFT 2017 Web Application Security Working Group Charter

+ +

This is DRAFT PROPOSED CHARTER. Please send comments to public-webappsec@w3.org

+ +

The mission of the + Web Application Security Working Group is to develop security and policy mechanisms to improve the security of Web Applications, and enable + secure cross-origin communication.

+ +
+

Join the + Web Application Security Working Group.

+
+ + + + + + + + + + + + + + + + + +
End date31 December 2018
ConfidentialityProceedings are + public +
ChairsBrad Hill, Dan Veditz
Team Contacts
+ (FTE %: 10)		Wendy Seltzer
Usual Meeting ScheduleTeleconferences: Bi-Weekly +
+ Face-to-face: 1-2 annually +
+ +
+

Scope

+ +

Modern Web Applications are composed of many parts and + technologies. They may transclude, reference or have + information flows between resources at the same, related or + different origins. Due to the historically coarse-grained + nature of the security boundaries and principals defined for + such applications, they can be very difficult to secure.

+ +

In particular, application authors desire uniform policy + mechanisms to allow application components to drop + privileges and reduce the chance they will be exploited, or + that exploits will compromise other content, to isolate + themselves from vulnerabilities in content that might + otherwise be within the same security boundaries, and to + communicate securely across security boundaries. + + These issues are especially relevant for the many web + applications which incorporate other web application resources + (mashups). That is, they comprise multiple origins (i.e., + security principals).

+ +

Areas of scope for this working group include:

+ +
+ +
Attack Surface Reduction
+
+

The WG will design mechanisms to allow applications to: +

    +
  • Restrict or forbid potentially dangerous features which + they do not intend to use
    • +
  • Govern information and + content flows into and out of an application
    • +
  • Isolate themselves from other content which may contain + unrelated vulnerabilities
    • +
  • Sandbox potentially untrusted content and allow it to be + interacted with more safely
    • +
  • Uniquely identify application content such that unauthorized + modifications may be detected and prevented
    • +
+

+
+ +
Secure Mashups
+
+

Several mechanisms for secure resource + sharing and messaging across origins exist or are being specified, but + several common and desirable use cases are not covered by existing + work, such as: +

    +
  • Allowing child IFRAMEs to protect themselves from + "clickjacking"
    • +
  • Providing labeled information flows and confinement + propeties to enable secure mashups. This is especially + relevent for, e.g. applcations communicating between + security principals with + different user-granted permissions (e.g. geolocation)
    • +
+

+
+ +
Manageability
+
+

Given the ad-hoc nature in which many important security features + of the Web have evolved, providing uniformly secure experiences + to users is difficult for developers. The WG will document + and create uniform experiences for several undefined areas of + major utility, including: +

    +
  • Treatment of Mixed HTTPS/HTTP Content and defining + Secure/Authenticated Origins for purposes of user + experience, content inclusion/transclusion and other information flows, + and for features which require a verifiably secure + environment
    • +
  • Providing hinting and direct support for credential + managers, whether integrated into the user-agent or 3rd-party, + to assist users in managing the complexities of secure + passwords
    • +
  • Application awareness of features which may + require explicit user permission to enable.
    • +
+

+
+ +
+ +

In addition to developing Recommendation Track documents in support + of these goals, the Web Application Security Working Group may provide review of + specifications from other Working Groups, in particular as these + specifications touch on chartered deliverables of this group (in + particular CSP), or the Web security model, and may also develop + non-normative documents in support of Web security, such as + developer and user guides for its normative specifications.

+ +

Success Criteria

+ +

To advance to Proposed Recommendation, each specification is expected + to have two independent implementations of each feature described in the + specification.

+ +
+ +
+

Deliverables

+ +

All of the following deliverables are on or proposed for the Recommendation Track:

+ +
+
Content Security Policy Level 3
+
+

A policy language intended to enable web designers or server + administrators to declare a security policy for a web resource. + The goal of this specification is to reduce attack surface by + specifying overall rules for what content may or may not do, thus + preventing violation of security assumptions by attackers who are + able to partially manipulate that content. Content Security Policy + (CSP) Level 3 succeeds CSP2, which [is now in PR].

+

Draft state: Working Draft

+

Expected completion: [Q1–4 yyyy]

+
+
+ +
+
User Interface Security and the Visibility API
+
+

Create and advance existing recommendations specifying bi- + directional parent/child policies to enable secure mash-up + applications built around cross-domain framing. To express necessary + constraints and demands, this deliverable will re-use and extend the + policy language of the Content Security Policy deliverable with the + goal of creating uniform semantics for requirements currently + disjoint in expression and implementation across the CSP, the HTML5 + IFRAME sandbox, and the X-Frame-Options HTTP header. This work will + be closely coordinated with the IETF websec WG in order to avoid + overlapping or conflicting specifications.

+

Draft state: Working Draft

+

Expected completion: [Q1-4 yyyy]

+
+
+
+ Mixed Content (CR)
+ +

A recommendation for dealing with + resources loaded over insecure channels in a secure web application. + Use cases includes standard behaviors for user agents to follow when encountering + insecure resource loads in a secure context. This might include + definitions of “active” and “passive” content that must be blocked + or can be loaded with a warning, and possibly ways for secure + applications to consume insecure but non-sensitive resources (such + as a weather feed). + + +

Draft state: Candidate Recommendation

+

Expected completion: [Q1-4 yyyy]

+
+
+
Upgrade Insecure Requests
+
+

Create a mechaimsm to assist in sites migrating from HTTP + to HTTPS by allowing them to assert to a user agent that they + intend a site to load only secure resources, and that insecure + URLs ought to be treated as though they had been replaced with + secure URLs. +

+

Draft state: Candidate Recommendation

+

Expected completion: [Q1-4 yyyy]

+ +
+ + +
+ Secure + Contexts
+ +

A recommendation defining "secure contexts", thereby + allowing user agent implementers and specification authors to + enable certain features only when certain minimum standards of + authentication and confidentiality are met. +

+

Draft state: Candidate Recommendation

+

Expected completion: [Q1-4 yyyy]

+
+
+
+ Referrer Policy +
+ +

A recommendation for a header and meta tag allowing + resource authors to specify a policy for the values sent + as part of the HTTP Referer (sic) header. Use cases + include making this policy more restrictive to protect + applications which include security capability tokens in + the URL, or allowing more permissive sharing of referrer + information from secure to insecure origins to remove + barriers which today prevent applications from moving to + secure origins.

+

Draft state: Working Draft

+

Expected completion: [Q1-4 yyyy]

+
+
+ +
Credential Management API
+ +
+

Create and advance recommendation(s) for a standardized + API to address use cases related to assisted management + of user credentials, including traditional + username/password pairs, username/federated identity + provider pairs. The API should allow for explicit and + interoperable imperative mechanism for use and lifecycle + management of these common credential types.

+
+ +
Suborigin Namespaces
+ +
+

Create and advance a recommendation to allow applications + to place themselves into namespaces within a traditional + scheme/host/port RFC 6454 Origin label to enable easier + development of modular applications with privilege + separation.

+
+ +
Confinement with Origin Web Labels
+ +
+

Create and advance a recommendation for a robust JavaScript + confinement system for modern web browsers, in a way that is + backward-compatible with legacy web content. The goal of the + specification is to define APIs for specifying privacy and + integrity policies on data, in the form of origin labels, and + a mechanism for confining browsing contexts (pages, iframes, + etc.) according to these labels. This would allow Web + application authors and server operators to share data with + untrusted code (e.g., in a mashup scenario, cross-origin + iframes) yet impose restrictions on how the code can further + share the sensitive data.

+ +

An additional goal is to define a light-weight, in-thread + Web Worker. This would allow developers to build + privilege-separated, compartmentalized applications, in + addition to sandboxing potentially untrusted scripts.

+
+ + +
Permissions API
+ +
+

Create and advance a recommendation to allow web + applications to be aware of the status of a given permission, + to know whether it is granted, denied, or if the user will be + asked whether the permission should be granted. This + recommendation will not address user agent implementations of + permissions, including their scope, duration, granularity, or + user interface and experience for indicating, configuring, or + asking for permissions.

+
+
+

@@@

+ +

Milestones

+ + + +
+

Dependencies and Liaisons

+ + + + +

W3C Groups

+ +
+
HTML Working Group
+
The HTML + specification defines many of the security policies that + apply in the current browser environment, and Subresource Integrity + defines new attributes that may be applied to HTML tags.
+
Privacy Interest Group
+
The WG may ask the Privacy Interest Group to review some of its specifications for privacy considerations.
+
Web Security Interest Group
+
The WG may ask the Web Security Interest Group review some of its specifications for security considerations.
+
Technical Architecture Group + (TAG)
+
The WG may ask the Technical Architecture Group to + review some of its specifications.
+
Protocols and Formats Working Group
+
The WG may ask the PFWG to review some of its specifications for potential accessibility issues.
+
Web Platform WG
+
The WG may coordinate with Web Platform WG around API design.
+
+ +

Outside Groups

+
Web Hypertext Application Technology Working Group (WHATWG)
+
Specifications such as CSP provide inputs into the algorithms defined by, e.g. the + Fetch specification and portions of CSP and Mixed Content may be defined in terms of + Fetch.
+ + +
+ +
+

Participation

+ + + +

To be successful, the Web Application Security Working Group is + expected to have 10 active participants for its duration. Effective + participation to Web Application Security Working Group is expected to + consume one day per week for chairs and editors. The Web Application + Security Working Group will allocate also the necessary resources for + building Test Suites for each specification.

+ + + + +
+ +
+

Communication

+ + +

This group primarily conducts its work on the public + mailing list public-webappsec@w3.org (archive). +

+ + + + +

Information about the group (deliverables, participants, + face-to-face + meetings, teleconferences, etc.) is + available from the Web Application Security Working Group home + page.

+
+ +
+

Decision Policy

+ +

As explained in the Process Document + (section 3.3), this group will seek to make + decisions when there is consensus. When the Chair puts a + question and observes dissent, after due consideration of + different opinions, the Chairs should put a question out for + voting within the group (allowing for remote asynchronous + participation -- using, for example, email and/or web-based + survey techniques) and record a decision, along with any + objections. The matter should then be considered resolved unless + and until new information becomes available.

+ +

Any resolution first taken in a + face-to-face meeting or teleconference [i.e., + that does not follow a 7 day call for + consensus on the mailing list] is to be + considered provisional until 5 working days + after the publication of the resolution in + draft minutes, available from the WG's + calendar or home page. If no objections are + raised on the mailing list within that time, + the resolution will be considered to have + consensus as a resolution of the Working + Group.

+ +
+ +
+

Patent Policy

+ + +

This Working Group operates under + the W3C Patent Policy (5 February 2004 + Version). To promote the widest adoption of Web standards, W3C + seeks to issue Recommendations that can be implemented, + according to this policy, on a Royalty-Free basis.

+ + +

For more information about disclosure obligations for + this group, please see the W3C + Patent Policy Implementation.

+ +
+ + + +

About this Charter

+ +

This charter for the Web Application Security Working Group has been created according to + section + 6.2 of the Process + Document. In the event of a + conflict between this document or the provisions of any charter + and the W3C Process, the W3C Process shall take precedence.

+ +

Please also see the previous charter for this group.

+
+ +
+ Brad Hill, Dan Veditz, Wendy Seltzer <wseltzer@w3.org> +
+ +

Copyright© + 2015 W3C + ® (MIT, + ERCIM, Keio, Beihang), All Rights + Reserved.

+