generated from w3c/note-respec-repo-template
-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathindex.html
858 lines (800 loc) · 34.5 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
<!DOCTYPE html>
<html>
<head>
<title>Verifiable Issuers and Verifiers v0.1</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<!--
=== NOTA BENE ===
For the three scripts below, if your spec resides on dev.w3 you can check them
out in the same tree and use relative links so that they'll work offline,
-->
<script
src="https://www.w3.org/Tools/respec/respec-w3c"
class="remove"
></script>
<script type="text/javascript" class="remove">
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "CG-DRAFT",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "verifiable-iv",
group: "credentials",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "1977-03-15",
// previousMaturity: "WD",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://github.com/w3c-ccg/verifiable-issuers-verifiers/",
// 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: ["spec.css", "prettify.css"],
// editors, add as many as you like
// only "name" is required
editors: [{
name: "Isaac Henderson Johnson Jeyakumar",
company: "Fraunhofer IAO, Germany"
}, {
name: "Manu Sporny",
company: "Digital Bazaar"
}],
authors: [{
name: "Manu Sporny",
company: "Digital Bazaar"
}, {
name: "Oskar van Deventer",
company: "TNO"
}, {
name: "Isaac Henderson Johnson Jeyakumar",
company: "Fraunhofer IAO, Germany"
}, {
name: "Shigeya Suzuki",
company: "Keio University"
}, {
name: "Konstantin Tsabolov",
company: "Spherity"
}, {
name: "Line Kofoed",
company: "Bloqzone"
}, {
name: "Rieks Joosten",
company: "TNO"
}],
// extend the bibliography entries
//localBiblio: webpayments.localBiblio,
wg: "Credentials Community Group",
// URI of the public WG page
wgURI: "https://www.w3.org/community/credentials/",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-credentials",
// 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/community/about/agreements/cla/",
github: "https://github.com/w3c-ccg/verifiable-issuers-verifiers/",
// 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: "",
maxTocLevel: 4,
/*preProcess: [ webpayments.preProcess ],
alternateFormats: [ {uri: "diff-20111214.html", label: "diff to previous version"} ],
*/
localBiblio: {}
}
</script>
<style>
pre .highlight {
font-weight: bold;
color: green;
}
pre .comment {
font-weight: bold;
color: Gray;
}
.color-text {
font-weight: bold;
text-shadow: -1px 0 black, 0 1px black, 1px 0 black, 0 -1px black;
}
ol.algorithm {
counter-reset: numsection;
list-style-type: none;
}
ol.algorithm li {
margin: 0.5em 0;
}
ol.algorithm li:before {
font-weight: bold;
counter-increment: numsection;
content: counters(numsection, ".") ") ";
}
</style>
</head>
<body>
<section id="abstract">
<p>
This work focuses on how a party or its agent can decide whether or not to
engage with a counterparty in a transaction. The purpose of this work is to
enable a party to share a list of Verifiable Issuers and Verifiers in a way that
is useful to a particular transaction.
</p>
</section>
<section id="sotd">
<p>
There was extensive analysis of existing initiatives performed at the
Rebooting the Web of Trust 11 conference in The Hague as well as a number of
follow on meetings to coordinate activity across various communities. The
paper analyzing the existing state of the art is available from the
Rebooting The Web of Trust <a href="https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/verifiable-issuer-verifier-lists/verifiable-issuer-verifier-lists.pdf">
paper archive</a>.
</p>
<p>
This specification is intended to align with work happening in other venues
such as the Trust Over IP Foundation, ESSIF-Lab, The European Digital Identity
Initiative and other European Trust Frameworks, Canadian Trust Framework
activities, as well as commercial ventures that are exploring Trust Frameworks.
Effort will continue to be expended to align this specification with work
happening in other related venues. The authors and editors of this
specification invite commentary on this specification through the Github
issue tracker listed at the top of this document.
</p>
<p>
This is an experimental specification and is undergoing regular revisions. It is
not fit for production deployment.
</p>
</section>
<section>
<h2>Introduction</h2>
<p>
The maintenance of lists of Verifiable Issuers, sometimes referred to as Trusted
Registries, are a well-known concept from the pre-internet age. Whenever there
is a diploma signed by a university, there are people and organizations that
keep track of what universities exist and what methods there are to confirm the
authenticity of that diploma. A list could be maintained by HR staff for the
purpose of hiring personnel based on qualifications asserted by particular
Verifiable Issuers, and the governance of that list would be minimal. Another
list could be maintained by a government, associated with well-governed
accreditation procedures, for the purpose of assuring that a diploma represents
a proper education. Lists of Verifiable Issuers support Verifiers in their
decision to trust the Issuer of a Verifiable Credential that is presented by a
Holder.
</p>
<p>
Digitally sharing lists of Verifiable Issuers and Verifiers is a relatively new
concept. Examples are the list of parties that are allowed to use the digital
fingerprint information on the chip of RFID-based digital passports. This is
cryptographically enforced: “chip-says-no” when an unauthorized party attempts
to access this information on the chip. Also eIDAS v2 will have a
Verifiable-Verifiers List that limits the access of Verifiers to credentials in
a EUDI (EUropean Digital Identity) wallet. Verifiable-Verifiers Lists support
Holders and holder implementations in their decision to trust a Verifier to
share a Verifiable Presentation to that Verifier.
<p>
Lists of Verifiable Issuers and Verifiers help to automate the decision process
of whether to engage with a counterparty in a transaction and make it more
auditable by ensuring that software can note that a party was on a list before
engaging with them. This paper contains the following sections that provide
background on the problem space as well as a proposed set of solutions given the
current state of the market:
</p>
<ul>
<li>
Section 2 presents a set of use cases in the digital age that explain the use of
lists of Verifiable Issuers and Verifiers.
</li>
<li>
Section 3 analyses prior art such as lists of Verifiable Issuers and Verifiers
that have already been deployed, or that are being developed, as well as a gap
analysis of the current solutions and desired outcomes.
</li>
<li>
Section 4 highlights the unified requirements derived from the analysis of prior
art and a conceptual model for sharing lists of Verifiable Issuers and Verifiers
and the format of the entries in the list.
</li>
<li>
Section 5 provides a concrete data model and possible serializations, which
could serve as a starting point for future standardization.
</li>
<li>
Section 6 discusses possible next steps towards future standardization.
</li>
<li>
Section 7 concludes the paper and proposes future work.
</li>
</ul>
<p>
The target audience of this paper are people that know the basics of
Self-Sovereign Identity (SSI) such as the concepts of Issuer, Holder, Verifier,
and Verifiable Credential. SSI developers may use this document as input and
inspiration for their code and other products. Deployers of SSI use cases may
use this document in the specification process of their deployment.
</p>
<section id="terminology">
<h2>Terminology</h2>
<p>
The following terms are used to describe concepts in this document.
</p>
<p>
<strong>Credential</strong>
</p>
<p>
A set of one or more <a
href="https://www.w3.org/TR/vc-data-model/#dfn-claims">claims</a> made by an <a
href="https://www.w3.org/TR/vc-data-model/#dfn-issuers">issuer</a>. A
<strong>verifiable credential</strong> is a tamper-evident credential that has
authorship that can be cryptographically verified. Verifiable credentials can be
used to build <a
href="https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations">verifiable
presentations</a>, which can also be cryptographically verified. The <a
href="https://www.w3.org/TR/vc-data-model/#dfn-claims">claims</a> in a
credential can be about different <a
href="https://www.w3.org/TR/vc-data-model/#dfn-subjects">subjects. </a>
</p>
<p>
<strong>Electronic Identification, Authentication and Trust Services
(eIDAS)</strong>
</p>
<p>
<strong>eIDAS</strong> (<strong>e</strong>lectronic
<strong>ID</strong>entification, <strong>A</strong>uthentication and trust
<strong>S</strong>ervices) is an <a
href="https://en.wikipedia.org/wiki/Regulation_(European_Union)">EU
regulation</a> on <a
href="https://en.wikipedia.org/wiki/Electronic_identification">electronic
identification</a> and <a
href="https://en.wikipedia.org/wiki/Trust_service_provider">trust services</a>
for <a href="https://en.wikipedia.org/wiki/Electronic_transactions">electronic
transactions</a> in the <a
href="https://en.wikipedia.org/wiki/European_Single_Market">European Single
Market</a>. It was established in EU Regulation 910/2014 of 23 July 2014.<sup>
</sup>All organizations delivering public digital services in an EU member state
must recognize electronic identification from all EU member states from
September 29, 2018.
</p>
<p>
<strong>European Digital Identity (EUDI)</strong>
</p>
<p>
The European Digital Identity is based on a European Commission document
called “European Digital Identity Architecture and Reference Framework” that has
established the functional and architectural requirements for an upcoming
European Digital Identity Wallet.
</p>
<p>
<strong>Holder</strong>
</p>
<p>
A role an <a
href="https://www.w3.org/TR/vc-data-model/#dfn-entities">entity</a> might
perform by possessing one or more <a
href="https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials">verifiable
credentials</a> and generating <a
href="https://www.w3.org/TR/vc-data-model/#dfn-presentations">presentations</a>
from them. A holder is usually, but not always, a <a
href="https://www.w3.org/TR/vc-data-model/#dfn-subjects">subject</a> of the <a
href="https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials">verifiable
credentials</a> they are holding. Holders store their <a
href="https://www.w3.org/TR/vc-data-model/#dfn-credential">credentials</a> in <a
href="https://www.w3.org/TR/vc-data-model/#dfn-credential-repository">credential
repositories</a>.
</p>
<p>
<strong>Issuer</strong>
</p>
<p>
A role an <a
href="https://www.w3.org/TR/vc-data-model/#dfn-entities">entity</a> can perform
by asserting <a
href="https://www.w3.org/TR/vc-data-model/#dfn-claims">claims</a> about one or
more <a href="https://www.w3.org/TR/vc-data-model/#dfn-subjects">subjects</a>,
creating a <a
href="https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials">verifiable
credential</a> from these <a
href="https://www.w3.org/TR/vc-data-model/#dfn-claims">claims</a>, and
transmitting the <a
href="https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials">verifiable
credential</a> to a <a
href="https://www.w3.org/TR/vc-data-model/#dfn-holders">holder</a>.
</p>
<p>
<strong>Level of Assurance (LoA)</strong>
</p>
<p>
The degree of certainty that a relying party can have about the true
identity of someone presenting an identity credential. Four levels of assurance
were outlined by a 2006 document from the US National Institute of Standards and
Technology (NIST 800-63). The level of assurance is measured by the strength and
rigor of the identity proofing process, the strength of the token used to
authenticate the identity claim, and the management processes the identity
provider applies to it.
</p>
<p>
<strong>Sharing</strong>
</p>
<p>
The act of transferring information from one party to another. This paper
uses the word "sharing" instead of "publishing" as the latter presumes a one-way
and public transfer of information. The <strong>Verifiable
Issuer/Verifier</strong> <strong>lists</strong> described in this paper are made
available in some form or other. They might be pushed to a party or pulled from
a party and might use a public communication channel or a private one.
</p>
<p>
<strong>Verifiable Issuer / Verifiable Verifier</strong>
</p>
<p>
A party that is verifiable might have different levels of trustworthiness
associated with it by different parties. Note that “trusted” or “authorized” are
sometimes used as synonyms for “verifiable”, as the purpose of some lists is to
assure trust or authority. This paper uses the word “verifiable” as no
presumption should be made about the application of the lists, or the
trust/authority that they assure.
</p>
<p>
<strong>Verifiable Issuer/Verifier List</strong>
</p>
<p>
A container that consists of a set of <strong>Verifiable</strong>
<strong>Issuers</strong> or <strong>Verifiers</strong>. The word “list” can be
considered synonymous to “register”, depending on the amount of governance,
assurances and authority associated with it. This paper uses the word “list” and
presumes there will always be some form of governance, if only the establishment
of its purpose and the format of its entries.
</p>
<p>
<strong>Verifier</strong>
</p>
<p>
A role an <a
href="https://www.w3.org/TR/vc-data-model/#dfn-entities">entity</a> performs by
receiving one or more <a
href="https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials">verifiable
credentials</a>, optionally inside a <a
href="https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations">verifiable
presentation</a> for processing. Other specifications might refer to this
concept as a relying party.
</p>
<section>
<h3>Criteria</h3>
<p>
This section contains criteria that can be used to determine whether something
does or does not fit a particular terminological definition in the previous
section.
</p>
<p>
<strong>sharing</strong>
</p>
<ul>
<li>Enables other parties to obtain a copy of a <strong>list entry</strong>
about an <strong>Issuer</strong> or <strong>Verifier</strong> from the
<strong>list</strong>, e.g. in VC format, through DNS query, or other mechanism.
<li>May or may not enable others to obtain a copy of the full contents of a
<strong>list</strong>.
<li>Those others may be anyone in the world, or they may be only those who have
access to the <strong>list</strong> or to a specific entry about an
<strong>Issuer</strong> or <strong>Verifier</strong>.
</li>
</ul>
<p>
<strong>list</strong>
</p>
<ul>
<li>Contains zero-or-more entries about any <strong>party</strong>.
<li>A list entry contains data about one specific <strong>party.</strong> The
data is specified by the <strong>party </strong>that <strong>governs
</strong>the <strong>list</strong>.
<li>A list is associated with a policy containing one or more criteria that are
used to determine whether or not a <strong>party</strong> qualifies for being
registered in the <strong>list</strong>. Criterion may distinguish between
<strong>parties</strong>, e.g., between parties that are trusted to issue or
verify VCs of a specific kind.
<li>Other parties may use the data in a <strong>list entry </strong>as the basis
for a decision, e.g., to share further information, or to engage in a
transaction. The perceived use of <strong>list entries</strong> by other
<strong>parties</strong> should guide the <strong>party</strong> that governs
the <strong>list</strong> as it specifies the structure of <strong>list
entries</strong>.
</li>
</ul>
<p>
<strong>parties</strong>
</p>
<ul>
<li>Are expected to perform the roles of <strong>issuer</strong>,
<strong>holder</strong>, and <strong>verifier</strong> as well as other
verifiable-credential-related roles (e.g., revocator).
<li>May or may not be a legal authority.
<li>The <strong>party </strong>that manages the list has to be able to precisely
describe the thing that the list entry enables because software will act upon
that machine-readable description. For example, "Issues Student ID cards for
University X".
</li>
</ul>
</section>
</section>
<section id="conformance">
<p>
A <dfn>conforming list</dfn> is any concrete expression of the data model
that complies with the normative statements in this specification. Specifically,
all relevant normative statements in Sections
<a href="#data-model"></a> of this document MUST be enforced.
</p>
<p>
A <dfn class="lint-ignore">conforming processor</dfn> is any algorithm realized
as software and/or hardware that generates or consumes a
<a>conforming list</a>. Conforming processors MUST produce errors when
non-conforming documents are consumed.
</p>
<p>
This document also contains examples that contain JSON and JSON-LD content. Some
of these examples contain characters that are invalid JSON, such as inline
comments (`//`) and the use of ellipsis (`...`) to denote
information that adds little value to the example. Implementers are cautioned to
remove this content if they desire to use the information as valid JSON or
JSON-LD.
</p>
</section>
</section>
<section>
<h2>Use Cases</h2>
<p>
This section outlines use cases that highlight the need for the technology
described in this paper by discussing the use cases in two categories:
</p>
<ul>
<li>Verifiable Issuers
<li>Verifiable Verifiers
</li>
</ul>
<p>
A final use case section then checks for commonalities and differences between
the two categories
</p>
<p>
There are a number of other locations that have published use cases that are
related to this paper. Rather than include those use cases in this document,
they are included by reference:
</p>
<ul>
<li><a
href="https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/authorized-issuer-lists.md#authorized-issuer-list-use-cases">Authorized
Issuer List Use Cases</a>
<li><a
href="https://gitlab.grnet.gr/essif-lab/infrastructure/fraunhofer/train_project_summary#business-problem">ESSIF-Lab
Trust Management Infrastructure (TRAIN) Business Case</a>
</li>
</ul>
<h3>Verifiable Issuer Use Cases</h3>
<ul>
<li>Acme Inc. is a producer of medical equipment. Twin Mountains Hospital
decided to buy equipment from Acme Inc. The law says that medical equipment
should be certified by a 3rd party certification body. Twin Mountains Hospital
requests a certification from Acme, Inc.; Twin Mountains Hospital delivers it to
them. The hospital then checks if Acme Inc. is in the Verifiable Issuer List of
licensed 3rd party certification bodies to see if the Issuer of Acme Inc.'s
certification is an approved certification body.
<ul>
<li>Note: The solution might need to convey a single item in a List vs. the
entire List.
<li>Note: Many similar certification/license use cases are out there.
</li>
</ul>
<li>Walmay, Inc. is a wholesaler of drugs. John & Jane is a manufacturer of
drugs. Walmay, Inc. finds out that a lot of Adenosine Triphosphate drugs has
broken packaging and decides to return the lot to the manufacturer. It is
required that all interactions in the drug market must be done only between
authorized trading partners. John & Jane requests an authorized trading partner
certificate from Walmay Inc. The certificate credential contains a link to the
Issuer. John & Jane then verifies that the Issuer is a member of the
Verifiable-Issuer List of Issuers authorized to issue ATP (Authorized Trading
Partner) credentials.
<li>Elena is an IT Administrator in the hiring department of a mid-size company
that would like to vet job applicants as having received their degrees from an
accredited college or university. Elena configures their hiring software to
refer to multiple lists (Verifiable-Issuer Lists) containing several hundred
organizations that are curated by the various accreditation bodies that they
trust.
<li>Line is elected treasurer of a Dutch church. In her role as treasurer, she
goes online to open a bank account for the church. To comply with certain laws
and adhere to internal risk mitigating policies, the bank needs to verify that
Line has been authorized by the church to sign on its behalf. For companies,
personal information about executive board members is registered by the Chamber
of Commerce alongside the registration of the legal entity. However, due to the
special sensitive nature of data regarding religious affiliations, the Chamber
of Commerce in the case of religious institutions (mosque/synagogue/church) is
prohibited from registering any data that can be correlated with a natural
person. Instead of checking the Chamber of Commerce public register, the bank
requests a credential from Line stating her mandate to sign, which she received
from the church. The bank checks whether the church is on the Verifiable
Issuer-List of Churches, which is maintained by the Chamber of Commerce. Finding
the church on the list, the bank is now able to open a bank account for the
church, which Line can administer.
</li>
</ul>
<img style="max-width: 75%; height: auto;" src="images/diploma.jpg"
alt="A graduate holding a diploma with a text bubble attached to the diploma
that says 'Verifiable-Issuer List says diploma is genuine'">
<p>
Figure 1: A Verifiable-Issuer List helps verifying whether a diploma is genuine.
</p>
<h3>Verifiable Verifier Use Cases</h3>
<p>
See also <a
href="https://blockchain.tno.nl/blog/verify-the-verifier-anti-coercion-by-design/">Verify
the Verifier - Anti-coercion by Design; October 2020 | TNO</a>
</p>
<ul>
<li>Yuri has a digital driver's license and is attempting to rent a car from
CarMart. CarMart requests to see Yuri's age, motor vehicle class, and driver's
license number. Yuri's software checks against a Verifiable-Verifier List to
make sure that CarMart is a Verifiable authority for information of that type,
so it can warn Yuri if CarMart isn't trusted to request that information from
Yuri.
<li>Oskar joins a tennis club. The tennis club requests a government-issued
proof of birth date. However, the tennis club does not have authorization to ask
for this personal information. As a consequence, Oskar’s certified EUDI wallet
refuses to present the information, based on the absence of the tennis club in
the relevant Verifiable-Verifier List. The tennis club realizes that they cannot
obtain this high-LoA information from the EUDI wallet and instead accepts a
self-asserted date-of-birth by Oskar.
<li>Oskar was invited by the European Commission to become an evaluator. Even
though Oskar would be paid only the equivalent of a book voucher, the EC
requires a full contracting process, which includes an eIDAS LoA high
identification and a recent authentic bank statement. Even though Oskar
considers these requirements unreasonable, Oskar’s certified EUDI wallet accepts
the request, as the EC is registered in the relevant Verifiable-Verifier List.
This way, Oskar knows at least that the request is genuine, and that there
exists a sufficiently-well-governed policy associated with the request.
<li>Oskar crosses the border to Dystopia. Immigration requests that Oskar
surrender all Verifiable Credentials in his SSI wallet, including
identification, driver’s license, diplomas, certifications and other records.
Immigration of this country is not authorized to make such a wide request, as it
is not included in the relevant Verifiable-Verifier List. As a consequence,
Oskar’s certified EUDI wallet refuses to present this information. Even the
threat of denial-of-entry or worse cannot change the situation, as neither
immigration nor Oskar himself is physically able to compromise Oskar’s EUDI
wallet to surrender the information.
</li>
</ul>
<img style="max-width: 75%; height: auto;" src="images/police.jpg"
alt="A police officer standing over a child asking for their credentials and
the child saying that they cannot provide the credentials because their
digital wallet cannot identify that the police officer is authorized to
ask for all of that information.">
<p>
Figure 2: A properly-implemented wallet with Verifiable-Verifier List protects
citizens against overzealous law enforcement.
</p>
<h3>Commonalities and Differences</h3>
<p>
Conceptually and technically, the two types of lists (Verifiable Issuer,
Verifiable Verifier) are fairly similar. Each type is a governed list of parties
with a role in SSI exchanges. Each type needs to provide some form of sharing
(publication/access), so that the list is available to its users. This paper
will presume that the types of lists themselves, as well as their sharing
methods, can be technically identical. The only distinction is that a list could
contain only Verifiable Issuers, only Verifiable Verifiers, or a mixture<sup
id="fnref2"><a href="#fn2" rel="footnote">2</a></sup> of both, so the data model
should accommodate this.
</p>
<p>
Major differences arise in the applications surrounding the lists. Verifiable
Issuer lists target Verifier implementations, whereas Verifiable Verifier lists
target Holder (digital wallet) implementations. Also there may be major
differences in the governance between the two types of lists, or whether/how the
consulting of lists is implemented and enforced. All of these differences are
out of the scope of this paper.
</p>
</section>
<section>
<h2>Requirements</h2>
<h3>Conceptual Model</h3>
<p>
An Assurance Community is what governs a list of Verifiable Issuers and/or
Verifiers. The community can consist of a single person, a group of people, an
organization, a group of organizations, or any other relevant structure. The
governing can be purely manual, partially automated, or completely automated
through the use of APIs or smart contracts.
</p>
<p>
A list of Verifiable Issuers and/or Verifiable Verifiers contains entries with
information about the Issuers and/or Verifiers that it verifies.This information
can be as minimal as a single DID or public key per Verifiable Issuer or
Verifiable Verifier, or it can also include metadata about each entity and the
services that each entity performs.
</p>
<p>
An Interested Party is an entity that uses one or more entries from the List of
Verifiable Issuers and/or Verifiable Verifiers in a decision making process. An
interested party is typically software that is acting on behalf of an Issuer,
Holder, or Verifier. The party might request the entire List, or portions of the
List over either a public channel, or a private channel.
</p>
<h3>Requirements</h3>
<p>
The following requirements have been specified by the authors. It includes both
requirements on a Verifiable-Issuers/Verifiers List (“a list” in short) as a
whole and its individual entries. These requirements may be updated in the
future.
</p>
<ul>
<li>A list may be created and governed by any individual, group of individuals,
organization, group of organizations, or other.
<li>A list and/or its entries shall be made available to subscribers.
<li>A list and/or its individual entries shall be serializable in one or more
formats such as a Verifiable Credential.
<li>Entries may be made available via a Wallet, a Website, a URI, a QR code, a
DNS Resource Records, DNSSEC, on-chain Ethereum transactions, or other methods.
<li>A list and its entries shall be cryptographically verifiable.
<ul>
<li>A list shall accommodate Different cryptographic mechanisms (X.509, JWK
etc.).
<li>There shall be an ability to authenticate the list or an individual entry.
</li>
</ul>
<li>A list and its entries shall have associated Governance Metadata Format,
including:
<ul>
<li>Policies; and
<li>Qualifier details.
</li>
</ul>
<li>A list and its entries shall be publicly resolvable.
<li>A list and its entries shall be privately transmittable/retrievable.
<li>A list may have metadata associated with it, e.g., metadata that is
applicable to all of its entries.
<li>A list may have different levels of privacy/confidentiality, ranging from
fully public to for-authorized-yes-only.
<li>Entries shall be able to be created, read, and deleted.
<li>Entries may be updated, suspended and/or revoked.
<li>Entries may have an individual level of assurance associated with it.
<li>Entries may have an associated level of assurance.
</li>
</ul>
<p class="issue">
The only technology approach that we were not able to analyze deeply is
Trinsic's approach. We need to make sure their approach is integrated into and
aligned with the documented use cases, requirements, and the rest of the
document.
</p>
</section>
<section>
<h2>Data Model</h2>
<p>
The following sections outline the data model that is used by this specification
for Verifiable Issuer and Verifier Lists.
</p>
<p>
The data model described in this section has been built using input from a
variety of the prior art evaluated for this paper including input from the EBSI
Trusted Issuer Registry, ETSI TS 119 612, eSSIF-Lab TRAIN, the Trust over IP
Foundation Trust Registry Protocol, and Rebooting the Web of Trust input
documents. The data model described in this section is capable of expressing
many, but not all, of the concepts described in those other specifications.
</p>
<p>
The unified data model for this work can be represented as a list of entries
that represent parties.
</p>
<p>
Each list entry, representing a party, contains the following mandatory
information:
</p>
<ul>
<li>An identifier
<li>The type, such as a "VerifiableIssuer" or "VerifiableVerifier"
<li>A human-readable name
</li>
</ul>
<p>
Each list entry, representing a party, might contain the following optional
information:
</p>
<ul>
<li>A legal name
<li>An associated website
<li>An email address
<li>A set of identifiers that specify a human readable name for the property and
its corresponding value
<li>A set of operational schemes, such as a trust scheme, under which it
operates, stored as tuples of a URL to the operational scheme and a
human-readable name.
<li>A set of accreditations that are identified by URL
<li>A set of credentials that the party is authorized to issue, verify, or
otherwise process where each credential description MUST contain:
<ul>
<li>A type
<li>A credential schema that can be used to match against a Verifiable
Credential
</li>
</ul>
</li>
</ul>
</section>
<section>
<h3>Verifiable Credential</h3>
<p>
The data model described in this section can be expressed as a Verifiable
Credential as outlined in the example below:
</p>
<pre
class="prettyprint">{
"@context": [
"https://www.w3.org/2018/credentials/v2",
"https://w3id.org/verifiable-party/v1"
],
"issuer": {
"id": "did:web:authority.example",
"name": "National Education Accreditation Authority of Utopia"
},
"issuanceDate": "2023-02-13T00:18:30.053Z",
"type": ["VerifiableCredential", "VerifiablePartyCredential"],
"credentialSubject": [{
"id": "did:web:registrar.utopia.edu.example",
"type": "VerifiableIssuer",
"name": "Utopia University Registrar",
"legalName": "The Polytechnic University of Utopia Registrar",
"website": "https://utopia.edu.example/",
"email": "[email protected]",
"identifier": [{
"type": "PropertyValue",
"propertyId": "Utopia Educational Institution ID",
"value": "123456789"
}],
"usesOperationalScheme": [{
"id": "http://oid-info.com/get/1.2.3.4.5",
"name": "Utopian Trust Scheme 819-4"
}],
"accreditation": [{
"id": "https://utopia.gov.example/accreditations/123"
}],
"authorizedToIssue": [{
"type": "UniversityDegreeCredential",
"credentialSchema": {
"id": "https://Issuer.example/degree.json",
"type": "AuthorizedIssuerJsonSchema2022",
"schema": "{\"properties\":\{\"credentialSubject.state\":\"UA\"}}"
}
}]
},
"proof": { ... }
}
</pre>
</section>
<section class="appendix informative">
<h2>Acknowledgements</h2>
<p>
The Working Group thanks the following individuals for significant
contributions to the community: TBD
</p>
<p>
Work on this specification has been supported by the Rebooting the
Web of Trust community facilitated by Christopher Allen, Joe Andrieu, and
Erica Connell. The participants in the Internet Identity Workshop,
facilitated by Phil Windley, Kaliya Young, Doc Searls, and Heidi Nobantu Saul,
also supported the refinement of this work through numerous working sessions
designed to educate about, debate on, and improve this specification.
</p>
<p>
The Working Group would like to thank the following individuals for reviewing
and providing feedback on the specification (in alphabetical order):
</p>
<p>
Some of the imagery in this specification was provided by
<a href="https://www.pexels.com/@ron-lach/">Ron Lach</a> and
<a href="https://www.pexels.com/@kindelmedia/">Kindel Media</a> under the
<a href="https://www.pexels.com/license/">Pexel's license</a>. We are
thankful to those individuals and Pexels for providing imagery that this
community could use and have made donations to each of those contributors.
</p>
</section>
</body>
</html>