Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tpac2023 charter comments #635

Merged
merged 11 commits into from
Oct 18, 2023
Merged

Tpac2023 charter comments #635

Changes from 9 commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
98cad74
WebCrypto curve25519 (Daniel)
plehegar Sep 19, 2023
0d87d55
(REC-track) .well-known URL for passkeys (Tim)
plehegar Sep 19, 2023
b11bf69
Registry. (RIP)
plehegar Sep 19, 2023
375c589
(REC-track) Request-OTR (Shivan)
plehegar Sep 19, 2023
b3128f6
(from incubation) PEPC (Andy and Balazs), "Unique" Origin, e2e email,…
plehegar Sep 19, 2023
a25ef4d
(Note) Cookie NOTE (Artur and Johann), Permissions best practice NOTE
plehegar Sep 19, 2023
c26cdba
Switch the charter to living CR
plehegar Sep 19, 2023
8bd9b27
Updated WHATWG coordination, Add IETF HTTP coordination
plehegar Sep 19, 2023
7143a2d
Sync with https://github.com/w3c/charter-drafts/commit/e78c83e1f417ba…
plehegar Sep 19, 2023
35eab4b
Move PEPC, "Unique" Origin out of deliverables and into the liaison s…
plehegar Sep 21, 2023
275d8b3
(from incubation) securer context
plehegar Sep 21, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
141 changes: 107 additions & 34 deletions admin/webappsec-charter-2023.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -247,7 +247,10 @@ <h2>Scope</h2>
side-channel attacks).</p>
</dd>
<dt><b>WebCrypto</b></dt>
<dd>The WG may adopt well-supported proposals from incubation for maintenance of the <a href="https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/">Web Cryptography API</a>.</dd>
<dd>The WG may adopt well-supported proposals from incubation for maintenance
of the <a href="https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/">Web
Cryptography API</a>, such as
<a href='https://wicg.github.io/webcrypto-secure-curves/'>secure curves</a>.</dd>
</dl>

<p>In addition to developing Recommendation Track documents in
Expand Down Expand Up @@ -321,7 +324,19 @@ <h3>

<p class="draft-status"><b>Draft state:</b> <a href="https://w3c.github.io/webappsec-change-password-url/">Editor's Draft</a></p>
</dd>


<dt id="passkey-url" class="spec"><a href="https://github.com/ms-id-standards/MSIdentityStandardsExplainers/blob/main/PasskeyEndpointsWellKnownUrl/explainer.md">Passkey Endpoints Well-Known URL</a></dt>

<dd>
<p>
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.
</p>
<p class="draft-status"><b>Draft state:</b>
<a href="https://github.com/ms-id-standards/MSIdentityStandardsExplainers/blob/main/PasskeyEndpointsWellKnownUrl/explainer.md">Explainer</a></p>
</dd>

<dt id="trusted-types" class="spec"><a href="https://w3c.github.io/webappsec-trusted-types/dist/spec/">Trusted Types</a></dt>

<dd>
Expand Down Expand Up @@ -462,12 +477,16 @@ <h3>
<dt class="spec"><a href="https://www.w3.org/TR/permissions/">Permissions API</a></dt>

<dd>
<p>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.</p>

<p>
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.
</p>
<p>
This document will also serve as the registry of permissions of the web
platform, which includes both policy-controlled features and powerful
features.
</p>
<p class="draft-status"><b>Draft state:</b> <a href="https://www.w3.org/TR/2020/WD-permissions-20200720/">Working Draft</a></p>
<p><b>Expected publication as a Candidate Recommendation:</b> No later than Q2 2022</p>
<p><b>Exclusion Draft:</b> <a href="https://www.w3.org/TR/2015/WD-permissions-20150407/">7 April 2015</a></p>
Expand All @@ -491,9 +510,20 @@ <h3>
</p>
<p class="draft-status"><b>Draft state:</b> Adopted from WICG</p>
</dd>


</dl>
<dt class="spec"><a href='https://datatracker.ietf.org/doc/draft-sahib-httpbis-off-the-record/'>Off-The-Record Response Header Field</a></dt>

<dd>
<p>
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.
</p>
<p class="draft-status"><b>Draft state:</b> <a href='https://datatracker.ietf.org/doc/draft-sahib-httpbis-off-the-record/'>IETF Internet-Draft</a></p>
</dd>

</dl>
<p>The Working Group will also maintain:</p>
<dl>
<dt class="spec"><a href="https://www.w3.org/TR/SRI/">Subresource Integrity</a></dt>
Expand Down Expand Up @@ -521,6 +551,41 @@ <h3>
</dl>
-->

<p>
Depending on the incubation progress, including interest from multiple implementers, the
Group may also produce Recommendation-track specifications for the following documents:
</p>
<dl>
<dt class="spec"><a href="https://github.com/WICG/PEPC/blob/main/explainer.md">Page Embedded Permission Control (PEPC)</a></dt>
<dd>
<p>
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.
</p>
</dd>
<dt class="spec"><a href="https://github.com/shhnjk/allow-unique-origin">Sandbox <code>allow-unique-origin</code></a></dt>
<dd>
<p>
A Web Platform API proposal to improve sandboxing and Blob URL.
</p>
</dd>
<dt class="spec"><a href="https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-09-14-TPAC-minutes.md#end-to-end-encryption">End-to-End Encryption email</a></dt>
<dd>
<p>
This idea would allow end-to-end encryption of emails, without exposing key content,
in Web applications.
</p>
</dd>
<dt class="spec"><a href="https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-09-15-TPAC-minutes.md#source-code-transparency-sketch">Source Code Transparency</a></dt>
<dd>
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.
</dd>

</dl>

</section>

<section id="ig-other-deliverables">
Expand Down Expand Up @@ -550,7 +615,21 @@ <h3>
<p><b>Exclusion Draft:</b> <a href="https://www.w3.org/TR/2015/WD-csp-embedded-enforcement-20151215/">15 December 2015</a>
<p><b>Other Charter:</b> <a href="https://www.w3.org/2015/03/webappsec-charter-2015.html">2015 charter</a></p>
</dd>

<dt>Security and privacy model for cookies</dt>
<dd>
<p>
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).
</p>
</dd>
<dt>Permissions best practices</dt>
<dd>
<p>
A Group Note to outline some of the best practices when requesting permissions
from users and adding new permission prompts to the Web platform.
</p>
</dd>
</dl>
<p>
Other non-normative documents may be created such as:
Expand Down Expand Up @@ -579,18 +658,6 @@ <h3>Timeline</h3>
<section id="success-criteria">
<h2>Success Criteria</h2>

<!-- Testing and interop -->
<p>In order to advance to <a href="https://www.w3.org/Consortium/Process/#RecsCR" title="Candidate Recommendation">Candidate Recommendation</a> 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. </p>

<p>
In order to advance to
<a href="https://www.w3.org/Consortium/Process/#RecsPR" title="Proposed Recommendation">Proposed Recommendation</a>, each normative specification is expected to have
<a href="https://www.w3.org/Consortium/Process/#implementation-experience">at least two independent interoperable
implementations</a> 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.</p>
<p>There should be testing plans for each specification, starting from the earliest drafts.</p>
<p>
To promote interoperability, all changes made to specifications
Expand All @@ -613,6 +680,10 @@ <h2>Success Criteria</h2>
TAG <a href="https://www.w3.org/TR/design-principles/">Web Platform Design Principles</a>.
</p>

<p>
All new features should be supported by at least two intents to implement before being
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:(

incorporated in the specification.
</p>
</section>

<section id="coordination">
Expand Down Expand Up @@ -646,15 +717,17 @@ <h3 id="external-coordination">External Organizations</h3>
<dl>
<dt><a href="https://whatwg.org/">Web Hypertext Application Technology Working Group
(WHATWG)</a></dt>

<dd>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 <a href="https://www.w3.org/2013/09/normative-references">normative
references policy</a>. </dd>
<dd>
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.
</dd>
<dt><a title="IETF Home Page" href="https://www.ietf.org/" id="ietf">Internet Engineering Task Force</a></dt>
<dd>
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.
</dd>
</dl>
</section>
</section>
Expand Down Expand Up @@ -720,7 +793,7 @@ <h2>
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.
</p>
<p>
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.
</p>
<p>
This charter is written in accordance with the <a href="https://www.w3.org/Consortium/Process/#Votes">W3C Process Document (Section 5.2.3, Deciding by Vote)</a> and includes no voting procedures beyond what the Process Document requires.
Expand Down