forked from w3c-ccg/vc-api-use-cases
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
1398 lines (1349 loc) · 86 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>VC API 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 class="remove" src="https://cdn.jsdelivr.net/gh/digitalbazaar/[email protected]/dist/main.js"></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: "NOTE",
useExperimentalStyles: true,
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "vc-api-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-ccg/vc-api-use-cases",
includePermalinks: false,
// if there a publicly available Editor's Draft, this is the link
//edDraftURI: "https://opencreds.github.io/vc-api-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: "Juan Caballero",
company: "Spherity", companyURL: "https://spherity.com/"},
{ name: "Joe Andrieu",
company: "Legendary Requirements", companyURL: "http://legreq.com" },
{ name: "Eric Schuh",
company: "Legendary Requirements", companyURL: "http://legreq.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: [
],
// maximum level of table of contents
maxTocLevel: 3,
// name of the WG
wg: "VC API Working Group",
// URI of the public WG page
wgURI: "TODO: get wg url",
// 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>
TODO: write a real abstract
</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://github.com/w3c-ccg/vc-api">VC API Specification</a>.
</p>
<p>
Comments regarding this document are welcome. Please file directly on
<a href="https://github.com/w3c-ccg/vc-api-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-api-comments/">archives</a>).
</p>
</section>
<section>
<!-- Editor - @eric-schuh -->
<h2>Abstract</h2>
<p>
Fundamentally, the Verifiable Credential API (VC-API) is a standard developed to give technologists a way to enable holders of
VCs to use them how and where they choose. Verifiable Credentials make claims which may be a qualification, achievement, quality, or piece
of information about an entity's background such as a name, government ID, payment provider, home address, or university degree.
The use cases outlined here are provided to help make progress toward possible future standardization and interoperability of the transport
of both low- and high-stakes claims as outlined in the VC Use Cases. 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 meant
to be reviewed alongside the <a href="https://w3c-ccg.github.io/vc-api/">Verifiable
Credentials API</a>.
</p>
<p>
Work on this document is ongoing and subject to change as the conversation around the
VC API evolves in the main group. This should currently be treated as a draft document and
as such will have errors. As the VC API gets closer to a completed specification, this
document should reflect the current understanding and status of that work.
</p>
<p>
Comments regarding this document are welcome. Please file directly on
<a href="https://github.com/w3c-ccg/vc-api-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>
<h2>Introduction</h2>
<p>
The VC-API Working Group at the W3C is developing standards for
exchanging Verifiable Credentials that have been verified by a third
party and to make them easier for holders to use on the Web and in life.
</p>
<section>
<h3>Importance of this work</h3>
<p>
<a>Entities</a> (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. The Holders of these claims, in the form of Verfiable Credentials,
need to be able to take the claims they control and make use of them where, when,
and how they wish, often in ways the original issuer of the VC may not have
originally indended. Having a common, standard way for these Holders of claims
to use them as they wish is vital to a person having control of their own data.
</p>
<p>
Standardization of the transport layer for digital <a>claims</a> makes it possible for many
stakeholders to interact with their desired 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 VC-API 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>
<p>
The model used here draws heavily from the Verifiable Credentials Use Cases model.
This is due to the fact that the VC-API is meant to support the transport of
VCs in the use cases considered for the Verfiable Credential Working Group.
</p>
</section>
</section>
<section>
<h2>User Roles</h2>
<p>
There are three roles supported by <a>Verifiable Credentials</a> as defined by the
VCWG: <a>Issuer</a>, <a>Verifier</a>, and <a>Holder</a>. In the VC Use Cases, a fourth
role — that of subject — is defined. However, for the purposes of the VC-API, the subject
is not relevant except when the same entity is both the Holder and the subject. For this
reason, the Subject role does not appear in the VC-API.
</p>
<figure>
<img alt="VC-API User Roles"
style="display:block; margin:auto"
src="user-roles.png" />
<figcaption>
VC-API User Roles
</figcaption>
</figure>
<p>
The above roles were those defined for the VCWG, however, due to the way most
production software on the internet works, for the purposes of the VC-API there arises
the need to delve into some detail as to how the Issuer and Verifier roles are structured.
This is due to the fact that there are many use cases where one company is making use of
services to handle part of the technology stack. This has led to both Verifier
and Issuer splitting into two entities each, henceforth refered to as components of the
Issuer and Verifier: <a>Issuer Service</a>, <a>Issuer Coordinator</a>,
<a>Verifier Service</a>, and <a>Verifier Coordinator</a>.
</p>
<figure>
<img alt="VC-API Role Components"
style="display:block; margin:auto"
src="role-components.png" />
<figcaption>
VC-API Role Components
</figcaption>
</figure>
<p>
The respective Service and Coordinator components combine to fulfill
the role of the Issuer and Verifier as described in the VCWG.
It is fully expected by the VC-API that software will exist that may fulfill only part of
any of the roles, by implementing any combination of these component roles:
<a>Issuer Service</a>, <a>Issuer Coordinator</a>
<a>Verifier Service</a>, and <a>Verifier Coordinator</a>.
</p>
<dl>
<dt>
Issuer Service
</dt>
<dd>
The <a>component</a> that creates, generates, and delivers a <a>Verifiable Credential</a> — which contains
a some set of <a>claims</a> made by the Issuer Coordinator about one or more subjects — to the Issuer Coordinator.
</dd>
<dt>
Issuer Coordinator
</dt>
<dd>
The <a>component</a> that deals with business rules and policies around a
user's request for a particlar <a>claim</a> to be issued.
</dd>
<dt>
Verifier Service
</dt>
<dd>
The <a>component</a> performing the verification of a <a>Verifiable Credential</a> containing <a>claims</a> about a given <a>subject</a>.
</dd>
<dt>
Verifier Coordinator
</dt>
<dd>
The <a>component</a> that deals with business rules and policies around a
user's request for a particular <a>Verifiable Credential</a> to be verified.
</dd>
<dt>
Subject
</dt>
<dd>
The <a>entity</a> about whom a <a>claim</a> is made.
</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>
The <a>VC-API</a> address user needs in a number of key domains:
</p>
<figure>
<img alt='VC-API User Needs'
style='display:block; margin:auto'
src="vc-api-problem-domain.png" />
<figcaption>
VC-API, 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>
A couple of years after Joleen succussfully started an "extended transcript"
program at the Unniversity she works for, the administration has decided to
issue all transcripts digitally. As such they upgrade the system to make use
of Education Credential Issuer Inc's issuing service, and put together a new
web page to act as their issueing coordinator. Once the system is in place,
Joleen pushes an email notification to the student body, both past and present,
that they can now receive digital transcripts at the newly created website to
the digital wallet of their choice.
</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. She presents her government-issued identity credential in the
form of a QR Code to the test runner, who scans it. The test runner's device
acts as the verification coordinator, which makes use of the ACT orginization's
verification service to verify the presented identification credential.
Everything checks out with Eunice's identification and she sits down to
take the text.
</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>verfifiable credentials</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, which he does
in the form of a government-issued idenfication credential. MOOC uses a backend
verification service which verifies these, and once they are satisfied that Nick
is who he says he is, have Nick take the courses he signed up for. At the end of
the courses, MOOC then uses their proprietary issuer service to provide Nick a
<a>verifiable credential</a> to the wallet of his choice 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 a verifiable credential--containing a claim by a known authority that a specific address has been verified--to Giant Shoe Company's
verifier coordinator, which verifies Francis's address, making use of
Generic Verfifier Service Inc. Francis 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
a proof-of-age 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. The store makes use of their Point of Sale Vendor's verification service
which intigrates into the Point of Sale so the clerk has an easy UI to use during
the transaction.
</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, by making use of the Verifier Service built into his
digital wallet which receives the proof of legitimacy, 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 goes
to the bank website, logs in, and navigates to the KYC page. She then
selects the government-supplied <a>verifiable credentials</a> that confirm she
receives postal mail at a certain address and that she has a national ID card.
She submits these to Midbank's verification coordinator. MidBank has their own verification service, which
checks the provided credentials, and confirms that they are properly issues,
and still valid, credentials issued to Jane. 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, by MidBank's Issuer Service,
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, which have decided to make use of TopBank's Verification
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. To receive
these credentials, John goes to Big Bank Co's website, selecting his prefered
wallet as the destination. 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. When John later goes to
do KYC with the New Bank Co, in his new city, he mistakenly submits his old
Big Bank Co account credential as part of the KYC process. New Bank Co's
verification service flags this credential as revoked, and New Bank Co's website
asks John for additional info.
</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 attributes (address, national
identity number, etc.), and opens her new account from her couch. As part of
this process, BigOnlineBank has stood up their own verification and issueing
services. Once they have verified Alice's credentials, they then notify Alice
that she can collect her proof of account credential from the provided link
at her leisure.
</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 makes use of the international Medical Certificate Issuer
to issue credentials that adhere to the international standards for
medical practitioners. Upon completing his state's board certificate test,
Barney is issued a verifiable credential confirming that he is
certified to practice medicine in that state. Barney can now use this
credential 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 attributes and her proof of insurance, which is checked by
the clinic using the issuer service provided by the Medical Office Supply
Co. 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. The clinic verifies these credentials,
making use of Medical Office Supply Co's verification service after John submits
the credentials to their administrative staff at the clinic via QR Code.
</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. As the ride
service is only checking very specific credentials, they have created their
own verification service to use. Once Trina's credential has been verifies,
they issue her a credential which gives full access to their service.
</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 would like
assurance that these are legit physicians, and so downloads the provided
credentials and submits them to the Open Medical Board Verification Service,
a national organization that checks the validity of medical claims for the
public. Once submitted, and verified, Jason is 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. However, Barney finds himself on a cruise where a fellow
cruise enjoyer has fallen over, in clear pain. Barney applies first aid until
the cruise doctors can get there. As part of the cruise ship's inquiry to the
event, for liability reasons, Barney provides them, via email,
his revoked physician credentials, along side his, still valid,
first aid certificate. The cruise doctor reviews these after they are verified
by the Generic Verifier Service that the cruise ship uses, and sends Barney
a response email thanking him for the assistance.
</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 authority to issue Project Manager certifications was revoked via
the US Department of Education's Accreditation Database. Jane's credential is
therefore invalid, and when Jane goes to submit the credential received from
BigTrainin Co. at her next job, she is notified by the company she is applying
to that her credential is not valid.
</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
<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, making use of their partner,
Workplace Credential Verifier Service, 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, using the international Education Verification Service,
which was stood up by a group of international univerisities to make the
verification of education credentials easy, 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 on the certifying authority's website,
(<a>issuer</a>) that she can use to prove to the officer
(<a>credential verifier</a>) that her <a>claim</a> is valid. The certifying
authority and officer both make use of the state's issuing and verifier
services, respectively, as they are both state entities.
</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,
by submitting a few credentials requested by the government authority, 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, by the TSA's verification service, 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, including 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. HVAC Manufacturing
provides Bob with the front end software for this, and has stood up their
own, custom, issueing service for use company wide.
</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. Certifications Testing Lab provides Carol with the front end software
to do this but makes use of the international Fan-Controller Standards Group's
issueing service, which requires attestations of the engineer making the
final claims about the device, before it will issue the specification-compliance
certificate.
</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. Sam's handheld scanner makes use of Scanner Co's verification
service, a package deal with the device.
</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. For this process,
VAR Resellers has stood up their own verification and issueing services
to be used within the company. 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>, using Generic Online
Verifier's online service. 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.
To do this, he goes to HVAC Manufacturing's website and requests the new
credential by scanning his new device's barcode and submitting an image to
HVAC Manufacturing's website. After verifying the device is one of their, HVAC
Manufacturing issuer's Sam the requested credential.
</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). To do this, Sam decides
he trust's HVAC Manufacturing to verify these types of credentials for him, and
so he puts the end-point provided by HVAC Manufacturing for these types of
purposes into his fan-controller's settings page.
</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. For this purpose,
Sam does not trust HVAC Manufacturing's verifier service, as there could be
a conflict of interest there, so Sam instead decides to use Generic HVAC
Verifier's verification service, adding the provided end-point to the approriate
configuration files so the devices use his selected verification services.
</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>
<!-- Editor - @eric-schuh -->
<h2>Focal Use Cases</h2>
<section>
<h3>Get Digital Permanent Resident Card</h3>
<p>Lana is an IT administrator for the United States Citizenship and Immigration Services (USCIS)
Digital Permanent Resident Card (PRC) program. She configures the USCIS website to issue digital
Permanent Resident Cards by utilizing industry standard issuer software and setting up the appropriate
HTTP API Authorizations between systems. Legal Permanent Residents, upon receiving their physical card
in the mail, are given the USCIS website URL, a login account, and PIN code that they may use to manage
their account and pick up their digital Permanent Resident Card. When Louis, a Legal Permanent Resident,
requests a digital Permanent Resident Card via the USCIS website, he authenticates using his login account
and once authenticated, provides a DID associated with his client-side digital wallet against which the
website will issue VCs. The USCIS website then connects to the digital card issuing server, which builds
the Verifiable Credential Permanent Resident Card using Louis' account data, and then utilizes industry
standard HTTP APIs to issue the Permanent Resident Card as a Verifiable Credential. Louis can then use his
Digital Permanent Resident Card in online scenarios when he needs to prove his resident status, such as
when applying for a job.</p>
<p><b>Requirements: </b><ul>
<li>1. Verify DID Authentication Presentation,</li>
<li>2. API Authorization,</li>
<li>3. Issue Verifiable Credential,</li>
<li>X. Website as Consumer</li>
</ul></p>
<p><b>Mermaid</b>
<figure>
<pre class="diagram mermaid">
sequenceDiagram
autonumber
Lana (Issuer Admin)->>uscis.gov (Issuer App):Configure to properly use Generic Issuer SAAS
uscis.gov (Issuer App)->>uscis.gov (Issuer App):Process configuration
uscis.gov (Issuer App)->>Generic Issuer SAAS (Issuer Service):Status check
Generic Issuer SAAS (Issuer Service)->>Generic Issuer SAAS (Issuer Service):Verify Authorization
Generic Issuer SAAS (Issuer Service)->>Generic Issuer SAAS (Issuer Service):Check business rules
Generic Issuer SAAS (Issuer Service)->>uscis.gov (Issuer App):All good
uscis.gov (Issuer App)->>Lana (Issuer Admin):Configuration complete
authn.io (Holder Service)->>Louis's Browser (Holder App):Holder-App/registerCredentialHandler
Louis (Holder)->>Louis's Browser (Holder App):uscis.gov
Louis's Browser (Holder App)->>uscis.gov (Issuer App):uscis.gov
uscis.gov (Issuer App)->>Louis's Browser (Holder App):uscis.gov/index.html
Louis's Browser (Holder App)->>Louis (Holder):uscis.gov/index.html
Louis (Holder)->>Louis's Browser (Holder App):Click "Get PRC"
Louis's Browser (Holder App)->>uscis.gov (Issuer App):uscis.gov/getPRC
uscis.gov (Issuer App)->>Louis's Browser (Holder App):request authentication
Louis's Browser (Holder App)->>Louis (Holder):request authentication
Louis (Holder)->>Louis's Browser (Holder App):provide authentication details
Louis's Browser (Holder App)->>uscis.gov (Issuer App):uscis.gov/authenticate?louiss-details
uscis.gov (Issuer App)->>uscis.gov (Issuer App):process provided authentication details
uscis.gov (Issuer App)->>Louis's Browser (Holder App):authentication succuss
Louis's Browser (Holder App)->>Louis (Holder):authentication succuss
uscis.gov (Issuer App)->>Louis's Browser (Holder App):Holder-App/requestPresentation
Louis's Browser (Holder App)->>Louis (Holder):Holder/selectHolderService
Louis (Holder)->>Louis's Browser (Holder App):holderServiceSelection
Louis's Browser (Holder App)->>authn.io (Holder Service):HolderService/requestPresentation
authn.io (Holder Service)->>Louis (Holder):Holder/selectWallet
Louis (Holder)->>authn.io (Holder Service):walletSelection
authn.io (Holder Service)->>Louis (Holder):Holder/selectProfile
Louis (Holder)->>authn.io (Holder Service):profileSelection
authn.io (Holder Service)->>Louis's Browser (Holder App):HolderApp/requestedPresentation
Louis's Browser (Holder App)->>uscis.gov (Issuer App):IssuerApp/requestedPresentation
uscis.gov (Issuer App)->>Generic Issuer SAAS (Issuer Service):IssuerService/credentials/issue?"providedVP"
Generic Issuer SAAS (Issuer Service)->>uscis.gov (Issuer App):IssuerApp/credentials/issued?"issuedCredentailsWrappedByIssuerApp"
uscis.gov (Issuer App)->>Louis's Browser (Holder App):HolderApp/newCredential?"issuedCredentialUnwrappedByIssuerApp"
Louis's Browser (Holder App)->>Louis (Holder):Holder/selectHolderService
Louis (Holder)->>Louis's Browser (Holder App):holderServiceSelection
Louis's Browser (Holder App)->>authn.io (Holder Service):HolderService/storeCredentials?"credentials"
authn.io (Holder Service)->>Louis (Holder):Holder/selectWallet
Louis (Holder)->>authn.io (Holder Service):walletSelection
authn.io (Holder Service)->>Louis (Holder):Holder/selectProfile
Louis (Holder)->>authn.io (Holder Service):profileSelection
authn.io (Holder Service)->>authn.io (Holder Service):Store credentials
authn.io (Holder Service)->>Louis's Browser (Holder App):HolderApp/credentialsStored
</pre>
<figcaption>UC6.1 Mermaid</figcaption>
</figure>
<p><i>Contributed by: </i>Digital Bazaar</p>
<p><i>Author Email: </i>[email protected]</p>
<p><i>Author Github: </i>msporny</p>
</p>
</section>
<section>
<h3>Refresh Expired Over Age Token</h3>
<p>Riley has onboarded into the TruAge digital age verification system, which has provided her
with a set of Verifiable Credentials that she stores in her digital wallet. A subset of the
Verifiable Credentials that she has received are digitally signed single-use age tokens that
only assert that she is above the age of 21 and are marked as "used" by the TruAge system
when they are submitted as a part of an age-restricted goods purchase, such as buying a
bottle of wine. Eventually, Riley runs out of single use age tokens in her digital wallet.
The digital wallet keeps track of which tokens have been used and once all tokens have been
consumed, contacts a refresh service endpoint listed in one of the TruAge credentials that
provides new over-age tokens. The digital wallet requests a new set of tokens by hitting the
HTTP API of this VC-refresh service listed in the “refreshService” array and POSTing the
original Verifiable Credential containing the refresh service description. The HTTP API
ensures that it has received a valid credential and reissues a set of new digitally signed