Rechartering

simoneonofri · web-flow · commit cae8b1d5d240 · 2024-04-18T04:39:12.000+02:00
diff --git a/2024/wg-fedid.html b/2024/wg-fedid.html
@@ -75,19 +75,12 @@
 
   <main>    <h1 id="title">Federated Identity Working Group Charter</h1>
 
-    <p class="mission">The <strong>mission</strong> of the <a href="https://www.w3.org/groups/wg/fedid">Federated Identity Working Group</a> is to
-        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.</p>
-
+    <p class="mission">The <strong>mission</strong> of the <a href="https://www.w3.org/groups/wg/fedid">Federated Identity Working Group</a> is to develop specifications that allow a website to request an identity credential from an Identity Provider or credential container (i.e., a wallet) to authenticate a user and request a set of claims in a way that is compatible with other protocols like OIDC, SAML, and OpenID4VP.</p>
     <div class="noprint">
       <p class="join"><a href="https://www.w3.org/groups/wg/fedid/join">Join the Federated Identity Working
           Group.</a></p>
     </div>
 
-    <!-- delete the GH link after AC review completed -->
-    <p style="padding: 0.5ex; border: 1px solid green"> This updated charter is available
-      on <a href="https://github.com/w3c/charter-drafts">GitHub</a>.
-      Feel free to raise <a href="http://github.com/w3c/charter-drafts/issues/new?title=%5Bwg/fedid%5D">issues</a>.
-    </p>
 
     <div id="details">
       <table class="summary-table">
@@ -96,24 +89,24 @@
             Charter Status
           </th>
           <td>
-            <i class="todo">See the <a href="https://www.w3.org/groups/wg/fedid/charters">group status page</A>
-              and <a href="#history">detailed change history</a>.</i>
+            See the <a href="https://www.w3.org/groups/wg/fedid/charters">group status page</a>
+              and <a href="#history">detailed change history</a>.
           </td>
         </tr>
         <tr id="Duration">
           <th>
             Start date
           </th>
           <td>
-            28 March 2024
+            TBD
           </td>
         </tr>
         <tr id="CharterEnd">
           <th>
             End date
           </th>
           <td>
-            28 March 2026
+            TBD + 2 years
           </td>
         </tr>
         <tr>
@@ -151,29 +144,38 @@
     <div id="background" class="background">
       <h2>Motivation and Background</h2>
       <p>
-        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.
+        Identity on the Web is critical to online interaction, privacy, and security. W3C fosters an ecosystem where privacy, security, and user sovereignty are all considered. That includes developing new mechanisms for individuals to have the ability to select the identity information, such as assertions, specific credentials, or specific attributes, relevant to a given interaction. These mechanisms must also be viable for the issuers, verifiers, identity providers, and relying parties to exchange information in a secure and privacy-preserving manner. 
       <p>
       <p>
-        One of the initial hurdles is ensuring support for federated identity while adhering to <a href='https://www.w3.org/TR/privacy-principles/'>privacy principles</a>, 
-        despite the deprecation of
-        <a href='https://www.w3.org/2001/tag/doc/web-without-3p-cookies/'>third-party cookies</a>, a cornerstone of such operations.
+        The user agent is the coordinator for these transactions. So, while the request and response protocols are being developed elsewhere (e.g., ISO, IETF, OpenID, and other W3C groups), the web platform layer must also be standardized to provide the privacy and security API framework in a protocol-agnostic and formats-agnostic fashion in a manner that is compatible with identity request/response protocols and different formats.
       </p>
+      <p>
+        The group would like to: 
+      </p>
+      <ul>
+        <li>Enable federated identity while adhering to <a href='https://www.w3.org/TR/privacy-principles/'>privacy principles</a> despite the <a href='https://www.w3.org/2001/tag/doc/web-without-3p-cookies/'>third-party cookies</a>, a cornerstone of such operations, with the FedCM AP</li>
+        <li>Enable privacy-preserving invocation of a wallet without <a href="https://github.com/WICG/digital-identities/blob/main/custom-schemes.md">custom schemes</a>, which have <a href="https://github.com/WICG/digital-identities/blob/main/custom-schemes.md#can-wallets-reliably-determine-their-invoker">security</a>, <a href="https://github.com/WICG/digital-identities/blob/main/custom-schemes.md#what-are-the-privacy-implications-of-a-wallet-accepting-custom-schemes">privacy</a>, and <a href="https://github.com/WICG/digital-identities/blob/main/custom-schemes.md#user-experience-concerns">user experience implications</a> and cannot reliably or securely work in cross-device scenarios, with the Digital Credentials API.</li>
+      </ul>
     </div>
 
     <section id="scope" class="scope">
       <h2>Scope</h2>
-      <p>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 &quot;privacy&quot; 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.</p>
-
-      <p>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.</p>
+      <p>
+        The Working Group will specify new web platform features intended to be implemented in user agents like browsers. The purpose of these features is to support privacy-preserving authentication, authorization flows, and requesting federated identities without compromising security principles for Identity Providers (IdPs) or Relying Parties (RPs) (in a ‘traditional’ federation model) or Issuers, Verifiers, and Holders (in a digital identity wallet architecture), and User Agents. Here, “privacy” minimally refers to the appropriate processing of personal information and preventing third parties from gleaming anything about the end-user’s environment (e.g., which wallets are available and their capabilities). This work results in developing new mechanisms that define how information is passed by the browser between the different entities and authentication intermediaries to facilitate federated authentication; these mechanisms are not authentication methods.
+      </p>  
+      <p>
+        If any mechanisms developed to support authentication and authorization flows would cause breaking changes for existing protocols, work on that mechanism must include a well-documented transition period.
+      </p>
 
       <section id="section-out-of-scope">
         <h3 id="out-of-scope">Out of Scope</h3>
-        <p>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.</p>
+        <p>
+          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.
+        </p>
 
         <p>Specific topics out of scope:</p>
         <ul class="out-of-scope">
-
-          <li>New authentication methods</li>
+          <li>Designing new authentication methods.</li>
           <li>Designing individual credential and assertion formats</li>
           <li>Performing any security or confidence assessment (e.g. checking signatures,
             audience, encoding, etc) of the <a
@@ -217,7 +219,7 @@ <h3>
             <p class="draft-status"><b>Draft state:</b> <a href="https://github.com/fedidcg/FedCM">Adopted from the
                 Federated Identity Community Group</a>
             </p>
-            <p class="milestone"><b>Expected completion:</b> CR in Q1 2025</p>
+            <p class="milestone"><b>Expected completion:</b> CR in Q2 2025</p>
           </dd>
           <dt id="bapi" class="spec"><a href="https://fedidcg.github.io/FedCM/#browser-api-login-status">Login Status API</a>
           </dt>
@@ -230,21 +232,21 @@ <h3>
             <p class="draft-status"><b>Draft state:</b> <a href="https://github.com/fedidcg/FedCM">Adopted from the
                 Federated Identity Community Group</a>
             </p>
-            <p class="milestone"><b>Expected completion:</b> CR in Q1 2025</p>
+            <p class="milestone"><b>Expected completion:</b> CR in Q2 2025</p>
           </dd>
         </dl>
         <h3>Tentative Deliverables</h3>
-        <p>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:</p>
+        <p>Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the Group may also produce Recommendation-track specifications for the following document:</p>  
+        <dl>
         <dt id="digid" class="spec"><a href="https://wicg.github.io/digital-identities/">Digital Credentials API</a></dt>
         <dd>
             <p>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.</p>
 
-            <p class="draft-status"><b>Draft state:</b> <a href="https://wicg.github.io/digital-identities/">Adopted from the
+            <p class="draft-status"><b>Draft state:</b> <a href="https://wicg.github.io/digital-identities/">Draft in the
                 Web Incubator Community Group</a>
             </p>
-            <p class="milestone"><b>Expected completion:</b> CR in Q4 2025</p>
           </dd>
-
+      </dl>
       </section>
 
       <section id="ig-other-deliverables">
@@ -260,8 +262,8 @@ <h3>
           Other non-normative documents may be created such as:
         </p>
         <ul>
-          <li>Use case and requirement documents;</li>
-          <li>Implementation report for the specification;</li>
+          <li>Use case and requirement documents.</li>
+          <li>Implementation report for the specification.</li>
           <li>Primer or Best Practice documents to support web developers when designing applications.</li>
           <li>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. 
         </li>
@@ -272,9 +274,7 @@ <h3>
         <h3>Timeline</h3>
         <ul>
           <li>Q4 2024: FPWD for Federated Credential Management API</li>
-          <li>Q4 2024: FPWD for Digital Credentials API</li>
           <li>Q1 2025: CR for Federated Credential Management API</li>
-          <li>Q4 2025: CR for Digital Credentials API</li>
           
         </ul>
       </section>
@@ -292,7 +292,7 @@ <h2>Success Criteria</h2>
           interoperable
           implementations</a> of every feature defined in the specification, where
         interoperability can be verified by passing open test suites, and two or
-        more implementations interoperating with each other. In order to advance to
+        more implementations (distinct browser engines) interoperating with each other. In order to advance to
         Proposed Recommendation, each normative specification must have an open
         test suite of every feature defined in the specification.
       </p>
@@ -310,7 +310,7 @@ <h2>Success Criteria</h2>
       <p>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 <a href="https://www.w3.org/TR/security-privacy-questionnaire/">Self-Review Questionnaire: Security and Privacy</a> and <a href="https://datatracker.ietf.org/doc/html/rfc3552">RFC 3552</a>, detailing all known security and privacy implications for implementers, Web authors, and end users.</p>
 
       <p>Each specification should contain a section on accessibility that describes the benefits and impacts, including
-        ways specification features can be used to address them, and
+        ways specification features can be used to address them and
         recommendations for maximising accessibility in implementations.</p>
 
       <!-- Principles -->
@@ -365,31 +365,43 @@ <h3 id="w3c-coordination">W3C Groups</h3>
 ensure that the work of the two groups is not in conflict.</dd>
 <dt><a href="https://www.w3.org/groups/wg/webauthn/" rel="nofollow">Web Authentication (WebAuthn) Working Group</a></dt>
 <dd>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.</dd>
-<dt><a href="https://www.w3.org/WAI/APA/" rel="nofollow">Accessible Platform Architectures (APA) WG</a></dt>
+<dt><a href="https://www.w3.org/WAI/APA/" rel="nofollow">Accessible Platform Architectures (APA) Working Group</a></dt>
 <dd>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.
+<dt><a href="https://www.w3.org/groups/wg/vc/" rel="nofollow">Verifiable Credentials Working Group</a></dt>
+<dd>The VC WG is a likely venue for standardization of Data Model for Verifiable Credentials and they are an important stakeholder in the identity space to coordinate with.
+  
 </dl>
       </section>
 
       <section>
         <h3 id="external-coordination">External Organizations</h3>
         <dl>
           <dt><a href="https://www.ietf.org" rel="nofollow">IETF</a></dt>
-          <dd>A number of IETF working groups, such as <a
-            href="https://datatracker.ietf.org/wg/oauth/about/">oauth</a>, are likely venues for standardization of
-          protocol components that authentication and authorization features
-          depend on and research groups are investigating issues that will feed
-          into the designs this group will consider.</dd>
+          <dd>To coordinate with the IETF research groups and working groups, such as <a
+            href="https://datatracker.ietf.org/wg/oauth/about/">oauth</a>, for
+          protocol components that authentication and authorization features 
+          depend on.</dd>
           <dt><a href="https://openid.net" rel="nofollow">OIDF</a></dt>
-          <dd>The OpenID Foundation (OIDF) is a likely venue for standardization of
-          components that certain authorization flows depend on (i.e., OIDC
+          <dd>To coordinate with the OpenID Foundation (OIDF) for authorization and credentials used in the flows (i.e., OIDC and OpenID4VC
           specs).</dd>
           <dt><a href="https://oasis-open.org" rel="nofollow">OASIS</a></dt>
-          <dd>OASIS is a likely venue for standardization of components that certain
-          authorization flows depend on (i.e., SAML specs).</dd>
+          <dd>To coordinate with OASIS for authorization flows used in the flows (i.e., SAML).</dd>
           <dt><a href="https://refeds.org" rel="nofollow">REFEDS</a></dt>
-          <dd>REFEDS is a likely venue for multi-lateral federation best practices and
+          <dd>To coordinate with REFEDS for multi-lateral federation best practices and
           a representative of the complex use cases of the research and education
-          communities around the world.</dd> 
+          communities around the world.</dd>
+          <dt><a href="https://www.etsi.org/committee/esi">European Telecommunications Standards Institute - Electronic Signatures and Infrastructure Technical Committee</a> </dt>
+          <dd>
+            To coordinate with ETSI for <a href="https://digital-strategy.ec.europa.eu/en/policies/discover-eidas" rel="nofollow">eIDAS</a>, which can use the deliverables of the Group.
+          </dd>
+          <dt><a href="https://www.nist.gov/"> National Institute of Standards and Technology, U.S. Department of Commerce </a></dt>
+          <dd>
+            To coordinate with NIST for their guidelines of Digital Identity and implementations.
+          </dd>
+          <dt><a href="https://www.iso.org/committee/45144.html">ISO/IEC JTC 1 SC17 WG4 and WG10</a></dt>
+          <dd>
+            To coordinate with ISO for their work on interfaces and protocols for security devices and vehicle driver licence and related digital identities (i.e., mdocs).
+          </dd>
         </dl>
       </section>
     </section>
@@ -420,7 +432,7 @@ <h2 id="participation">
       </p>
       <p>Participants in the group are required (by the <a
           href="https://www.w3.org/Consortium/Process/#ParticipationCriteria">W3C Process</a>) to follow the
-        W3C <a href="https://www.w3.org/Consortium/cepc/">Code of Ethics and Professional Conduct</a>.</p>
+        W3C <a href="https://www.w3.org/policies/code-of-conduct/">Code of Conduct</a>.</p>
     </section>
 
 
@@ -575,10 +587,10 @@ <h3>
             </tr>
             <tr>
                 <th>
-                    &nbsp;
+                  <a href="">Rechartered</a>
                 </th>
                 <td>
-                  @@ June 2024
+                  TBD
                 </td>
                 <td>
                   &nbsp;
