From 98cad746de1b322de8bbb3dba51b53a4952ba340 Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 19 Sep 2023 16:06:36 -0400 Subject: [PATCH 01/11] WebCrypto curve25519 (Daniel) --- admin/webappsec-charter-2023.html | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index c845be36..61352039 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -247,7 +247,10 @@

Scope

side-channel attacks).

WebCrypto
-
The WG may adopt well-supported proposals from incubation for maintenance of the Web Cryptography API.
+
The WG may adopt well-supported proposals from incubation for maintenance + of the Web + Cryptography API, such as + secure curves.

In addition to developing Recommendation Track documents in From 0d87d5548ea6bb856ca92c0879cf2ac68cbea75f Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 19 Sep 2023 16:07:17 -0400 Subject: [PATCH 02/11] (REC-track) .well-known URL for passkeys (Tim) --- admin/webappsec-charter-2023.html | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index 61352039..5a817d4a 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -324,7 +324,19 @@

Draft state: Editor's Draft

- + +
Passkey Endpoints Well-Known URL
+ +
+

+ Similar to the well-known URLs for changing passwords, + this proposes a well-known URL that sites can use to make + their passkeys, the FIDO2 and WebAuthn credentials, discoverable by tools. +

+

Draft state: + Explainer

+
+
Trusted Types
From b11bf691dc7b4a2db14da7da05f050991a934733 Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 19 Sep 2023 16:08:02 -0400 Subject: [PATCH 03/11] Registry. (RIP) --- admin/webappsec-charter-2023.html | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index 5a817d4a..96016d24 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -477,12 +477,16 @@

Permissions API
-

An API 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.

- +

+ An API 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 document will also serve as the registry of permissions of the web + platform, which includes both policy-controlled features and powerful + features. +

Draft state: Working Draft

Expected publication as a Candidate Recommendation: No later than Q2 2022

Exclusion Draft: 7 April 2015

From 375c589aef3dd248e0460a3588cddeb424e912a3 Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 19 Sep 2023 16:08:39 -0400 Subject: [PATCH 04/11] (REC-track) Request-OTR (Shivan) --- admin/webappsec-charter-2023.html | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index 96016d24..6d521b54 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -510,9 +510,20 @@

Draft state: Adopted from WICG

- - - +
Off-The-Record Response Header Field
+ +
+

+ This document specifies an HTTP response header field that enables a + server to inform the client that the requested website should be + treated as "off-the-record." The purpose is to indicate that the + server considers the content sensitive in some way, and the client + may choose not to retain any record of accessing it. +

+

Draft state: IETF Internet-Draft

+
+ +

The Working Group will also maintain:

Subresource Integrity
From b3128f6ca7458ee0d0c66919ceb2f93c941e1923 Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 19 Sep 2023 16:10:29 -0400 Subject: [PATCH 05/11] (from incubation) PEPC (Andy and Balazs), "Unique" Origin, e2e email, Source Code Transparency --- admin/webappsec-charter-2023.html | 35 +++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index 6d521b54..44ace01f 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -551,6 +551,41 @@

--> +

+ Depending on the incubation progress, including interest from multiple implementers, the + Group may also produce Recommendation-track specifications for the following documents: +

+
+
Page Embedded Permission Control (PEPC)
+
+

+ This proposes adding a new HTML element to the web platform which will be used to provide + an in-content entry point to permission requests. +

+
+
Sandbox allow-unique-origin
+
+

+ A Web Platform API proposal to improve sandboxing and Blob URL. +

+
+
End-to-End Encryption email
+
+

+ This idea would allow end-to-end encryption of emails, without exposing key content, + in Web applications. +

+
+
Source Code Transparency
+
+ The goal would be to have a mechanism to verify that the source code of a web app + appears in some transparency log (similar to Certificate Transparency), to allow + auditors to check the source code, and make it impossible to surreptitiously serve + a malicious version of a web app to one user, for example. +
+ +
+
From a25ef4d7912c77334d6c04aa328d2db5e4e98c7e Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 19 Sep 2023 16:11:38 -0400 Subject: [PATCH 06/11] (Note) Cookie NOTE (Artur and Johann), Permissions best practice NOTE --- admin/webappsec-charter-2023.html | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index 44ace01f..0c7622df 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -615,7 +615,21 @@

Exclusion Draft: 15 December 2015

Other Charter: 2015 charter

- +
Security and privacy model for cookies
+
+

+ A Group Note to outline the desired security and privacy model for cookies post third-party + cookie deprecation, including cookie behaviors by default and mechanisms for reenabling + them in third-party contexts (SAA, user controls, etc). +

+
+
Permissions best practices
+
+

+ A Group Note to outline some of the best practices when requesting permissions + from users and adding new permission prompts to the Web platform. +

+

Other non-normative documents may be created such as: From c26cdba0e73cff7afb8aab3e624e566e3589501d Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 19 Sep 2023 16:12:28 -0400 Subject: [PATCH 07/11] Switch the charter to living CR --- admin/webappsec-charter-2023.html | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index 0c7622df..caa20fc9 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -658,18 +658,6 @@

Timeline

Success Criteria

- -

In order to advance to Candidate Recommendation and to add features after reaching Candidate Recommendation, each feature is expected to be supported by at least two implementations, which may be judged by factors including existing implementations, expressions of interest, and lack of opposition.

- -

- In order to advance to - Proposed Recommendation, each normative specification is expected to have - at least two independent interoperable - implementations of every feature defined in the specification, where -interoperability can be verified by passing open test suites, and two or -more implementations interoperating with each other. In order to advance to -Proposed Recommendation, each normative specification must have an open -test suite of every feature defined in the specification.

There should be testing plans for each specification, starting from the earliest drafts.

To promote interoperability, all changes made to specifications @@ -692,6 +680,10 @@

Success Criteria

TAG Web Platform Design Principles.

+

+ All new features should be supported by at least two intents to implement before being + incorporated in the specification. +

From 8bd9b2744d3203a18f5afd89dd1115cf5b69ad14 Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 19 Sep 2023 16:13:28 -0400 Subject: [PATCH 08/11] Updated WHATWG coordination, Add IETF HTTP coordination --- admin/webappsec-charter-2023.html | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index caa20fc9..72213621 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -717,15 +717,17 @@

External Organizations

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. WebAppSec will work with WHATWG Fetch to - ensure that CSP's normative dependencies on Fetch - satisfy the - W3C normative - references policy.
+
+ 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. +
+
Internet Engineering Task Force
+
+ The IETF is responsible for defining robust and secure protocols for Internet + functionality, in particular HTTP. The Working Group should coordinate + protocol-related work (e.g. cookies) with the appropriate IETF WGs. +
From 7143a2d6b68a06985f60fc7490db319e186be0f4 Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 19 Sep 2023 16:14:18 -0400 Subject: [PATCH 09/11] Sync with https://github.com/w3c/charter-drafts/commit/e78c83e1f417baba5e436a68a919a8ba6381513b --- admin/webappsec-charter-2023.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index 72213621..1eacc4a8 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -793,7 +793,7 @@

If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

- All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director. + All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs.

This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the Process Document requires. From 35eab4b4f354753b51a0f09c3fd31395e7b5be6c Mon Sep 17 00:00:00 2001 From: plehegar Date: Thu, 21 Sep 2023 11:23:17 -0400 Subject: [PATCH 10/11] Move PEPC, "Unique" Origin out of deliverables and into the liaison section with WHATWG --- admin/webappsec-charter-2023.html | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index 1eacc4a8..39b7fab1 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -556,19 +556,6 @@

Group may also produce Recommendation-track specifications for the following documents:

-
Page Embedded Permission Control (PEPC)
-
-

- This proposes adding a new HTML element to the web platform which will be used to provide - an in-content entry point to permission requests. -

-
-
Sandbox allow-unique-origin
-
-

- A Web Platform API proposal to improve sandboxing and Blob URL. -

-
End-to-End Encryption email

@@ -720,7 +707,9 @@

External Organizations

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. + Fetch. The Working Group should also pay attention to work, such as Page Embedded Permission Control (PEPC) + and Sandbox allow-unique-origin.
Internet Engineering Task Force
From 275d8b34182b78c216774a6d1891ddb48b9558fc Mon Sep 17 00:00:00 2001 From: plehegar Date: Thu, 21 Sep 2023 11:26:30 -0400 Subject: [PATCH 11/11] (from incubation) securer context --- admin/webappsec-charter-2023.html | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/admin/webappsec-charter-2023.html b/admin/webappsec-charter-2023.html index 39b7fab1..31952dee 100644 --- a/admin/webappsec-charter-2023.html +++ b/admin/webappsec-charter-2023.html @@ -570,7 +570,12 @@

auditors to check the source code, and make it impossible to surreptitiously serve a malicious version of a web app to one user, for example.

- +
Securer Contexts
+
+ Securer context is a proposal to extend the thread model beyond encrypting + the transport layer, and bring attention to application layer threats that + rely on either injection or insufficient isolation. +