forked from w3c/vc-use-cases
-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
2077 lines (2003 loc) · 78.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
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!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-common' 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'>
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",
// 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/"}
],
// 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"
};
</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, comprised 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>
<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>
<img alt='Verifiable Credential User Needs'
style='display:block; margin:auto'
src="VerifiableCredentialsProblemDomains.png" />
<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">
<dt>
<udef>E.1 Digital transcript</udef>
</dt>
<dd>
Joleen is the registrar of Mega University and, by virtue of her office, is
responsible for the integrity, accuracy, and security of academic records.
Joleen has been a pioneering registrar in advocating an "extended transcript"
that includes not only the standard set of course grades but also adds
supplementary information on learner competencies. These might include work
experiences and non-educational but marketable skills. Upon the request of her
students, Joleen issues a digital credential that includes an extended
transcript.
</dd>
<dt>
<udef>E.2 Taking a test</udef>
</dt>
<dd>
Eunice is about to take her ACT (a test used to evaluate her readiness for
college). When she arrives at the testing center, she is required to present
identification. Her government-issued identity certificate is acceptable, as
the <a>verifiable credentials</a> contained in it reflect all of the required
attributes and it is difficult to counterfeit.
</dd>
<dt>
<udef>E.3 Transferring schools</udef>
</dt>
<dd>
Rocky is an undergraduate student at Wossamotta U. His school provides a
<a>credential repository</a> service to all students and alumni, so he chooses
to use it. In his third year, Rocky decides to transfer to Moosylvania Tech.
They do not offer a service, but he does not want to continue to use the
service of his old (and now rival school) so he moves his <a>claims</a> to the
service offered by his bank without needing to have them reissued.
</dd>
<dt>
<udef>E.4 Online classes</udef>
</dt>
<dd>
In MOOC and other online learning systems, being able to reliably identify
participants is vital to ensure the individual evaluation and certification.
Nick is participating in a course online and takes a test. He is required to
provide his credentials to prove his identity before the test, and then to
allow the system to issue a <a>verifiable credential</a> regarding the
results of his test.
</dd>
</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">
<dt>
<udef>R.1 Address verification</udef>
</dt>
<dd>
Francis has found the perfect pair of shoes. When processing orders, Giant Shoe
Company wants to be certain that his shipping address is accurate (inaccurate
addresses are very expensive in terms of customer service). They offer a
discount for customers who make verifiable addresses available as part of the
checkout process. Francis offers his certificate and gets the perfect shoes for
even less than he expected.
</dd>
<dt>
<udef>R.2 Adult beverages</udef>
</dt>
<dd>
June goes to her local beer and wine store to buy a bottle of wine. She submits
her identity credential that lets the liquor store owner know that she is over
21 without having to reveal her actual date of birth, her address, or her state
ID number.
</dd>
<dt>
<udef>R.3 Fraud detection</udef>
</dt>
<dd>
On a bright Sunday, Oskar remembers that he still needs to buy his wife a
precious gift for their wedding anniversary. However, he is acutely aware that
it is precisely in weekends that gangs set up fraudulent web shops that claim
to sell such gifts, while in fact they only take the cash, and disappear on
Mondays. So before actually purchasing a gift from the web shop of his choice,
he requests the shop to provide a credential issued by the chamber of commerce,
that contains proof of legitimacy. After having verified that the shop is
legit, he can purchase his gift.
</dd>
</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">
<dt>
<udef>F.1 Reuse know your customer</udef>
</dt>
<dd>
Jane is opening an account at MidBank in Finland. As part of that process,
the bank asks her to provide two from a variety of possible sources to confirm
her identity — a so-called "Know Your Customer" check. She
selects government-supplied <a>verifiable credentials</a> that confirm she
receives postal mail at a certain address and that she has a national ID card.
Confirming these allows the bank to open her account and be confident in her
identity when she conducts transactions.
</dd>
<dd>
Now that the account is open, Jane is issued a digitally-signed
<a>credential</a> for her checking account at MidBank. This <a>credential</a>
verifies that Jane has an account at MidBank and has access to her associated
checking account. Since MidBank (and all banks in Finland) are required to
perform "Know Your Customer" checks on accounts, this credential
can also be used as sufficient verification by other financial institutions.
This can help Jane assure destination banks that she is verified, thereby
allaying concerns about misdirected transactions and money laundering.
</dd>
<dt>
<udef>F.2 Money transfer</udef>
</dt>
<dd>
Susan wants to send funds to her family in another country via a popular money
transfer service. She has <a>verifiable credentials</a> in her
<a>credential repository</a> that can be used to share her
identity profile. She has also been sent a <a>credential</a> from her
family verifying their banking information. By sharing these with the money
transfer service, they can automatically verify the source and destination of
funds, thus being confident in the delivery of those funds and satisfying
various regulations regarding prevention of money laundering.
</dd>
<dt>
<udef>F.3 Closing account</udef>
</dt>
<dd>
John opens a checking account at Big Bank Co and is issued a
<a>verifiable credential</a> indicating that the account exists, that the bank
verified John's identity, and that John has access to the account. Some time
later, John is moving to a new city and decides to close that account. Big
Bank Co needs to revoke that claim as part of their normal account closing
process.
</dd>
<dt>
<udef>F.4 Trying out a new service</udef>
</dt>
<dd>
Nikita has several accounts with BigBank, as well as a brokerage account with
WallStreetCo. She had placed all of her <a>claims</a> in a
<a>credential repository</a> at BigBank that came free when she opened her
accounts. WallStreetCo is now offering a new <a>repository</a> that has an
interface she thinks she will prefer. Nikita copies her <a>claims</a> from
BigBank into the repository at WallStreetCo to experiment with their service,
but continues to use the service from BigBank while she is testing.
</dd>
<dt>
<udef>F.5 New bank account from home</udef>
</dt>
<dd>
Alice wants to open a new bank account. BigOnlineBank offers the ability to
do this from home if she can provide electronic credentials. She offers
government-issued certificates that verify her identity (address, national
identity number, etc.), and opens her new account from her couch.
</dd>
</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">
<dt>
<udef>H.1 Prescribing</udef>
</dt>
<dd>
Barney is a physician, and has recently become board certified in his state.
The state's board issues Barney a digital certificate confirming that he is
certified to practice medicine in that state. Barney can now use this
certificate when writing prescriptions and referrals, thereby improving
accountability and verifiability.
</dd>
<dt>
<udef>H.2 Online pharmacy</udef>
</dt>
<dd>
iPharmacy receives a prescription for Bob electronically from a local clinic.
It includes a certificate about the physician that issued the prescription as
well as one about Bob. iPharmacy's system automatically verifies the ability
of the physician to write prescriptions, as well as Bob's insurance coverage.
When Bob arrives to pick up his medication, iPharmacy further correlates his
identity with the certificate, thereby improving the end-to-end accountability
of their system.
</dd>
<dt>
<udef>H.3 Insurance claim</udef>
</dt>
<dd>
Tracy has a sore throat soon after moving to a new town. She finds a physician
through her health care network and goes in for treatment. She is a new
patient, so the clinic needs to know who she is and how she will be paying.
When checking in, she presents her <a>verifiable credential</a> that
demonstrates her identity and her proof of insurance. When the clinic submits
this to the insurance company, they can automatically ascertain that she
submitted her proof of identity and insurance to the provider and granted the
physician the ability to submit the claim for payment.
</dd>
<dt>
<udef>H.4 Traveling illness</udef>
</dt>
<dd>
John is on the vacation of a lifetime, travelling the world. Falling ill, he
visits a health clinic in a country in which he does not live. At the clinic,
he is asked for proof of identity. He provides a credential that verifies his
name and address, but elects not to disclose his marital status nor his social
security number, as those are neither requested nor required at this clinic.
He further marks the disclosure as expiring in 30 days—he does not want
his information verifiable after that time.
</dd>
<dt>
<udef>H.5 Proving Legal Disability Status</udef>
</dt>
<dd>
Trina, who is legally blind, is currently unemployed, and needs to use the
local free disability ride service to get to the employment office. To use
this service, she is required to verify that she maintains legal disability
status. Trina provides her government-issued disability credential to sign up
for the ride service, and is not required to disclose her specific disability
to the ride service, as this could put her at personal risk.
</dd>
</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">
<dt>
<udef>C.1 Find a doctor</udef>
</dt>
<dd>
Jason is looking for a new primary care physician. His health provider
includes information on their web site about the physicians they have on
staff, including <a data-lt="claim">verifiable credentials</a> about their
education, board certification, and continuing education. Jason can verify
these credentials and be confident that his new physician satisfies his
requirements.
</dd>
<dt>
<udef>C.2 Busy doctor</udef>
</dt>
<dd>
Barney was a board-certified physician, but he ran out of time to complete
his continuing education requirements and his certification lapsed. Since the
board can revoke his certification, <a>credential verifiers</a> will
automatically be aware that he can no longer issue prescriptions or perform
medical procedures.
</dd>
<dt>
<udef>C.3 Bad university</udef>
</dt>
<dd>
Jane was issued a certificate by BigTraining Co., indicating that she was a
trained Project Manager. It was later discovered that BigTraining Co. was not
actually training anyone, and their organization's certificate was revoked via
the US Department of Education's Accreditation Database. Jane's credential is
therefore invalid, and prospective employers will be aware of this when they
check her certifications.
</dd>
<dt>
<udef>C.4 New employer</udef>
</dt>
<dd>
Jessica is a medical doctor practicing in the United States. She has a variety
of digital <a>claims</a> that explain her qualifications, schooling, continuing
education achievements, and board certifications. These are all stored in the
<a>credential repository</a> provided by her employer. When she is offered a
position with another health provider network, she can automatically transfer
all of these <a>claims</a> to her new employer.
</dd>
<dt>
<udef>C.5 Social authority</udef>
</dt>
<dd>
Josie is a healthcare worker that has created a profile on a professional
social network to make herself readily available for new opportunities in the
workforce. She lists her employment history and credentials including degrees,
certificates, and digital badges. The website requests verification of her
credential <a>claims</a> in order for her credentials to be visible when she
posts messages. Josie authorizes the sharing of the relevant <a>claims</a> with
the website, and the site verifies them before allowing Josie to expose them.
</dd>
<dd>
"Freedom?" is an online forum that encourages free discussion about issues
controversial in Freedonia. The forum allows users to register anonymous
accounts, but it also allows users to obtain badges based upon real-world
certifications. Paula has been certified as an aid worker, and wishes that
information to be marked on her posts. She shares her certificate with the
forum, but limits it to only verifying that she is the <a>holder</a> of the
certificate, that she is the <a>subject</a> of it, and that she is an aid
worker. In this way she maintains her anonymity in this controversial forum
while still being able to assist her fellow countrymen.
</dd>
<dt>
<udef>C.6 Job applicant</udef>
</dt>
<dd>
Software Co. has posted an open position online and they are receiving
thousands of applications. Cindy has applied for the job. Unlike many
applicants, she has attached her education credentials—college degree,
additional specific software training, etc. Software Co. evaluates these
credentials automatically as they receive her application. Because her
materials are verifiable and verified, her application is immediately
forwarded as a viable candidate.
</dd>
</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">
<dt>
<udef>L.1 Digital driving license</udef>
</dt>
<dd>
Asako just passed the final test to receive a drivers license. As she is still
a new driver, and may be pulled over for a traffic violation, she would like
to receive a <a>credential</a> that asserts a <a>claim</a> that she has right
to drive a car. She requests a credential from the certifying authority
(<a>issuer</a>) that she can use to prove to the officer
(<a>credential verifier</a>) that her <a>claim</a> is valid.
</dd>
<dt>
<udef>L.2 Seamless immigration</udef>
</dt>
<dd>
Tom is a frequent international traveler. In order to speed processing
through immigration check points, he applies for a digital passport from his
governmental authority. After satisfying background check requirements, the
authority issues Tom an electronic version of his passport. This version is
verifiable and retains a history of all the places he visits so that
immigration officials can quickly and easily evaluate his suitability as a
visitor to their country. Once they are satisfied, they will automatically
add the details of this new visit to Tom's passport.
</dd>
<dt>
<udef>L.3 Speedy air travel</udef>
</dt>
<dd>
Security for air travel is more and more rigorous, requiring more and more
time to validate each passenger. Ivan has a collection of
<a>verifiable credentials</a> that are assembled into his air travel
<em>Identity Profile</em>. When Ivan needs to pass through a security
checkpoint at his airport, he presents this profile before entering the
line. Because his identification can be immediately and automatically
verified, he is permitted to skip the long line and go straight to the
metal detector.
</dd>
<dt>
<udef>L.4 Refugee crisis</udef>
</dt>
<dd>
Thousands of people each year are displaced because of man-made and natural
disasters. Anoushka is one such, having been forced to flee her village along
with her mother and younger brother. They reach an IFRC center just across
the border in a relatively safe area, but with no documentation. Since the
government of her homeland is in turmoil, there is no way for the IFRC staff
to easily establish their identities. Fortunately, Anoushka had been issued
a self-sovereign proof of birth, attached to which is the proof of birth and
marriage for her parents. She is able to retrieve this because it is available
from many places often the Internet. Since it is verifiable, the IFRC is
comfortable vouching for them and resettling them in a safer area for the
duration of the conflict.
</dd>
</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">
<dt>
<udef>D.1 Devices during manufacturing</udef>
</dt>
<dd>
<p>
Bob, the director of production at HVAC Manufacturing, issues a
device-identifying <a>verifiable credential</a> (e.g. IDevID, IAK) at the
factory for an energy-saving fan controller IoT device.
</p>
<p>
Carol, senior quality engineer at Certifications Testing Lab, issues a
certification of specification-compliance <a>verifiable credential</a> to the
fan-controller device at the certification lab during the manufacturing
process.
</p>
<p>
When the fan controller is installed at the customer's office at Modern Office
Spaces, the controller's identifying <a>credential</a> can be verified by Sam,
IT technician, to establish the identity of the controller as part of the
on-boarding of the new controller. The controller's specification-compliance
<a>credential</a> is verified to demonstrate the controller's Energy-Star
compliance.
</p>
</dd>
<dt>
<udef>D.2 Devices during delivery</udef>
</dt>
<dd>
<p>
As the fan controller leaves the factory, additional
<a>verifiable credentials</a> are issued by Vince, a systems engineer at VAR
Resellers, as he verifies the manufacturer's configuration matches the
<a>verifiable credentials</a> accompanying the device. He then installs a
software package specific to Modern Office Spaces needs and issues
<a>verifiable credentials</a> that establish evidence of possession by VAR
Resellers and the software additions Vince made to the device.
</p>
<p>
Finally, upon delivery to Sam, the end customer, the
<a>verifiable credentials</a> show that the fan controller has been securely
handled and contains the correct features and certifications.
</p>
</dd>
<dt>
<udef>D.3 Devices setup for operating autonomously</udef>
</dt>
<dd>
<p>
Sam, the new device owner, needs to trust the device originated from HVAC
Manufacturing and was handled correctly at Certifications Testing Lab and
installed with the correct software package at VAR Resellers. After Sam
verifies each of the <a>verifiable credentials</a>, he issues another
<a>verifiable credential</a> for fan controller #37 which includes assertions
relating to trust: device manufacturer model/version, software manufacturer
model/version, security versions of components TCB, and associated devices the
fan controller is authorized to interact with including thermostat-board-room.
</p>
<p>
The thermostat-board-room monitors room temperature. When the temperature is
too hot it switches the fan controller #37 on and later when the temperature
reaches a comfortable level, off. The device makes sure the control signals
from thermostat-board-room are authorized (namely, that Sam intended for
thermostat-board-room to control the fan controller).
</p>
<p>
Sam is concerned about the security of the smart board room. He configures
the autonomously interacting devices to re-verify device trustworthiness
attributes periodically by re-checking that the device originated from HVAC
Manufacturing and was handled correctly by Certifications Testing Lab and
installed with the correct software package by VAR Resellers.
</p>
<p>
Sam may update the device’s software occasionally during its lifetime. Even
though Sam is applying the update, VAR Resellers supplies the correct update.
The device ensures that only VAR Resellers is able to supply the updated
software image and that only Sam is able to apply the update.
</p>
</dd>
</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 Claim</h3>
<dl class="dl-horizontal">
<dt>Requirement</dt>
<dd>
It MUST 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>. The verifying <a>entity</a> must have the capability to
connect the issuer’s identity to its credential identifier and the
<a>subject's</a> identity to their identifier as indicated in the credential.
The issuer’s verification information, such as its public key, must be
discoverable from the credential record and verifiably linked to the issuer.
It MUST be possible to do this in an automated fashion.
</dd>
<dt>Motivations</dt>
<dd>
In many environments (such as order processing) information such as a payer's
address, citizenship, or age need to be automatically verified in order to
complete the transaction.
</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 / Move 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>. It MUST also be possible for the holder
to move a claim among <a>credential repositories</a>, and to do so without
requesting a new claim from the claim issuer.
</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>
<section>
<h3>Citizenship by Parentage</h3>
<h4>Background</h4>
<p>
Sam wants to claim US citizenship because his mother is American. Sam has a
digital birth certificate from Kenya, where he was born while his Mother was
in the Peace corps. He also has a digital version of his mother's US passport.
Because his mother’s name changed between his birth and the issuance of the
passport, Sam also has a marriage license with her maiden and married names.
Sam is applying for a new passport from the US Secretary of State.
</p>
<h4>Distinction</h4>
<p>
This use case is challenging because the mother’s name changed, by marriage,
between the issuance of the birth certificate and passport.
</p>
<h4>Scenario</h4>
<p>
Sam’s mother emailed him the certificate, license, and passport as independent
<a>Verifiable Credentials</a>. He then creates a <a>verifiable presentation</a>
which includes those credentials, a statement of their relationship to each
other and his relationship to his mother. He then visits the US Secretary of
State website, creates an account, starts the application for a passport, and
uploads his new <a>verifiable presentation</a> as supporting evidence. After
processing the application, Sam is issued both a traditional passport and a
new digital passport.
</p>
<h4>Verifiable Credentials</h4>
<dl class="dl-horizontal">
<dt>
Birth Certificate
</dt>
<dd>
Establishes relationship to mother with maiden name
</dd>
<dt>
Marriage License
</dt>