-
Notifications
You must be signed in to change notification settings - Fork 22
/
Copy pathindex.html
965 lines (916 loc) · 37.2 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
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
<!DOCTYPE html>
<html>
<head>
<title>Verifiable Credentials Use Cases</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8' />
<script src='https://www.w3.org/Tools/respec/respec-w3c' class='remove'></script>
<script src='https://opencreds.github.io/vc-common/common.js' class='remove'></script>
<script src='./refs.js' class='remove'></script>
<script class="remove"
src="https://cdn.jsdelivr.net/gh/w3c/[email protected]/dist/main.js"></script>
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use .
specStatus: "ED",
useExperimentalStyles: true,
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "vc-use-cases",
// the specification's group as found in https://respec.org/w3c/groups/
group: "vc",
// if you wish the publication date to be other than today, set this
// publishDate: "2019-09-24",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
//previousPublishDate: "2017-05-01",
//previousMaturity: "CG-FINAL",
// extend the bibliography entries
localBiblio: opencreds.localBiblio,
github: "https://github.com/w3c/vc-use-cases",
includePermalinks: false,
// if there a publicly available Editor's Draft, this is the link
//edDraftURI: "https://opencreds.github.io/vc-use-cases/",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
//extraCSS: [],
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Shane McCarron", url: "http://blog.halindrome.com/",
company: "Spec-Ops", companyURL: "https://spec-ops.io", w3cid: "23346" },
{ name: "Joe Andrieu",
company: "Legendary Requirements", companyURL: "http://legreq.com" },
{ name: "Matt Stone", url: "https://www.lithos.me/about",
company: "The Brightlink", companyURL: "http://www.thebrightlink.com" },
{ name: "Tzviya Siegman", url: "",
company: "Wiley", companyURL: ""},
{ name: "Gregg Kellogg", url: "http://greggkellogg.net/",
company: "Spec-Ops", companyURL: "https://spec-ops.io/",
w3cid: "44770" },
{ name: "Ted Thibodeau, Jr.", url: "https://www.linkedin.com/in/macted/",
company: "OpenLink Software, Inc.", companyURL: "http://www.openlinksw.com/"},
{ name: "Kevin Dean", url: "https://www.linkedin.com/in/kdean/",
company: "GS1", companyURL: "https://www.gs1.org/"}
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
authors: [
{ name: "Nate Otto", url: "",
company: "Badge Alliance", companyURL: "" },
{ name: "Sunny Lee", url: "",
company: "Badge Alliance", companyURL: "" },
{ name: "Brian Sletten", url: "http://bosatsu.net",
company: "Bosatsu Consulting, Inc.", companyURL: "http://bosatsu.net" },
{ name: "Daniel Burnett",
company: "Standards Play", companyURL: "http://standardsplay.com/"},
{ name: "Manu Sporny", url: "http://digitalbazaar.com/",
company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" },
{ name: "Ken Ebert", url: "",
company: "Sovrin Foundation", companyURL: "https://sovrin.org/" }
],
// maximum level of table of contents
maxTocLevel: 3,
// name of the WG
wg: "Verifiable Claims Working Group",
// URI of the public WG page
wgURI: "https://www.w3.org/2017/vc/",
// name (with the @w3c.org) of the public mailing to which comments are due
// wgPublicList: "public-vc-comments",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "https://www.w3.org/2004/01/pp-impl/98922/status",
// This is for the mermaid rendering
preProcess: [window.respecMermaid.createFigures]
};
</script>
<style>
dl {
margin-top: 20px;
margin-bottom: 20px;
}
dt,
dd {
line-height: 1.42857143;
}
dl.dl-horizontal > dt {
font-weight: bold;
}
dl.dl-horizontal > dd {
padding-bottom: 10px;
}
@media (min-width: 768px), print {
.dl-horizontal {
margin-bottom: 2em;
}
.dl-horizontal dt {
font-weight: normal;
float: left;
width: 160px;
clear: left;
overflow: hidden;
text-align: right;
}
.dl-horizontal dd {
margin-left: 180px;
}
.dl-horizontal dd > ul {
padding-left: 20px;
margin: 0px;
}
.dl-horizontal dd + dt { border-top: solid thin grey; }
dl.dl-horizontal dt:not(:first-child) + dd { border-top: solid thin grey; }
.left.dl-horizontal dt {
text-align: left;
}
}
.dl-horizontal dd + dd { border-top: dotted thin grey;
padding-top: 0.5em; }
</style>
</head>
<body>
<section id='abstract'>
<p>
A <em>verifiable claim</em> is a qualification, achievement, quality, or piece
of information about an <a>entity's</a> background such as a name, government
ID, payment provider, home address, or university degree. Such a claim
describes a quality or qualities, property or properties of an <a>entity</a>
which establish its existence and uniqueness. The use cases outlined here are
provided in order to make progress toward possible future standardization and
interoperability of both low- and high-stakes <a>claims</a> with the goals of
storing, transmitting, and receiving digitally verifiable proof of attributes
such as qualifications and achievements. The use cases in this document focus
on concrete scenarios that the technology defined by the group should address.
</p>
</section>
<section id='sotd'>
<p>
This document represents a concise but limited collection of use cases readers
should review alongside the <a href="https://www.w3.org/TR/vc-data-model/">Verifiable
Credentials Data Model</a>.
</p>
<p>
The work on this document was carried out under tight time constraints due to
limitations of the W3C process and publishing deadlines. Under such conditions,
errors are unavoidable and some of the ideas presented here are incomplete.
The Working Group hopes that in the future, W3C process can be revised to better
support the dynamic nature of standards work in a more consistent way across
different groups.
</p>
<p>
Comments regarding this document are welcome. Please file directly on
<a href="https://github.com/w3c/vc-use-cases/issues/">GitHub</a>, or send them
to <a href="mailto:[email protected]">[email protected]</a>
(<a href="mailto:[email protected]?subject=subscribe">subscribe</a>,
<a href="https://lists.w3.org/Archives/Public/public-vc-comments/">archives</a>).
</p>
</section>
<section>
<!-- Editor - @halindrome -->
<h2>Introduction</h2>
<p>
The Verifiable Claims Working Group at the W3C is developing standards for
expressing and exchanging "<a>claims</a>" that have been verified by a third
party and to make them easier and more secure on the Web.
</p>
<div class="note">
This document does NOT attempt to define an architecture for the support of
Verifiable Claims. Instead it expresses the sorts of needs that real users have
that could be addressed through support for some sort of self-sovereign claim
environment. It attempts to use terminology that is consistent with the other
deliverables of the Verifiable Claims Working Group (you can see the relevant
terms in Appendix A).
</div>
<section>
<h3>Importance of this work</h3>
<p>
Entities (people, organizations, devices) need to make many kinds of
<a>claims</a> as part of their everyday activities. As more and more of these
important activities move to the Internet, <a>entities</a> need to be able to
transmit instantly <em>verifiable</em> claims (e.g., about their location,
accomplishments, value, what-have-you). From educational records to payment
account access, the next generation of web applications will authorize
<a>entities</a> to perform actions based on rich sets of credentials issued by
trusted parties. Human- and machine-mediated decisions about job applications,
account access, collaboration, and professional development will depend on
filtering and analyzing growing amounts of data. It is essential that data be
verifiable.
</p>
<p>
Standardization of digital <a>claim</a> technologies makes it possible for many
stakeholders to issue, earn, and trust these essential records about their
counterparties, without being locked into proprietary platforms.
</p>
</section>
<section>
<h3>Use case model</h3>
<p>
This document presents an aggregate use case model, composed of Needs, Roles,
Tasks, and Sequences. Taken together, these models define the use cases that
the Verifiable Claims Working Group has addressed.
</p>
<p>
User needs define the problem space addressed by <a>verifiable credentials</a>.
User Roles specify the roles different <a>entities</a> play when interacting
with <a>verifiable credentials</a>. Tasks define the functions users can
accomplish, and sequences demonstrate how tasks might be realized, by
interactions between <a>entities</a> over time.
</p>
<p>
As with all models, this use case model is neither exhaustive nor complete. The
listed uses cannot capture all possible use cases. Similarly, the models do not
completely characterize the use cases represented. However, the combined model
is intended to provide specific, coherent guidance for the work ahead.
</p>
</section>
<section id="conformance" class="normative">
</section>
</section>
<section>
<h2>User Roles</h2>
<p>
There are four roles supported by <a>verifiable credentials</a>: <a>Issuer</a>,
<a>Verifier</a>, <a>Subject</a>, and <a>Holder</a>.
</p>
<figure>
<img alt="Verifiable Credential User Roles"
style="display:block; margin:auto"
src="VerifiableCredentialsUserRoles.png" />
<figcaption>
Verifiable Credential User Roles
</figcaption>
</figure>
<dl>
<dt>
Issuer
</dt>
<dd>
The <a>entity</a> that creates a <a>claim</a> and associates it with a
particular <a>subject</a>.
</dd>
<dt>
Verifier
</dt>
<dd>
The <a>entity</a> verifying a <a>claim</a> about a given <a>subject</a>.
</dd>
<dt>
Subject
</dt>
<dd>
The <a>entity</a> about whom a <a>claim</a> is issued.
</dd>
<dt>
Holder
</dt>
<dd>
A role an <a>entity</a> may perform by possessing one or more
<a>verifiable credentials</a>. A <a>holder</a> is usually, but not always, the
<a>subject</a> of the <a>verifiable credentials</a> that they are holding.
<a>Holders</a> store their <a>credentials</a> in <a>credential repositories</a>.
</dd>
</dl>
</section>
<section>
<h2>User Needs</h2>
<p>
<a>Verifiable credentials</a> address user needs in a number of key domains:
</p>
<figure>
<pre class="diagram mermaid">
%%{init:{'flowchart':{'nodeSpacing': 20, 'rankSpacing': 10}}}%%
flowchart TD
classDef Domain stroke:#000,stroke-width:3px,padding:2px;
classDef Problem stroke:#222,stroke-width:1px,padding:2px;
classDef Education fill:#ffe4e6
classDef Retail fill:#ffefd6
classDef Finance fill:#fffdd0
classDef Healthcare fill:#dff6d1
classDef Credentials fill:#bffedb
classDef Legal fill:#beddfe
classDef Devices fill:#fcdfef
E(Education) --- E.1[E.1 Digital Transcript]
E.1 --- E.2[E.2 Taking a Test]
E.2 --- E.3[E.3 Transferring Schools]
E.3 --- E.4[E.4 Online Classes]
R(Retail) --- R.1[R.1 Address verification]
R.1 --- R.2[R.2 Adult beverages]
R.2 --- R.3[R.3 Fraud detection]
R.3 --- R.4[R.4 Bona-fide Shopper]
F(Finance) --- F.1["F.1 Reuse Know
Your Customer"]
F.1 --- F.2[F.2 Money Transfer]
F.2 --- F.3[F.3 Closing Account]
F.3 --- F.4[F.4 Trying out a new service]
F.4 --- F.5["F.5 New Bank
Account from Home"]
H(Healthcare) --- H.1[H.1 Prescribing]
H.1 --- H.2[H.2 Online Pharmacy]
H.2 --- H.3[H.3 Insurance Claim]
H.3 --- H.4[H.4 Traveling Illness]
H.4 --- H.5["H.5 Proving Legal
Disability Status"]
C(Professional Credentials) --- C.1[C.1 Find a Doctor]
C.1 --- C.2[C.2 Busy Doctor]
C.2 --- C.3[C.3 Bad University]
C.3 --- C.4[C.4 New Employer]
C.4 --- C.5[C.5 Social Authority]
C.5 --- C.6[C.6 Job Applicant]
L(Legal Identity) --- L.1[L.1 Digital Driver's License]
L.1 --- L.2[L.2 Seamless Integration]
L.2 --- L.3[L.3 Speedy Air Travel]
L.3 --- L.4[L.4 Refugee Crisis]
D(Devices) --- D.1["D.1 Devices
During Manufacturing"]
D.1 --- D.2[D.2 Devices During Delivery]
D.2 --- D.3["D.3 Device setup for
operating autonomously"]
class E,E.1,E.2,E.3,E.4 Education
class R,R.1,R.2,R.3,R.4 Retail
class F,F.1,F.2,F.3,F.4,F.5, Finance
class H,H.1,H.2,H.3,H.4,H.5 Healthcare
class C,C.1,C.2,C.3,C.4,C.5,C.6 Credentials
class L,L.1,L.2,L.3,L.4 Legal
class D,D.1,D.2,D.3 Devices
class E,R,F,H,C,L,D Domain
class E.1,E.2,E.3,E.4,R.1,R.2,R.3,R.4,F.1,F.2,F.3,F.4,F.5,H.1,H.2,H.3,H.4,H.5,C.1,C.2,C.3,C.4,C.5,C.6,L.1,L.2,L.3,L.4,D.1,D.2,D.3 Problem
</pre>
<figcaption>
Verifiable Credentials, Example Domains for User Needs
</figcaption>
</figure>
<section>
<h3>Education</h3>
<p>
The education domain includes all levels of the educational experience; from
primary through professional continuing education.
</p>
<dl class="left dl-horizontal">
<div data-include="short/e1_digital_transcript.html"
data-include-replace="true"
data-format="html"></div>
<div data-include="short/e2_taking_a_test.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/e3_transferring_schools.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/e4_online_classes.html"
data-include-replace="true" data-format="html"></div>
</dl>
</section>
<section>
<h3>Retail</h3>
<p>
The retail domain encompasses all things where there is an exchange of value on
an individual level. This includes brick-and-mortar store fronts, web-only
venues, and even person-to-person sales.
</p>
<dl class="left dl-horizontal">
<div data-include="short/r1_address-verification.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/r2_adult_beverages.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/r3_fraud_detection.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/r4_bona_fide_shopper.html"
data-include-replace="true" data-format="html"></div>
</dl>
</section>
<section>
<h3>Finance</h3>
<p>
The Finance domain includes banking, brokerage, insurance, and other
industries where there is a high value placed on knowing exactly with whom
you are dealing.
</p>
<dl class="left dl-horizontal">
<div data-include="short/f1_reuse_know_your_customer.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/f2_money_transfer.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/f3_closing_account.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/f4_trying_out_a_new_service.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/f5_new_bank_account_from_home.html"
data-include-replace="true" data-format="html"></div>
</dl>
</section>
<section>
<h3>Healthcare</h3>
<p>
Privacy is critically important in the healthcare industry. This domain looks
at everything from physical interaction to connecting patients and providers
with service organizations.
</p>
<dl class="left dl-horizontal">
<div data-include="short/h1_prescribing.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/h2_online_pharmacy.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/h3_insurance_claim.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/h4_traveling_illness.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/h5_proving_legal_disability_status.html"
data-include-replace="true" data-format="html"></div>
</dl>
</section>
<section>
<h3>Professional Credentials</h3>
<p>
In many aspects of life it is important to know that <a>entities</a> are who
they say they are, and that they can do what they say. Professional
accreditation is one way of learning about the abilities of an <a>entity</a>.
Being able to verify these credentials is essential to their value.
</p>
<dl class="left dl-horizontal">
<div data-include="short/c1_find_a_doctor.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/c2_busy_doctor.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/c3_bad_university.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/c4_new_employer.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/c5_social_authority.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/c6_job_applicant.html"
data-include-replace="true" data-format="html"></div>
</dl>
</section>
<section>
<h3>Legal Identity</h3>
<p>
For many transactions, an <a>entity</a> must be able to prove some aspect of
their identity in a way that can be quickly verified. Governments and other
widely recognized <a>entities</a> are well positioned to provide such
identification in a verifiable digital form.
</p>
<dl class="left dl-horizontal">
<div data-include="short/l1_digital_driving_license.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/l2_seamless_immigration.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/l3_speedy_air_travel.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/l4_refugee_crisis.html"
data-include-replace="true" data-format="html"></div>
</dl>
</section>
<section>
<h3>Devices</h3>
<p>
Intelligence devices are created and deployed so that they can interact with
other <a>entities</a> (people, organizations, devices). Establishing trust
and maintaining secure relationships with these devices is especially critical.
</p>
<dl class="left dl-horizontal">
<div data-include="short/d1_devices_during_manufacturing.html"
data-include-replace="true" data-format="html"></div>
<div data-include="short/d2_devices_during_delivery.html"
data-include-replace="true" data-format="html"></div>
<div
data-include="short/d3_devices_setup_for_operating_autonomously.html"
data-include-replace="true" data-format="html"></div>
</dl>
</section>
</section>
<section>
<h2>User Tasks</h2>
<p>
Use cases are often used as a driver for requirements. While the users of
<a>verifiable credentials</a> have needs across many domains, the tasks
associated with those needs span the domains. This section summarizes those
tasks, as well as requirements related to the tasks, and maps the tasks and
requirements back to the associated needs.
</p>
<p class="note">
It is worth noting that the <a>subject</a> may or may not be the same
<a>entity</a> as the <a>holder</a>. There are no tasks in these examples that
require participation of the <a>subject</a>.
</p>
<figure>
<img alt="Verifiable Credential User Tasks"
style="display:block; margin:auto"
src="VerifiableCredentialsUserTasks.png" />
<figcaption>
Verifiable Credential User Tasks
</figcaption>
</figure>
<section>
<h3>Issue Claim</h3>
<dl class="dl-horizontal">
<dt>Requirement</dt>
<dd>
It MUST be possible for any <a>entity</a> to issue a <a>verifiable credential</a>.
</dd>
<dt>Motivation</dt>
<dd>
Individuals and organizations need a way to issue <a>claims</a> about
themselves or others that can be verified and trusted.
</dd>
<dt>Needs</dt>
<dd>
<uref>F.1</uref>, <uref>E.1</uref>, <uref>L.1</uref>, <uref>H.1</uref>
</dd>
</dl>
</section>
<section>
<h3>Assert Claim</h3>
<dl class="dl-horizontal">
<dt>Requirement</dt>
<dd>
It MUST be possible for the <a>holder</a> of a <a>verifiable credential</a>
to restrict the amount of information exposed in a <a>credential</a> they
choose to share. It also MUST be possible for the holder to limit the
duration for which that information is shared.
</dd>
<dt>Motivations</dt>
<dd>
<a>Credentials</a> may be issued about a <a>subject</a> that include multiple
attributes, only some of which are required when verifying a specific criteria
is satisfied. The <a>holder</a> should have the ability to satisfy the
criteria without revealing additional attributes that are not required.
</dd>
<dt>Needs</dt>
<dd>
<uref>R.2</uref>, <uref>H.4</uref>
</dd>
</dl>
</section>
<section>
<h3>Verify Credential</h3>
<dl class="dl-horizontal">
<dt>Requirement</dt>
<dd>
It is expected to be possible for a <a>verifier</a> to verify that the
credential is an authentic statement of an <a>issuer's</a>
<a>claims</a> about the
<a>subject</a>. Verifiers MUST have the capability to
cryptographically prove that a credential has not been tampered
with since issuance (authenticity) and that the issuer continues
to assert the claims as true (currency).
<br><br>
To check authenticity, the issuer's verification method(s), such as
a public key, must be discoverable from the credential itself. It
is expected that the issuer identifier either is
itself cryptographically verifiable, or that it can be used to
reliably discover the cryptographic material necessary to confirm
that the content of a credential has not been changed since
issuance. It is understood that verification depends on the
verifier's acceptance of the robustness of the cryptographic
mechanisms used for testing authenticity and for discovering
verification methods. An untrusted verification method cannot be
relied upon for verification.
<br><br>
Verifiers must also be able to
inquire about the current status of a credential without
revealing to the issuer
<ol type="a">
<li>The entity requesting that status</li>
<li>The credential for which status is being checked</li>
<li>The subject of the credential being checked</li>
</ol>
Requiring that verifiers perform this status check
is what enables issuers to revoke, suspend, or otherwise
moderate the status of the credential.
<br><br>
Similarly, if a discovery mechanism is used to retrieve
verification methods for a given issuer, verifiers must be able
to do so without revealing unnecessary information to the issuer.
<br><br>
In short, it must be possible to fully verify a credential
without leaking usage data to the issuer or anyone else. This
is to avoid the so-called "phone home" problem.
</dd>
<dt>Motivations</dt>
<dd>
In many environments (such as order processing), information — such
as a payer's address, citizenship, or age — needs to be
automatically verified to complete the transaction.
<br><br>
It MUST be possible to verify these in an automated fashion.
</dd>
<dt>Needs</dt>
<dd>
<uref>F.2</uref>, <uref>C.1</uref>, <uref>E.2</uref>, <uref>R.1
</uref>,
<uref>F.5</uref>, <uref>H.2</uref>, <uref>C.6</uref>
</dd>
</dl>
</section>
<section>
<h3>Validate Claim</h3>
<dl class="dl-horizontal">
<dt>Requirement</dt>
<dd>
It MUST be possible for a <a>verifier</a> to check whether a
given claim is appropriate for a particular use. That is, given
a credential that is authentic and current, the verifier needs to
interpret the claims in the context of their own 'business rules'
concerning, for instance, which parties are acceptable authorities, and which
cryptographic mechanisms are acceptable for what situations.
<ol>
<li>Is the issuer someone we know?</li>
<li>Are the claims made by this issuer appropriate for this
particular issuer's authority?</li>
<li>Is the holder's presentation an appropriate use of the
credential?</li>
</ol>
The first and second questions will be answered because either the
verifier already knows the public identifiers for the issuers it
recognizes for specific claims, or there is a discovery mechanism
whereby verifiers can find appropriate issuers given their
business requirements.
<br><br>
The business rules may allow the use of certain credentials for
specific situations, even when verification fails. For example, a
suspended or expired professional license may be accepted by an employer as
evidence of past experience without it being treated as a current
qualification for roles that require that license. For this
reason, current status (as part of verification) only deals with the
status of the credential as maintained by the Issuer. Timeliness
is the domain of validation.
<br><br>
It's important to note that the bounds of authority for a given
issuer are specific claim types made by them and relied upon by
others. While a region's DMV (Department of Motor Vehicles)
or equivalent agency might be an acceptable authority for an
individual's driving privilege, it should probably not be treated
as authoritative for an individual's hair color or current
address, even though DMVs regularly include such claims in
today's driver's licenses.
<br><br>
Unlike verification, it may not always be possible to
automate validation. Some use cases require human review before accepting
a particular credential for a particular use. For example, a
digital proof of age system might need a trusted human agent to
visually compare the holder/presenter in real-space to a
reference photo securely referenced in the VC, before accepting a
credential as valid.
</dd>
<dt>Motivations</dt>
<dd>
Verifiers need to be able to apply their own policies and rules
to the information they rely on to run their "business" (which we
mean broadly, to encompass all activity focused towards a goal).
<br><br>
Given this need, any given VC might be verified but not usable in a
particular situation. For example, a self-issued driver's license
would likely not be acceptable for a car rental by most car
rental agencies, even though the verification succeeds.
<br><br>
Even so, in other cases, such as at a go-cart racing facility, it
may be entirely appropriate to accept the name and image from a
self-issued license for the purpose of leaderboards,
announcements, and correspondence.
<br><br>
These business rules are entirely the province of the verifier. Only after
satisfying their rules should a verifier rely upon a claim as an
accepted fact for specific use.
</dd>
<dt>Needs</dt>
<dd>
<uref>F.2</uref>, <uref>C.1</uref>, <uref>E.2</uref>, <uref>R.1
</uref>,
<uref>F.5</uref>, <uref>H.2</uref>, <uref>C.6</uref>
</dd>
</dl>
</section>
<section>
<h3>Store Claim</h3>
<dl class="dl-horizontal">
<dt>Requirement</dt>
<dd>
It MUST be possible for the holder of a claim to store that claim in one or
more <a>credential repositories</a>.
</dd>
<dt>Motivation</dt>
<dd>
A <a>claim</a> is under the control of its <a>holder</a>. That holder will
choose where their <a>claims</a> are stored based upon a variety of factors
(e.g., employer requirements, convenience, service levels, provider cost,
business intelligence). The holder needs to be able to easily choose among
various <a>credential repositories</a>, and also to be able to migrate their
<a>claims</a> to another without requesting new <a>claims</a> from the
<a>claim</a> <a>issuer</a>.
</dd>
<dt>Needs</dt>
<dd>
<uref>F.4</uref>, <uref>E.3</uref>, <uref>C.4</uref>
</dd>
</dl>
</section>
<section>
<h3>Retrieve Claim</h3>
<dl class="dl-horizontal">
<dt>Requirement</dt>
<dd>
It MUST be possible for a <a>holder</a> to select if and which appropriate
credential should be sent to a <a>verifier</a>.
</dd>
<dt>Motivations</dt>
<dd>
A <a>verifier</a> may require that a <a>holder</a> verify aspects of their
suitability for a transaction. In this case, the <a>holder</a> must be able
to select which, if any, <a>verifiable credential</a> stored with their
<a>credential repository</a> is used to satisfy the <a>verifier</a>.
</dd>
<dt>Needs</dt>
<dd>
<uref>C.5</uref>, <uref>E.4</uref>
</dd>
</dl>
</section>
<section>
<h3>Revoke Claim</h3>
<dl class="dl-horizontal">
<dt>Requirement</dt>
<dd>
It MUST be possible for the <a>issuer</a> of a <a>claim</a> to revoke it,
after which it will no longer satisfy verification procedures.
</dd>
<dt>Motivation</dt>
<dd>
An <a>entity</a> (<a>issuer</a>) discovers that a <a>claim</a> they have
issued and are endorsing for an end user (<a>subject</a>), is no longer valid
and wishes to revoke the issued claim.
</dd>
<dt>Needs</dt>
<dd>
<uref>F.3</uref>, <uref>C.2</uref>, <uref>C.3</uref>
</dd>
</dl>
</section>
</section>
<section>
<h2>Focal Use Cases</h2>
<p>
Focal Use Cases are meant to provide examples where a blend of features from
<a>verifiable credentials</a> standard may be used together to solve complex
or challenging marketplace needs.
</p>
<div data-include="focal/1_citizenship_by_parentage.html"
data-include-replace="true" data-format="html"></div>
<div data-include="focal/2_expert_dive_instructor.html"
data-include-replace="true" data-format="html"></div>
<div data-include="focal/3_international_travel_with_minor_and_upgrade.html"
data-include-replace="true" data-format="html"></div>
<div data-include="focal/4_gs1_identification.html"
data-include-replace="true" data-format="html"></div>
</section>
<section>
<h2>Extant Use Cases</h2>
<p>
Extant Use Cases are illustrative of market adoption, i.e., examples of the use
of <a>verifiable credentials</a> in real-world applications.
</p>
</section>
<section>
<!-- Editor - @halindrome -->
<h2>User Sequences</h2>
<p>
The transaction examples in this section show basic ways in which
<a>verifiable credentials</a> might be used. They are not meant to be
architecturally constraining. Instead, they are meant to help illustrate the
basic way it <em>could</em> be done in a typical commerce situation. Again
— please remember that it is just an example, and should not be thought
of as the canonical way such a <a>claims</a> environment must be implemented.
</p>
<section>
<h3>How a Verifiable Credential Might Be Created</h3>
<p>
In this first example, a user will request a verifiable credential—a
confirmation of their identity. Consider this illustration:
</p>
<figure>
<img aria-describedby="claim_flow"
alt="Verifiable Credential Creation Flow Description"
style="display:block; margin:auto"
src="uc-issuing-claims.svg" />
<figcaption>Verifiable Credential Creation Flow Diagram</figcaption>
</figure>
<p>
Expanding on these steps:
</p>
<ol id="claim_flow" title="Verifiable Credential Creation Flow Description">
<li>
Jane asks her User Agent to help her get a <a>verifiable credential</a> about
her identity.
</li>
<li>
Her user agent connects her to a <a>credential</a> <a>issuer</a> that is able to
<a>verify</a> her identity.
</li>
<li>
The issuer examines her documentation.
</li>
<li>
They are satisfied, so the <a>issuer</a> generates a
<a>verifiable credential</a> for Jane that includes information about her
identity linked to their own trusted <a>credential</a>.
</li>
<li>
The issuer delivers the <a>verifiable credential</a> back to Jane's User Agent.
</li>
<li>
Jane views the <a>verifiable credential</a> to ensure it reflects her requirements.
</li>
<li>
When she is satisfied, she instructs her User Agent to save the
<a>verifiable credential</a> so she can use it in the future.
</li>
<li>
The UA communicates with her <a>credential repository</a>, instructing it to
store the new <a>verifiable credential</a>.
</li>
<li>
The <a>credential repository</a> returns a list of the
<a>verifiable credentials</a> it is holding for Jane to the UA.
</li>
<li>
The UA shows Jane her <a>verifiable credential</a> collection —
confirming everything she has available.
</li>
</ol>
</section>
<section>
<h3>How a Verifiable Credential Might Be Used</h3>
<p>
In this example, a <a>holder</a> of a <a>claim</a> needs to use that
<a>claim</a> in a typical commerce situation:
</p>
<figure>
<img aria-describedby="vf-flow"
alt="Verifiable Credential Usage Flow Diagram"
style="display:block; margin:auto"
src="example.svg" />
<figcaption>
Verifiable Credential Usage Flow Diagram
</figcaption>
</figure>
<ol title="Verifiable Credential Usage Flow Description" id="vf-flow">
<li>
Jane decides to shop on the website WinesOfTheWorld.example.com (merchant).
</li>
<li>
The merchant's site requires Jane be 21 years of age and requests (via a user
agent-supported API call) that Jane prove this.
</li>
<li>
Jane's user agent asks her <a>credential repository</a> for the proof.
</li>
<li>
The <a>credential repository</a> shows Jane some <a>verifiable credentials</a>
it holds that can support her age claim (e.g., her passport, driving license,
and birth certificate).
</li>
<li>
Jane selects one of these, and authorizes that it be shared with the merchant.
</li>
<li>
The <a>credential repository</a> returns the selected <a>credential</a> as a
response to the user agent-supported API call, which in turn delivers it to
the merchant.
</li>
<li>
The merchant's server verifies that the <a>claim</a> is valid and satisfies
the requirement.
</li>
<li>
The merchant redirects the user agent to the web site with appropriate
authorization.
</li>
</ol>
</section>
</section>
<section class="appendix">
<!-- Editor - @halindrome -->
<h2>Terminology</h2>
<em>This section is non-normative.</em>
<div data-include="./terms.html"
data-oninclude="restrictReferences">
</div>
</section>
<section class="appendix">
<h2>Example Verifiable Credentials</h2>
<div data-include="focal/3_international_travel_with_minor_and_upgrade_examples.html"
data-include-replace="true" data-format="html"></div>
<div data-include="focal/4_gs1_identification_examples.html"
data-include-replace="true" data-format="html"></div>
</section>
<section class="informative">
<h2>Acknowledgements</h2>
<p>
The editors are thankful to the contributions from the Web Payments Workshop,
the Web Payments Community Group, the Web Payments Interest Group, the
Credentials Community Group, the Verifiable Claims Task Force, and the
Verifiable Claims Working Group.
</p>
</section>
</body>
</html>