diff --git a/2023/did-wg.html b/2023/did-wg.html index 952a4f05..7812121e 100644 --- a/2023/did-wg.html +++ b/2023/did-wg.html @@ -80,7 +80,7 @@

PROPOSED Decentralized Identifier Working Gro Decentralized Identifier Working Group is two-fold. First, it will maintain the Decentralized Identifiers (DIDs) specification and related Working Group Notes. -Second, it will define common requirements, algorithms, architectural options, and various considerations for the DID resolution and DID URL dereferencing processes. +Second, it will seek consensus around the best way to achieve effective interoperability through common requirements, algorithms, architectural options, and various considerations for the DID resolution and DID URL dereferencing processes.

@@ -116,7 +116,7 @@

PROPOSED Decentralized Identifier Working Gro Chairs - TBD + Daniel Burnett (Invited Expert), Gabe Cohen (Block, Inc) diff --git a/2024/btt-wg.html b/2024/btt-wg.html index dd6402d2..9357511a 100644 --- a/2024/btt-wg.html +++ b/2024/btt-wg.html @@ -182,14 +182,21 @@

WebDriver

WebDriver is a remote control interface that enables introspection and control of user agents. It provides a platform- and language-neutral wire protocol as a way for out-of-process programs to remotely instruct the behavior of web browsers.

+

Draft state: Working Draft.

+

Adopted Draft: WebDriver, https://www.w3.org/TR/2019/WD-webdriver2-20190912/, 12 September 2019. +

Exclusion Draft: WebDriver, https://www.w3.org/TR/2019/WD-webdriver2-20190912/, 12 September 2019.
+ Exclusion Draft began on 12 September 2019, and ended on 11 February 2020. +

Exclusion Draft Charter: https://www.w3.org/2018/12/browser-testing-tools.html

WebDriver Bidirectional Protocol

The WebDriver Bidirectional Protocol extends WebDriver by introducing a bidirectional communication mechanism; in place of the strict command/response format of WebDriver, that bidirectional communication mechanism permits events to stream from the user agent to the controlling software, better matching the evented nature of the browser DOM.

+

Draft state: Editor's Draft

AT Driver

AT Driver defines a protocol for introspection and remote control of assistive technology (AT) such as screen readers, using a bidirectional communication channel.

+

Draft state: Editor's Draft

@@ -213,7 +220,6 @@

Success Criteria

-

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.

To promote interoperability, all changes made to specifications in Candidate Recommendation or to features that have deployed implementations will have tests. Testing efforts will be conducted via the Web Platform Tests project.

@@ -248,6 +254,18 @@

W3C Groups

+
+

External Organizations

+
+
Web Platform Tests project
+
Coordination on mechanisms for automating tests that cannot be written purely using web-platform APIs.
+
+
+
WHATWG
+
Coordination on the Test Utils specification, which defines a set of APIs for use in tests but not suitable to enable for end users — and the primary client for which is the Web Platform Tests project’s web-platform-tests testsuite.
+
+
+

Participation @@ -262,7 +280,7 @@

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the - W3C Code of Ethics and Professional Conduct.

+ W3C Code of Conduct.

@@ -491,7 +509,6 @@

2023‑08‑10 WebDriver BiDi deliverable added.
- AT Driver deliverable added.
New Patent Policy 2020. @@ -520,7 +537,7 @@

2026-nn-nn - No changes in scope or deliverables. + AT Driver deliverable added. diff --git a/2024/ig-exploration.html b/2024/ig-exploration.html new file mode 100644 index 00000000..3cf9a742 --- /dev/null +++ b/2024/ig-exploration.html @@ -0,0 +1,477 @@ + + + + + + Exploration Interest Group Charter + + + + + + + + + + +
+

DRAFT Exploration Interest Group Charter

+ + +

The mission of the Exploration Interest Group is to [do something cool and specific on the Web].

+ + +

+ There are arguments to make it a Community Group instead of an Interest Group. + Feedback would be welcome. +

+ + + + +

This draft charter is available + on GitHub. + + Feel free to raise issues. +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Charter Status + + See the group status page and detailed change history. +
+ Start date + + [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) +
+ End date + + [dd monthname yyyy] (Start date + 2 years) +
+ Chairs + + [chair name] (affiliation) +
+ Team Contacts + + [team contact name] (0.1 FTE) +
+ Meeting Schedule + + Teleconferences: topic-specific calls may be held or something else +
+ Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year. +
+
+ +
+

Motivation and Background

+

+ This Group is intended to address several use cases: +

+
    +
  • New ideas and dimensions: a new human step may impact + the Web, e.g., "autonomous L4/L5 cars", "one continent + forking the technology stack of the Internet and the Web", + "sustainable blockchain", "6G Networks";
  • +
  • New people: a welcoming point for Members/people who are unfamiliar + with our processes and systems, to understand the organization;
  • +
  • New workshops: a relevant topic needs alignment around the + next steps for W3C, e.g., "generative AI", "Digital Identity on + the Web";
  • +
  • Monitoring industry trends: monitor other SDOs by leveraging the + knowledge of W3C Members and enrolling them to monitor outside + organizations, and report back on regular basis;
  • +
  • Publishing Report: Create public analyses of trends that affect + the Web, seeking rough consensus or presentation of + competing perspectives. The analyses would summarize + the trending topic, outline the promise and pitfalls that are + being discussed, point to relevant W3C efforts, and indicate + the degree of consensus in the group on the value of the topic + for the Web;
  • +
  • Chartering: there is a charter but we need to measure the interest + from the W3C community at large and make it fit in the larger + picture, e.g., Real Estate IG.
  • +
+
+ +
+

Scope

+

+ The goal of Exploration Interest Group provides a platform to help + the W3C community explore emerging Web-related technology trends, + consider how the community could collaborate to shape these trends + for the benefit of the Web users, accelerate chartering investigations + and endeavors, and continually strengthen the innovation of W3C. +

+
    +
  • + Work with W3C Members and the W3C Team to propose, prioritize, and + assist in organizing Workshops or other events. Topics may come + from discussions within CGs, TPAC Breakout Sessions, Workshops + and Liaison Reports, etc. +
  • +
  • + Work with W3C Members and W3C Team to prioritize potential + work areas, to facilitate creation of Community Groups, to + coordinate among Community Groups, and to advise on how to + transition work from CG to WG; +
  • +
  • + Work with W3C Members and the W3C Team to monitor W3C Liaisons, + invite insightful SDOs experts, and provide a platform to report + back on potential areas of investigations; +
  • +
  • + Discuss how to continue improving the exploration and + investigation process, and propose improvements to the W3C Advisory Board and the + W3C Team. +
  • +
+
+ +

+ +
+

+ Deliverables +

+ +

Updated document status is available on the group publication status page. [or link to a page this group prefers to use]

+ +

+ Non-normative documents may be created such as reports on + exploration and investigations. +

+
+ +
+

Success Criteria

+ +

How do we measure success ?

+ +
+ +
+

Coordination

+ +

+ This Group is expected to coordinate with any relevant group... +

+ +
+

W3C Groups

+
+
[other name] Working Group
+
[specific nature of liaison]
+
+ +

Note: Do not list horizontal groups here, only specific WGs relevant to your work.

+

Note: Do not bury normative text inside the liaison section. + Instead, put it in the scope section.

+
+ +
+

External Organizations

+
+
[other name] Working Group
+
[specific nature of liaison]
+
+
+
+ + + +
+

+ Participation +

+

+ To be successful, this Interest Group is expected to have 6 or + more active participants for its duration. The Chairs + are expected to contribute a quarter of a working day per week + towards the Interest Group. There is no minimum requirement for + other Participants. +

+

+ The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication. +

+

+ The group also welcomes non-Members to contribute through its public communication channels. +

+

Participants in the group are required (by the W3C Process) to follow the + W3C Code of Conduct.

+
+ +
+

+ Communication +

+

+ Technical discussions for this Interest Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. (Does the IG plan to write EDs and WDs?) + The meetings themselves are not open to public participation, however. +

+

+ Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Exploration Interest Group home page. +

+

+ Most Exploration Interest Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis. +

+

+ This group primarily conducts its technical work pick one, or both, as appropriate: on the public mailing list public-[email-list]@w3.org (archive) + or on GitHub issues. + The public is invited to review, discuss and contribute to this work. +

+

+ The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion. +

+
+ + + +
+

+ Decision Policy +

+

+ This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

+

+ However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections. +

+

+ To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. + + A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from [pick a duration within:] one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. + + 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 Interest 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. +

+

+ 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. +

+
+ + + +
+

Patent Disclosures

+

The Interest Group provides an opportunity to + share perspectives on the topic addressed by this charter. W3C reminds + Interest Group participants of their obligation to comply with patent + disclosure obligations as set out in Section + 6 of the W3C Patent Policy. While the Interest Group does not + produce Recommendation-track documents, when Interest Group + participants review Recommendation-track specifications from Working + Groups, the patent disclosure obligations do apply. For more information about disclosure obligations for this group, + please see the licensing information.

+
+ + + +
+

Licensing

+

This Interest Group will use the W3C Software and Document license for all its deliverables.

+
+ + + +
+

+ About this Charter +

+

+ This charter has been created according to section 3.4 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. +

+ +
+

+ Charter History +

+

Note:Display this table and update it when appropriate. Requirements for charter extension history are documented in the Charter Guidebook (section 4).

+ +

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):

+ + + + + + + + + + + + + + + + + +
+ Charter Period + + Start Date + + End Date + + Changes +
+ Initial Charter + + [dd monthname yyyy] + + [dd monthname yyyy] + + none +
+
+ +
+

Change log

+ + +

Changes to this document are documented in this section.

+ +
+
+ + +
+ + + + + diff --git a/2024/ig-security.html b/2024/ig-security.html new file mode 100644 index 00000000..40a38d38 --- /dev/null +++ b/2024/ig-security.html @@ -0,0 +1,432 @@ + + + + + + <i class="todo">Security</i> Interest Group Charter + + + + + + + + + + +
+

PROPOSED Security Interest Group Charter

+ + +

The mission of the Security Interest Group is to is to improve Security on the Web by advising groups developing standards on how to avoid and mitigate security issues with their technologies. Security Interest Group also suggests changes to existing standards and technologies to improve the security of existing systems.

+ + + + + +

This proposed charter is available + on GitHub. + + Feel free to raise issues. +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Charter Status + + See the group status page and detailed change history. +
+ Start date + + [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) +
+ End date + + [dd monthname yyyy] (Start date + 2 years) +
+ Chairs + + [chair name] (affiliation) +
+ Team Contacts + + Simone Onofri (0.25 FTE) +
+ Meeting Schedule + + Teleconferences: typically 1-2 per month, or as needed. +
+ Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year. +
+ +

Note: The W3C Process Document requires “The level of confidentiality of the group's proceedings and deliverables”; however, it does not mandate where this appears. Since all W3C Working Groups should be chartered as public, this notice has been moved from the essentials table to the communication section.

+
+ +
+

Motivation and Background

+

The W3C’s mission is to make the Web work based on the principles of accessibility, internationalization, privacy, and security.

+

The last two principles, Privacy and Security, are integral to human rights and civil liberties and have always been of the Consortium's concern.

+

Also, in the Ethical Web Principles, there are several principles related to security both as a societal impact The web does not cause harm to society and in terms of people's security The web is secure, and respects peoples' privacy, where the goal is to create technology that creates as few threats as possible, or mitigates those threats

+

Several working groups deal with security issues, such as develop mechanisms and best practices which improve the security of Web Applications, develop strong authentication functionality to Web Applications, and enhance the security and interoperability of various Web payments technologies.

+

Security is also a horizontal topic that often touches other groups and standards. Security can impact any protocol or API, which can have security implications. W3C Process mandates Wide Reviews, which is one of the Interest Group’s main scope.

+
+ +
+

Scope

+

The Security Interest Group (SING) develops and documents guidelines, patterns, processes, and best practices for addressing security considerations in Web standards.

+

SING provides "horizontal review" - offering groups developing web standards on-request guidance on security issues and mitigations specific to their technologies. SING aims to offer this review as early in the technology development lifecycle as requested, observing that early feedback is often more helpful. SING may also seek out technologies that benefit from earlier security reviews and conduct such reviews on its initiative.

+

SING incubates standards work on security issues by collecting requirements, prototyping, and/or initiating the work within the IG and recommending that the W3C move the work into other groups when appropriate.

+

SING may recommend mitigations for security issues in existing features of the Web platform, up to and including their deprecation.

+

SING may provide input to the W3C Process Community Group on process changes that will improve security in Web standards, e.g., by establishing particular requirements for identifying and mitigating security issues in W3C Recommendations.

+

SING may recommend to the W3C Advisory Committee and the W3C TAG regarding the security impact of proposed standards.

+ +
+

Out of Scope

+

The following features are out of scope, and will not be addressed by this Interest group.

+

The technical development of standards is not in the scope of the Interest Group. Identified Recommendation Track opportunities will be handed over to appropriate W3C groups if such a group exists or within a dedicated Community Group or Business Group when incubation is needed.

+
    +
+
+ +
+ +
+

+ Deliverables +

+ +

Updated document status is available on the group publication status page.

+ +

In conjunction with W3C's Technical Architecture Group (TAG) and PING, SING maintains a Self-Review Questionnaire for Security and Privacy.

+

SING may publish other documents consistent with the above scope, such as analyses of security issues, prototype specifications, and guidelines for user interface design and future standards.

+ +
+ +
+

+ Other Deliverables +

+

+ Other non-normative documents may be created such as: +

+
    +
  • Use case and requirement documents;
  • +
  • Test suite and implementation report for the specification;
  • +
  • Primer or Best Practice documents to support web security when designing standards and applications.
  • +
+
+ +
+

Success Criteria

+
    +
  • Feedback to other W3C groups, upon request, regarding security issues in their specifications.
  • +
  • Systematizing the security review of Web standards.
  • +
+
+ +
+

Coordination

+

SING will seek a horizontal review of its deliverables for accessibility, internationalization, performance, and privacy with the relevant Working and Interest Groups and with the TAG.

+

SING should collaborate with the WICG and TAG to coordinate security review of specifications early in their development lifecycle.

+
+

External Organizations

+

W3C needs to coordinate with other security groups, alliances, and standards development organizations to improve the Web's security. The following list provides examples of organizations:

+
+
IETF
+
OpenSSF
+
OWASP
+
OpenJS Foundation
+
ISECOM
+
...
+
+
+
+ +
+

+ Participation +

+

Participation in SING is open to the public. Participants who do not represent a W3C Member should join as Invited Experts. Invited Experts in this group are not granted access to Member-only information.

+

+ The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication. +

+

+ The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy. +

+

Participants in the group are required (by the W3C Process) to follow the + W3C Code of Conduct.

+
+ + + +
+

+ Communication +

+

+ Technical discussions for this Interest Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. + The meetings themselves are not open to public participation, however. +

+

+ Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Security Interest Group home page. +

+

+ Most Security Interest Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis. +

+

+ This group primarily conducts its technical work pick one, or both, as appropriate: on the public mailing list public-[email-list]@w3.org (archive) + or on GitHub issues. + The public is invited to review, discuss and contribute to this work. +

+

+ The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion. +

+
+ + + +
+

+ Decision Policy +

+

+ This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

+

+ However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections. +

+

+ To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. + + A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from [pick a duration within:] one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. + + 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 Interest 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. +

+

+ 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. +

+
+ + + +
+ +

Patent Disclosures

+

The Interest Group provides an opportunity to + share perspectives on the topic addressed by this charter. W3C reminds + Interest Group participants of their obligation to comply with patent + disclosure obligations as set out in Section + 6 of the W3C Patent Policy. While the Interest Group does not + produce Recommendation-track documents, when Interest Group + participants review Recommendation-track specifications from Working + Groups, the patent disclosure obligations do apply. For more information about disclosure obligations for this group, + please see the licensing information.

+
+ + + +
+

Licensing

+

This Interest Group will use the W3C Software and Document license for all its deliverables.

+
+ + + +
+

+ About this Charter +

+

+ This charter has been created according to section 3.4 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. +

+ +
+

+ Charter History +

+

Note:Display this table and update it when appropriate. Requirements for charter extension history are documented in the Charter Guidebook (section 4).

+ +

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Charter Period + + Start Date + + End Date + + Changes +
+ Initial Charter + + [dd monthname yyyy] + + [dd monthname yyyy] + + none +
+ Charter Extension + + [dd monthname yyyy] + + [dd monthname yyyy] + + none +
+ Rechartered + + [dd monthname yyyy] + + [dd monthname yyyy] + +

[description of change to charter, with link to new deliverable item in charter] Note: use the class new for all new deliverables, for ease of recognition.

+
+
+ +
+

Change log

+ + +

Changes to this document are documented in this section.

+ +
+
+
+ +
+ + + + + diff --git a/2024/immersive-web-wg.html b/2024/immersive-web-wg.html index dce4fc13..bcfe5cef 100644 --- a/2024/immersive-web-wg.html +++ b/2024/immersive-web-wg.html @@ -27,11 +27,11 @@ background: yellow; } - ul.out-of-scope > li { + ul.out-of-scope>li { font-weight: bold; } - ul.out-of-scope > li > ul > li{ + ul.out-of-scope>li>ul>li { font-weight: normal; } @@ -92,11 +92,11 @@

Immersive Web Working Group Charter

-

This proposed charter is available +

This proposed charter is available on GitHub. - Feel free to raise issues. -

+ Feel free to raise issues. +

@@ -130,7 +130,7 @@

Immersive Web Working Group Charter

Chairs @@ -170,7 +170,8 @@

Scope

access to input and output capabilities commonly associated with XR hardware such as tethered headsets and sensors as well as mobile handheld devices and standalone headsets. - The group will also investigate compatibility with non head-worn, multi-view displays. Examples include Looking Glass or zSpace displays. + The group will also investigate compatibility with non head-worn, multi-view displays. Examples include + Looking Glass or zSpace displays. The group will develop APIs to enable the creation of XR web experiences that are embeddable in the Web of today, enabling progressive enhancement of existing sites. @@ -226,14 +227,16 @@

More detailed milestones and updated publication schedules are available on the group publication status page. + href="https://www.w3.org/groups/wg/immersive-web/publications" target="_blank">group publication status + page.

text for keeping CR/CRS - The group will advance its other documents to Candidate Recommendation (with Snapshots) and, - when they are sufficiently mature, to Recommendation. - As noted below, some documents (XXXX) have particular milestones for being published as Candidate Recommendations. + The group will advance its other documents to Candidate Recommendation (with Snapshots) and, + when they are sufficiently mature, to Recommendation. + As noted below, some documents (XXXX) have particular milestones for being published as Candidate + Recommendations.

Draft state indicates the state of the deliverable at the time of the charter approval. Expected @@ -245,7 +248,8 @@

Normative Specifications

- The Working Group will deliver the following W3C normative specifications: + The Working Group will deliver the following W3C normative specifications and WebXR Living Standards as noted + under the module deliverables section:

@@ -253,23 +257,31 @@

target="_blank">WebXR Device API
-

We will continue to maintain the core WebXR Device API but we don’t intend to add new features or make - substantial - changes.

+

We will continue to maintain the core WebXR Device API to support new XR hardware as a living + specification where we + will publish new candidate recommendations in timely after substantive changes. +

This specification defines support for accessing virtual reality (VR) and augmented reality (AR) devices, including sensors and head-mounted displays, on the Web.

-

Draft state: Candidate Recommendation

-

Expected completion: Q3 2023

-

Adopted Working Draft: WebXR Device API (31 March 2022)

+

Draft state: WebXR + Living + Standard

+ +

Expected W3C Recommendation: yearly basis

+ +

Adopted Working Draft: WebXR Device API (16 April 2024)

Produced under Working Group Charter: Previous charter period + href="https://www.w3.org/2022/07/immersive-web-wg-charter.html" target="_blank">Previous charter period of the Immersive Web Working Group

Exclusion Draft: - https://www.w3.org/TR/2022/CR-webxr-20220331/
- associated Call for Exclusion on 2022-03-31, opportunity until 2022-05-30

+ https://www.w3.org/TR/2024/CRD-webxr-20240416/
+ associated Call + for Exclusion on 2024-04-TODO, opportunity until 2024-06-TODO +

This specification defines support for accessing button, trigger, thumbstick, and touchpad data associated with virtual reality (VR) and augmented reality (AR) devices on the Web.

Draft state: Working Draft

-

Expected completion: Q4 2023

-

Adopted Working Draft: Working Draft

+

Expected completion: Q4 2026

+

Adopted Working Draft: WebXR Gamepads - Module - Level 1 (24 August 2021)

+ Module - Level 1 (16 April 2024)

Produced under Working Group Charter: Previous charter period of the Immersive Web Working Group

Exclusion Draft: - https://www.w3.org/TR/2019/WD-webxr-gamepads-module-1-20191010/
- associated Call for Exclusion on 2019-10-10 ended on 2020-03-08

+ https://www.w3.org/TR/2024/WD-webxr-gamepads-module-1-20240409/
+ associated Call + for Exclusion on 2019-10-10 ended on 2020-03-08 +

This specification defines an expansion module of the WebXR Device API with the functionality available on AR hardware.

Draft state: Candidate Recommendation

-

Expected completion: Q2 2024

-

Adopted Working Draft: Candidate Recommendation

+

Expected completion: Q2 2025

+

Adopted Working Draft: WebXR Augmented Reality - Module - Level 1 (24 August 2021)

+ Module - Level 1 (2 November 2022)

Produced under Working Group Charter: Previous charter period of the Immersive Web Working Group

Exclusion Draft: - https://www.w3.org/TR/2022/CR-webxr-ar-module-1-20221101/
- associated Call for Exclusion on 2019-10-10 ended on 2020-03-08

+ https://www.w3.org/TR/2022/CR-webxr-ar-module-1-20221101/
+ associated + Call for Exclusion on 2019-10-10 ended on 2020-03-08 +

WebXR @@ -329,15 +347,18 @@

This specification defines a method for performing hit tests against real world geometry to be used with the WebXR Device API.

Draft state: Working Draft

-

Expected completion: Q3 2024

-

Adopted Working Draft: Working Draft

+

Expected completion: Q4 2025

+

Adopted Working Draft: WebXR Hit Test - Module (31 August 2021)

+ Module (19 April 2022)

Exclusion Draft: - https://www.w3.org/TR/2021/WD-webxr-hit-test-1-20210831/
- associated Call for Exclusion on 2021-08-31 ended on 2022-01-28

+ https://www.w3.org/TR/2021/WD-webxr-hit-test-1-20210831/
+ associated Call + for Exclusion on 2021-08-31 ended on 2022-01-28 +

@@ -349,14 +370,17 @@

This specification defines a mechanism for showing interactive 2D web content during an immersive WebXR session.

Draft state: Working Draft

-

Expected completion: Q4 2024

-

Adopted Working Draft: Working Draft

+

Expected completion: Q4 2026

+

Adopted Working Draft: WebXR DOM Overlays - Module (31 August 2021)

+ Module (17 November 2022)

Exclusion Draft: - https://www.w3.org/TR/2021/WD-webxr-dom-overlays-1-20210831/
- associated Call for Exclusion on 2021-08-31 ended on 2022-01-28

+ https://www.w3.org/TR/2021/WD-webxr-dom-overlays-1-20210831/
+ associated Call + for Exclusion on 2021-08-31 ended on 2022-01-28 +

This specification enables developers to render augmented reality content that reacts to real world lighting with the WebXR Device API and the WebXR AR Module.

-

Draft state: Working Draft

-

Expected completion: Q4 2024

+

Draft state: Working Draft

+

Expected completion: Q4 2026

Adopted Working Draft: WebXR Lighting Estimation API Level 1 (9 September 2021)

+ href="https://www.w3.org/TR/2022/WD-webxr-lighting-estimation-1-20220603/" target="_blank">WebXR + Lighting Estimation API Level 1 (3 June 2022)

Exclusion Draft: - https://www.w3.org/TR/2021/WD-webxr-lighting-estimation-1-20210909/
- associated Call for Exclusion on 2021-09-09 ended on 2022-02-06

+ https://www.w3.org/TR/2021/WD-webxr-lighting-estimation-1-20210909/
+ associated Call + for Exclusion on 2021-09-09 ended on 2022-02-06 +

This specification defines a method for enabling hand input to be used with the WebXR Device API.

Draft state: Working Draft

-

Expected completion: Q4 2024

-

Adopted Working Draft: WebXR Hand Input Module - Level 1 (24 August 2021)

+ target="_blank">Working Draft

+

Expected completion: Q4 2026

+

Adopted Working Draft: WebXR Hand Input Module - Level 1 (7 February 2024)

Exclusion Draft: - https://www.w3.org/TR/2020/WD-webxr-hand-input-1-20201022/
- associated Call for Exclusion on 2020-10-22 ended on 2021-03-21

+ https://www.w3.org/TR/2020/WD-webxr-hand-input-1-20201022/
+ associated Call + for Exclusion on 2020-10-22 ended on 2021-03-21 +

WebXR Anchors @@ -397,91 +429,69 @@

that need to be updated to correctly reflect the evolving understanding of the world, such that the poses remain aligned with the same place in the physical world. These poses will persist inside sessions, but not across sessions.

-

Draft state: Editor's Draft

-

Expected completion: Q4 2024

+

Draft state: Editor's + Draft

+

Expected completion: Q4 2025

Adopted Working Draft: Adopted from the Immersive Web CG

-
WebXR Anchors - Module - Level 2
-
-

This specification enables users of the WebXR Device API Anchors to have persistent Anchors between sessions.

-

Draft state: No Draft

-

Expected completion: Q4 2024

-
- -
WebXR Layers API Level 1
+
WebXR + Layers API Level 1

This specification defines methods for manipulating composition layers used with the WebXR Device API.

Draft state: Working Draft

-

Expected completion: Q2 2024

+ target="_blank">WebXR + Living + Standard

+

Expected W3C Recommendation: yearly basis

Adopted Working Draft: WebXR Layers API Level 1 (7 December 2021)

Exclusion Draft: - https://www.w3.org/TR/2020/WD-webxrlayers-1-20201203/
- associated Call for Exclusion on 2020-12-03 ended on 2021-05-02

+ https://www.w3.org/TR/2020/WD-webxrlayers-1-20201203/
+ associated Call + for Exclusion on 2020-12-03 ended on 2021-05-02 +

-
-
WebXR Raw Camera Access Module
-
-

This feature would enable predictable access to camera frame data for AR devices.

-

Draft state: Adopted from the Immersive Web CG

-

Expected completion: Q4 2023

-

Adopted Working Draft: Adopted from the - Immersive Web CG

-
+
Depth/Occlusion + API
+
+

This feature would provide depth and occlusion data on AR devices.

+

Draft state: Candidate + Recommendation

+

Expected completion: Q4 2026

+

Adopted Working Draft: WebXR + Depth + Sensing Module (19 + April 2022)

+

Exclusion Draft: + https://www.w3.org/TR/2021/WD-webxr-depth-sensing-1-20210831/
+ associated Call + for Exclusion on 2021-08-31 ended on 2022-01-28 +

+
-
Depth/Occlusion - API
-
-

This feature would provide depth and occlusion data on AR devices.

-

Draft state: Working Draft

-

Expected completion: Q4 2024

-

Adopted Working Draft: WebXR Depth Sensing Module (31 August 2021)

-

Exclusion Draft: - https://www.w3.org/TR/2021/WD-webxr-depth-sensing-1-20210831/
- associated Call for Exclusion on 2021-08-31 ended on 2022-01-28

-
+
Navigation

This feature would enable better control of experiences when users navigate from one XR experience to another.

-

Draft state: Adopted from the Immersive Web CG

-

Expected completion: Q4 2024

-

Adopted Working Draft: Adopted from the Immersive Web CG

-
- -
Model Element -
-
-

This feature is to add a new HTML element to handle displaying 3D

-

This may become a recommendation to the WhatWG rather than being published under the Immersive Web Working Group

-

Draft state: No draft yet

-

Expected completion: Q4 2024

+

Draft state: Adopted from the Immersive Web CG

+

Expected completion: Q4 2027

+

Adopted Working Draft: Adopted from the + Immersive Web CG

-
-

- The Working Group also intends to work on the following Recommendation-Track deliverables, although it - recognizes these - Recommendations may not be completed before the end of this charter period. All work is expected to be - incubated in the - Immersive Web Community Group first. These deliverables are in rough priority order as of the start of the - charter - period, although the Chairs may reprioritize based on the consensus of the Working Group during the - charter period.

- -
+
WebXR Real World Geometry Module
@@ -491,24 +501,81 @@

Draft state: Adopted from the Immersive Web CG

-

Expected completion: Q4 2024

+

Expected completion: Q4 2026

Adopted Working Draft: WebXR Real World Geometry Proposal

+ +
WebXR Raw + Camera Access Module
+
+

This feature would enable predictable access to camera frame data for AR devices.

+

Draft state: Adopted from the + Immersive Web CG

+

Expected completion: Q4 2026

+

Adopted Working Draft: Adopted from the + Immersive Web CG

+

-

- The Working Group also may choose to deliver normative specifications for the following features, if there - is consensus - in the Working Group that they are ready to move to the Recommendation track after sufficient incubation in - the - Immersive Web CG. +

+ The Working Group also intends to work on the following Recommendation-Track deliverables, although it + recognizes these + Recommendations may not be completed before the end of this charter period. All work is expected to be + incubated in the + Immersive Web Community Group first. These deliverables are in rough priority order as of the start of the + charter + period, although the Chairs may reprioritize based on the consensus of the Working Group during the + charter period.

+ +
+ +
Model + Element +
+
+

This feature is to add a new HTML element to handle displaying 3D

+

This may become a recommendation to the WhatWG rather than being published under the Immersive Web + Working Group

+

Draft state: No draft yet

+

Expected completion: Q4 2028

+
+ +
WebXR Anchors + Module - Level 2
+
+

This specification enables users of the WebXR Device API Anchors to have persistent Anchors between + sessions.

+

Draft state: No Draft

+

Expected completion: Q4 2027

+
+ -

+ +
Body + Tracking + Module
+
+

The WebXR Body Tracking module expands the WebXR Device API with the functionality to track articulated + body poses.

+
+
+ +

+ The Working Group also may choose to deliver normative specifications for the following features, if there + is consensus + in the Working Group that they are ready to move to the Recommendation track after sufficient incubation in + the + Immersive Web CG. + +

+
XR Capture Module
@@ -522,7 +589,8 @@

This feature would enable access to image detection support on AR devices.

-
Marker Detection
+
Marker + Detection

This feature would enable access to QR code marker detection support on AR devices.

@@ -536,9 +604,11 @@

This feature would provide data tracking the user's gaze, for example to provide foveal-rendering improvement features.

-
Geo-alignment
+
Geo-alignment +
-

This feature would facilitate geo-spatial AR data in the context of immersive web, to utilize geo alignment using coordinate system with geospatial orientation.

+

This feature would facilitate geo-spatial AR data in the context of immersive web, to utilize geo + alignment using coordinate system with geospatial orientation.

@@ -575,27 +645,37 @@

Success Criteria

possible alternate text for keeping CR/CRS - 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 independent interoperable implementations, - which may be judged by factors including existing implementations, expressions of interest, and lack of opposition. + 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 independent interoperable + 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 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. [delate this sentence? dup to others] - In order to advance to Proposed Recommendation, each normative specification must have an open test suite of every feature defined in the specification. + 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.

+

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

-

- To promote interoperability, all changes made to specifications - in Candidate Recommendation - or to features that have deployed implementations - should have tests. - Testing efforts should be conducted via the Web Platform Tests project.

+

+ To promote interoperability, all changes made to specifications + in Candidate Recommendation + or to features that have deployed implementations + should have tests. + Testing efforts should be conducted via the Web Platform + Tests project.

- +

Each specification should contain sections detailing all known security and privacy implications for implementers, Web authors, and end users.

@@ -604,19 +684,21 @@

Success Criteria

ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.

- -

This Working Group expects to follow the - TAG Web Platform Design Principles. -

- - -

All new features should have expressions of interest from at least two potential implementors before being incorporated in the specification.

- + +

This Working Group expects to follow the + TAG Web Platform Design Principles. +

-

- [dup to new test section?] - To promote interoperability, all changes made to specifications should have tests.

+ +

All new features should have expressions of interest from at least two potential implementors before being + incorporated in the specification.

+ + +

+ [dup to new test section?] + To promote interoperability, all changes made to specifications should have tests. +

@@ -652,8 +734,10 @@

W3C Groups

The Immersive Web Community Group will provide the WebXR Device API seed specification to begin the standards process. In addition, the Immersive Web Working Group plans to partner closely with the IWCG to - incubate new features - in particular, incubation of features that are out of current scope for the Immersive Web Working - Group will happen in the Community Group, and then be followed by future Immersive Web Working Group rechartering to include them in + incubate new features - in particular, incubation of features that are out of current scope for the + Immersive Web Working + Group will happen in the Community Group, and then be followed by future Immersive Web Working Group + rechartering to include them in scope.
@@ -680,7 +764,8 @@

W3C Groups

The APA Working Group will review deliverables for accessibility - implications and help develop solutions, noting the following XR Accessibility User Requirements resource. + implications and help develop solutions, noting the following XR + Accessibility User Requirements resource.
Audio Working Group
The Audio Working group develops the Web Audio @@ -691,17 +776,18 @@

W3C Groups

GPU For The Web Working Group
- The GPU for the Web Working Group develops the WebGPU + The GPU for the Web Working Group develops the WebGPU Specification and the WebGPU Shading Language Specification, both of which might apply to the features provided by the WebXR Device API and modules.
-
Web Platform Incubator Community Group
+
Web Platform Incubator Community Group +
- The Web Platform Incubator Community Group provides a lightweight venue for proposing, incubating, - and discussing new web platform features. - The Immersive Web Working Group will incubate and work on new model element proposal that are within - scope of WICG. + The Web Platform Incubator Community Group provides a lightweight venue for proposing, incubating, + and discussing new web platform features. + The Immersive Web Working Group will incubate and work on new model element proposal that are within + scope of WICG.
@@ -717,7 +803,8 @@

External Organizations

The Khronos Group is in charge of the WebGL specification on which the WebXR Device API heavily relies for its operations. The Immersive Web Working Group will coordinate its roadmap with planned evolutions of WebGL. The - Immersive Web Working Group will also track and coordinate with Khronos + Immersive Web Working Group will also track and coordinate with Khronos OpenXR standard initiative. @@ -730,9 +817,18 @@

External Organizations

and version 4.1 will add Mixed Augmented Reality capabilities for diverse virtual and augmented reality devices. -
Open Geospatial Consortium
+
Open Geospatial Consortium +
- The Open Geospatial Consortium creates free, publicly available geospatial standards that enable new technologies. OGC also manages an agile and collaborative research and development process that anticipates and solves real-world geospatial challenges experienced by its members. One of the OGC working groups that is most relevant for Immersive Web focuses on development of GeoPose, an encoding specification to seamlessly express, record, and share the geographically-anchored position and 6 DOF orientation of objects in an entirely consistent manner across different applications, users, devices, services, and platforms which adopt the standard or are able to translate/exchange the GeoPose into another CRS. The Immersive Web Working Group will coordinate its roadmap with planned evolutions of relevant OGC standards, including but not limited to GeoPose. + The Open Geospatial Consortium creates free, publicly available geospatial standards that enable new + technologies. OGC also manages an agile and collaborative research and development process that anticipates + and solves real-world geospatial challenges experienced by its members. One of the OGC working groups that + is most relevant for Immersive Web focuses on development of GeoPose, an encoding specification to + seamlessly express, record, and share the geographically-anchored position and 6 DOF orientation of objects + in an entirely consistent manner across different applications, users, devices, services, and platforms + which adopt the standard or are able to translate/exchange the GeoPose into another CRS. The Immersive Web + Working Group will coordinate its roadmap with planned evolutions of relevant OGC standards, including but + not limited to GeoPose.
@@ -755,11 +851,12 @@

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement - to the terms of the W3C Patent Policy. + to the terms of the W3C Patent + Policy.

Participants in the group are required (by the W3C Process) to follow the - W3C Code of Ethics and Professional Conduct. + W3C Code of Conduct.

@@ -809,7 +906,8 @@

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus3). Typically, an + href="https://www.w3.org/Consortium/Process/#Consensus"> W3C Process Document (section 5.2.1, Consensus3). + Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

@@ -835,7 +933,8 @@

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 + Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the + Process Document requires.

@@ -857,125 +956,129 @@

href="https://www.w3.org/groups/wg/immersive-web/ipr">licensing information.

-
-

Licensing

-

This Working Group will use the W3C Software - and Document license for all its deliverables.

-
+
+

Licensing

+

This Working Group will use the W3C Software + and Document license for all its deliverables.

+
-
-

- About this Charter -

-

- This charter has been created according to section - 3.4 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. -

+
+

+ About this Charter +

+

+ This charter has been created according to section + 3.4 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. +

-
-

- Charter History -

-

- Ada Rose Cannon (Samsung), Chris Wilson (Google), Ayşegül Yönet (Microsoft) + Ada Rose Cannon (Samsung), Chris Wilson (Google), Ayşegül Yönet (ARtistus)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+

+ Charter History +

+
- Charter Period - - Start Date - - End Date - - Changes -
- Initial Charter - - 24 September 2018 - - 1 March 2020 - - none -
- Charter - Extension - - 9 March 2020 - - 30 April 2020 - - none -
- Rechartered - - 12 May 2020 - - 1 June 2022 - -

Added: WebXR Gamepads Module, WebXR Augmented Reality Module, WebXR Hit Test Module, WebXR DOM Overlays - Module, WebXR Lighting Estimation Module, WebXR Hand Input Module, WebXR Real World Geometry Module, - WebXR Anchors Module, WebXR Layers

-
- Charter - Extension - - 1 June 2022 - - 1 September 2022 - - none -
- Rechartered - - 8 July 2022 - - 7 July 2024 - -

Added: Raw Camera Access, Depth/Occlusion API, Navigation, WebXR Anchors Proposal Module - Level 2, Model Element
- Expanded Scope with new type of devices, handling of 3D models, and navigation to follow emering industrial needs.

-
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - -
+ Charter Period + + Start Date + + End Date + + Changes +
+ Initial Charter + + 24 September 2018 + + 1 March 2020 + + none +
+ Charter + Extension + + 9 March 2020 + + 30 April 2020 + + none +
+ Rechartered + + 12 May 2020 + + 1 June 2022 + +

Added: WebXR Gamepads Module, WebXR Augmented Reality Module, WebXR Hit Test Module, WebXR DOM + Overlays + Module, WebXR Lighting Estimation Module, WebXR Hand Input Module, WebXR Real World Geometry Module, + WebXR Anchors Module, WebXR Layers

+
+ Charter + Extension + + 1 June 2022 + + 1 September 2022 + + none +
+ Rechartered + + 8 July 2022 + + 7 July 2024 + +

Added: Body-tracking, WebXR Anchors Proposal Module - Level 2, + Model Element
+ Expanded Scope with new type of devices, handling of 3D models, and navigation to follow emering + industrial needs.

+
Rechartered @@ -987,26 +1090,28 @@

[dd monthname yyyy]

-

[description of change to charter, with link to new deliverable item in charter] Note: use the class new for all new deliverables, for ease of recognition.

+

[description of change to charter, with link to new deliverable item in charter] + Note: use the class new for all new deliverables, for ease of recognition. +

-
+ + + -
-

Change log

+
+

Change log

- -

Changes to this document are documented in this section.

- +

Changes to this document are documented in this section.

+ +
-
@@ -1016,14 +1121,17 @@

Change log

Atsushi Shimono - -
-

Yes, it's on GitHub!.

- + +
+

Yes, it's on GitHub!.

+ diff --git a/2024/sdw-wg.html b/2024/sdw-wg.html new file mode 100644 index 00000000..7290b72b --- /dev/null +++ b/2024/sdw-wg.html @@ -0,0 +1,848 @@ + + + + + + PROPOSED Spatial Data on the Web Working Group Charter + + + + + + + + + + +
+

PROPOSED Spatial Data on the Web Working Group + Charter

+ +

The mission of the Spatial Data on the Web + Working Group is to: + +

+ + +
+

W3C Members join the + Spatial Data on the Web Working Group; OGC Members + should contact the Chairs or Staff Contact to join the group. + +

OGC Members should join the Observations, Measurements and Samples Standards Working + Group. +

+ +

This proposed + charter is available on GitHub. Feel free to raise issues. + +

+ + + + + + + + +
Charter Status + + See the group + status page and detailed + change history. + +
Start date + + [dd monthname yyyy] (date of the + "Call for Participation", when the charter is + approved) + +
End date + + [dd monthname yyyy] (Start date + + 2 years) + +
Chairs + + [chair name] (affiliation) + + +
Team Contacts + + Bert Bos + (0.1 FTE) + +
Meeting Schedule + + Teleconferences: weekly?
+ Face-to-face: during + the W3C's annual Technical Plenary week; additional + face-to-face meetings may be scheduled by consent of + the participants, usually no more than 3 per year. +
+ the WG will meet in conjunction with the + OMS SWG during OGC's Member Meetings. +
+
+ +
+

Motivation and Background

+ +

Background of landscape, technology, and + relationship to the Web, users, developers, implementers, and + industry. +

+ +
+

Scope

+ +

The Spatial Data on the Web WG will: + +

+ +
+

Out of Scope

+ +

The Spatial Data on the Web Working Group will only + produce deliverables where it is in the interests of both + OGC and W3C to collaborate. +

+
+ +
+

Deliverables

+ +

Updated document status is available on the group + publication status page. + +

Draft state indicates the state of the deliverable + at the time of the charter approval. Expected + completion indicates when the deliverable is projected + to become a Recommendation, or otherwise reach a stable + state. + +

+

Normative Specifications

+ +

The Working Group will deliver the following W3C + normative specifications: + +

    +
  • Semantic Sensor Network Ontology – new edition +
      +
    • Draft state: Adopted + +
    • Expected completion: Q4 2024 + +
    • Latest publication: 2017-10-19 + +
    • Abstract: +

      The Semantic Sensor Network (SSN) ontology is an + RDFS/OWL ontology for describing observations made + by sensors implementing specified procedures, the + studied features of interest and the observed + properties, along with samples used in the + observations and the sampling activities that + created them, as well as actuations which follow a + similar semantics and data structure. + +

      The SOSA vocabulary (Sensors, Observations, + Samples and Actuations) contains the core terms and + definitions from SSN, packaged for use in general + applications. + +

      Some extension modules are included in the + recommendation. + +

      Alignments with some related ontologies and data + models are included in the recommendation. +

    +
+ +

The Working Group will maintain the following existing + specifications: + +

+
+ +
+

Other Deliverables

+ +

Other non-normative documents may be created such as: + +

    +
  • RDF artefacts including testing and validation tools + (e.g. JSON-Schema, SHACL Shapes) + +
  • Test suite and implementation report for the + specifications + +
  • Primer or Best Practice documents to support web + developers when designing applications + +
  • OGC Discussion Papers + +
  • OGC Technical Papers + +
  • W3C Notes +
+
+ +
+

Timeline

+ +

Put here a timeline view of all deliverables. + +

    +
  • Month YYYY: First teleconference + +
  • Month YYYY: First face-to-face meeting + +
  • Month YYYY: Requirements and Use Cases for FooML + +
  • Month YYYY: FPWD for FooML + +
  • Month YYYY: Requirements and Use Cases for BarML + +
  • Month YYYY: FPWD FooML Primer +
+
+
+ +
+

Success Criteria

+ +

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. + +

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

Consider adopting a healthy testing + policy, such as: To promote interoperability, all + changes made to specifications in Candidate Recommendation or + to features that have deployed implementations should have tests. Testing efforts should be conducted via the Web + Platform Tests project.

+ +

Each specification should contain sections detailing all + known security and privacy implications for implementers, Web + authors, and end users. + +

For specifications of technologies that + directly impact user experience, such as content + technologies, as well as protocols and APIs which impact + content: Each specification should contain a section on + accessibility that describes the benefits and impacts, + including ways specification features can be used to address + them, and recommendations for maximising accessibility in + implementations.

+ +

This Working Group expects to follow the TAG Web Platform + Design Principles.

+ +

Consider adding this clause if the Group + does not intend to move to REC: All new features + should have expressions of interest from at least two + potential implementors before being incorporated in the + specification. +

+ +
+

Coordination

+ +

For all specifications, this Working Group will seek horizontal review for accessibility, + internationalization, privacy, and security with the relevant + Working and Interest Groups, and with the TAG. Invitation + for review must be issued during each major standards-track + document transition, including FPWD. The Working + Group is encouraged to engage collaboratively with the + horizontal review groups throughout development of each + specification. The Working Group is advised to seek a review + at least 3 months before first entering CR and is encouraged + to proactively notify the horizontal review groups when major + changes occur in a specification following a review. + +

Additional technical coordination with the following Groups + will be made, per the W3C + Process Document: + +

In addition to the above catch-all reference to + horizontal review which includes accessibility review, please + check with chairs and staff contacts of the Accessible Platform + Architectures Working Group to determine if an + additional liaison statement with more specific information + about concrete review issues is needed in the list below. + +

+

W3C Groups

+ +
+
Dataset + Exchange Working Group + +
Spatial Data has specific needs for data description, + such as coordinate reference system, granularity. These + must be taken into account by the DXWG. + +
Devices + and Sensors Working Group + +
Sensor and system descriptions. +
+
+ +
+

OGC Groups

+ +

Most working groups operating at OGC have a scope that + may intersect with topics of interest discussed in the + Spatial Data on the Web Working Group. The OGC Architecture + Board (OAB), comparable to the W3C Technical Advisory Group + (TAG) will provide high level guidance to the Spatial Data + on the Web Working Group. The Working Group expects to + liaise with OGC groups as needed, and more specifically + with: + +

+
Geosemantics DWG + +
Umbrella group in OGC for geospatial semantics + applications + +
Connected Systems SWG + +
Linking work on SSN in W3C with the open interfaces + for sensor web applications developed at OGC. + +
SensorThings SWG + +
Linking work on SSN in W3C with the OGC SensorThings + API. + +
GeoDCAT SWG + +
Linking the W3C and OGC work on dataset description + and profiles. + +
GeoPose SWG + +
Direction alongside location for sensors, systems and + platforms +
+
+ +
+

External Organizations

+ +
+
[other name] Working + Group + +
[specific nature of liaison] +
+
+
+ +
+

Participation

+ +

To be successful, this Working) Group is expected to have 6 + or more active participants for its duration, including + representatives from the key implementors of this + specification, and active Editors and Test Leads for each + specification. The Chairs, specification Editors, and Test + Leads are expected to contribute half of a working day per + week towards the Working Group. There is no minimum + requirement for other Participants. + +

The group encourages questions, comments and issues on its + public mailing lists and document repositories, as described + in Communication. + +

The group also welcomes non-Members to contribute technical + submissions for consideration upon their agreement to the + terms of the W3C + Patent Policy. + +

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics + and Professional Conduct. +

+ +
+

Communication

+ +

Technical discussions for this Working Group are + conducted in public: the meeting minutes from teleconference and + face-to-face meetings will be archived for public review, and + technical discussions and issue tracking will be conducted in + a manner that can be both read and written to by the general + public. Working Drafts and Editor's Drafts of specifications + will be developed in public repositories and may permit + direct public contribution requests. The meetings themselves + are not open to public participation, however. + +

Information about the group (including details about + deliverables, issues, actions, status, participants, and + meetings) will be available from the Spatial Data on the Web + Working Group home page. + +

Most Spatial Data on the Web Working Group teleconferences + will focus on discussion of particular specifications, and + will be conducted on an as-needed basis. + +

This group primarily conducts its technical work pick one, or both, as appropriate: on the + public mailing list public-sdw-wg@w3.org (archive) or on GitHub issues. The public is invited to review, discuss + and contribute to this work. + +

The group may use a Member-confidential mailing list for + administrative purposes and, at the discretion of the Chairs + and members of the group, for member-only discussions in + special cases when a participant requests such a discussion. +

+ +
+

Decision Policy

+ +

This group will seek to make decisions through consensus + and due process, per the W3C + Process Document (section 5.2.1, Consensus). Typically, + an editor or other participant makes an initial proposal, + which is then refined in discussion with members of the group + and other reviewers, and consensus emerges with little formal + voting being required. + +

However, if a decision is necessary for timely progress + and consensus is not achieved after careful consideration of + the range of views presented, the Chairs may call for a group + vote and record a decision along with any objections. + +

To afford asynchronous decisions and organizational + deliberation, any resolution (including publication + decisions) taken in a face-to-face meeting or teleconference + will be considered provisional. A call for consensus (CfC) + will be issued for all resolutions (for example, via email, + GitHub issue or web-based survey), with a response period + from one week to 10 working days, depending on the chair's + evaluation of the group consensus on the issue. 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. + +

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. +

+ +
+

Patent Policy

+ +

This Working Group operates under the W3C + Patent Policy (Version of 15 September 2020). To promote + the widest adoption of Web standards, W3C seeks to issue Web + specifications 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 licensing + information. +

+ +
+

Licensing

+ +

This Working Group will use the W3C Software and Document license for all its + deliverables, with copyright held by OGC and W3C. Published + documents will be clearly marked as joint deliverables. +

+ +
+

About this Charter

+ +

This charter has been created according to section 3.4 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. + +

+

Charter History

+ +

Note:Display this table and update + it when appropriate. Requirements for charter extension + history are documented in the Charter Guidebook (section 4). + +

The following table lists details of all changes from the + initial charter, per the W3C Process Document (section 4.3, Advisory Committee + Review of a Charter): + + + + + + + + +
Charter Period + + Start Date + + End Date + + Changes + +
Initial charter + + 19 October 2021 + + 04 October 2023 + + + +
Extension + + 04 October 2023 + + 04 April 2024 + + + +
Rechartered + + [dd monthname yyyy] + + [dd monthname yyyy] + + +

[description of change to charter, + with link to new deliverable item in charter] Note: use the class new for + all new deliverables, for ease of recognition. +

+

+ +
+

Change log

+ +

Changes to this document are documented in this section.

+
+
+
+ +
+ + diff --git a/2024/svg-wg.html b/2024/svg-wg.html index 37c82d5c..4540b2bd 100644 --- a/2024/svg-wg.html +++ b/2024/svg-wg.html @@ -425,7 +425,7 @@

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct. + "https://www.w3.org/policies/code-of-conduct/">Code of Conduct.

@@ -465,12 +465,11 @@

Decision Policy

-

- This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an - editor or other participant makes an initial proposal, which is then refined in discussion with members of - the group and other reviewers, and consensus emerges with little formal voting being required. -

+

This group will seek to make decisions through consensus and due process, per the + W3C Process Document (section 5.2.1, Consensus). + Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members + of the group and other reviewers, and consensus emerges with little formal voting being required. +

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision @@ -485,9 +484,9 @@

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. @@ -835,7 +834,7 @@

Change log

- +

Changes to this document are documented in this section.

- -

The mission of the Federated Identity Working Group is to - develop specifications to allow a website to request a federated identity - credential or assertion with the purpose of authenticating a user and/or requesting a set of claims in a - compatible way to OIDC or SAML.

- +

DRAFT Federated Identity Working Group Charter

+

The mission of the Federated Identity Working Group is to develop specifications that allow a website to request an identity credential from an Identity Provider or credential container (i.e., a wallet) to authenticate a user and request a set of claims in a way that is compatible with other protocols like OIDC, SAML, and OpenID4VP.

-

This proposed charter is available - on GitHub. - Feel free to raise issues. -

+

This draft charter is available + on GitHub. + + Feel free to raise issues or see the ones that are open. +

@@ -101,8 +95,8 @@

PROPOSED Federated Identity Working Group Charter

Charter Status @@ -110,7 +104,7 @@

PROPOSED Federated Identity Working Group Charter

Start date @@ -118,7 +112,7 @@

PROPOSED Federated Identity Working Group Charter

End date @@ -135,8 +129,8 @@

PROPOSED Federated Identity Working Group Charter

Team Contacts @@ -156,44 +150,45 @@

PROPOSED Federated Identity Working Group Charter

Motivation and Background

- With changes to the support for underlying privacy principles, - fundamental assumptions of the web platform are being redefined or removed. While overall good for the web, the - third-party cookie deprecation - removes a building block used by certain designs of federated - identity. This Group aims to bridge the gap for the federated identity designs which relied - on third-party cookies. + Identity on the Web is critical to online interaction, privacy, and security. W3C fosters an ecosystem where privacy, security, and user sovereignty are all considered. That includes developing new mechanisms for individuals to have the ability to select the identity information, such as assertions, specific credentials, or specific attributes, relevant to a given interaction. These mechanisms must also be viable for the issuers, verifiers, identity providers, and relying parties to exchange information in a secure and privacy-preserving manner. +

+

+ The user agent is the coordinator for these transactions. So, while the request and response protocols are being developed elsewhere (e.g., ISO, IETF, OpenID, and other W3C groups), the web platform layer must also be standardized to provide the privacy and security API framework in a protocol-agnostic and formats-agnostic fashion in a manner that is compatible with identity request/response protocols and different formats. +

+

+ The group would like to:

+

Scope

-

The Working Group will specify new web platform features intended to be implemented in browsers or similar user - agents. The purpose of these features is to support authentication and authorization flows without compromising - security principles for Identity Providers (IdPs), Relying Parties (RPs), and User Agents as well as protecting user - privacy. Here "privacy" minimally refers to the appropriate processing of personal information. The result of - this work is the development of new mechanisms that define how information is passed by the browser between the - RP, the IdP, and authentication intermediaries to facilitate federated authentication; these mechanisms are not - an authentication method.

- -

If any of the mechanisms developed to support authentication and authorization flows would cause - breaking changes for existing protocols, work on that mechanism must include a well-documented transition - period.

+

+ The Working Group will specify new web platform features intended to be implemented in user agents like browsers. The purpose of these features is to support privacy-preserving authentication, authorization flows, and requesting federated identities without compromising security principles for Identity Providers (IdPs) or Relying Parties (RPs) (in a ‘traditional’ federation model) or Issuers, Verifiers, and Holders (in a digital identity wallet architecture), and User Agents. Here, “privacy” minimally refers to the appropriate processing of personal information and preventing third parties from gleaming anything about the end-user’s environment (e.g., which wallets are available and their capabilities). This work results in developing new mechanisms that define how information is passed by the browser between the different entities and authentication intermediaries to facilitate federated authentication; these mechanisms are not authentication methods. +

+

+ If any mechanisms developed to support authentication and authorization flows would cause breaking changes for existing protocols, work on that mechanism must include a well-documented transition period. +

Out of Scope

-

The identity space is much larger than federated authentication. While several topics related to - identity may be of interest, they are out of scope for our work.

+

+ The identity space is much larger than that of federated authentication and digital credential wallets. While several topics related to identity may be of interest, they are out of the scope for our work. +

Specific topics out of scope:

    - -
  • New authentication methods
  • - -
  • Design and discussion regarding individual credential and assertion formats
  • - -
  • Ad-tech tools or APIs
  • - -
  • Interactions with identity wallets
  • +
  • Designing new authentication methods.
  • +
  • Designing individual credential and assertion formats
  • +
  • Performing any security or confidence assessment (e.g. checking signatures, + audience, encoding, etc) of the token that + encodes the identity + assertions.
  • +
  • Ad-tech tools or APIs specifically focused on advertising as opposed to authentication.
@@ -230,9 +225,9 @@

Draft state: Adopted from the Federated Identity Community Group

-

Expected completion: CR in Q1 2025

+

Expected completion: CR in Q2 2025

-
Login Status API +
Login Status API

This specification defines an API to inform the Web Application of their user's @@ -243,10 +238,21 @@

Draft state: Adopted from the Federated Identity Community Group

-

Expected completion: CR in Q1 2025

+

Expected completion: CR in Q2 2025

+

Tentative Deliverables

+

Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the Group may also produce Recommendation-track specifications for the following document:

+
+
Digital Credentials API
+
+

This specification specifies an API to enable user agents to mediate access to, and presentation of, digital credentials such as a driver's license, government-issued identification card, and/or other types of digital credentials.

+

Draft state: Draft in the + Web Incubator Community Group +

+
+
@@ -262,17 +268,20 @@

Other non-normative documents may be created such as:

    -
  • Use case and requirement documents;
  • -
  • Implementation report for the specification;
  • +
  • Use case and requirement documents.
  • +
  • Implementation report for the specification.
  • Primer or Best Practice documents to support web developers when designing applications.
  • +
  • Harm Model or other documents to identify the impact of the technology (API and also Digital Identities in general) on people and their security and privacy. +

Timeline

    -
  • Q1 2024: FPWD for Federated Credential Management API
  • +
  • Q4 2024: FPWD for Federated Credential Management API
  • Q1 2025: CR for Federated Credential Management API
  • +
@@ -289,7 +298,7 @@

Success Criteria

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 + more implementations (distinct browser engines) 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.

@@ -304,16 +313,15 @@

Success Criteria

-

Each specification should contain sections detailing all known security and - privacy implications for implementers, Web authors, and end users.

+

Each specification should contain a Security Considerations section that must include a Threat Model with threats, attacks, mitigations, and residual risks and a Privacy Consideration section as specified in Self-Review Questionnaire: Security and Privacy and RFC 3552, detailing all known security and privacy implications for implementers, Web authors, and end users.

Each specification should contain a section on accessibility that describes the benefits and impacts, including - ways specification features can be used to address them, and + ways specification features can be used to address them and recommendations for maximising accessibility in implementations.

- -

This Working Group expects to follow the - TAG Web Platform Design Principles. + +

+ This Working Group expects to follow the TAG Web Platform Design Principles, Ethical Web Principles, and Privacy Principles.

@@ -363,8 +371,11 @@

W3C Groups

ensure that the work of the two groups is not in conflict.
Web Authentication (WebAuthn) Working Group
While we are not developing an authentication mechanism, this work must operate in conjunction with existing authentication mechanisms. The WebAuthn Working Group may provide input and guidance for this requirement.
-
Accessible Platform Architectures (APA) WG
-
The APA WG seeks to ensure that accessibility is kept front of mind, as authentication timing and the reliance on short term memory are known and thorny topics for people with disabilities. APA WG can represent these issues that have been raised in the Cognitive Accessibility (COGA) TF, and Accessibility Guidelines (AG) WG.

+
Accessible Platform Architectures (APA) Working Group
+
The APA WG seeks to ensure that accessibility is kept front of mind, as authentication timing and the reliance on short term memory are known and thorny topics for people with disabilities. APA WG can represent these issues that have been raised in the Cognitive Accessibility (COGA) TF, and Accessibility Guidelines (AG) WG. +
Verifiable Credentials Working Group
+
The VC WG is a likely venue for standardization of Data Model for Verifiable Credentials and they are an important stakeholder in the identity space to coordinate with. + @@ -372,22 +383,31 @@

W3C Groups

External Organizations

IETF
-
A number of IETF working groups, such as oauth, are likely venues for standardization of - protocol components that authentication and authorization features - depend on and research groups are investigating issues that will feed - into the designs this group will consider.
+
To coordinate with the IETF research groups and working groups, such as oauth, for + protocol components that authentication and authorization features + depend on.
OIDF
-
The OpenID Foundation (OIDF) is a likely venue for standardization of - components that certain authorization flows depend on (i.e., OIDC +
To coordinate with the OpenID Foundation (OIDF) for authorization and credentials used in the flows (i.e., OIDC and OpenID4VC specs).
OASIS
-
OASIS is a likely venue for standardization of components that certain - authorization flows depend on (i.e., SAML specs).
+
To coordinate with OASIS for authorization flows used in the flows (i.e., SAML).
REFEDS
-
REFEDS is a likely venue for multi-lateral federation best practices and +
To coordinate with REFEDS for multi-lateral federation best practices and a representative of the complex use cases of the research and education - communities around the world.
+ communities around the world.
+
European Telecommunications Standards Institute - Electronic Signatures and Infrastructure Technical Committee
+
+ To coordinate with ETSI for eIDAS, which can use the deliverables of the Group. +
+
National Institute of Standards and Technology, U.S. Department of Commerce
+
+ To coordinate with NIST for their guidelines of Digital Identity and implementations. +
+
ISO/IEC JTC 1 SC17 WG4 and WG10
+
+ To coordinate with ISO for their work on interfaces and protocols for security devices and vehicle driver licence and related digital identities (i.e., mdocs). +
@@ -418,7 +438,7 @@

Participants in the group are required (by the W3C Process) to follow the - W3C Code of Ethics and Professional Conduct.

+ W3C Code of Conduct.

@@ -559,18 +579,34 @@

+ + + + + +

@@ -101,7 +101,7 @@

DRAFT: Web Authentication Working Group Charter

Charter Status @@ -125,7 +125,7 @@

DRAFT: Web Authentication Working Group Charter

Chairs @@ -133,8 +133,9 @@

DRAFT: Web Authentication Working Group Charter

- @@ -300,15 +301,21 @@

Success Criteria

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.

+more implementations interoperating with each other.

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

- +

+ To promote interoperability, all changes made to specifications + in Candidate Recommendation + or to features that have deployed implementations + should have tests. + Testing efforts should be conducted via the Web Platform Tests project.

Each specification should contain sections detailing all known security and - privacy implications for implementers, Web authors, and end users.

+ privacy implications for implementers, Web authors, and end users. + The security considerations section must include a comprehensive + threat model with threats, attacks, mitigations and residual risks. +

Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and @@ -365,8 +372,8 @@

External Organizations

IETF Security Area Directorate
The IETF Security Area Directorate consists of the Working Group Chairs of the Security Area and selected individuals chosen for their technical knowledge in security.
-
FIDO 2.0 Working Group
-
Coordination on Client to Authenticator Protocol.
+
FIDO2 Technical Working Group
+
Coordination on Client to Authenticator Protocol.
@@ -387,7 +394,7 @@

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the - W3C Code of Ethics and Professional Conduct.

+ W3C Code of Conduct.

diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 00000000..2d3ac155 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,3 @@ +# Code of Conduct + +All documentation, code and communication under this repository are covered by the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/). diff --git a/CodeOfConduct.md b/CodeOfConduct.md deleted file mode 100644 index a3c2c8bf..00000000 --- a/CodeOfConduct.md +++ /dev/null @@ -1,26 +0,0 @@ -# Code of Ethics and Professional Conduct - -W3C Charter development operates under the W3C's -[Code of Ethics and Professional Conduct][]: - -> W3C is a growing and global community where participants choose to work -> together, and in that process experience differences in language, location, -> nationality, and experience. In such a diverse environment, misunderstandings -> and disagreements happen, which in most cases can be resolved informally. In -> rare cases, however, behavior can intimidate, harass, or otherwise disrupt one -> or more people in the community, which W3C will not tolerate. -> -> A Code of Ethics and Professional Conduct is useful to define accepted and -> acceptable behaviors and to promote high standards of professional -> practice. It also provides a benchmark for self evaluation and acts as a -> vehicle for better identity of the organization. - -We hope that our community group act according to these guidelines, and that -participants hold each other to these high standards. If you have any questions -or are worried that the code isn't being followed, please contact the Community -Group's chairs at `team-webassembly-chairs@w3.org` (note: this list is also -visible to W3C staff). For very serious concerns, the W3C has [procedures][] -allowing you to access its ombuds directly and confidentially. - - [Code of Ethics and Professional Conduct]: https://www.w3.org/Consortium/cepc - [procedures]: https://www.w3.org/Consortium/pwe/#Procedures diff --git a/Contributing.md b/Contributing.md index bc9ebdfa..1c83425c 100644 --- a/Contributing.md +++ b/Contributing.md @@ -4,6 +4,6 @@ Interested in participating? Please follow 1. the - [Code of Ethics and Professional Conduct](CodeOfConduct.md). + [Code of Conduct](CodeOfConduct.md). Also, please be sure to read [the README.md](README.md) for this repository. diff --git a/charter-template.html b/charter-template.html index 0bda282b..0d2b78f2 100644 --- a/charter-template.html +++ b/charter-template.html @@ -3,7 +3,7 @@ - <i class="todo">[name]</i> (Working|Interest) Group Charter + <i class="todo">[name]</i> <i class="todo">(Working|Interest)</i> Group Charter @@ -74,14 +74,14 @@
-

PROPOSED [name] (Working|Interest) Group Charter

+

PROPOSED [name] (Working|Interest) Group Charter

-

The mission of the [name] (Working|Interest) Group is to [do something cool and specific on the Web].

+

The mission of the [name] (Working|Interest) Group is to [do something cool and specific on the Web].

@@ -98,7 +98,7 @@

PROPOSED [name] (Working|Interest) Group Char Charter Status

@@ -138,7 +138,7 @@

PROPOSED [name] (Working|Interest) Group Char Meeting Schedule

@@ -173,7 +173,7 @@

Deliverables

-

Updated document status is available on the group publication status page. [or link to a page this group prefers to use]

+

Updated document status is available on the group publication status page. [or link to a page this group prefers to use]

Draft state indicates the state of the deliverable at the time of the charter approval. Choose one: Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state The Working Group intends to publish the latest state of their work as Candidate Recommendation (with Snapshots) and does not intend to advance their documents to Recommendation.

@@ -204,6 +204,24 @@

+
+ +

+ Tentative Deliverables +

+

Depending on the incubation progress, interest from multiple implementers, and the consensus + of the Group participants, the Working Group may adopt the following documents + as Rec-track specifications:

+
+
Web [spec name]
+
+

This specification defines [concrete description].

+

Draft state: + Proposal in [other name] Community Group

+
+
+
+

Other Deliverables @@ -241,9 +259,7 @@

Success Criteria

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.

+more implementations interoperating with each other.

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

Consider adopting a healthy testing policy, such as: To promote interoperability, all changes made to specifications @@ -274,7 +290,7 @@

Success Criteria

Coordination

For all specifications, this (Working|Interest) Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and - Interest Groups, and with the TAG. + Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The (Working|Interest) Group is encouraged to engage collaboratively with the horizontal review groups throughout development of @@ -284,7 +300,7 @@

Coordination

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

-

In addition to the above catch-all reference to horizontal review which includes accessibility review, please check with chairs and staff contacts of the Accessible Platform Architectures Working Group to determine if an additional liaison statement with more specific information about concrete review issues is needed in the list below.

+

In addition to the above catch-all reference to horizontal review which includes accessibility review, please check with chairs and staff contacts of the Accessible Platform Architectures Working Group to determine if an additional liaison statement with more specific information about concrete review issues is needed in the list below.

W3C Groups

@@ -323,7 +339,7 @@

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the - W3C Code of Ethics and Professional Conduct.

+ W3C Code of Conduct.

@@ -337,10 +353,10 @@

The meetings themselves are not open to public participation, however.

- Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the [name] (Working|Interest) Group home page. + Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the [name] (Working|Interest) Group home page.

- Most [name] (Working|Interest) Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis. + Most [name] (Working|Interest) Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.

This group primarily conducts its technical work pick one, or both, as appropriate: on the public mailing list public-[email-list]@w3.org (archive) @@ -389,7 +405,7 @@

This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications 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 licensing information. + For more information about disclosure obligations for this group, please see the licensing information.

Patent Disclosures

@@ -401,14 +417,14 @@

Patent Disclosures

produce Recommendation-track documents, when Interest Group participants review Recommendation-track specifications from Working Groups, the patent disclosure obligations do apply. For more information about disclosure obligations for this group, - please see the licensing information.

+ please see the licensing information.

Licensing

-

This (Working|Interest) Group will use the W3C Software and Document license for all its deliverables.

+

This (Working|Interest) Group will use the W3C Software and Document license for all its deliverables.

@@ -515,9 +531,10 @@

Change log

+ liability, + trademark and + permissive document license rules apply.

+

Yes, it's on GitHub!.

- See the group status page - and detailed change history. + See the group status page + and detailed change history.
- [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) + TBD
- [dd monthname yyyy] (Start date + 2 years) + TBD + 2 years
- [team contact name] (0.15 FTE) + Simone Onofri (0.25 FTE)
- Initial Charter + Initial Charter - [dd monthname yyyy] + 28 March 2024 - [dd monthname yyyy] + 28 March 2026 - none + (initial)
+ Rechartered + + TBD + +   + +

Revised

+

in-scope/out-of-scope section

+

Added Digital Credentials API

+
- DRAFT + PROPOSED
- John Fontana, Yubico
+ John Fontana, W3C Invited Expert
Anthony Nadalin, W3C Invited Expert
Team Contacts - Philippe Le Hegaret (0.05 FTE) + + Simone Onofri (0.05 FTE)
- See the group status page and detailed change history. + See the group status page and detailed change history.
- Teleconferences: topic-specific calls may be held or somthing else + Teleconferences: topic-specific calls may be held or something else
Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year.