-
Notifications
You must be signed in to change notification settings - Fork 10
/
Copy pathindex.html
4195 lines (3811 loc) · 170 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>Controlled Identifiers v1.0</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='//www.w3.org/Tools/respec/respec-w3c' class='remove'></script>
<script class='remove' src="./common.js"></script>
<script class="remove"
src="https://cdn.jsdelivr.net/gh/digitalbazaar/[email protected]/dist/main.js"></script>
<script type="text/javascript" class="remove">
var respecConfig = {
// specification status (for example WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "PR",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "cid-1.0",
// subtitle
//subtitle: "Controlled Identifier Documents",
// if you wish the publication date to be other than today, set this
publishDate: "2025-03-06",
crEnd: "2025-02-28",
prEnd: "2025-04-03",
// 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://w3c.github.io/cid/",
// if this is a LCWD, uncomment and set the end of its review period
implementationReportURI: "https://w3c.github.io/cid/implementations/1.0/",
// 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: "Manu Sporny", url: "https://www.linkedin.com/in/manusporny/",
company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/",
w3cid: 41758
}, { name: "Michael B. Jones", url: "https://self-issued.info/",
company: "Invited Expert",
w3cid: 38745}],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
authors: [
{
name: "Dave Longley",
url: "http://digitalbazaar.com/",
company: "Digital Bazaar",
companyURL: "http://digitalbazaar.com/"
},
{
name: "Manu Sporny",
url: "http://digitalbazaar.com/",
company: "Digital Bazaar",
companyURL: "http://digitalbazaar.com/"
},
{
name: "Markus Sabadello",
url: "https://www.linkedin.com/in/markus-sabadello-353a0821",
company: "Danube Tech",
companyURL: "https://danubetech.com/",
w3cid: 46729
},
{
name: "Drummond Reed",
url: "https://www.linkedin.com/in/drummondreed/",
company: "Evernym/Avast",
companyURL: "https://www.evernym.com/",
w3cid: 3096
},
{
name: "Orie Steele",
url: "https://www.linkedin.com/in/or13b/",
company: "Transmute",
companyURL: "https://transmute.industries/"
},
{
name: "Christopher Allen",
url: "https://www.linkedin.com/in/christophera",
company: "Blockchain Commons",
companyURL: "https://www.BlockchainCommons.com",
w3cid: 85560
}
],
// extend the bibliography entries
//localBiblio: webpayments.localBiblio,
// name of the WG
group: "vc",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-vc-wg",
github: "w3c/cid",
// 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: "",
xref: ["URL", "I18N-GLOSSARY", "INFRA", "VC-DATA-MODEL-2.0"],
maxTocLevel: 3,
/*preProcess: [ ],
alternateFormats: [ {uri: "diff-20111214.html", label: "diff to previous version"} ],
*/
localBiblio: {
"JOSE-REGISTRIES": {
title: "The JSON Object Signing and Encryption (JOSE) Registries",
href: "https://www.iana.org/assignments/jose",
authors: ["The Internet Assigned Numbers Authority"],
status: "REC",
publisher: "The Internet Assigned Numbers Authority"
},
"MULTIBASE": {
title: "The Multibase Data Format",
date: "February 2023",
href: "https://datatracker.ietf.org/doc/draft-multiformats-multibase",
authors: [
"Juan Benet",
"Manu Sporny"
],
status: "Internet-Draft",
publisher: "IETF"
},
"SHA3": {
title: "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions",
href: "https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf",
authors: [
"National Institute of Standards and Technology",
],
status: "National Standard",
publisher: "U.S. Department of Commerce"
},
"PRIVACY-BY-DESIGN": {
title: "Privacy by Design",
href: "https://iapp.org/media/pdf/resource_center/pbd_implement_7found_principles.pdf",
authors: [
"Ann Cavoukian"
],
date: "2011",
publisher: "Information and Privacy Commissioner"
}
},
postProcess: [window.respecVc.createVcExamples],
otherLinks: [{
key: "Related Specifications",
data: [{
value: "Decentralized Identifiers v1.0",
href: "https://www.w3.org/TR/did-core/"
}, {
value: "The Verifiable Credentials Data Model v2.0",
href: "https://www.w3.org/TR/vc-data-model-2.0/"
}, {
value: "Data Integrity v1.0",
href: "https://www.w3.org/TR/vc-data-integrity/"
}, {
value: "Securing Verifiable Credentials using JOSE and COSE",
href: "https://www.w3.org/TR/vc-jose-cose/"
}]
}]
};
</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 .nohighlight {
overflow-x: auto;
white-space: pre-wrap;
}
pre .comment {
font-weight: bold;
color: SteelBlue;
-webkit-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;
}
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, ".") ") "; }
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>
</head>
<body>
<section id='abstract'>
<p>
A controlled identifier document contains cryptographic material and lists service
endpoints for the purposes of verifying cryptographic proofs from, and
interacting with, the controller of an identifier.
</p>
</section>
<section id='sotd'>
</section>
<section class="informative">
<h2>Introduction</h2>
<p>
[=Controlled identifier documents=] identify a [=subject=] and provide [=verification
methods=] that express public cryptographic material, such as [=public keys=],
for verifying [=proofs=] created on behalf of the [=subject=] for specific
purposes, such as authentication, attestation, key agreement (for encryption),
and capability invocation and delegation. [=Controlled identifier documents=] also list
[=service=] endpoints related to an [=identifier=]; for example, from which to
request additional information for verification.
</p>
<p>
In other words, the controlled identifier document contains the information necessary to
communicate with, and/or prove that specific actions were taken by, the
controller of an [=identifier=], including material for [=proofs=] and
[=service=] endpoints for additional communications.
</p>
<p>
A [=controlled identifier document=] specifies
[=verification relationships=] and [=service=] endpoints for a single
identifier, for which the current controlled identifier document is taken as authoritative.
</p>
<p>
It is expected that other specifications will profile
the features that are defined in this specification, requiring and/or
recommending the use of some and prohibiting and/or deprecating the use of
others.
</p>
<p class="issue" data-number="150"></p>
<section>
<h3>Use Cases</h3>
<p>
The use cases below illustrate the need for this specification.
While many other related use cases exist, such as those in [[[DID-USE-CASES]]]
and [[[VC-USE-CASES]]], those described below are the main scenarios that this
specification is designed to address.
</p>
<section class="notoc">
<h4>Globally Unique Identifiers</h4>
<p>
Lemmy runs multiple enterprise portals that manage large amounts of sensitive
data submitted by people working for a variety of organizations. He would like
to use identifiers for entities in the databases that are provided by
his customers and do not depend on easily phishable information such as
email addresses and passwords.
</p>
</section>
<section class="notoc">
<h4>Cryptographic Verification</h4>
<p>
Lemmy would like to ensure that his customers prove control over their
identifiers — for example, by using public/private key cryptography
— in order to increase security related to who is allowed to access and
update each organization's data.
</p>
</section>
<section class="notoc">
<h4>Cryptographic Purpose</h4>
<p>
Stef, who operates a high security service, would like to ensure that certain
cryptographic keys used by his customers can only be used for specific purposes
(such as encryption, authorization, and/or authentication) to enable different
levels of access and protection for each type of cryptographic key.
</p>
</section>
<section class="notoc">
<h4>Service Engagement</h4>
<p>
Marge, a software developer, would like to publicly advertise ways in which
other people on the Web can reach her through various communication services she
uses based on her globally unique identifier(s).
</p>
</section>
<section class="notoc">
<h4>Extensibility</h4>
<p>
Cory, a systems architect, would like to extend the use cases described in this
section in a way that provides new functionality without creating conflicts
with extensions being added by others.
</p>
</section>
<section class="notoc">
<h4>Issue and Present Claims</h4>
<p>
Neru would like to issue digital credentials on behalf of her company that
contain claims about their employees. The claims that are made need to use
identifiers that are cryptographically attributable back to Neru's company and
need to allow for the holders of those credentials to be able to
cryptographically authenticate themselves when they present the credential.
</p>
</section>
</section>
<section>
<h3>Requirements</h3>
<p>
The following requirements are derived from the use cases described earlier in
this specification. Additional requirements which could lead to a more
decentralized solution can be found in [[[DID-USE-CASES]]].
</p>
<dl>
<dt>1. Guaranteed Unique Identifier</dt>
<dd>
Identifiers are globally unique with no possibility of duplication.
</dd>
<dt>2. Proof of Control</dt>
<dd>
It is possible to prove that the entity claiming control over the identifier is
indeed its controller.
</dd>
<dt>3. Associated cryptographic material</dt>
<dd>
The identifier is tightly coupled with cryptographic material that an entity
can use to prove control over that identifier.
</dd>
<dt>4. Streamlined key rotation</dt>
<dd>
Entities denoted by designated identifiers can update authentication materials
without direct intervention by requesting parties and with minimal individual
interaction.
</dd>
<dt>5. Service endpoint discovery</dt>
<dd>
These identifiers allow requesting parties to look up available service
endpoints for interacting with the subject of the identifier.
</dd>
<dt>6. Delegation of control</dt>
<dd>
The controller of the identifier is able to delegate that control, in full
and/or in part, to a third party.
</dd>
<dt>7. Cryptographically future-proof</dt>
<dd>
These identifiers and associated information are capable of being updated
as technology evolves. Current cryptographic techniques are known to be
susceptible to quantum computational attacks. Future-proofed identifiers
provide a means by which to continue using the same identifier with updated,
advanced authentication and/or authorization technologies.
</dd>
<dt>8. Cryptographic authentication and communication</dt>
<dd>
These identifiers enable the use of cryptographic techniques that can be employed
to authenticate individuals and/or to secure communications with the subject of
the identifier, typically using public-private key pairs.
</dd>
<dt>9. Legally recognizable identification</dt>
<dd>
These identifiers can be used as a basis for credentials and transactions that
can be recognized as legally valid under one or more jurisdictions.
</dd>
<dt>10. Human-centered interoperability</dt>
<dd>
Decentralized identifiers need to be easy to use by people with no technical
expertise or specialist knowledge.
</dd>
</dl>
</section>
<section id="conformance">
<p>
A <dfn>conforming controlled identifier document</dfn> is any concrete expression of the
data model that follows the relevant normative requirements in Sections
[[[#data-model]]] and [[[#contexts-and-vocabularies]]].
</p>
<p>
A <dfn>conforming verification method</dfn> is any concrete expression of the
data model that follows the relevant normative requirements in Sections
[[[#verification-methods]]] and
[[[#contexts-and-vocabularies]]].
</p>
<p>
A <dfn class="lint-ignore">conforming document</dfn> is either a
[=conforming controlled identifier document=], or a
[=conforming verification method=].
</p>
<p>
A <dfn class="lint-ignore">conforming processor</dfn> is any algorithm realized
as software and/or hardware that generates and/or consumes a
[=conforming document=] according to the relevant normative statements in
Section [[[#algorithms]]]. Conforming processors MUST produce errors
when non-conforming documents are consumed.
</p>
</section>
<section>
<h3>Terminology</h3>
<p>
This section defines the terms used in this specification. A link to the relevant
definition is included whenever one of these terms appears in this specification.
</p>
<dl class="termlist definitions" data-sort="ascending">
<dt><dfn>public key</dfn></dt>
<dd>
Cryptographic material that can be used to verify [=proofs=] created with a
corresponding [=private key=].
</dd>
<dt><dfn>private key</dfn></dt>
<dd>
Cryptographic material that can be used to generate [=proofs=].
</dd>
<dt><dfn data-lt="authenticated|authenticate">authentication</dfn></dt>
<dd>
A process by which an entity can prove to a verifier that it has a specific
attribute or controls a specific secret.
</dd>
<dt><dfn>proof</dfn></dt>
<dd>
A mathematical demonstration that confirms the validity of an assertion. The
demonstration consists of a set of properties and values that enable a verifier
to cryptographically validate the assertion. A
<a href="https://en.wikipedia.org/wiki/Digital_signature">digital signature</a>
is a type of proof.
</dd>
<dt><dfn data-lt="authorized|authorize">authorization</dfn></dt>
<dd>
A process by which an entity can prove to a verifier that it is allowed to
perform a specific activity.
</dd>
<dt><dfn class="export" data-lt="cryptosuite">cryptographic suite</dfn></dt>
<dd>
A means of using specific cryptographic primitives
to achieve a particular security goal. These suites can
specify [=verification methods=], digital signature types,
their identifiers, and other related properties.<!-- See Section -->
<!-- [[[#cryptographic-suites]]] for further detail. -->
</dd>
<dt><dfn class="export" data-lt="controller(s)|Controllers">controller</dfn></dt>
<dd>
<p>
An entity that is capable of performing an action with a specific resource, such
as updating a [=controlled identifier document=] or generating a [=proof=] using a
[=verification method=].
</p>
</dd>
<dt><dfn class="export">controlled identifier</dfn></dt>
<dd>
<p>
A type of identifier that can be proven to be under the control of an entity.
</p>
</dd>
<dt><dfn class="export">controlled identifier document</dfn></dt>
<dd>
<p>
A document that contains cryptographic material and lists service endpoints that
can be used for verifying [=proofs=] from, and interacting with, the
[=controller=] of an identifier.
</p>
</dd>
<dt><dfn data-lt="subjects">subject</dfn></dt>
<dd>
<p>
An entity, such as a person, group, organization, physical thing, digital thing,
or logical thing that is referred to by the value of an `id` property in a
[=controlled identifier document=]. Subjects identified in a [=controlled identifier document=]
are also used as a subjects in other contexts, such as during
[=authentication=] or in [=verifiable credentials=].
</p>
</dd>
<dt><dfn class="export">verification method</dfn></dt>
<dd>
<p>
A method and its parameters, used to independently verify a [=proof=]. For
example, a cryptographic public key can be used as a verification method with
respect to a digital signature; in such use, it verifies that the signer
used the associated cryptographic private key.
</p>
</dd>
<dt><dfn class="export">verification relationship</dfn></dt>
<dd>
<p>
An expression that one or more [=verification methods=] are authorized to verify
proofs made on behalf of the [=subject=]. One example of a verification
relationship is [[[#authentication]]].
</p>
</dd>
</dl>
</section>
</section>
<section>
<h3>Data Model</h3>
<p>
A [=controlled identifier document=] specifies one or more relationships between
an [=identifier=] and a set of [=verification methods=] and/or service
endpoints. The [=controlled identifier document=] SHOULD
contain [=verification relationships=] that explicitly permit the use of
certain [=verification methods=] for specific purposes.
</p>
<pre class="example nohighlight" title="Controlled Identifier Document in JSON-LD format using Multikey">
{
"@context": "https://www.w3.org/ns/cid/v1",
"id": "https://controller.example",
"authentication": [<span class="highlight">{
"id": "https://controller.example#authn-key-123",
"type": "Multikey",
"controller": "https://controller.example",
"publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
}</span>]
}
</pre>
<p>
The example above shows a valid JSON-LD [=controlled identifier document=]
that expresses a [=public key=] that can be used for the purposes of
[=authentication=] using the <a href="#Multikey">Multikey</a> format.
</p>
<pre class="example nohighlight" title="Controlled Identifier Document in JSON format using JsonWebKey">
{
"id": "https://controller.example/101",
"verificationMethod": [<span class="highlight">{
"id": "https://controller.example/101#key-20240828",
"type": "JsonWebKey",
"controller": "https://controller.example/101",
"publicKeyJwk": {
"kid": "key-20240828",
"kty": "EC",
"crv": "P-256",
"alg": "ES256",
"x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
}
}</span>],
"authentication": ["#key-20240828"]
}
</pre>
<p>
The example above shows a valid JSON [=controlled identifier document=]
that expresses a [=public key=] that can be used for the purposes of
[=authentication=] using the <a href="#JsonWebKey">JsonWebKey</a> format.
</p>
<p class="note"
title="Property names used in map of different types">
The property names `id`, `type`, and `controller` can be present in map of
different types with possible differences in constraints.
</p>
<section>
<h2>Controlled Identifier Documents</h2>
<p>
The following sections define the properties in a [=controlled identifier document=],
including whether these properties are required or optional. These properties
describe relationships between the [=subject=] and the value of the
property.
</p>
<p>
The following tables contain informative references for the core properties
defined by this specification, with expected values, and whether or not they are
required. The property names in the tables are linked to the normative
definitions and more detailed descriptions of each property.
</p>
<table class="simple">
<thead>
<tr>
<th>Property</th>
<th>Required?</th>
<th>Value constraints</th>
<th style="white-space: nowrap;">Definition</th>
</tr>
</thead>
<tbody>
<tr>
<td>`id`</td>
<td>yes</td>
<td>
A <a data-cite="INFRA#string">string</a> that conforms to the URL syntax.
</td>
<td style="white-space: nowrap;">[[[#subjects]]]</td>
</tr>
<tr>
<td>`controller`</td>
<td>no</td>
<td>
A <a data-cite="INFRA#string">string</a> or a
<a data-cite="INFRA#ordered-set">set</a> of
<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL
syntax.
</td>
<td style="white-space: nowrap;">[[[#controllers]]]</td>
</tr>
<tr>
<td>`alsoKnownAs`</td>
<td>no</td>
<td>
A <a data-cite="INFRA#ordered-set">set</a> of
<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL
syntax.
</td>
<td style="white-space: nowrap;">[[[#also-known-as]]]</td>
</tr>
<tr>
<td>`service`</td>
<td>no</td>
<td>
A <a data-cite="INFRA#ordered-set">set</a> of [=service=]
<a data-cite="INFRA#ordered-map">maps</a>.
</td>
<td style="white-space: nowrap;">[[[#services]]]</td>
</tr>
<tr>
<td>`verificationMethod`</td>
<td>no</td>
<td>
A <a data-cite="INFRA#ordered-set">set</a> of
[=verification method=] <a data-cite="INFRA#ordered-map">maps</a>.
</td>
<td style="white-space: nowrap;">[[[#verification-methods]]]</td>
</tr>
<tr>
<td>`authentication`</td>
<td>no</td>
<td>
A <a data-cite="INFRA#ordered-set">set</a> of <a
data-cite="INFRA#string">strings</a>, each of which conforms to
the URL syntax, or a <a data-cite="INFRA#ordered-set">set</a> of
[=verification method=] <a data-cite="INFRA#ordered-map">maps</a>.
</td>
<td style="white-space: nowrap;">[[[#authentication]]]</td>
</tr>
<tr>
<td>`assertionMethod`</td>
<td>no</td>
<td>
A <a data-cite="INFRA#ordered-set">set</a> of <a
data-cite="INFRA#string">strings</a>, each of which conforms to
the URL syntax, or a <a data-cite="INFRA#ordered-set">set</a> of
[=verification method=] <a data-cite="INFRA#ordered-map">maps</a>.
</td>
<td style="white-space: nowrap;">[[[#assertion]]]</td>
</tr>
<tr>
<td>`keyAgreement`</td>
<td>no</td>
<td>
A <a data-cite="INFRA#ordered-set">set</a> of <a
data-cite="INFRA#string">strings</a>, each of which conforms to
the URL syntax, or a <a data-cite="INFRA#ordered-set">set</a> of
[=verification method=] <a data-cite="INFRA#ordered-map">maps</a>.
</td>
<td style="white-space: nowrap;">[[[#key-agreement]]]</td>
</tr>
<tr>
<td>`capabilityInvocation`</td>
<td>no</td>
<td>
A <a data-cite="INFRA#ordered-set">set</a> of <a
data-cite="INFRA#string">strings</a>, each of which conforms to
the URL syntax, or a <a data-cite="INFRA#ordered-set">set</a> of
[=verification method=] <a data-cite="INFRA#ordered-map">maps</a>.
</td>
<td style="white-space: nowrap;">[[[#capability-invocation]]]</td>
</tr>
<tr>
<td>`capabilityDelegation`</td>
<td>no</td>
<td>
A <a data-cite="INFRA#ordered-set">set</a> of <a
data-cite="INFRA#string">strings</a>, each of which conforms to
the URL syntax, or a <a data-cite="INFRA#ordered-set">set</a> of
[=verification method=] <a data-cite="INFRA#ordered-map">maps</a>.
</td>
<td style="white-space: nowrap;">[[[#capability-delegation]]]</td>
</tr>
</tbody>
</table>
<section>
<h3>Subjects</h3>
<p>
A [=subject=] is expressed using the `id` property in a [=controlled identifier document=].
The value of an `id` property is referred to as an <dfn>identifier</dfn>.
</p>
<dl>
<dt>id</dt>
<dd>
The value of `id` property MUST be a <a data-cite="INFRA#string">string</a> that
conforms to the rules in the [[[URL]]].
</dd>
</dl>
<p>
A [=controlled identifier document=] MUST contain an `id` value in the <em>topmost</em>
<a data-cite="INFRA#ordered-map">map</a>.
</p>
<pre class="example nohighlight" title="Usage of the `id` property">
{
"@context": "https://www.w3.org/ns/cid/v1",
<span class="highlight">"id": "https://controller.example"</span>,
"authentication": [{
"id": "https://controller.example#authn-key-123",
"type": "Multikey",
"controller": "https://controller.example",
"publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
}]
}
</pre>
<p>
The value of the `id` property in the <em>topmost</em>
<a data-cite="INFRA#ordered-map">map</a> of the [=controlled identifier document=] is
called the <dfn>base identifier</dfn> for the [=controlled identifier document=]. The URL
for retrieving the current, authoritative [=controlled identifier document=] for a given
[=identifier=] is called the <dfn>canonical URL</dfn> for the [=controlled identifier
document=]. Dereferencing the [=canonical URL=] MUST return the current
authoritative [=controlled identifier document=]. The returned document's [=base
identifier=] MUST be the same as the [=canonical URL=]; if it is anything else,
then the returned document is not an authoritative [=controlled identifier document=] and
the [=identifier=] SHOULD be treated as invalid. Every controlled identifier document is
stored and retrieved according to the [=canonical URL=] of the document, which
MUST also be the [=base identifier=] of the document.
</p>
<div class="note" title="Identifiers are context-dependent">
<p>
It is expected that the [=subject=] referred to by an `id` in a [=controlled identifier
document=] will be consistent over time, such that any [=verifiable
credentials=] that use them can be interpreted as referring to the same entity.
For example, it is preferred that an [=issuer=] of a [=verifiable credential=]
require that a [=subject=] demonstrate [=proof=] of control over their
[=identifier=] before issuing a credential with that [=identifier=] as
[=subject=], creating assurance that the same entity was involved in the
issuance of each credential with that [=identifier=] as [=subject=].
</p>
<p>
However, there are valid cases where that practice is either impossible or
unreasonable; for example, when a parent requests a [=verifiable credential=]
for their child. There are also cases where an [=issuer=] simply makes a mistake
or intentionally issues a false statement. All of these possibilities are
considered when evaluating the security impacts of reliance on a given
[=identifier=] for any given purpose. See Section [[[#identifier-ambiguity]]].
</p>
</div>
</section>
<section>
<h3>Controllers</h3>
<p>
A [=controller=] of a [=controlled identifier document=] is any entity capable of making changes to that
[=controlled identifier document=]. Whoever can update
the content of the resource returned from dereferencing the controller
document's canonical URL is, by definition, a controller of the
document and its canonical identifier. Proofs that satisfy a
[=controlled identifier document=]'s [=verification methods=] are taken as cryptographic
assurance that the [=controller=] of the [=identifier=] created those [=proofs=].
</p>
<p class="note" title="Identifier Controller versus Document Controller">
The [=controller=] of the [=controlled identifier document=] is taken to be the
[=controller=] of the document's canonical [=identifier=], also known as its
URL. That is, whoever can update the [=controlled identifier document=] is both
the document [=controller=] and the [=identifier=] [=controller=]. Updating the
document is how you control the [=identifier=]. These terms can be used
interchangeably. Controlling the canonical [=controlled identifier document=] for
an [=identifier=] is the same as controlling the [=identifier=].
</p>
<dl>
<dt>controller</dt>
<dd>
The `controller` property is OPTIONAL. If it is possible to represent
the legitimate controllers of the document as URLs, the document SHOULD
list URLs identifying those controllers.
<p class="note" title="Presumed Control">
It is possible to list a verification method which is
functionally under the control of someone other than the [=controller=]
of the [=controlled identifier document=]. For example, a document [=controller=] could
set a public key under another party's control as an authentication
verification method. This would enable the other party to authenticate
on behalf of this [=identifier=] (because their public key is listed in
an authentication verification method) <em>without</em> enabling that party
to update the [=controlled identifier document=]. However, since the document
[=controller=] explicitly listed that key for authentication, the
proof in question is taken as created by the document [=controller=], as
it was created by their explicit assignee. This is especially useful
when the "other party" is a device under the control of the document
controller, but with a distinct cryptographic authority, i.e., it
has its own keystore and can generate [=proofs=]. That pattern enables
different devices, each using their own cryptographic material, to
generate verifiable [=proofs=] that are taken as [=proofs=] created by
controller of the identifier.
</p>
If present, its value MUST be a
<a data-cite="INFRA#string">string</a> or a
<a data-cite="INFRA#ordered-set">set</a> of
<a data-cite="INFRA#string">strings</a>,
each of which conforms to the rules in the [[[URL]]].
</p>
<p>
Each entry in the `controller` property MUST identify
an entity capable of updating the canonical version
of the [=controlled identifier document=].
Subsequent requests for this [=controlled identifier document=] through its
canonical location will always receive the latest version.
</p>
<p>
If the `controller` property is not present, then control of the document
is determined entirely by its storage location.
</dd>
</dl>
<pre class="example nohighlight"
title="Controlled identifier document with a controller property">
{
"@context": "https://www.w3.org/ns/cid/v1",
"id": "https://controllerA.example",
<span class="highlight">"controller": "https://controllerB.example/abc"</span>,
"authentication": [{
"id": "https://controllerA.example#authn-key-123",
"type": "Multikey",
"controller": "https://controllerA.example",
"publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
}]
}
</pre>
<p>
While the [=identifier=] used for a [=controller=] is unambiguous, this does not
imply that a single entity is always the [=controller=], nor that a [=controller=]
only has a single identifier. A [=controller=] might be a single entity, or a
collection of entities, such as a partnership. A [=controller=] might also use
multiple identifiers to refer to itself, for purposes such as privacy or
delineating operational boundaries within an organization. Similarly, a
[=controller=] might control many [=verification methods=]. For these reasons,
no assumptions are to be made about a [=controller=] being a single entity nor
controlling only a single [=verification method=].
</p>
<p class="note" title="Authentication versus Authorization">
Note that the definition of [=authentication=] is different from the definition
of [=authorization=]. Generally speaking, [=authentication=] answers the
question of "Do we know who this is?" while [=authorization=] answers the question of "Are
they allowed to perform this action?". The `authentication` property in this
specification is used to, unsurprisingly, perform [=authentication=] while the
other [=verification relationships=] such as `capabilityDelegation` and
`capabilityInvocation` are used to perform [=authorization=]. Since successfully
performing [=authorization=] might have more serious effects on a system,
[=controllers=] are urged to use different [=verification methods=] when
performing [=authentication=] versus [=authorization=] and provide stronger
access protection for [=verification methods=] used for [=authorization=] versus
[=authentication=]. See [[[#security-considerations]]] for information related
to threat models and attack vectors.
</p>
</section>
<section>
<h3>Also Known As</h3>
<p>
A [=subject=] can have multiple identifiers that are used for different purposes
or at different times. The assertion that two or more identifiers (or other types
of URI) refer to the same [=subject=] can be made using the
`alsoKnownAs` property.
</p>
<dl>
<dt>alsoKnownAs</dt>
<dd>
The `alsoKnownAs` property is OPTIONAL. If present, its value MUST
be a <a data-cite="INFRA#ordered-set">set</a> where each item in the
set is a URI conforming to [[RFC3986]].
</dd>
</dl>
<p>
This relationship is a statement that the subject of this identifier is
also identified by one or more other identifiers.
</p>
<pre class="example nohighlight"
title="Controlled identifier document using an alsoKnownAs property">
{
"@context": "https://www.w3.org/ns/cid/v1",
"id": "https://controller.example",
<span class="highlight">"alsoKnownAs": [
"https://someOtherIdentifier.example/xyz",
"https://yetAnotherIdentifier.example/987"
]</span>,
"authentication": [{
"id": "https://controller.example#authn-key-123",
"type": "Multikey",
"controller": "https://controller.example",
"publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
}]
}
</pre>
<div class="note" title="Equivalence and alsoKnownAs">
<p>
Applications might choose to consider two identifiers related by `alsoKnownAs`
to be equivalent <em>if</em> the `alsoKnownAs` relationship expressed in the
controlled identifier document of one [=subject=] is also expressed in the reverse direction
(i.e., reciprocated) in the controlled identifier document of the other [=subject=]. It is
best practice <em>not</em> to consider them
equivalent in the absence of this reciprocating relationship. In other words,
the presence of an `alsoKnownAs` assertion does not prove that this assertion
is true. Therefore, it is strongly advised that a requesting party obtain
independent verification of an `alsoKnownAs` assertion.
</p>
<p>
Given that the [=subject=] might use different identifiers for different
purposes, such as enhanced privacy protection, an expectation of strong