From 9fc8ac7928e73848b2a68ecc84099179b4304402 Mon Sep 17 00:00:00 2001 From: sideshowbarker Date: Fri, 8 Mar 2024 18:48:28 +0900 Subject: [PATCH 01/41] Update 2024/btt-wg.html --- 2024/btt-wg.html | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/2024/btt-wg.html b/2024/btt-wg.html index dd6402d..b7c86d1 100644 --- a/2024/btt-wg.html +++ b/2024/btt-wg.html @@ -248,6 +248,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 @@ -491,7 +503,6 @@

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

2026-nn-nn - No changes in scope or deliverables. + AT Driver deliverable added. From 28011c2c77abfe1e9f093ee7df2e06399cb0fff8 Mon Sep 17 00:00:00 2001 From: sideshowbarker Date: Fri, 8 Mar 2024 19:45:39 +0900 Subject: [PATCH 02/41] Update 2024/btt-wg.html --- 2024/btt-wg.html | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/2024/btt-wg.html b/2024/btt-wg.html index b7c86d1..d184392 100644 --- a/2024/btt-wg.html +++ b/2024/btt-wg.html @@ -182,14 +182,24 @@

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.

+

Expected completion: [Q1–4 yyyy]

+

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

+

Expected completion: [Q1–4 yyyy]

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

+

Expected completion: [Q1–4 yyyy]

From cd971639182b48cf89d6bd06bddbe0a189f9c4a9 Mon Sep 17 00:00:00 2001 From: sideshowbarker Date: Sat, 9 Mar 2024 06:41:41 +0900 Subject: [PATCH 03/41] Update 2024/btt-wg.html --- 2024/btt-wg.html | 1 - 1 file changed, 1 deletion(-) diff --git a/2024/btt-wg.html b/2024/btt-wg.html index d184392..d3f38e3 100644 --- a/2024/btt-wg.html +++ b/2024/btt-wg.html @@ -223,7 +223,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.

From 54deaa4c44353e41857052e6879670710d6131e4 Mon Sep 17 00:00:00 2001 From: Philippe Le Hegaret Date: Tue, 12 Mar 2024 11:06:42 -0400 Subject: [PATCH 04/41] AC Feedback #2 - addition to out of scope (#486) --- 2024/wg-fedid.html | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/2024/wg-fedid.html b/2024/wg-fedid.html index 81702dc..6d2e5c1 100644 --- a/2024/wg-fedid.html +++ b/2024/wg-fedid.html @@ -191,6 +191,12 @@

Out of Scope

  • Design and discussion regarding 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
  • Interactions with identity wallets
    • From 2e1be4f6fef397e146836ffccdbdba616f476835 Mon Sep 17 00:00:00 2001 From: Pierre-Antoine Champin Date: Thu, 14 Mar 2024 18:50:20 +0100 Subject: [PATCH 05/41] Re-introduce wording about seeking consensus (#474) --- 2023/did-wg.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2023/did-wg.html b/2023/did-wg.html index 952a4f0..4c71614 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.

    From 2e1d3571d2bc1525c7543deab29ccb34044dff14 Mon Sep 17 00:00:00 2001 From: Pierre-Antoine Champin Date: Thu, 14 Mar 2024 19:04:01 +0100 Subject: [PATCH 06/41] adding known chairs --- 2023/did-wg.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2023/did-wg.html b/2023/did-wg.html index 4c71614..7812121 100644 --- a/2023/did-wg.html +++ b/2023/did-wg.html @@ -116,7 +116,7 @@

    PROPOSED Decentralized Identifier Working Gro Chairs - TBD + Daniel Burnett (Invited Expert), Gabe Cohen (Block, Inc) From 2f8766b7296748fc9dcf9fbaa84aafb591c4a2c0 Mon Sep 17 00:00:00 2001 From: Chris Lilley Date: Mon, 18 Mar 2024 09:02:56 -0400 Subject: [PATCH 07/41] Removed duplicate text from success criteria, fix #485 --- charter-template.html | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/charter-template.html b/charter-template.html index 0bda282..4b8c514 100644 --- a/charter-template.html +++ b/charter-template.html @@ -241,9 +241,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 From b7e025dfd5f9bf13c568bfd3235ba89fe0b58485 Mon Sep 17 00:00:00 2001 From: plehegar Date: Mon, 18 Mar 2024 11:56:05 -0400 Subject: [PATCH 08/41] Align with https://github.com/w3c/charter-drafts/commit/2f8766b7296748fc9dcf9fbaa84aafb591c4a2c0 --- 2024/wg-webauthn.html | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/2024/wg-webauthn.html b/2024/wg-webauthn.html index b7cfa80..51c7989 100644 --- a/2024/wg-webauthn.html +++ b/2024/wg-webauthn.html @@ -300,9 +300,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.

    From 02098e1bef54dabaeadfb5f5ec3a9ea02aa71537 Mon Sep 17 00:00:00 2001 From: plehegar Date: Mon, 18 Mar 2024 11:58:33 -0400 Subject: [PATCH 09/41] John is now an IE --- 2024/wg-webauthn.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2024/wg-webauthn.html b/2024/wg-webauthn.html index 51c7989..a6e4647 100644 --- a/2024/wg-webauthn.html +++ b/2024/wg-webauthn.html @@ -125,7 +125,7 @@

    DRAFT: Web Authentication Working Group Charter

    Chairs - John Fontana, Yubico
    + John Fontana, W3C Invited Expert
    Anthony Nadalin, W3C Invited Expert From a29e1defa19b0647c0b6180678f75ff7ddbc9d85 Mon Sep 17 00:00:00 2001 From: plehegar Date: Mon, 18 Mar 2024 15:24:05 -0400 Subject: [PATCH 10/41] Added Simone on WebAuthn --- 2024/wg-webauthn.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/2024/wg-webauthn.html b/2024/wg-webauthn.html index a6e4647..b2572d0 100644 --- a/2024/wg-webauthn.html +++ b/2024/wg-webauthn.html @@ -134,7 +134,8 @@

    DRAFT: Web Authentication Working Group Charter

    Team Contacts - Philippe Le Hegaret (0.05 FTE) + Simone Onofri (0.05 FTE) From a99574f6395a1a4a5315c298ae37808fc80ff37e Mon Sep 17 00:00:00 2001 From: plehegar Date: Mon, 18 Mar 2024 15:25:00 -0400 Subject: [PATCH 11/41] Removed todo --- 2024/wg-webauthn.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2024/wg-webauthn.html b/2024/wg-webauthn.html index b2572d0..627712f 100644 --- a/2024/wg-webauthn.html +++ b/2024/wg-webauthn.html @@ -133,7 +133,7 @@

    DRAFT: Web Authentication Working Group Charter

    Team Contacts - + Simone Onofri (0.05 FTE) From db1ddb6664e971c5fbc89a6e886a043a2b9a28eb Mon Sep 17 00:00:00 2001 From: simoneonofri Date: Wed, 20 Mar 2024 19:06:13 +0100 Subject: [PATCH 12/41] Fix typo in charter-template.html (#490) Fixed a typo --- charter-template.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/charter-template.html b/charter-template.html index 4b8c514..07dfe96 100644 --- a/charter-template.html +++ b/charter-template.html @@ -138,7 +138,7 @@

    PROPOSED [name] (Working|Interest) Group Char Meeting Schedule - 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. From 0422ebe2d0387e2c9e975eb411b34325ce498da0 Mon Sep 17 00:00:00 2001 From: Philippe Le Hegaret Date: Wed, 20 Mar 2024 15:12:41 -0400 Subject: [PATCH 13/41] [wg/webauthn] Tilt changes for WebAuthn charter 2024 (#491) * Charter status * Testing policy * Security considerations * Refresh FIDO2 references --- 2024/wg-webauthn.html | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/2024/wg-webauthn.html b/2024/wg-webauthn.html index 627712f..2fffe87 100644 --- a/2024/wg-webauthn.html +++ b/2024/wg-webauthn.html @@ -72,7 +72,7 @@
    -

    DRAFT: Web Authentication Working Group Charter

    +

    PROPOSED: Web Authentication Working Group Charter

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

    DRAFT: Web Authentication Working Group Charter

    Charter Status - DRAFT + PROPOSED @@ -303,11 +303,19 @@

    Success Criteria

    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.

    - +

    + 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 @@ -364,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.
    From 67b721aa38d3821b583491dce82777f9f689027c Mon Sep 17 00:00:00 2001 From: simoneonofri Date: Tue, 26 Mar 2024 12:54:49 +0100 Subject: [PATCH 14/41] First commit for Security IG Charter first draft of the Security IG Charter to talk about it all together. --- 2024/ig-security.html | 430 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 430 insertions(+) create mode 100644 2024/ig-security.html diff --git a/2024/ig-security.html b/2024/ig-security.html new file mode 100644 index 0000000..f02dd8b --- /dev/null +++ b/2024/ig-security.html @@ -0,0 +1,430 @@ + + + + + + <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.

    + + +
    +

    Join the Security Interest 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 + + 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 risks as possible, or mitigates those risks.

    +

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

    + 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 Ethics and Professional 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.

    + +
    +
    +
    + +
    + + + + + From 7fa74e9ea3801a4454768f0a71316ac3ba231182 Mon Sep 17 00:00:00 2001 From: sideshowbarker Date: Thu, 28 Mar 2024 12:04:29 +0900 Subject: [PATCH 15/41] Update 2024/btt-wg.html --- 2024/btt-wg.html | 1 - 1 file changed, 1 deletion(-) diff --git a/2024/btt-wg.html b/2024/btt-wg.html index d3f38e3..a9a75d2 100644 --- a/2024/btt-wg.html +++ b/2024/btt-wg.html @@ -183,7 +183,6 @@

    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.

    -

    Expected completion: [Q1–4 yyyy]

    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. From 25b5a5eed34c086229a4d56a753a6d0a66d872e6 Mon Sep 17 00:00:00 2001 From: sideshowbarker Date: Thu, 28 Mar 2024 14:59:17 +0900 Subject: [PATCH 16/41] Update 2024/btt-wg.html --- 2024/btt-wg.html | 2 -- 1 file changed, 2 deletions(-) diff --git a/2024/btt-wg.html b/2024/btt-wg.html index a9a75d2..535903e 100644 --- a/2024/btt-wg.html +++ b/2024/btt-wg.html @@ -192,13 +192,11 @@

    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

    -

    Expected completion: [Q1–4 yyyy]

    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

    -

    Expected completion: [Q1–4 yyyy]

    From c40562cae70bad957e2bfd122bab5aeebccd43c2 Mon Sep 17 00:00:00 2001 From: simoneonofri Date: Thu, 28 Mar 2024 12:20:25 +0100 Subject: [PATCH 17/41] Create Security Web Application Guidelines (SWAG) Community Group Charter --- 2024/swag-cg.html | 318 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 318 insertions(+) create mode 100644 2024/swag-cg.html diff --git a/2024/swag-cg.html b/2024/swag-cg.html new file mode 100644 index 0000000..8621b02 --- /dev/null +++ b/2024/swag-cg.html @@ -0,0 +1,318 @@ + + + + + Security Web Application Guidelines (SWAG) Community Group Charter + + + + + + + +

    + [DRAFT] Security Web Application Guidelines (SWAG) Community Group Charter +

    +

    + {TBD: remove next sentence before submitting for + approval} This Charter is work in progress. To submit feedback, + please use + GitHub Repository Issue where Charter is being developed. +

    +
      +
    • This Charter: https://w3c.github.io/charter-drafts/2024/cg-swag.html +
      • +
    • Previous Charter: N/A +
      • +
    • Start Date: {TBD: date the charter takes effect, + estimate if not known. Update this if the charter is revised and include + a link to the previous version of the charter.} +
      • +
    • Last Modifed: {TBD: If the system does not + automatically provide information about the date of the last + modification, it can be useful to include that in the charter.} +
      • +
    +

    + Goals +

    +

    + The mission of this Community Group is to increase the overall security + of web application development, thereby making the + web a more + secure platform for web users. + It will accomplish this by writing web developers security best practices + and providing a platform for stakeholder collaboration. +

    +

    + Scope of Work +

    +

    This Community will:

    +
      +
    • Clarify documentation needs to inform security documentation writers, which will include: +
        +
      • Web Application Security Developer's Principles.
        • +
      • Threat Models.
        • +
      • Theory, Attacks, Practices and Tools.
        • +
      +
      • +
    • Develop a set of security best practices for web developers and product owners. This includes: +
        +
      • Framework/Library secure development best practices.
        • +
      • WebAssembly secure development best practices.
        • +
      • Integrating software supply chain approaches to ease security assessments.
        • +
      • Formulating end-user stories related to security to inform groups developing technical APIs and policymakers developing regulations.
        • +
      +
      • +
    • Coordinate actions with external organizations: +
        +
      • It could include one or more joint deliverables.
        • +
      • It could include joint communication.
        • +
      • Integrating software supply chain approaches to ease security assessments.
        • +
      • Formulating end-user stories related to security to inform groups developing technical APIs and policymakers developing regulations.
        • +
      +
      • +
    • Review possible directions to sanitize web APIs in isolated contexts (compartments).
      • +
    • Track specifications and vendor implementations related to security.
      • +
    • ...What should build tools do to assure that nobody is hijacking the process?
      • +
    • ...helping to bring security best practices into the default developer lifecycle for web developers
      • +
    • ...helping package managers become more responsible about their dependency checking
      • +
    • ...work with Security IG to help develop security principles that can be used in wide reviews
      • +
    +

    + Out of Scope +

    +

    + The development of normative standards and technical specifications is not in the scope of the Community Group. +

    +

    + This group does not perform horizontal reviews for security at W3C; that is the responsibility of the Security Interest Group (SING). +

    + +

    + Deliverables +

    +

    + Non-Normative Reports +

    +
      +
    • Application Developer’s security best practices, by the end of 2025.
      • +
    +

    + The group may produce other Community Group Reports within the scope of + this charter but that are not Specifications, for instance use cases, + requirements, or white papers. +

    +

    + Test Suites and Other Software +

    +

    + The group MAY produce test suites to support the Specifications. Please + see the GitHub LICENSE file for test suite contribution licensing + information. +

    +

    + Dependencies or Liaisons +

    +
      +
    • OpenSSF
      • +
    • OWASP
      • +
    • OpenJS Foundation
      • +
    • ...
      • +
    +

    + Community and Business Group Process +

    +

    + The group operates under the Community and Business + Group Process. Terms in this Charter that conflict with those of the + Community and Business Group Process are void. +

    +

    + As with other Community Groups, W3C seeks organizational licensing + commitments under the W3C Community + Contributor License Agreement (CLA). When people request to + participate without representing their organization's legal interests, + W3C will in general approve those requests for this group with the + following understanding: W3C will seek and expect an organizational + commitment under the CLA starting with the individual's first request to + make a contribution to a group Deliverable. + The section on Contribution Mechanics describes + how W3C expects to monitor these contribution requests. +

    + +

    + The W3C Code of + Ethics and Professional Conduct applies to participation in + this group. +

    + +

    + Work Limited to Charter Scope +

    +

    + The group will not publish Specifications on topics other than those + listed under Specifications above. See + below for how to modify the charter. +

    +

    + Contribution Mechanics +

    +

    + Substantive Contributions to Specifications can only be made by Community + Group Participants who have agreed to the W3C Community + Contributor License Agreement (CLA). +

    +

    + Specifications created in the Community Group must use the + W3C Software and Document License. All other documents produced by + the group should use that License where possible. +

    +

    + {TBD: if CG doesn't use GitHub replace the remaining paragraphs in this + section with: "All Contributions are made on the groups public mail list + or public contrib list"} +

    +

    + Community Group participants agree to make all contributions in the + GitHub repo the group is using for the particular document. This may be + in the form of a pull request (preferred), by raising an issue, or by + adding a comment to an existing issue. +

    +

    + All Github repositories attached to the Community Group must contain a + copy of the CONTRIBUTING + and LICENSE + files. +

    +

    + Transparency +

    +

    + The group will conduct all of its technical work in public. If the group + uses GitHub, all technical work will occur in its GitHub repositories + (and not in mailing list discussions). This is to ensure contributions + can be tracked through a software tool. +

    +

    + Meetings may be restricted to Community Group participants, but a public + summary or minutes must be posted to the group's public mailing list, or + to a GitHub issue if the group uses GitHub. +

    +

    + Decision Process +

    +

    + If the decision policy is documented somewhere, update this section accordingly to link to it. +

    +

    + This group will seek to make decisions where there is consensus. Groups + are free to decide how to make decisions (e.g. Participants who have + earned Committer status for a history of useful contributions assess + consensus, or the Chair assesses consensus, or where consensus isn't + clear there is a Call for Consensus [CfC] to allow multi-day online + feedback for a proposed course of action). It is expected that + participants can earn Committer status through a history of valuable + contributions as is common in open source projects. After discussion and + due consideration of different opinions, a decision should be publicly + recorded (where GitHub is used as the resolution of an Issue). +

    +

    + If substantial disagreement remains (e.g. the group is divided) and the + group needs to decide an Issue in order to continue to make progress, the + Committers will choose an alternative that had substantial support (with + a vote of Committers if necessary). Individuals who disagree with the + choice are strongly encouraged to take ownership of their objection by + taking ownership of an alternative fork. This is explicitly allowed (and + preferred to blocking progress) with a goal of letting implementation + experience inform which spec is ultimately chosen by the group to move + ahead with. +

    +

    + Any decisions reached at any meeting are tentative and should be recorded + in a GitHub Issue for groups that use GitHub and otherwise on the group's + public mail list. Any group participant may object to a decision reached + at an online or in-person meeting within 7 days of publication of the + decision provided that they include clear technical reasons for their + objection. The Chairs will facilitate discussion to try to resolve the + objection according to this decision process. +

    +

    + It is the Chairs' responsibility to ensure that the decision process is + fair, respects the consensus of the CG, and does not unreasonably favour + or discriminate against any group participant or their employer. +

    +

    + Chair Selection +

    +

    + Participants in this group choose their Chair(s) and can replace their + Chair(s) at any time using whatever means they prefer. However, if 5 + participants, no two from the same organisation, call for an election, + the group must use the following process to replace any current Chair(s) + with a new Chair, consulting the Community Development Lead on election + operations (e.g., voting infrastructure and using RFC 2777). +

    +
      +
    1. Participants announce their candidacies. Participants have 14 days to + announce their candidacies, but this period ends as soon as all + participants have announced their intentions. If there is only one + candidate, that person becomes the Chair. If there are two or more + candidates, there is a vote. Otherwise, nothing changes. +
      2. +
    2. Participants vote. Participants have 21 days to vote for a single + candidate, but this period ends as soon as all participants have voted. + The individual who receives the most votes, no two from the same + organisation, is elected chair. In case of a tie, RFC2777 is used to + break the tie. An elected Chair may appoint co-Chairs. +
      3. +
    +

    + Participants dissatisfied with the outcome of an election may ask the + Community Development Lead to intervene. The Community Development Lead, + after evaluating the election, may take any action including no action. +

    +

    + Amendments to this Charter +

    +

    + The group can decide to work on a proposed amended charter, editing the + text using the Decision Process described above. + The decision on whether to adopt the amended charter is made by + conducting a 30-day vote on the proposed new charter. The new charter, if + approved, takes effect on either the proposed date in the charter itself, + or 7 days after the result of the election is announced, whichever is + later. A new charter must receive 2/3 of the votes cast in the approval + vote to pass. The group may make simple corrections to the charter such + as deliverable dates by the simpler group decision process rather than + this charter amendment process. The group will use the amendment process + for any substantive changes to the goals, scope, deliverables, decision + process or rules for amending the charter. +

    + + From 1e9b4afe217aa915f366ee5ce983f39cf6d21330 Mon Sep 17 00:00:00 2001 From: Philippe Le Hegaret Date: Thu, 28 Mar 2024 17:12:30 -0400 Subject: [PATCH 18/41] Initial (#493) --- 2024/ig-exploration.html | 477 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 477 insertions(+) create mode 100644 2024/ig-exploration.html diff --git a/2024/ig-exploration.html b/2024/ig-exploration.html new file mode 100644 index 0000000..5ac1b85 --- /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. +

    + +
    +

    Join the Exploration Interest Group.

    +
    + + +

    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 people who are unfamiliar + with our processes and systems, to understand the organization;
      • +
    • New workshops: it's relevant and need to have align 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 respectful presentation of + competing perspectives on them. 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 CG on the value of the topic + for the web;
      • +
    • Chartering: there is a charter but need to measure the interest + from 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 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 AB 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. + 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.

    + +
    +
    +
    + +
    + + + + + From 3393ebf472f41e74156d3571131ff96644b689da Mon Sep 17 00:00:00 2001 From: simoneonofri Date: Mon, 1 Apr 2024 22:35:27 +0200 Subject: [PATCH 19/41] Update ig-security.html: added references and some wording --- 2024/ig-security.html | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/2024/ig-security.html b/2024/ig-security.html index f02dd8b..57bc54d 100644 --- a/2024/ig-security.html +++ b/2024/ig-security.html @@ -55,7 +55,7 @@
  • Background
  • Scope
  • Deliverables
    • -
  • Success Criteria
    • +
  • Success Criteria
  • Coordination
  • Participation
  • Communication
    • @@ -85,9 +85,9 @@

    PROPOSED Security Interest Group Charter

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

    @@ -150,8 +150,8 @@

    PROPOSED Security Interest Group Charter

    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 risks as possible, or mitigates those risks.

    +

    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.

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

    External Organizations

    IETF
    OpenSSF
    OWASP
    +
    OpenJS Foundation
    ...
    From bcb859181642588a387ec2c9473de736007d5571 Mon Sep 17 00:00:00 2001 From: simoneonofri Date: Tue, 2 Apr 2024 11:21:37 +0200 Subject: [PATCH 20/41] Update ig-security.html: added coordination with ISECOM --- 2024/ig-security.html | 1 + 1 file changed, 1 insertion(+) diff --git a/2024/ig-security.html b/2024/ig-security.html index 57bc54d..6d96776 100644 --- a/2024/ig-security.html +++ b/2024/ig-security.html @@ -221,6 +221,7 @@

    External Organizations

    OpenSSF
    OWASP
    OpenJS Foundation
    +
    ISECOM
    ...
    From c199047f36b5db668b6bde964ea350a160d43bb6 Mon Sep 17 00:00:00 2001 From: simoneonofri Date: Tue, 2 Apr 2024 11:23:39 +0200 Subject: [PATCH 21/41] Update swag-cg.html: added liaisons with ISECOM --- 2024/swag-cg.html | 1 + 1 file changed, 1 insertion(+) diff --git a/2024/swag-cg.html b/2024/swag-cg.html index 8621b02..4064bdc 100644 --- a/2024/swag-cg.html +++ b/2024/swag-cg.html @@ -136,6 +136,7 @@

  • OpenSSF
  • OWASP
  • OpenJS Foundation
    • +
  • ISECOM
  • ...

    • From e8e4adf296af796e68dde35be110151973cd5945 Mon Sep 17 00:00:00 2001 From: Coralie Mercier Date: Tue, 2 Apr 2024 14:41:12 +0200 Subject: [PATCH 22/41] Quality Assurance --- 2024/ig-exploration.html | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/2024/ig-exploration.html b/2024/ig-exploration.html index 5ac1b85..3cf9a74 100644 --- a/2024/ig-exploration.html +++ b/2024/ig-exploration.html @@ -156,27 +156,27 @@

    Motivation and Background

    • New ideas and dimensions: a new human step may impact - the Web, e.g. "autonomous L4/L5 cars", "one continent + 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 people who are unfamiliar +
    • New people: a welcoming point for Members/people who are unfamiliar with our processes and systems, to understand the organization;
      • -
    • New workshops: it's relevant and need to have align around the - next steps for W3C, e.g. "generative AI", "Digital Identity on +
    • 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 respectful presentation of - competing perspectives on them. The analyses would summarize + 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 CG on the value of the topic - for the web;
      • -
    • Chartering: there is a charter but need to measure the interest - from W3C community at large and make it fit in the larger - picture, e.g. Real Estate IG.
      • + 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.

    @@ -186,7 +186,7 @@

    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 Web users, accelerate chartering investigations + for the benefit of the Web users, accelerate chartering investigations and endeavors, and continually strengthen the innovation of W3C.

      @@ -209,7 +209,7 @@

      Scope

    • Discuss how to continue improving the exploration and - investigation process, and propose improvements to the AB and the + investigation process, and propose improvements to the W3C Advisory Board and the W3C Team.
    @@ -293,7 +293,7 @@

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

    From 938cc8c7a4592605dfa0b8a6af077325073bda4f Mon Sep 17 00:00:00 2001 From: plehegar Date: Thu, 28 Mar 2024 17:24:35 -0400 Subject: [PATCH 23/41] New Code of Conduct --- 2024/btt-wg.html | 2 +- 2024/ig-security.html | 2 +- 2024/immersive-web-wg.html | 2 +- 2024/svg-wg.html | 2 +- 2024/wg-webauthn.html | 2 +- CODE_OF_CONDUCT.md | 3 +++ CodeOfConduct.md | 26 -------------------------- Contributing.md | 2 +- charter-template.html | 2 +- 9 files changed, 10 insertions(+), 33 deletions(-) create mode 100644 CODE_OF_CONDUCT.md delete mode 100644 CodeOfConduct.md diff --git a/2024/btt-wg.html b/2024/btt-wg.html index 535903e..9357511 100644 --- a/2024/btt-wg.html +++ b/2024/btt-wg.html @@ -280,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.

    diff --git a/2024/ig-security.html b/2024/ig-security.html index 6d96776..40a38d3 100644 --- a/2024/ig-security.html +++ b/2024/ig-security.html @@ -239,7 +239,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/2024/immersive-web-wg.html b/2024/immersive-web-wg.html index dce4fc1..cb620b4 100644 --- a/2024/immersive-web-wg.html +++ b/2024/immersive-web-wg.html @@ -759,7 +759,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.

    diff --git a/2024/svg-wg.html b/2024/svg-wg.html index 37c82d5..79ccf3e 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.

    diff --git a/2024/wg-webauthn.html b/2024/wg-webauthn.html index 2fffe87..53b7486 100644 --- a/2024/wg-webauthn.html +++ b/2024/wg-webauthn.html @@ -394,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 0000000..2d3ac15 --- /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 a3c2c8b..0000000 --- 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 bc9ebdf..1c83425 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 07dfe96..f3709f9 100644 --- a/charter-template.html +++ b/charter-template.html @@ -321,7 +321,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.

    From 92acc8cf0d09c5dd52bdf48986ad98e5522b7a48 Mon Sep 17 00:00:00 2001 From: Bert Bos Date: Wed, 3 Apr 2024 16:39:16 +0200 Subject: [PATCH 24/41] Draft for discussion by the SDW WG. --- 2024/sdw-wg.html | 948 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 948 insertions(+) create mode 100644 2024/sdw-wg.html diff --git a/2024/sdw-wg.html b/2024/sdw-wg.html new file mode 100644 index 0000000..e7874c4 --- /dev/null +++ b/2024/sdw-wg.html @@ -0,0 +1,948 @@ + + + + + + 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: + +

      +
    • develop and maintain vocabularies and best practices that + encourage better sharing of spatial data on the Web; + +
    • identify areas where standards should be developed jointly by both W3C and the Open Geospatial Consortium + (OGC). +
    + + +
    +

    W3C Members join the + Spatial Data on the Web Working Group; OGC Members + should contact the Chairs or Staff Contact to join the 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. +
    +
    + +
    +

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

      +
    • Create and maintain geospatial Web standards and + geospatial profiles of more general standards as enumerated + in deliverables. + +
    • Coordinate among incubation groups, by providing a forum + where early ideas for geospatial Web standards can be + shared, identifying ideas for further standardisation by + W3C and/or OGC, and making recommendations about these + incubations to the relevant standards body or bodies. + Related incubation will generally happen in W3C Community + Groups and OGC Innovation Program initiatives. + +
    • Respond to requests from OGC Architecture Board (OAB) + and W3C Technical Architecture Group (TAG) to review + materials relating to Geospatial Web standards, and + proactively bring relevant matters to the attention of the + OAB and TAG. + +
    • Periodically review and amend the OGC Technology Trends, + OGC Innovation Program ideas issue tracker and W3C strategic incubation pipeline ("funnel") to + identify, prioritise and track important ideas relating to + geospatial Web standards. +
    + +
    +

    Out of Scope

    + +

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

      +
    • 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: + +

    Consider making a second list for existing + specifications that the group will maintain. + +

      +
    • Time Ontology in OWL +
        +
      • Draft state: Adopted + +
      • Expected completion: [Q1–4 yyyy] + +
      • Latest Publication: 2022-11-15 + +
      • Exclusion Draft: https://www.w3.org/TR/2017/CR-owl-time-20170606/ + +
      • Associated Call for Exclusion on 2017-06-06 ended on + 2017-08-05 + +
      • Produced under Working Group Charter: http://www.w3.org/2015/spatial/charter + +
      • Abstract: OWL-Time is an OWL-2 DL ontology of + temporal concepts, for describing the temporal + properties of resources in the world or described in + Web pages. The ontology provides a vocabulary for + expressing facts about topological (ordering) + relations among instants and intervals, together with + information about durations, and about temporal + position including date-time information. Time + positions and durations may be expressed using either + the conventional (Gregorian) calendar and clock, or + using another temporal reference system such as + Unix-time, geologic time, or different calendars. +
      + +
    • Semantic Sensor Network Ontology +
        +
      • Draft state: Adopted + +
      • Expected completion: N/A + +
      • Latest publication: 2017-10-19 +
      +
    +
    + +
    +

    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 + developers when designing applications. +
    +
    + +
    +

    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

    + +

    Check this list + +

    +
    Web of Things Interest Group and Working Group + +
    The Web of Things is heavily dependent on location + data. Cooperation and interoperability of specifications + is essential. + +
    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. + +
    Semantic Statistics Community Group + +
    The Statistical Data on the Web Best Practices + deliverable will not be restricted to geospatial + statistics data. The Spatial Data on the Web Working + Group expects to maintain a close liaison with the + Semantic Statistics Community Group to gather feedback + and contributions from organizations publishing open data + such as National Statistics Offices. + +
    Linked + Building Data Community Group + +
    The Linked Building Data Community Group brings + together experts in the area of building information + modelling (BIM) and Web of Data technologies to define + existing and future use cases and requirements for linked + data based applications and corresponding ontologies + across the life cycle of buildings. + +
    Linked + Data for Accessibility Community Group + +
    The Linked Data for Accessibility Community Group’s + mission is to make accessibility information about + buildings, services and routes easier to find — + everywhere where people need it. + +
    Automotive and Transportation Business Group + +
    The Automotive and Transportation Business Group, soon + to be renamed and relaunched as the Automotive and + Transportation Business Group has been exploring the use + cases and challenge of off-boarding vehicle information + to the cloud and how this information fits within the + broader transportation sector. It is taking a data + centric focus and working on an ontology for vehicle + signals and coordinating effort with OGC, SDWWG, ISO + SmartCities, ISO Intelligent Transportation Systems and + others on transportation related ontologies. + +
    Maps For HTML Community Group + +
    The Maps For HTML Community Group seeks to establish + maps as a first class object on the web similar to the + Media and Entertainment activity did for video, allowing + for layering and customizing data on a scale not + currently possible with proprietary online map offerings. + +
    Augmented + Reality Community Group + +
    The Augmented Reality Community Group is an open forum + for collaborative discussions about the intersection of + Augmented Reality and the Web. + +
    Immersive Web Working + Group and Community Group + +
    These groups helps bring high-performance Virtual + Reality (VR) and Augmented Reality (AR) (collectively + known as XR) to the open Web. + +
    Media and + Entertainment Interest Group + +
    The Media and Entertainment Interest Group provides a + forum for media-related technical discussions and + includes the Media Timed Events Task Force, which is + relevant for WebVMT coordination. +
    +
    + +
    +

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

    +
    GeoPose SWG + +
    Linking the W3C and OGC work on virtual, augmented and + mixed reality. + +
    Metadata DWG (DCAT sub-group) + +
    Linking the W3C and OGC work on dataset description + and profiles. + +
    SensorThings SWG + +
    Linking work on SSN in W3C with the OGC SensorThings + API. + +
    Sensor Web Enablement (SWE) DWG + +
    Linking work on SSN in W3C with the open interfaces + for sensor web applications developed at OGC. + +
    Observations and Measurements v2 SWG + +
    Linking work on SSN in W3C with the data model for + Observations and Measurements at OGC. + +
    OGC API Standards + Working Groups + +
    These Working Groups develop the OGC API suite of + Standards that will likely be discussed within the + Spatial Data on the Web Working Group. + +
    Mobile Location Services DWG + +
    Linking the W3C and OGC work on location-aware mobile + services. + +
    GeoSemantics DWG + +
    Linking the W3C and OGC work on semantics and linked + data. +
    +
    + +
    +

    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.

    +
    +
    +
    + +
    + + From 52d745c388a7777b09d27d8bf1dc0b3bb285737c Mon Sep 17 00:00:00 2001 From: Florian Scholz Date: Thu, 4 Apr 2024 15:33:19 +0200 Subject: [PATCH 25/41] Add Open Web Docs as liaison to SWAG CG --- 2024/swag-cg.html | 1 + 1 file changed, 1 insertion(+) diff --git a/2024/swag-cg.html b/2024/swag-cg.html index 4064bdc..8690746 100644 --- a/2024/swag-cg.html +++ b/2024/swag-cg.html @@ -137,6 +137,7 @@

  • OWASP
  • OpenJS Foundation
  • ISECOM
    • +
  • Open Web Docs
  • ...

    • From 28cf91037bd7dcd88cb11728cba4d7660b534b63 Mon Sep 17 00:00:00 2001 From: simoneonofri Date: Tue, 16 Apr 2024 19:06:07 +0200 Subject: [PATCH 26/41] Drafting: revised, in-scope/out-of-scope section, Added Digital Credentials API --- 2024/wg-fedid.html | 112 +++++++++++++++++++++++++-------------------- 1 file changed, 62 insertions(+), 50 deletions(-) diff --git a/2024/wg-fedid.html b/2024/wg-fedid.html index 6d2e5c1..55fad93 100644 --- a/2024/wg-fedid.html +++ b/2024/wg-fedid.html @@ -73,15 +73,10 @@ -
    -

    PROPOSED Federated Identity Working Group Charter

    - +

    Federated Identity Working Group Charter

    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.

    - + is to develop specifications that allow a website to request an identity credential from a credential container (e.g., 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.

    Join the Federated Identity Working @@ -110,7 +105,7 @@

    PROPOSED Federated Identity Working Group Charter

    Start date - [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) + 28 March 2024 @@ -118,7 +113,7 @@

    PROPOSED Federated Identity Working Group Charter

    End date - [dd monthname yyyy] (Start date + 2 years) + 28 March 2026 @@ -135,8 +130,8 @@

    PROPOSED Federated Identity Working Group Charter

    Team Contacts -     [team contact name] (0.15 FTE) + Simone Onofri (0.25 FTE) @@ -156,50 +151,36 @@

    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 has a role in fostering an ecosystem where privacy, security, and user sovereignty are all taken into account. 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 fashion in a manner that is compatible with identity request/response protocols like mDoc, Verifiable Credentials, and OpenID4VP. +

    +

    + One of the initial hurdles is ensuring support for federated identity while adhering to privacy principles, + despite the deprecation of + third-party cookies, a cornerstone of such operations.

    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 digital credentials 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). The result of this work is the development of 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 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.

    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
      • - +
    • 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
      • - -
    • Interactions with identity wallets
      • +
    • Ad-tech tools or APIs specifically focused on advertising as opposed to authentication.
    @@ -238,7 +219,7 @@

    Expected completion: CR in Q1 2025

    -
    Login Status API +
    Login Status API

    This specification defines an API to inform the Web Application of their user's @@ -252,6 +233,17 @@

    Expected completion: CR in Q1 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 documents:

    +
    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: Adopted from the + Web Incubator Community Group +

    +

    Expected completion: CR in Q4 2025

    +
    @@ -271,14 +263,19 @@

  • 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
      • +
    • Q4 2024: FPWD for Digital Credentials API
    • Q1 2025: CR for Federated Credential Management API
      • +
    • Q4 2025: CR for Digital Credentials API
      • +
    @@ -310,16 +307,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 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.

    @@ -370,7 +366,7 @@

    W3C Groups

    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.

    +
    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. @@ -565,18 +561,34 @@

    - Initial Charter + Initial Charter - [dd monthname yyyy] + 28 March 2024 - [dd monthname yyyy] + 28 March 2026 - none + (initial) + + +   + + + @@ June 2024 + + +   + + +

    Revised

    +

    in-scope/out-of-scope section

    +

    Added Digital Credentials API

    + + -

    This proposed charter is available +

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

    From fe68b0aed8967f226e7046a15079f9f2ef5104c0 Mon Sep 17 00:00:00 2001 From: Bert Bos Date: Wed, 17 Apr 2024 01:29:02 +0200 Subject: [PATCH 28/41] Merged elements from Simon's draft Simon's draft is https://github.com/w3c/sdw-sosa-ssn/blob/new-charter/charter/index.html (preview at https://raw.githack.com/w3c/sdw-sosa-ssn/new-charter/charter/index.html) --- 2024/sdw-wg.html | 286 +++++++++++++++++------------------------------ 1 file changed, 104 insertions(+), 182 deletions(-) diff --git a/2024/sdw-wg.html b/2024/sdw-wg.html index e7874c4..7259339 100644 --- a/2024/sdw-wg.html +++ b/2024/sdw-wg.html @@ -109,6 +109,11 @@

    PROPOSED Spatial Data on the Web Working Group href="https://www.w3.org/groups/wg/sdw/join">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 @@ -146,6 +151,8 @@

    PROPOSED Spatial Data on the Web Working Group Chairs [chair name] (affiliation) + Team Contacts @@ -162,6 +169,11 @@

    PROPOSED Spatial Data on the Web Working Group 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.

    @@ -179,9 +191,15 @@

    Scope

    The Spatial Data on the Web WG will:

      -
    • Create and maintain geospatial Web standards and - geospatial profiles of more general standards as enumerated - in deliverables. +
    • Maintain and update the SSN Ontology, including the SOSA + vocabulary. + +
    • Support the development of resources required to support + the adoption of the SSN ontology. + +
    • Maintain geospatial Web standards and geospatial + profiles of more general standards as enumerated in + deliverables.
    • Coordinate among incubation groups, by providing a forum where early ideas for geospatial Web standards can be @@ -209,14 +227,9 @@

      Scope

      Out of Scope

      -

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

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

      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.

      @@ -239,8 +252,45 @@

      Normative Specifications

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

      Consider making a second list for existing - specifications that the group will maintain. +

        +
      • 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:

      • Normative Specifications
      • Produced under Working Group Charter: http://www.w3.org/2015/spatial/charter - -
      • Abstract: OWL-Time is an OWL-2 DL ontology of - temporal concepts, for describing the temporal - properties of resources in the world or described in - Web pages. The ontology provides a vocabulary for - expressing facts about topological (ordering) - relations among instants and intervals, together with - information about durations, and about temporal - position including date-time information. Time - positions and durations may be expressed using either - the conventional (Gregorian) calendar and clock, or - using another temporal reference system such as - Unix-time, geologic time, or different calendars. -
      - -
    • Semantic Sensor Network Ontology -
        -
      • Draft state: Adopted - -
      • Expected completion: N/A - -
      • Latest publication: 2017-10-19
      -
    - - -
    -

    Other Deliverables

    - +
    + +
    +

    Other Deliverables

    Other non-normative documents may be created such as:

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

    Coordination

    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 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 @@ -514,17 +543,7 @@

    Coordination

    W3C Groups

    -

    Check this list -

    -
    Web of Things Interest Group and Working Group - -
    The Web of Things is heavily dependent on location - data. Cooperation and interoperability of specifications - is essential. -
    Dataset Exchange Working Group @@ -532,83 +551,10 @@

    W3C Groups

    such as coordinate reference system, granularity. These must be taken into account by the DXWG. -
    Semantic Statistics Community Group - -
    The Statistical Data on the Web Best Practices - deliverable will not be restricted to geospatial - statistics data. The Spatial Data on the Web Working - Group expects to maintain a close liaison with the - Semantic Statistics Community Group to gather feedback - and contributions from organizations publishing open data - such as National Statistics Offices. - -
    Linked - Building Data Community Group +
    Devices + and Sensors Working Group -
    The Linked Building Data Community Group brings - together experts in the area of building information - modelling (BIM) and Web of Data technologies to define - existing and future use cases and requirements for linked - data based applications and corresponding ontologies - across the life cycle of buildings. - -
    Linked - Data for Accessibility Community Group - -
    The Linked Data for Accessibility Community Group’s - mission is to make accessibility information about - buildings, services and routes easier to find — - everywhere where people need it. - -
    Automotive and Transportation Business Group - -
    The Automotive and Transportation Business Group, soon - to be renamed and relaunched as the Automotive and - Transportation Business Group has been exploring the use - cases and challenge of off-boarding vehicle information - to the cloud and how this information fits within the - broader transportation sector. It is taking a data - centric focus and working on an ontology for vehicle - signals and coordinating effort with OGC, SDWWG, ISO - SmartCities, ISO Intelligent Transportation Systems and - others on transportation related ontologies. - -
    Maps For HTML Community Group - -
    The Maps For HTML Community Group seeks to establish - maps as a first class object on the web similar to the - Media and Entertainment activity did for video, allowing - for layering and customizing data on a scale not - currently possible with proprietary online map offerings. - -
    Augmented - Reality Community Group - -
    The Augmented Reality Community Group is an open forum - for collaborative discussions about the intersection of - Augmented Reality and the Web. - -
    Immersive Web Working - Group and Community Group - -
    These groups helps bring high-performance Virtual - Reality (VR) and Augmented Reality (AR) (collectively - known as XR) to the open Web. - -
    Media and - Entertainment Interest Group - -
    The Media and Entertainment Interest Group provides a - forum for media-related technical discussions and - includes the Media Timed Events Task Force, which is - relevant for WebVMT coordination. +
    Sensor and system descriptions.
    @@ -626,23 +572,23 @@

    OGC Groups

    GeoPose SWG + href="https://portal.ogc.org/?m=projects&a=view&project_id=50" + >Geosemantics DWG -
    Linking the W3C and OGC work on virtual, augmented and - mixed reality. +
    Umbrella group in OGC for geospatial semantics + applications
    Metadata DWG (DCAT sub-group) + href="https://portal.ogc.org/?m=projects&a=view&project_id=286" + >Connected Systems SWG -
    Linking the W3C and OGC work on dataset description - and profiles. +
    Linking work on SSN in W3C with the open interfaces + for sensor web applications developed at OGC.
    SensorThings SWG @@ -650,44 +596,20 @@

    OGC Groups

    API.
    Sensor Web Enablement (SWE) DWG - -
    Linking work on SSN in W3C with the open interfaces - for sensor web applications developed at OGC. - -
    Observations and Measurements v2 SWG - -
    Linking work on SSN in W3C with the data model for - Observations and Measurements at OGC. - -
    OGC API Standards - Working Groups - -
    These Working Groups develop the OGC API suite of - Standards that will likely be discussed within the - Spatial Data on the Web Working Group. - -
    Mobile Location Services DWG + href="https://portal.ogc.org/?m=projects&a=view&project_id=713" + >GeoDCAT SWG -
    Linking the W3C and OGC work on location-aware mobile - services. +
    Linking the W3C and OGC work on dataset description + and profiles.
    GeoSemantics DWG + href="https://portal.ogc.org/?m=projects&a=view&project_id=629" + >GeoPose SWG -
    Linking the W3C and OGC work on semantics and linked - data. +
    Direction alongside location for sensors, systems and + platforms
    From 974fe9a22dc384f59938ae8ab9ce9e2630078654 Mon Sep 17 00:00:00 2001 From: Bert Bos Date: Wed, 17 Apr 2024 01:42:24 +0200 Subject: [PATCH 29/41] Removed completion dates from specs that the group will only maintain --- 2024/sdw-wg.html | 24 +----------------------- 1 file changed, 1 insertion(+), 23 deletions(-) diff --git a/2024/sdw-wg.html b/2024/sdw-wg.html index 7259339..7290b72 100644 --- a/2024/sdw-wg.html +++ b/2024/sdw-wg.html @@ -259,8 +259,7 @@

    Normative Specifications