-
Notifications
You must be signed in to change notification settings - Fork 9
/
index.html
658 lines (658 loc) · 22.4 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>
Digital Credentials
</title>
<script src="https://www.w3.org/Tools/respec/respec-w3c" class=
"remove"></script>
<script class="remove">
"use strict";
// See https://github.com/w3c/respec/wiki/ for how to configure ReSpec
var respecConfig = {
github: "WICG/digital-credentials",
editors: [
{
name: "Marcos Caceres",
email: "[email protected]",
company: "Apple Inc.",
companyURL: "https://apple.com",
},
{
name: "Tim Cappalli",
email: "[email protected]",
company: "Okta",
companyURL: "https://okta.com",
},
{
name: "Sam Goto",
email: "[email protected]",
company: "Google Inc.",
companyURL: "https://google.com",
},
// Add additional editors here.
// https://github.com/w3c/respec/wiki/editors
],
latestVersion: null,
shortName: "digital-credentials",
specStatus: "CG-DRAFT",
group: "wicg",
localBiblio: {},
xref: {
profile: "web-platform",
},
};
</script>
</head>
<body data-cite="credential-management-1 vc-data-model">
<section id="abstract">
<p>
This document 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 [=credential
type examples|other types of digital credential=]. The API builds on
[[[credential-management-1]]] as a means by which to request a digital
credential from a user agent or underlying platform.
</p>
</section>
<section id="sotd">
<p>
This is an unofficial proposal.
</p>
</section>
<h2>
Introduction
</h2>
<p id="credential-type-examples">
There are many types of digital credential that can be presented using
this API. <dfn data-lt="credential type examples">Examples of these
types</dfn> include:
</p>
<ul>
<li>a driving license, passport, or other identity card issued by a
government institution
</li>
<li>a travel authorization document issued by an embassy or consulate
</li>
<li>a proof of employment issued by a public or private organization
</li>
<li>a proof of education or professional training issued by an
institution
</li>
<li>and many other scenarios as described in <a href=
"https://www.w3.org/TR/vc-use-cases/">Verifiable Credentials Use
Cases</a>
</li>
</ul>
<h2>
Model
</h2>
<p class="note" title="Definitions under discussion">
The goal of the definitions in this section is to reuse or establish
terminology that is common across a variety of digital credential formats
and protocols. Discussions surrounding these definitions are active and
the definitions are likely to change over the next several months.
</p>
<dl class="definitions" data-sort="" data-cite="vc-data-model-2.0">
<dt>
<dfn>Digital credential</dfn>
</dt>
<dd>
A cryptographically signed digital document containing one or more
[=claims=] made by an [=issuer=] about one or more [=subjects=].
<p class="note" title="Focus on digital credentials about people">
This specification is currently focused on digital credentials
pertaining to people.
</p>
</dd>
<dt>
<dfn data-dfn-for="digital credential">Presentation request</dfn>
</dt>
<dd>
A presentation request is a request for a [=digital credential=]
composed of [=digital credential/request data=] and a [=digital
credential/exchange protocol=].
</dd>
<dt>
<dfn data-dfn-for="digital credential">request data</dfn>
</dt>
<dd>
A format that [=verifier=] software or a [=user agent=] uses, via an
[=digital credential/exchange protocol=], to request a [=digital
credential=] from a [=holder=].
</dd>
<dt>
<dfn>Presentation response</dfn>
</dt>
<dd>
A format that a [=holder|holder's=] software, such as a digital wallet,
uses, via an [=digital credential/exchange protocol=], to respond to a
[=digital credential/request data=] by a [=verifier=].
</dd>
<dt>
<dfn data-dfn-for="digital credential">Exchange protocol</dfn>
</dt>
<dd>
A protocol used for exchanging a [=digital credential=] between a
[=holder=] and a [=verifier=]. See section [[[#protocol-registry]]].
</dd>
</dl>
<h2>
Scope
</h2>
<p>
The following items are within the scope of this specification:
</p>
<ul>
<li>Requesting a [=digital credential=], including mechanisms for secure
presentation.
</li>
<li>Ensuring that when an API call is made, the website does not learn
anything about the a holder's [=digital credentials=] or their software
unless the [=user agent=] has previously received user consent.
</li>
<li>Ensuring that any installed application software will not learn
anything about a given [=request=] unless the [=holder=] explicitly
consents to use that software.
</li>
</ul>
<p>
The following items are out of scope:
</p>
<ul>
<li>Issuance process for establishing a [=digital credential=].
</li>
<li>UI/UX considerations, with the exception of privacy considerations,
which are addressed to ensure the protection of user data during the
request process.
</li>
</ul>
<h2>
Extensions to `CredentialRequestOptions` dictionary
</h2>
<pre class="idl">
partial dictionary CredentialRequestOptions {
DigitalCredentialRequestOptions digital;
};
</pre>
<h3>
The `digital` member
</h3>
<p>
The <dfn data-dfn-for="CredentialRequestOptions">digital</dfn> member
allows for options to configure the request for a [=digital credential=].
</p>
<h2>
The `DigitalCredentialRequestOptions` dictionary
</h2>
<pre class="idl">
dictionary DigitalCredentialRequestOptions {
sequence<DigitalCredentialsRequest> requests;
};
</pre>
<h3>
The `requests` member
</h3>
<p>
The <dfn data-dfn-for="DigitalCredentialRequestOptions">requests</dfn>
specify an [=digital credential/exchange protocol=] and [=digital
credential/request data=], which the user agent MAY match against a
holder's software, such as a digital wallet.
</p>
<h2>
The `DigitalCredentialsRequest` dictionary
</h2>
<p>
The {{DigitalCredentialsRequest}} dictionary represents a [=digital
credential/presentation request=]. It is used to specify an [=digital
credential/exchange protocol=] and a [=digital credential/request data=],
which the user agent MAY match against software used by a holder, such as
a digital wallet.
</p>
<pre class="idl">
dictionary DigitalCredentialsRequest {
required DOMString protocol;
required object data;
};
</pre>
<h3>
The `protocol` member
</h3>
<p>
The <dfn data-dfn-for="DigitalCredentialsRequest">protocol</dfn> member
denotes the [=digital credential/exchange protocol=] when requesting an
identify credential.
</p>
<p>
The {{DigitalCredentialsRequest/protocol}} member's value is be one of
the well-defined keys defined in [[[#protocol-registry]]] or any other
custom one.
</p>
<h3>
The `data` member
</h3>
<p>
The <dfn data-dfn-for="DigitalCredentialsRequest">data</dfn> member is
the [=digital credential/request data=] to be handled by the holder's
software, such as a digital wallet.
</p>
<h2>
The `DigitalCredential` interface
</h2>
<p>
The <dfn>DigitalCredential</dfn> interface represents a conceptual
[=digital credential=].
</p>
<p>
[=User mediation=] is always
{{CredentialMediationRequirement/"required"}}. [=Request a
credential|Requesting a DigitalCredential credential=] does not support
{{CredentialMediationRequirement/"conditional"}},
{{CredentialMediationRequirement/"optional"}}, or
{{CredentialMediationRequirement/"silent"}} [=user mediation=]. If
{{CredentialsContainer/get()}} is called with anything other than
{{CredentialMediationRequirement/"required"}}, a {{TypeError}} will be
thrown.
</p>
<pre class="idl">
[Exposed=Window, SecureContext]
interface DigitalCredential : Credential {
readonly attribute DOMString protocol;
readonly attribute object data;
};
</pre>
<p>
{{DigitalCredential}} instances are [=Credential/origin bound=].
</p>
<h3>
Integration with Credential Management API
</h3>
<aside class="issue" data-number="65"></aside>
<h3>
The `protocol` member
</h3>
<p>
The <dfn data-dfn-for="DigitalCredential">protocol</dfn> member is the
[=digital credential/exchange protocol=] that was used to request the
[=digital credential=].
</p>
<h3>
The `data` member
</h3>
<p>
The <dfn data-dfn-for="DigitalCredential">data</dfn> member is the
credential's response data. It contains the subset of JSON-parseable
object types.
</p>
<h3>
[[\DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
internal method
</h3>
<p>
When invoked, the <dfn class="export" data-dfn-for=
"DigitalCredential">[[\DiscoverFromExternalSource]](origin, options,
sameOriginWithAncestors)</dfn> internal method MUST:
</p>
<ol class="algorithm">
<li>Let |global| be [=this=]'s [=relevant global object=].
</li>
<li>Let |document| be |global|'s [=associated `Document`=].
</li>
<li>If |document| is not a [=Document/fully active descendant of a
top-level traversable with user attention=], [=exception/throw=]
{{"NotAllowedError"}} {{DOMException}}.
</li>
<li>If |window| does not have [=transient activation=],
[=exception/throw=] {{"NotAllowedError"}} {{DOMException}}.
</li>
<li>[=Consume user activation=] of |window|.
</li>
<li>Let |requests| be |options|'s {{CredentialRequestOptions/digital}}'s
{{DigitalCredentialRequestOptions/requests}} member.
</li>
<li>If |requests| is empty, [=exception/throw=] a {{TypeError}}.
</li>
<li>
<aside class="issue">
Details of how to actually get the [=digital credential=] are
forthcoming.
</aside>
</li>
<li>Return a {{DigitalCredential}}.
</li>
</ol>
<h3>
[[\Store]](credential, sameOriginWithAncestors) internal method
</h3>
<p>
When invoked, the <dfn class="export" data-dfn-for=
"DigitalCredential">[[\Store]](credential, sameOriginWithAncestors)</dfn>
MUST call the default implementation of {{Credential}}'s
{{Credential/[[Store]](credential, sameOriginWithAncestors)}} internal
method with the same arguments.
</p>
<h3>
[[\Create]](origin, options, sameOriginWithAncestors) internal method
</h3>
<p>
When invoked, the <dfn class="export" data-dfn-for=
"DigitalCredential">[[\Create]](origin, options,
sameOriginWithAncestors)</dfn> internal method MUST call the default
implementation of {{Credential}}'s {{Credential/[[Create]](origin,
options, sameOriginWithAncestors)}} internal method with the same
arguments.
</p>
<h3>
[[\type]] internal slot
</h3>
<p>
The {{DigitalCredential}} [=interface object=] has an internal slot named
<dfn class="export" data-dfn-for="DigitalCredential">[[\type]]</dfn>
whose value is "digital".
</p>
<h3>
[[\discovey]] internal slot
</h3>
<p>
The {{DigitalCredential}} [=interface object=] has an internal slot named
<dfn class="export" data-dfn-for="DigitalCredential">[[\discovery]]</dfn>
whose value is "remote".
</p>
<section class="informative">
<h3>
User consent
</h3>
<p data-cite="permissions">
The <cite>Digital Credential API</cite> is a [=powerful feature=] that
requires [=express permission=] from an end-user. This requirement is
normatively enforced when calling {{CredentialsContainer}}'s
{{CredentialsContainer/get()}} method.
</p>
</section>
<section id="permissions-policy" data-cite="permissions-policy">
<h2>
Permissions Policy integration
</h2>
<p>
This specification defines a [=policy-controlled feature=] identified
by the string <dfn class="permission">"digital-credentials-get"</dfn>.
Its [=policy-controlled feature/default allowlist=] is [=default
allowlist/'self'=].
</p>
</section>
<h2 id="protocol-registry">
Registry of protocols for requesting digital credential
</h2>
<p>
The following is the registry of [=digital credential/exchange
protocols=] that are supported by this specification.
</p>
<p class="note" title="Official Registry" data-cite="w3c-process">
It is expected that this registry will be become a [=W3C registry=] in
the future.
</p>
<h3>
Inclusion criteria
</h3>
<p>
To be included in the registry...
</p>
<aside class="issue" data-number="58"></aside>
<p>
[=User agents=] MUST support the following [=digital credential/exchange
protocols=]:
</p>
<table class="data">
<caption>
Table of officially registered [=digital credential/exchange
protocols=].
</caption>
<thead>
<tr>
<th>
Protocol identifier
</th>
<th>
Description
</th>
<th>
Specification
</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="3">
Coming soon...
</td>
</tr>
</tbody>
</table>
<section class="informative">
<h2>
Security Considerations
</h2>
<div class="issue" title=
"Security Considerations section is a work in progress">
<p>
This section is a work in progress as this document evolves.
</p>
<p>
The documents listed below outline initial security considerations
for Digital Credentials, both broadly and for presentation on the
web. Their contents will be integrated into this document gradually.
</p>
<ul>
<li>
<a href=
"https://github.com/WICG/digital-credentials/blob/main/horizontal-reviews/security-privacy.md">
TAG Security and Privacy Considerations Questionnaire (WIP)</a>
</li>
<li>
<a href=
"https://github.com/w3c-cg/threat-modeling/blob/main/models/decentralized-identities.md">
Threat Model for Decentralized Identities</a>
</li>
</ul>
</div>
<section>
<h3>
Credential Protocols
</h3>
<p class="issue" title="Work in progress">
Explain that while the API provides security at the browser API
level, that security for the underlying credential issuance or
presentation protocol is a separate concern and that developers need
to understand that layer of the stack to get a total picture of the
protections that are in place during any given transaction.
</p>
</section>
<section>
<h3>
Cross-device Protocols
</h3>
<p class="issue" title="Work in progress">
Explain that cross-device issuance or presentation uses a separate
protocol that has its own security characteristics.
</p>
</section>
<section>
<h3>
Quishing
</h3>
<p class="issue" title="Work in progress">
Explain that the API is designed to avoid the problem of quishing
(phishing via QR Codes) and other QR Code and non-browser API-based
attacks and to be aware of exposure of QR Codes during digital
credential interactions.
</p>
</section>
<section>
<h3>
Data Integrity
</h3>
<p class="issue" title="Work in progress">
Explain that the API does not provide data integrity on the digital
credential requests or responses and that responsibility is up to the
underlying protocol used for the request or response.
</p>
</section>
<section>
<h3>
Authentication
</h3>
<p class="issue" title="Work in progress">
Explain that authentication (such as a PIN code to unlock) to a
particular app, such as a digital wallet, that responds to an API
request is crucial in high-risk use cases.
</p>
</section>
<section>
<h3>
Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF)
</h3>
<p class="issue" title="Work in progress">
Explain what attacks are possible via XSS and CSRF, if any.
</p>
</section>
<section>
<h3>
Session Security
</h3>
<p class="issue" title="Work in progress">
Explain that once a secure session is established at a website using
credentials exchanged over this API, that the subsequent security is
no longer a function of the credential used or this API and is up to
the session management utilized on the website.
</p>
</section>
</section>
<section class="informative">
<h2>
Privacy Considerations
</h2>
<div class="issue" title=
"Privacy Considerations section is a work in progress">
<p>
This section is a work in progress as this document evolves.
</p>
<p>
The documents listed below outline various privacy considerations for
Digital Credentials, both broadly and for presentation on the web.
Their contents will be integrated into this document gradually.
</p>
<ul>
<li>
<a href=
"https://github.com/WICG/digital-credentials/blob/main/horizontal-reviews/security-privacy.md">
TAG Security and Privacy Considerations Questionnaire (WIP)</a>
</li>
<li>
<a href="https://github.com/w3cping/credential-considerations">W3C
Privacy Interest Group (PING) Credentials Considerations
repository</a> which contains in-progress list of concerns and
implications of identity-verification and credential presentation,
for consideration in Internet and Web standardization
</li>
<li>
<a href=
"https://github.com/w3c-cg/threat-modeling/blob/main/models/decentralized-identities.md">
Threat Model for Decentralized Identities</a>
</li>
</ul>
</div>
<section>
<h3>
Unnecessary Requests for Credentials
</h3>
<p class="issue" title="Work in progress">
Explain how the API could be used to unnecessarily request digital
credentials from individuals such as requesting a driver's license to
log into a movie rating website and how the ecosystem can mitigate
this risk.
</p>
</section>
<section>
<h3>
Over Collection of Data
</h3>
<p class="issue" title="Work in progress">
Explain how the API could be used to request more data than necessary
for a transaction and how the ecosystem can mitigate that over
collection.
</p>
</section>
<section>
<h3>
Individual Consent
</h3>
<p class="issue" title="Work in progress">
Explain how the API acquires an individual's consent to share a
digital credential and how digital wallets can also provide further
consent when sharing information.
</p>
</section>
<section>
<h3>
Data Retention
</h3>
<p class="issue" title="Work in progress">
Explain how verifiers might retain data and what the ecosystem does
to mitigate excessive data retention policies.
</p>
</section>
<section>
<h3>
Compliance with Privacy Regulations
</h3>
<p class="issue" title="Work in progress">
Explain to what extent the API complies with known privacy
regulations (e.g., consent) and what parts of those regulations are
not possible to enforce via the API (e.g., retention).
</p>
</section>
<section>
<h3>
Selective and Unlinkable Disclosure
</h3>
<p class="issue" title="Work in progress">
Explain how selective disclosure and unlinkable disclosure help
preserve privacy as well as their limitations in doing so.
</p>
</section>
<section>
<h3>
Phoning Home
</h3>
<p class="issue" title="Work in progress">
Explain how some systems might "phone home", the impact on privacy
that might have, and what the ecosystem provides to mitigate the
risk.
</p>
</section>
<section>
<h3>
Transmission of Personally Identifiable Information
</h3>
<p class="issue" title="Work in progress">
Explain that the API does enable the transmission of personally
identifiable information and that it does its best to ensure there is
informed consent by the individual, but that the consent might be
provided due to exhaustion or not understanding what PII is being
transmitted and how to mitigate those concerns.
</p>
</section>
</section>
<section class="informative">
<h2>
Accessibility Considerations
</h2>
<p class="issue" title="Work in Progress">
This section is a work in progress as this document evolves.
</p>
</section>
<section id="idl-index"></section>
<section id="conformance"></section>
</body>
</html>