-
Notifications
You must be signed in to change notification settings - Fork 3
Expand file tree
/
Copy pathindex.html
More file actions
1094 lines (1048 loc) · 40.3 KB
/
Copy pathindex.html
File metadata and controls
1094 lines (1048 loc) · 40.3 KB
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 lang="en">
<head>
<meta charset="utf-8">
<title>Confidence Method v1.0</title>
<script src="https://www.w3.org/Tools/respec/respec-w3c"
class="remove"></script>
<script class="remove"
src="https://cdn.jsdelivr.net/gh/w3c/respec-vc@3.4.3/dist/main.js">
</script>
<script class="remove">
// All config options at https://respec.org/docs/
var respecConfig = {
specStatus: "FPWD",
publishDate: "2025-10-30",
editors: [{
name: "Joe Andrieu",
url: "https://www.linkedin.com/in/joe-andrieu/",
company: "Legendary Requirements",
companyURL: "https://legreq.com/",
w3cid: 97261
}, {
name: "Denken Chen",
url: "https://denkeni.org/",
company: "Ministry of Digital Affairs, Taiwan",
companyURL: "https://moda.gov.tw/",
w3cid: 158074
}],
shortName: "vc-confidence-method",
subtitle: "Increasing confidence during presentation of verifiable credentials",
wg: "W3C Credentials Community Group",
group: "vc",
github: "https://github.com/w3c/vc-confidence-method/",
edDraftURI: "https://w3c.github.io/vc-confidence-method/",
inlineCSS: true,
maxTocLevel: 4,
localBiblio: {
"NIST-SP-800-63-4": {
"title": "Digital Identity Guidelines",
"href": "https://pages.nist.gov/800-63-4/sp800-63.html",
"authors": [
"David Temoshok",
"Yee-Yin Choong",
"Ryan Galluzzo",
"Connie LaSalle",
"Andrew Regenscheid",
"Diana Proud-Madruga",
"Sarbari Gupta",
"Naomi Lefkovitz"
],
"publisher": "National Institute of Standards and Technology",
"date": "August 2025",
"id": "NIST SP 800-63-4"
},
"EIDAS2": {
"title": "Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework",
"href": "http://data.europa.eu/eli/reg/2024/1183/oj",
"authors": [
"European Parliament",
"Council of the European Union"
],
"publisher": "Official Journal of the European Union",
"date": "30 April 2024"
}
},
doJsonLd: true,
includePermalinks: false,
lint: {
"no-unused-dfns": false,
"informative-dfn": false
},
xref: [
"INFRA", "I18N-GLOSSARY", "VC-DATA-MODEL-2.0", "VC-DATA-INTEGRITY", "CID"
],
postProcess: [window.respecVc.createVcExamples],
otherLinks: [{
key: "Related Documents",
data: [{
value: "Verifiable Credentials Data Model v2.0",
href: "https://www.w3.org/TR/vc-data-model-2.0/"
}]
}]
};
</script>
<style>
code {
color: rgb(199, 73, 0);
font-weight: bold;
}
pre {
overflow-x: auto;
white-space: pre-wrap;
}
pre .highlight {
font-weight: bold;
color: Green;
}
pre .subject {
font-weight: bold;
color: RoyalBlue;
}
pre .property {
font-weight: bold;
color: DarkGoldenrod;
}
pre .comment {
font-weight: bold;
color: SteelBlue;
-webkit-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;
}
.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, ".") ") ";
}
.supported {
background-color: #93c47d;
}
.missing {
background-color: #e06666;
}
table.simple {
border-collapse: collapse;
margin: 25px 0;
min-width: 400px;
border: 1px solid #dddddd;
}
table.simple thead tr {
background-color: #005a9c;
color: #ffffff;
text-align: left;
}
table.simple th,
table.simple td {
padding: 12px 15px;
vertical-align: top;
text-align: left;
}
table.simple tbody tr {
border-bottom: 1px solid #dddddd;
}
table.simple tbody tr:nth-of-type(even) {
background-color: #00000008;
}
table.simple tbody tr:last-of-type {
border-bottom: 2px solid #005a9c;
}
</style>
<style>
.property-comparison {
border-collapse: collapse;
margin: 25px 0;
min-width: 400px;
border: 1px solid #dddddd;
}
.property-comparison td,
.property-comparison th {
padding: 12px 15px;
vertical-align: top;
border: 1px solid #dddddd;
}
</style>
</head>
<body>
<section id='abstract'>
<p>
This specification defines mechanisms that can be used with the
[[[VC-DATA-MODEL-2.0]]] to increase a [=verifier|verifier's=]
confidence that a presenter of a [=verifiable credential=] is,
in fact, appropriately related for its use. In the simplest
situation, this means the presenter is the original, legitimate
recipient of the credential. This specification defines a data
model for expressing confidence methods and evidence in a
[=verifiable credential=] and provides examples of how to use
it.
</p>
</section>
<section id='sotd'>
<p>
This is an experimental specification and is undergoing regular
revisions. It is
not fit for production deployment.
</p>
</section>
<section id="introduction" class="informative">
<h2>Introduction</h2>
<p>
Determining that a current presenter is the [=subject=] of a
[=Verifiable Credential=] is a key concern for verifiers.
</p>
<p>
This specification defines two extensible mechanisms that
[=Issuers=]
can use to help [=Verifiers=] increase their confidence that the
presentation of a given Verifiable Credential is legitimate.
</p>
<p>
The confidenceMethod property enables issuers to provide
specific
techniques for improving the confidence that a candidate party
is one of the subjects in a VC. For example, improving
confidence
that the presenter of a marriage license is one of the parties
involved: the officiant, one of the spouses, or one of the
witnesses.
</p>
<p>
The confidenceMethod property can be used to specify a
particular biometric, cryptographic key, or other mechanism that
the presenter can use to demonstrate that they are that subject
in the VC. It is up to the verifier to decide whether to require
the presenter to use the confidence method, or to use a
different mechanism to increase their confidence about whether,
for example, the presenter is the same entity the issuer made
claims about in the VC. Such a decision can impact the
verifier's liability when accepting VCs during certain use
cases.
</p>
<p>
The assuranceLevel property enables issuers to declare the
level of assurance that the issuer established before issuing
the
credential to its initial recipient. For example,
an issuer can declare that they used a particular identity
proofing process, signifying standard levels of assurance like
IAL 3 defined in [[NIST-SP-800-63-4]]. This can
help verifiers understand the level of assurance that
the issuer had at the time of issuance as an input for their own
informed decisions about whether to accept them.
</p>
<p>
Both of these mechanisms are extensible using JSON-LD to
define a new type of confidence method or assurance level.
</p>
<p>
For example, when an employer (the
[=issuer=]) issues a corporate identification card to an
employee (the
[=subject=]), it might require that the employee bind a
particular cryptographic
key (<a
data-cite="VC-DATA-INTEGRITY#dfn-verification-method">verification
method</a>) to the [=verifiable credential=] during the
issuing process. In that
case, the [=issuer=] can use this specification to convey to the
[=verifier=]
which cryptographic key was bound during the initial identity
assurance process.
</p>
<p>
In other words, an [=issuer=] can use this specification to
convey which
provable mechanisms it used to bind [=claims=] in a [=verifiable
credential=] so
that a [=verifier=] can increase their confidence in the truth
of a variety of
things, including the following:
</p>
<ul>
<li>
a particular identifier in the [=verifiable credential=]
refers to the same
[=subject=] the issuer intended it to refer to,
</li>
<li>
a [=subject=], such as the [=presentation|presenter=] of a
[=verifiable
credential=], is the same [=subject=] that the [=issuer=] made
[=claims=] about,
</li>
<li>
a [=subject=] [=controller|controls=], or has been designated
to use, one or
more mechanisms for demonstrating proof-of-possession of
cryptographic key
material,
</li>
<li>
a [=subject=] identified in the [=verifiable credential=] can
be checked against
a biometric.
</li>
</ul>
</section>
<section id="conformance">
<p>
A <dfn>conforming document</dfn> is any concrete expression of
the data model
that follows the relevant normative requirements in Section
<a href="#data-model"></a>.
</p>
<p>
A <dfn>conforming processor</dfn> is any algorithm realized as
software and/or
hardware that generates and/or consumes a [=conforming
document=]. Conforming
processors MUST produce errors when non-conforming documents
are consumed.
</p>
</section>
<section id="evidence" class="informative">
<h1>Relation to the <a>evidence</a> property</h1>
<p>The Verifiable Credentials specification defines an
<a>evidence</a> property:
</p>
<blockquote>
Evidence can be included by an issuer to provide the verifier
with
additional supporting information in a verifiable credential.
This
could be used by the verifier to establish the confidence with
which
it relies on the claims in the verifiable credential. For
example, an
issuer could check physical documentation provided by the
subject or
perform a set of background checks before issuing the
credential. In
certain scenarios, this information is useful to the verifier
when
determining the risk associated with relying on a given
credential.
</blockquote>
<p>
This property is expected to be used at the top level of the
credential, effectively providing "supporting information" for
the entire credential.
</p>
<p>
The example provided in the specification illustrates how this
might be used:
<pre class="example nohighlight"
title="Example of evidence supporting a skill achievement credential">
{
...
"evidence": [{
<span class='comment'>// url to an externally hosted evidence file/artifact</span>
"id": "https://videos.example/training/alice-espresso.mp4",
"type": ["Evidence"],
"name": "Talk-aloud video of double espresso preparation",
"description": "This is a talk-aloud video of Alice demonstrating preparation of a double espresso drink.",
<span class='comment'>// digest hash of the mp4 video file</span>
"digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
}
]
}
</pre>
</p>
<p>This example is accompanied by the following note:
<p class="note"
title="Evidence has a different purpose from securing mechanisms">
The `evidence` property provides information that is
different
from and
information to the securing mechanism used. The `evidence`
property is
used to express supporting information, such as documentary
evidence, related to
the [=verifiable credential=]. In contrast, the securing
mechanism
is used to
express machine-verifiable mathematical proofs related to the
authenticity of
the [=issuer=] and integrity of the [=verifiable credential=].
For
more
information about securing mechanisms, see Section
<a href="https://www.w3.org/TR/vc-data-model-2.0/#securing-mechanisms">#securing mechanisms</a>.
</p>
<p>As demonstrated, the evidence property is expected to provide
evidence, such as the mp4 video file in the example.
</p>
<p>This specification presents two additional measures that
provide mechanisms for increasing the verifier's confidence in
specific subjects without revealing unnecessary personal
information. Rather than provide additional "evidence", the additional properties of
<a>confidenceMethod</a> and <a>assuranceLevel</a> provide
distinct attestations from the issuer:
<table class="property-comparison">
<tr>
<th><a>evidence</a></th>
<td>A top-level property, this presents evidence
independently evaluatable by the verifier without further
interaction with either the issuer or the holder. For
example, the issuer might provide a video of the subject
performing some specific action such as performing a task.
</td>
</tr>
<tr>
<th><a>confidenceMethod</a></th>
<td>A subject-level property, this defines mechanisms the
<a>verifier</a> can use to increase the confidence that a
<a>subject</a> of the VC is also the subject of another
interaction. For example, the <a>issuer</a> might provide
a <a data-cite="VC-DATA-INTEGRITY#dfn-verification-method">verification
method</a>, such as a public key, by
which the verifier could apply a proof-of-use protocol to
establish that a current user has the ability to sign
cryptographic challenges using the same cryptographic
secrets believed by the issuer to be under the control of
the subject. This is sometimes called "proof-of-control".
</td>
</tr>
<tr>
<th><a>assuranceLevel</a></th>
<td><span class="issue atrisk">A subject-level property,
this allows <a>issuers</a> to attest to having established a known Assurance Level according to public standards such as NIST-SP-800-63-4 and EIDAS2. Rather than providing evidence to be evaluated or a mechanism to be applied, this property simply describes the issuers own processes for identifying the subject before issuing the credential.</span></td>
</tr>
</table>
</p>
</p>
</section>
<section>
<h2>Data Model</h2>
<p>
This specification defines the `confidenceMethod` property for
expressing
confidence method information in a `credentialSubject` in a
[=verifiable
credential=].
</p>
<dl>
<dt><dfn>confidenceMethod</dfn></dt>
<dd>
<dd>
<p>
If present, the value of the `confidenceMethod` property is
one or more
confidence methods as defined below. Each confidence method
specifies the specific
type of confidence method and any reference data that might
be required to evaluate the method. The method is bound to a
[=subject=]
in the [=verifiable credential=] and provides enough
information for a
[=verifier=] to evaluate whether a particular candidate
party is, for their purposes, the same entity referenced in
the credential. THe verifier evaluates the confidence
method, executing the process of that method. Successful
evaluation indicates the credential has satisfied the
confidence method and the verifier can safely rely on that
belief to provide services. </p>
<p>
Each confidence method MUST specify its `type` and MAY
specify an `id`. The precise properties and semantics of
each confidence method are determined by the
specific `confidenceMethod` type definition.
</p>
</dd>
<dt><dfn>assuranceLevel</dfn></dt>
<dd>
<p class="issue atrisk">If present, the value of the `assuranceLevel` property is
one or more assurance levels, defined below. Each assurance
method specifies the specific type of assurance level and
any reference data that might be required to evaluate the
method. The method is bound to a [=subject=] in the
[=verifiable credential=] and provides information about the
level of assurance that the issuer had about the subject at
the time of issuance. This can help a [=verifier=]
understand the means by which the verifier established their
own level of assurance that for that subject. Different
subjects may have different assurance level, allowing the
issuer to use different levels of assurance for different
subjects in the same credential. For example, an issuer can
use a high level of assurance for the subject that is the
officiant or spouse in a marriage license, but a lower level
of assurance for the witnesses to that ceremony. </p>
</p>
<p>
Each assurance level MUST specify its `type` and MAY
specify an `id`. The precise properties and semantics of
each assurance level are determined by the
specific `assuranceLevel` type definition.
</p>
</dd>
</dl>
<p>
A [=verifier=] can decide to accept [=claims=] in a [=verifiable
credential=]
without requiring use of the confidence method, or use a
different mechanism to
increase their confidence about whether, for example, the
[=holder=] is the same
entity the issuer made [=claims=] about in the [=verifiable
credential=]. Such a
decision can impact the [=verifier=]'s liability when accepting
[=verifiable credentials=] during certain use cases.
</p>
<p>
A [=verifier=] can validate that the [=holder=] controls, or has
been designated
the ability to use, a confidence method by verifying the [=data
integrity
proof|proof=] of the <a>verifiable presentation</a> using the
information in the
confidence method. The confidence method can include the
verification key, or
the type of the confidence method can define that the
verification key is to be
inferred from other properties in the [=verifiable credential=],
such as the
`credentialSubject.id`.
</p>
<p>
The following example demonstrates the various types of
confidence methods
that can be used, including public cryptographic keys,
verification methods,
and Decentralized Identifier Documents.
</p>
<pre class="example nohighlight"
title="Usage of the confirmationMethod property of type VerificationKeyConfirmation">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
<span class="highlight">"confidenceMethod": [{
"type": "BiometricPortraitImage",
"image": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD",
}, {
"id": "urn:uuid:818d5ca0-3978-11f0-8658-4f17a1afd652#key-abc",
"type": "JsonWebKey",
"controller": "urn:uuid:818d5ca0-3978-11f0-8658-4f17a1afd652",
"publicKeyJwk": {
"crv": "Ed25519",
"x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
"kty": "OKP",
"kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
}
}, {
"id": "did:example:123#key-567",
"type": "Multikey",
"controller": "did:example:123",
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}, {
"id": "did:example:1234",
"type": "DecentralizedIdentifierDocument"
}]</span>,
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": { <span class="comment">...</span> }
}
</pre>
<p class="note">
A confidence method can express various metadata such as the
[=issuer=]'s level
of confidence that the [=holder=] is the [=subject=] of the
[=verifiable
credential=], specific form factors or mechanisms of
authenticators, and/or
references to other [=verifiable credentials=] or versioned
trust frameworks.
For example, an [=issuer=] can make a [=claim=] about a
confidence method that
is based on a cryptographic key pair, but to produce a signature
using that key,
the [=holder=] has to unlock a device using multi-factor
authentication.
</p>
</section>
<section>
<h2>Confidence Methods</h2>
<dl>
<dt><dfn>VerificationConfidence</dfn></dt>
<dd>
<p>
VerificationConfidence specifies how to use a verification
method in a controlled identifier document such as a DID
document.
</p>
</dd>
<dt><dfn>BiometricImageConfidence</dfn></dt>
<dd>
<p>
BiometricImageConfidence specifies how to use an image
in a verifiable credential for recognizing the subject of
the credential.
</p>
</dd>
</dl>
<section>
<h3>Verification Confidence</h3>
<p>TBD</p>
</section>
<section>
<h3>Biometric Image Confidence</h3>
<p>TBD</p>
</section>
<section>
<h3>Biometric Vector Confidence Method</h3>
<div class="issue atrisk"
title="Biometric Vector Confidence Method is unstable">
The Biometric Vector Confidence Method is unstable and continues to
be refined by the Task Force. The following concerns are actively
being worked on at present:
<ol>
<li>The specification needs to be agnostic to biometric matching
providers and not favor any particular proprietary or open
approaches or types.</li>
<li>Model and vector data might be combined since they are associated
with one another. It doesn't really make sense to decouple the
model and the vector information. `base64url` encoded CBOR might
be a better approach to holding this information.</li>
<li>How do we specify examples with open matching models, which
need to exist in the spec?</li>
<li>Clarify that the issuer can provide multiple vectors from
different providers when the credential is issued.</li>
<li>There is no standardized ZKP for biometric matching yet,
but the group believes that is the ideal end-state.</li>
<li>Issuers putting service URLs into the biometric matching model
might not be the best design and will need to be refined. More
work will be needed to figure out how the negotiation is to be
performed between the holder and the verifier, and between the
holder and the issuer.</li>
<li>Where should this information be published? Is it safe to put
this in the DID Document?</li>
<li>Describe "ideal state" use cases in the specification.</li>
<li>How do holders find "the right" biometric provider? Is it
asking too much of the holder? Is that a security/privacy risk?
How much are we asking holders to do?</li>
<li>Do application integrity checks need to be performed for local
device checks?</li>
<li>Nonces need to be added to the model.</li>
</ol>
</div>
<p>
A <dfn>BiometricVectorConfidenceMethod</dfn> enables an [=issuer=] to embed
biometric <em>vectors</em> in a [=verifiable credential=] so that a
[=verifier=] can increase their confidence that the
[=presentation|presenter=] is the same individual the [=issuer=] made
[=claims=] about. Unlike raw biometric data (e.g., photos, audio
recordings), biometric <em>vectors</em> are compact mathematical
representations produced by a matching model. Vectors from different
models are not interchangeable.
</p>
<section>
<h4>Use Cases</h4>
<p>
<strong>Age verification at point of sale.</strong> When a consumer
purchases age-restricted goods, the clerk currently handles the
consumer's physical ID, exposing full name, address, and date of
birth — creating risks of identity theft and physical safety. With
a biometric vector confidence method, the consumer's device performs
a biometric match and sends only a signed verification result to the
point-of-sale system. The clerk never sees the consumer's personal
information and never has to judge whether a document is authentic.
</p>
<p>
<strong>Account recovery.</strong> When a user loses access to an
account through a forgotten password or lost device, service
providers typically rely on insecure knowledge-based authentication
or manual support processes. A biometric vector confidence method
enables automated recovery by comparing a fresh biometric capture
against vectors enrolled at registration — stronger than security
questions and faster than customer support, without storing photos.
</p>
<p>
<strong>Mobile credential presenter restriction.</strong> Digital
credentials such as mobile driver's licenses can be transferred to
unauthorized parties without a mechanism to verify whether a presenter
is the legitimate and intended presenter. A biometric vector confidence
method provides cryptographic verification of a presenter — the credential
includes enrolled vectors, and the presenter proves authorized possession
through a fresh biometric match at the time of presentation.
</p>
<p>
<strong>Remote onboarding and identity proofing.</strong> When
organizations need to verify a person's identity remotely — e.g., for
employment, financial services, or government benefits — a biometric
vector confidence method can bind the verified identity to a
credential without requiring in-person presence. A biometric
match confirms that the person presenting themselves remotely is the same
person whose identity was proven during issuance, reducing fraud while
preserving privacy.
</p>
</section>
<p>
A biometric vector confidence method MUST specify the following properties:
</p>
<dl>
<dt>`id`</dt>
<dd>
A unique identifier for this confidence method instance. Enables a
person to maintain multiple biometric enrollments for different contexts.
</dd>
<dt>`type`</dt>
<dd>
The value MUST be `BiometricVectorConfidenceMethod`.
</dd>
<dt>`biometricModality`</dt>
<dd>
The biometric modality. Expected values include `face`, `voice`,
`fingerprint`, `palmprint`, `iris`, and `retina`.
</dd>
<dt>`captureFormat`</dt>
<dd>
The capture format. Expected values include `video`, `static-image`,
`image-sequence`, and `audio`.
</dd>
<dt>`biometricModel`</dt>
<dd>
An object identifying the matching model, containing a `type` property
(MUST be `BiometricMatchingModel`) and a `matchingModel` property
(vendor and model identifier, e.g., `example-biometric-2026-v3.2`).
</dd>
<dt>`biometricVectors`</dt>
<dd>
Multibase-encoded (base64url-nopad) biometric vector. The format is
specific to the matching model that generated it. An [=issuer=] MAY
include multiple vectors from different providers to give the
[=holder=] flexibility in selecting a verification service.
</dd>
</dl>
<p>
A biometric vector confidence method MAY also specify:
</p>
<dl>
<dt>`service`</dt>
<dd>
A service endpoint for server-assisted verification, following the
service definition structure from [[[DID-CORE]] ][[DID-CORE]], containing
`id`, `type` (`BiometricVerificationService`), and `serviceEndpoint`
properties.
</dd>
</dl>
<p>
Two implementation scenarios are supported: client-side local processing
and user-selected provider. In both cases, a fresh biometric sample is
captured and compared against the enrolled vectors. The result is
expressed as a `BiometricVerificationCredential`.
</p>
<section>
<h4>Client-Side Verification</h4>
<p>
In this scenario, biometric verification happens entirely on the
[=holder=]'s device. No biometric data leaves the device; a
zero-knowledge proof demonstrates the match.
</p>
<p>
The following example demonstrates a credential with a biometric vector
confidence method for client-side verification:
</p>
<pre class="example" title="Client-side biometric vector confidence method">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"validFrom": "2026-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"confidenceMethod": {
"id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
"type": "BiometricVectorConfidenceMethod",
"biometricModality": "face",
"captureFormat": "video",
"biometricModel": {
"type": "BiometricMatchingModel",
"matchingModel": "example-biometric-2026-v3.2"
},
"biometricVectors": "uAVvLMv6gm...MNam"
},
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science"
}
}
}
</pre>
<p>
The [=holder=]'s device captures a fresh biometric sample, compares it
locally against the enrolled `biometricVectors`, and produces a
`BiometricVerificationCredential` asserting the match. Note that the
`credentialSubject.id` in the verification output references the
confidence method `id` from the credential above, linking the
verification result to the specific biometric enrollment:
</p>
<pre class="example" title="Verification output for client-side biometric match">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiableCredential", "BiometricVerificationCredential"],
"issuer": "did:example:holder-device",
"validFrom": "2026-05-15T14:30:00Z",
"validUntil": "2026-05-15T14:45:00Z",
"credentialSubject": {
"id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
"biometricMatch": {
"type": "BiometricMatch",
"matchingMethod": "client-side-zkp",
"matchDate": "2026-05-15T14:30:00Z",
"matchResult": "verified",
"confidence": "0.96"
}
},
"proof": {
"type": "DataIntegrityProof",
"cryptosuite": "example-biometric-zkp-2028",
"created": "2026-05-15T14:30:05Z",
"challenge": "9a4f2c8b-3e7d-4f1a-b5c9-2d8e6f0a1b3c",
"verificationMethod": "did:example:holder-device#key-1",
"proofPurpose": "authentication",
"proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndTeel..."
}
}
</pre>
<p class="issue atrisk">
The `example-biometric-zkp-2028` cryptosuite does not exist at the
time of this writing. It is included here to illustrate how a future
zero-knowledge proof cryptosuite could be used for client-side
biometric verification. This area is under active research.
</p>
</section>
<section>
<h4>User-Selected Provider</h4>
<p>
In this scenario, the [=holder=] selects a trusted biometric
verification service. The wallet presents available options and the
[=holder=] consents before any biometric data is transmitted. The
[=holder=]'s biometric data is sent only to their chosen provider, not
to the [=verifier=].
</p>
<p>
The following example demonstrates a credential with a biometric vector
confidence method that includes a service endpoint:
</p>
<pre class="example" title="User-selected provider biometric vector confidence method">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"validFrom": "2026-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"confidenceMethod": {
"id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
"type": "BiometricVectorConfidenceMethod",
"biometricModality": "face",
"captureFormat": "video",
"biometricModel": {
"type": "BiometricMatchingModel",
"matchingModel": "example-biometric-2026-v3.2"
},
"service": {
"id": "urn:uuid:service-1",
"type": "BiometricVerificationService",
"serviceEndpoint": "https://biometric-provider.example/verify/v3"
},
"biometricVectors": "uAVvLMv6gm...MNam"
},
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science"
}
}
}
</pre>
<p>
The verification flow ensures that the biometric provider and
[=verifier=] do not need to know about each other:
</p>
<ol>
<li>The [=verifier=] requests biometric verification from the
[=holder=], specifying accepted biometric providers and a challenge
nonce.</li>
<li>The wallet presents the accepted providers to the [=holder=], who
selects their preferred provider and consents to the
verification.</li>
<li>The wallet transmits the `biometricVectors`, a fresh biometric
capture, and the challenge nonce to the selected provider's
`serviceEndpoint`.</li>
<li>The provider compares the fresh capture against the enrolled
vectors and issues a signed `BiometricVerificationCredential` with
the challenge nonce embedded.</li>
<li>The wallet presents the `BiometricVerificationCredential` to the
[=verifier=], who validates the proof and checks the embedded
challenge matches their original request.</li>
</ol>
<p>
The challenge nonce prevents replay attacks and proves the verification
was performed in response to the [=verifier=]'s specific request.
As with the client-side scenario, the `credentialSubject.id` in the
verification output references the confidence method `id` from the
credential above:
</p>
<pre class="example" title="Verification output for user-selected provider biometric match">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiableCredential", "BiometricVerificationCredential"],
"issuer": "did:web:biometric-provider.example",
"validFrom": "2026-05-15T14:30:00Z",
"validUntil": "2026-05-15T14:45:00Z",
"credentialSubject": {
"id": "urn:uuid:a7f8c3d1-4b2e-4f9a-8c6d-1e3b5a7f9c2d",
"biometricMatch": {
"type": "BiometricMatch",
"matchingMethod": "server-assisted-video-stream",
"matchDate": "2026-05-15T14:30:00Z",
"domain": "https://verifier.example/",
"matchResult": "verified",
"confidence": "0.94"
}
},
"proof": {
"type": "DataIntegrityProof",
"cryptosuite": "ecdsa-rdfc-2019",
"created": "2026-05-15T14:30:05Z",
"challenge": "9a4f2c8b-3e7d-4f1a-b5c9-2d8e6f0a1b3c",
"verificationMethod": "did:web:biometric-provider.example#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndTeel..."
}
}
</pre>
</section>
</section>
<section>
<h2>Assurance Levels</h2>
<dl>
<dt><dfn>NIST_800-63-4_LOA</dfn></dt>
<dd>
<p>NIST_800-63-4 defines an assurance level based on the