In addition to developing Recommendation Track documents in @@ -321,7 +324,19 @@
Draft state: Editor's Draft
- + ++ 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
+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
@@ -491,9 +510,20 @@Draft state: Adopted from WICG
+ 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:
+ Depending on the incubation progress, including interest from multiple implementers, the + Group may also produce Recommendation-track specifications for the following documents: +
++ This idea would allow end-to-end encryption of emails, without exposing key content, + in Web applications. +
+Exclusion Draft: 15 December 2015
Other Charter: 2015 charter
+ 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). +
++ 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: @@ -579,18 +650,6 @@
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 @@ -613,6 +672,10 @@
+ All new features should be supported by at least two intents to implement before being + incorporated in the specification. +
allow-unique-origin.
+ - 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.