Skip to content

Commit

Permalink
Tpac2023 charter comments (#635)
Browse files Browse the repository at this point in the history 
* WebCrypto curve25519 (Daniel)

* (REC-track) .well-known URL for passkeys (Tim)

* Registry. (RIP)

* (REC-track) Request-OTR (Shivan)

* (from incubation) PEPC (Andy and Balazs), "Unique" Origin, e2e email, Source Code Transparency

* (Note) Cookie NOTE (Artur and Johann), Permissions best practice NOTE

* Switch the charter to living CR

* Updated WHATWG coordination, Add IETF HTTP coordination

* Sync with w3c/charter-drafts@e78c83e

* Move PEPC, "Unique" Origin out of deliverables and into the liaison section with WHATWG

* (from incubation) securer context
  • Loading branch information
@plehegar
plehegar authored Oct 18, 2023
1 parent 1aef6eb commit ca76688
Showing 1 changed file with 101 additions and 34 deletions.
135 changes: 101 additions & 34 deletions admin/webappsec-charter-2023.html
View file
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,33 @@ <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/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>
<dt><a href="https://github.com/mikewest/securer-contexts">Securer Contexts</a></dt>
<dd>
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.
</dd>
</dl>

</section>

<section id="ig-other-deliverables">
Expand Down Expand Up @@ -550,7 +607,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 +650,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 +672,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
incorporated in the specification.
</p>
</section>

<section id="coordination">
Expand Down Expand Up @@ -646,15 +709,19 @@ <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. The Working Group should also pay attention to work, such as <a
href="https://github.com/WICG/PEPC/blob/main/explainer.md">Page Embedded Permission Control (PEPC)</a>
and <a href="https://github.com/shhnjk/allow-unique-origin">Sandbox <code>allow-unique-origin</code></a>.
</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 +787,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

0 comments on commit ca76688

Please sign in to comment.