You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 2024/wg-fedid.html
+62-50Lines changed: 62 additions & 50 deletions
Original file line number
Diff line number
Diff line change
@@ -73,15 +73,10 @@
73
73
</header>
74
74
75
75
76
-
<main>
77
-
<h1id="title">PROPOSED Federated Identity Working Group Charter</h1>
78
-
<!-- delete PROPOSED after AC review completed -->
76
+
<main><h1id="title">Federated Identity Working Group Charter</h1>
79
77
80
78
<pclass="mission">The <strong>mission</strong> of the <ahref="https://www.w3.org/groups/wg/fedid">Federated Identity Working Group</a> is to
81
-
develop specifications to allow a website to request a federated identity
82
-
credential or assertion with the purpose of authenticating a user and/or requesting a set of claims in a
83
-
compatible way to OIDC or SAML.</p>
84
-
<!-- the link to the group is ALWAYS that available from https://www.w3.org/groups/wg or https://www.w3.org/groups/ig because each group page can then point to a different homepage, but not the other way around. -->
79
+
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>
85
80
86
81
<divclass="noprint">
87
82
<pclass="join"><ahref="https://www.w3.org/groups/wg/fedid/join">Join the Federated Identity Working
@@ -110,15 +105,15 @@ <h1 id="title">PROPOSED Federated Identity Working Group Charter</h1>
110
105
Start date
111
106
</th>
112
107
<td>
113
-
<iclass="todo">[dd monthname yyyy] (date of the "Call for Participation", when the charter is approved)</i>
108
+
28 March 2024
114
109
</td>
115
110
</tr>
116
111
<trid="CharterEnd">
117
112
<th>
118
113
End date
119
114
</th>
120
115
<td>
121
-
<iclass="todo">[dd monthname yyyy]</i> (Start date + 2 years)
116
+
28 March 2026
122
117
</td>
123
118
</tr>
124
119
<tr>
@@ -135,8 +130,8 @@ <h1 id="title">PROPOSED Federated Identity Working Group Charter</h1>
removes a building block used by certain designs of federated
163
-
identity. This Group aims to bridge the gap for the federated identity designs which relied
164
-
on third-party cookies.
154
+
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.
155
+
<p>
156
+
<p>
157
+
One of the initial hurdles is ensuring support for federated identity while adhering to <ahref='https://www.w3.org/TR/privacy-principles/'>privacy principles</a>,
158
+
despite the deprecation of
159
+
<ahref='https://www.w3.org/2001/tag/doc/web-without-3p-cookies/'>third-party cookies</a>, a cornerstone of such operations.
165
160
</p>
166
161
</div>
167
162
168
163
<sectionid="scope" class="scope">
169
164
<h2>Scope</h2>
170
-
<p>The Working Group will specify new web platform features intended to be implemented in browsers or similar user
171
-
agents. The purpose of these features is to support authentication and authorization flows without compromising
172
-
security principles for Identity Providers (IdPs), Relying Parties (RPs), and User Agents as well as protecting user
173
-
privacy. Here "privacy" minimally refers to the appropriate processing of personal information. The result of
174
-
this work is the development of new mechanisms that define how information is passed by the browser between the
175
-
RP, the IdP, and authentication intermediaries to facilitate federated authentication; these mechanisms are not
176
-
an authentication method.</p>
177
-
178
-
<p>If any of the mechanisms developed to support authentication and authorization flows would cause
179
-
breaking changes for existing protocols, work on that mechanism must include a well-documented transition
180
-
period.</p>
165
+
<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 "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.</p>
166
+
167
+
<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>
181
168
182
169
<sectionid="section-out-of-scope">
183
170
<h3id="out-of-scope">Out of Scope</h3>
184
-
<p>The identity space is much larger than federated authentication. While several topics related to
185
-
identity may be of interest, they are out of scope for our work.</p>
171
+
<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>
186
172
187
173
<p>Specific topics out of scope:</p>
188
174
<ulclass="out-of-scope">
189
175
190
176
<li>New authentication methods</li>
191
-
192
-
<li>Design and discussion regarding individual credential and assertion formats</li>
193
-
177
+
<li>Designing individual credential and assertion formats</li>
194
178
<li>Performing any security or confidence assessment (e.g. checking signatures,
195
179
audience, encoding, etc) of the <a
196
180
href="https://fedidcg.github.io/FedCM/#dom-identityprovidertoken-token">token</a> that
197
181
encodes the <ahref="https://fedidcg.github.io/FedCM/#fetch-identity-assertion">identity
198
182
assertions</a>.</li>
199
-
200
-
<li>Ad-tech tools or APIs</li>
201
-
202
-
<li>Interactions with identity wallets</li>
183
+
<li>Ad-tech tools or APIs specifically focused on advertising as opposed to authentication.</li>
203
184
</ul>
204
185
</section>
205
186
@@ -238,7 +219,7 @@ <h3>
238
219
</p>
239
220
<pclass="milestone"><b>Expected completion:</b> CR in Q1 2025</p>
240
221
</dd>
241
-
<dtid="fedcm" class="spec"><ahref="https://fedidcg.github.io/FedCM/#browser-api-login-status">Login Status API</a>
222
+
<dtid="bapi" class="spec"><ahref="https://fedidcg.github.io/FedCM/#browser-api-login-status">Login Status API</a>
242
223
</dt>
243
224
<dd>
244
225
<p>This specification defines an API to inform the Web Application of their user's
@@ -252,6 +233,17 @@ <h3>
252
233
<pclass="milestone"><b>Expected completion:</b> CR in Q1 2025</p>
253
234
</dd>
254
235
</dl>
236
+
<h3>Tentative Deliverables</h3>
237
+
<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>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>
241
+
242
+
<pclass="draft-status"><b>Draft state:</b><ahref="https://wicg.github.io/digital-identities/">Adopted from the
243
+
Web Incubator Community Group</a>
244
+
</p>
245
+
<pclass="milestone"><b>Expected completion:</b> CR in Q4 2025</p>
246
+
</dd>
255
247
256
248
</section>
257
249
@@ -271,14 +263,19 @@ <h3>
271
263
<li>Use case and requirement documents;</li>
272
264
<li>Implementation report for the specification;</li>
273
265
<li>Primer or Best Practice documents to support web developers when designing applications.</li>
266
+
<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.
267
+
</li>
274
268
</ul>
275
269
</section>
276
270
277
271
<sectionid="timeline">
278
272
<h3>Timeline</h3>
279
273
<ul>
280
-
<li>Q1 2024: FPWD for Federated Credential Management API</li>
274
+
<li>Q4 2024: FPWD for Federated Credential Management API</li>
275
+
<li>Q4 2024: FPWD for Digital Credentials API</li>
281
276
<li>Q1 2025: CR for Federated Credential Management API</li>
277
+
<li>Q4 2025: CR for Digital Credentials API</li>
278
+
282
279
</ul>
283
280
</section>
284
281
</section>
@@ -310,16 +307,15 @@ <h2>Success Criteria</h2>
310
307
311
308
<!-- Horizontal review -->
312
309
313
-
<p>Each specification should contain sections detailing all known security and
314
-
privacy implications for implementers, Web authors, and end users.</p>
310
+
<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 <ahref="https://www.w3.org/TR/security-privacy-questionnaire/">Self-Review Questionnaire: Security and Privacy</a> and <ahref="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>
315
311
316
312
<p>Each specification should contain a section on accessibility that describes the benefits and impacts, including
317
313
ways specification features can be used to address them, and
318
314
recommendations for maximising accessibility in implementations.</p>
319
315
320
-
<!-- Design principles -->
321
-
<p>This Working Group expects to follow the
322
-
TAG <ahref="https://www.w3.org/TR/design-principles/">Web Platform Design Principles</a>.
316
+
<!-- Principles -->
317
+
<p>
318
+
This Working Group expects to follow the TAG <ahref="https://www.w3.org/TR/design-principles/">Web Platform Design Principles</a>, <ahref="https://www.w3.org/TR/ethical-web-principles/">Ethical Web Principles</a>, and <ahref="https://www.w3.org/TR/privacy-principles/">Privacy Principles</a>.
<dt><ahref="https://www.w3.org/groups/wg/webauthn/" rel="nofollow">Web Authentication (WebAuthn) Working Group</a></dt>
371
367
<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>
<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.</p>
369
+
<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.
0 commit comments