-
Notifications
You must be signed in to change notification settings - Fork 99
/
Copy pathindex.html
4774 lines (4407 loc) · 178 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>Decentralized Identifiers (DIDs) v1.1</title>
<meta content='text/html; charset=utf-8' http-equiv='Content-Type'>
<!--
=== 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 class="remove"
src="https://www.w3.org/Tools/respec/respec-w3c"></script>
<script class="remove" type="text/javascript">
var respecConfig = {
// the W3C WG and public mailing list
group: "did",
wgPublicList: "public-did-wg",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "did-1.1",
// specification status (e.g., WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
// W3C Proposed Recommendation information
//prEnd: "2021-08-31",
// W3C Candidate Recommendation information
//crEnd: "2021-07-13",
//implementationReportURI: "https://w3c.github.io/did-test-suite/",
// Editor's Draft URL
edDraftURI: "https://w3c.github.io/did/",
// subtitle for the spec
subtitle: "Core architecture, data model, and representations",
// if you wish the publication date to be other than today, set this
//publishDate: "2025-01-23",
// previously published draft, uncomment this and set its
// YYYY-MM-DD date and its maturity status
previousPublishDate: "2022-07-19",
previousMaturity: "REC",
// automatically allow term pluralization
pluralize: true,
// extend the bibliography entries
localBiblio: {
"REST": {
title: "Architectural Styles and the Design of Network-based Software Architectures",
date: "2000",
href: "http://www.ics.uci.edu/~fielding/pubs/dissertation/",
authors: [
"Fielding, Roy Thomas"
],
publisher: "University of California, Irvine."
},
"MACAROONS": {
title: 'Macaroons',
// TODO: create spec
href: 'http://macaroons.io/',
authors: ['Arnar Birgisson', 'Joe Gibbs Politz', 'Úlfar Erlingsson',
'Ankur Taly', 'Michael Vrable', 'Mark Lentczner'],
status: 'unofficial',
publisher: 'Credentials Community Group'
},
'OPEN-BADGES': {
title: 'Open Badges',
href: 'https://github.com/openbadges/openbadges-specification',
authors: ['Brian Brennan', 'Mike Larsson', 'Chris McAvoy',
'Nate Otto', 'Kerri Lemoie'],
status: 'BA-DRAFT',
publisher: 'Badge Alliance Standard Working Group'
},
"MATRIX-URIS": {
title: "Matrix URIs - Ideas about Web Architecture",
date: "December 1996",
href: "https://www.w3.org/DesignIssues/MatrixURIs.html",
authors: [
"Tim Berners-Lee"
],
status: "Personal View"
},
"DNS-DID": {
title: "The Decentralized Identifier (DID) in the DNS",
date: "February 2019",
href: "https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/",
authors: [
"Alexander Mayrhofer",
"Dimitrij Klesev",
"Markus Sabadello"
],
status: "Internet-Draft"
},
"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"
}
},
xref: ["web-platform", "cid"],
lint: {
"informative-dfn": false
},
github: {
repoURL: "https://github.com/w3c/did/",
branch: "main"
},
includePermalinks: false,
// Uncomment these to use the respec extension that generates a list of
// normative statements:
preProcess: [/*prepare_reqlist*/],
postProcess: [/*add_reqlist_button, restrictRefs*/],
// list of specification editors
editors: [{
name: "Manu Sporny", url: "https://www.linkedin.com/in/manusporny/",
company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/",
w3cid: 41758, note: "v1.0, v1.1"
}, {
name: "Dmitri Zagidulin", url: "https://digitalcredentials.mit.edu/",
company: "Invited Expert", w3cid: 86708,
note: "v1.1"
}/*, {
name: "Steve McCown",
note: "v1.1"
}*/],
formerEditors: [{
name: "Amy Guy",
url: "https://rhiaro.co.uk/",
company: "Digital Bazaar",
companyURL: "https://digitalbazaar.com/",
w3cid: 69000,
note: "v1.0"
}, {
name: "Markus Sabadello",
url: "https://www.linkedin.com/in/markus-sabadello-353a0821",
company: "Danube Tech",
companyURL: "https://danubetech.com/",
w3cid: 46729,
note: "v1.0"
}, {
name: "Drummond Reed",
url: "https://www.linkedin.com/in/drummondreed/",
company: "Evernym/Avast",
companyURL: "https://www.evernym.com/",
w3cid: 3096,
note: "v1.0"
}],
// list of specification authors
authors: [{
name: "Manu Sporny",
url: "https://www.linkedin.com/in/manusporny/",
company: "Digital Bazaar",
companyURL: "https://digitalbazaar.com/",
w3cid: 41758
}, {
name: "Dave Longley",
url: "https://github.com/dlongley",
company: "Digital Bazaar",
companyURL: "https://digitalbazaar.com/",
w3cid: 48025
}, {
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
}],
otherLinks: [{
key: "Related Documents",
data: [{
value: "DID Use Cases and Requirements",
href: "https://www.w3.org/TR/did-use-cases/"
}, {
value: "DID Extensions",
href: "https://www.w3.org/TR/did-extensions/"
}, {
value: "DID Core Implementation Report",
href: "https://w3c.github.io/did-test-suite/"
}]
}],
//errata: "https://w3c.github.io/did/errata.html"
};
</script>
<style>
pre .highlight {
font-weight: bold;
color: green;
}
pre .comment {
color: SteelBlue;
user-select: none;
}
code a[href] {
color: inherit;
border-bottom: none;
}
code {
color: rgb(199, 73, 0);
font-weight: bold;
}
code a[href]:hover {
border-bottom: 1px solid #c63501;
}
table.column-width-50 td {
width: 50%;
}
.longdesc {
display: none;
}
.longdesc:target {
display: block;
background-color: #ff9;
}
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 data-cite="infra rfc3986">
<section id='abstract'>
<p>
[=Decentralized identifiers=] (DIDs) are a new type of identifier that
enables verifiable, decentralized digital identity. A [=DID=] refers to any
subject (e.g., a person, organization, thing, data model, abstract entity, etc.)
as determined by the controller of the [=DID=]. In contrast to
typical, federated identifiers, [=DIDs=] have been designed so that they may
be decoupled from centralized registries, identity providers, and certificate
authorities. Specifically, while other parties might be used to help enable the
discovery of information related to a [=DID=], the design enables the
controller of a [=DID=] to prove control over it without requiring permission
from any other party. [=DIDs=] are [=URIs=] that associate a [=DID
subject=] with a [=DID document=] allowing trustable interactions
associated with that subject.
</p>
<p>
Each [=DID document=] can express cryptographic material, [=verification
methods=], or [=services=], which provide a set of mechanisms enabling a
[=DID controller=] to prove control of the [=DID=]. [=Services=] enable
trusted interactions associated with the [=DID subject=]. A [=DID=] might
provide the means to return the [=DID subject=] itself, if the [=DID
subject=] is an information resource such as a data model.
</p>
<p>
This document specifies the DID syntax, a common data model, core properties,
serialized representations, DID operations, and an explanation of the process
of resolving DIDs to the resources that they represent.
</p>
</section>
<section id='sotd'>
<p>
This version of the DID Core specification, version 1.1, is experimental.
DO NOT implement it. If you want to implement DIDs, use the current version 1.0
specification: [[[DID-CORE]]].
</p>
</section>
<section class="informative">
<h1>Introduction</h1>
<p>
As individuals and organizations, many of us use globally unique identifiers in
a wide variety of contexts. They serve as communications addresses (telephone
numbers, email addresses, usernames on social media), ID numbers (for passports,
drivers licenses, tax IDs, health insurance), and product identifiers (serial
numbers, barcodes, RFIDs). URIs (Uniform Resource Identifiers) are used for
resources on the Web and each web page you view in a browser has a globally
unique URL (Uniform Resource Locator).
</p>
<p>
The vast majority of these globally unique identifiers are not under our
control. They are issued by external authorities that decide who or what they
refer to and when they can be revoked. They are useful only in certain contexts
and recognized only by certain bodies not of our choosing. They might
disappear or cease to be valid with the failure of an organization. They might
unnecessarily reveal personal information. In many cases, they can be
fraudulently replicated and asserted by a malicious third-party, which is
more commonly known as "identity theft".
</p>
<p>
The Decentralized Identifiers (DIDs) defined in this specification are a new
type of globally unique identifier. They are designed to enable individuals and
organizations to generate their own identifiers using systems they trust. These
new identifiers enable entities to prove control over them by authenticating
using cryptographic proofs such as digital signatures.
</p>
<p>
Since the generation and assertion of Decentralized Identifiers is
entity-controlled, each entity can have as many DIDs as necessary to maintain
their desired separation of identities, personas, and interactions. The use of
these identifiers can be scoped appropriately to different contexts. They
support interactions with other people, institutions, or systems that require
entities to identify themselves, or things they control, while providing control
over how much personal or private data should be revealed, all without depending
on a central authority to guarantee the continued existence of the identifier.
These ideas are explored in the DID Use Cases document [[DID-USE-CASES]].
</p>
<p>
This specification does not presuppose any particular technology or cryptography
to underpin the generation, persistence, resolution, or interpretation of DIDs.
For example, implementers can create Decentralized Identifiers based on
identifiers registered in federated or centralized identity management systems.
Indeed, almost all types of identifier systems can add support for DIDs. This
creates an interoperability bridge between the worlds of centralized, federated,
and decentralized identifiers. This also enables implementers to design specific
types of DIDs to work with the computing infrastructure they trust, such as
distributed ledgers, decentralized file systems, distributed databases, and
peer-to-peer networks.
</p>
<p>
This specification is for:
</p>
<ul>
<li>
Anyone that wants to understand the core architectural principles that
are the foundation for Decentralized Identifiers;
</li>
<li>
Software developers that want to produce and consume Decentralized Identifiers
and their associated data formats;
</li>
<li>
Systems integrators that want to understand how to use Decentralized
Identifiers in their software and hardware systems;
</li>
<li>
Specification authors that want to create new DID infrastructures, known as DID
methods, that conform to the ecosystem described by this document.
</li>
</ul>
<p>
In addition to this specification, readers might find the
Use Cases and Requirements for Decentralized Identifiers [[DID-USE-CASES]]
document useful.
</p>
<section class="informative">
<h2>A Simple Example</h2>
<p>
A [=DID=] is a simple text string consisting of three parts: 1) the
`did` URI scheme identifier, 2) the identifier for the [=DID
method=], and 3) the DID method-specific identifier.
</p>
<figure id="parts-of-a-did">
<img style="margin: auto; display: block; width: 75%;"
src="diagrams/parts-of-a-did.svg" alt="
A diagram showing the parts of a DID. The left-most letters spell 'did' in blue,
are enclosed in a horizontal bracket from above and a label that reads 'scheme'
above the bracket. A gray colon follows the 'did' letters. The middle letters
spell 'example' in magenta, are enclosed in a horizontal bracket from below and
a label that reads 'DID Method' below the bracket. A gray colon follows the
DID Method. Finally, the letters at the end read '123456789abcdefghi' in
green, are enclosed in a horizontal bracket from below and a label that
reads 'DID Method Specific String' below the bracket.
" >
<figcaption>
A simple example of a decentralized identifier (DID)
</figcaption>
</figure>
<p>
The example [=DID=] above resolves to a [=DID document=]. A [=DID
document=] contains information associated with the [=DID=], such as ways
to cryptographically [=authentication|authenticate=] a [=DID controller=].
</p>
<pre class="example nohighlight" title="A simple DID document">
{
"@context": "https://www.w3.org/ns/did/v1.1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
<span class="comment">// used to authenticate as did:...fghi</span>
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Multikey",
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
}]
}
</pre>
</section>
<section class="informative">
<h2>Design Goals</h2>
<p>
[=Decentralized Identifiers=] are a component of larger systems, such as the
Verifiable Credentials ecosystem [[VC-DATA-MODEL]], which influenced the design
goals for this specification. The design goals for Decentralized Identifiers
are summarized here.
</p>
<table class="simple">
<thead>
<tr>
<th>
Goal
</th>
<th>
Description
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
Decentralization
</td>
<td>
Eliminate the requirement for centralized authorities or single points of
failure in identifier management, including the registration of globally unique
identifiers, public verification keys, [=services=], and other information.
</td>
</tr>
<tr>
<td>
Control
</td>
<td>
Give entities, both human and non-human, the power to directly control their
digital identifiers without the need to rely on external authorities.
</td>
</tr>
<tr>
<td>
Privacy
</td>
<td>
Enable entities to control the privacy of their information, including minimal,
selective, and progressive disclosure of attributes or other data.
</td>
</tr>
<tr>
<td>
Security
</td>
<td>
Enable sufficient security for requesting parties to depend on [=DID
documents=] for their required level of assurance.
</td>
</tr>
<tr>
<td>
Proof-based
</td>
<td>
Enable [=DID controllers=] to provide cryptographic proof when interacting
with other entities.
</td>
</tr>
<tr>
<td>
Discoverability
</td>
<td>
Make it possible for entities to discover [=DIDs=] for other entities, to
learn more about or interact with those entities.
</td>
</tr>
<tr>
<td>
Interoperability
</td>
<td>
Use interoperable standards so [=DID=] infrastructure can make use of
existing tools and software libraries designed for interoperability.
</td>
</tr>
<tr>
<td>
Portability
</td>
<td>
Be system- and network-independent and enable entities to use their digital
identifiers with any system that supports [=DIDs=] and [=DID methods=].
</td>
</tr>
<tr>
<td>
Simplicity
</td>
<td>
Favor a reduced set of simple features to make the technology easier to
understand, implement, and deploy.
</td>
</tr>
<tr>
<td>
Extensibility
</td>
<td>
Where possible, enable extensibility provided it does not greatly hinder
interoperability, portability, or simplicity.
</td>
</tr>
</tbody>
</table>
</section>
<section class="informative">
<h2>
Architecture Overview
</h2>
<p>
This section provides a basic overview of the major components of
Decentralized Identifier architecture.
</p>
<figure id="brief-architecture-overview">
<img style="margin: auto; display: block; width: 75%;"
src="diagrams/did_brief_architecture_overview.svg" alt="
DIDs and DID documents are recorded on a Verifiable Data Registry; DIDs resolve
to DID documents; DIDs refer to DID subjects; a DID controller controls a DID
document; DID URLs contains a DID; DID URLs dereferenced to DID document
fragments or external resources.
" >
<figcaption>
Overview of DID architecture and the relationship of the basic components.
See also: <a class="longdesc-link"
href="#brief-architecture-overview-longdesc">narrative description</a>.
</figcaption>
</figure>
<div class="longdesc" id="brief-architecture-overview-longdesc">
<p>
Six internally-labeled shapes appear in the diagram, with labeled arrows
between them, as follows. In the center of the diagram is a rectangle labeled
DID URL, containing small typewritten text "did:example:123/path/to/rsrc". At
the center top of the diagram is a rectangle labeled, "DID", containing small
typewritten text "did:example:123". At the top left of the diagram is an oval,
labeled "DID Subject". At the bottom center of the diagram is a rectangle
labeled, "DID document". At the bottom left is an oval, labeled, "DID
Controller". On the center right of the diagram is a two-dimensional rendering
of a cylinder, labeled, "Verifiable Data Registry".
</p>
<p>
From the top of the "DID URL" rectangle, an arrow, labeled "contains", extends
upwards, pointing to the "DID" rectangle. From the bottom of the "DID URL"
rectangle, an arrow, labeled "refers, and
<strong><em>dereferences</em></strong>, to", extends downward, pointing to the
"DID document" rectangle. An arrow from the "DID" rectangle, labeled
"<strong><em>resolves</em></strong> to", points down to the "DID document"
rectangle. An arrow from the "DID" rectangle, labeled "refers to", points left
to the "DID subject" oval. An arrow from the "DID controller" oval, labeled
"controls", points right to the "DID document" rectangle. An arrow from the
"DID" rectangle, labeled "recorded on", points downards to the right, to the
"Verifiable Data Registry" cylinder. An arrow from the "DID document" rectangle,
labeled "recorded on", points upwards to the right to the "Verifiable Data
Registry" cylinder.
</p>
</div>
<dl>
<dt>
DIDs and DID URLs
</dt>
<dd>
A Decentralized Identifier, or [=DID=], is a [=URI=] composed of three
parts: the scheme `did:`, a method identifier, and a unique,
method-specific identifier specified by the [=DID method=]. [=DIDs=] are
resolvable to [=DID documents=]. A [=DID URL=] extends the syntax of a
basic [=DID=] to incorporate other standard [=URI=] components such as
path, query, and fragment in order to locate a particular
[=resource=]—for example, a cryptographic public key inside a [=DID
document=], or a [=resource=] external to the [=DID document=].
These concepts are elaborated upon in [[[#did-syntax]]] and
[[[#did-url-syntax]]].
</dd>
<dt>
DID subjects
</dt>
<dd>
The subject of a [=DID=] is, by definition, the entity identified by the
[=DID=]. The [=DID subject=] might also be the [=DID controller=].
Anything can be the subject of a [=DID=]: person, group, organization,
thing, or concept. This is further defined in [[[#did-subject]]].
</dd>
<dt>
DID controllers
</dt>
<dd>
The [=controller=] of a [=DID=] is the entity (person, organization, or
autonomous software) that has the capability—as defined by a [=DID
method=]—to make changes to a [=DID document=]. This capability is
typically asserted by the control of a set of cryptographic keys used by
software acting on behalf of the controller, though it might also be asserted
via other mechanisms. Note that a [=DID=] might have more than one
controller, and the [=DID subject=] can be the [=DID controller=], or one
of them. This concept is documented in [[[#did-controller]]].
</dd>
<dt>
Verifiable data registries
</dt>
<dd>
In order to be resolvable to [=DID documents=], [=DIDs=] are typically
recorded on an underlying system or network of some kind. Regardless of the
specific technology used, any such system that supports recording [=DIDs=]
and returning data necessary to produce [=DID documents=] is called a
[=verifiable data registry=]. Examples include [=distributed ledgers=],
decentralized file systems, databases of any kind, peer-to-peer networks, and
other forms of trusted data storage. This concept is further elaborated upon in
[[[#methods]]].
</dd>
<dt>
DID documents
</dt>
<dd>
[=DID documents=] contain information associated with a [=DID=]. They
typically express [=verification methods=], such as cryptographic public
keys, and [=services=] relevant to interactions with the [=DID subject=].
The generic properties supported in a [=DID document=] are specified in [[[#core-properties]]]. A [=DID document=] can be serialized to a byte
stream (see [[[#representations]]]). The properties present in
a [=DID document=] can be updated according to the applicable operations
outlined in [[[#methods]]].
</dd>
<dt>
DID methods
</dt>
<dd>
[=DID methods=] are the mechanism by which a particular type of [=DID=]
and its associated [=DID document=] are created, resolved, updated, and
deactivated. [=DID methods=] are defined using separate DID method
specifications as defined in [[[#methods]]].
</dd>
<dt>
DID resolvers and DID resolution
</dt>
<dd>
A [=DID resolver=] is a system component that takes a [=DID=] as input and
produces a conforming [=DID document=] as output. This process is called
[=DID resolution=]. The steps for resolving a specific type of [=DID=] are
defined by the relevant [=DID method=] specification. The process of [=DID
resolution=] is elaborated upon in [[?DID-RESOLUTION]].
</dd>
<dt>
DID URL dereferencers and DID URL dereferencing
</dt>
<dd>
A [=DID URL dereferencer=] is a system component that takes a [=DID URL=]
as input and produces a [=resource=] as output. This process is
called [=DID URL dereferencing=]. The process of [=DID URL dereferencing=]
is elaborated upon in [[?DID-RESOLUTION]].
</dd>
</dl>
</section>
<section id="conformance">
<p>
This document contains examples that contain JSON and JSON-LD content.
Some of these examples contain characters that are invalid, 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>
<p>
Some examples contain terms, both property names and values, that are not
defined in this specification. These are indicated with a comment (`//
external (property name|value)`). Such terms, when used in a [=DID
document=], are expected to be registered in the repository of DID Extensions
[[?DID-EXTENSIONS]] with links to both a formal definition and a JSON-LD
context.
</p>
<p>
Interoperability of implementations for [=DIDs=] and [=DID documents=] is
tested by evaluating an implementation's ability to create and parse [=DIDs=]
and [=DID documents=] that conform to this specification. Interoperability
for producers and consumers of [=DIDs=] and [=DID documents=] is provided
by ensuring the [=DIDs=] and [=DID documents=] conform. Interoperability
for [=DID method=] specifications is provided by the details in each [=DID
method=] specification. It is understood that, in the same way that a web
browser is not required to implement all known [=URI=] schemes, conformant
software that works with [=DIDs=] is not required to implement all known
[=DID methods=]. However, all implementations of a given [=DID method=]
are expected to be interoperable for that method.
</p>
<p>
A <dfn>conforming DID</dfn> is any concrete expression of the rules specified in
[[[#identifier]]] which complies with relevant normative statements in
that section.
</p>
<p>
A <dfn class="export">conforming DID document</dfn> is any concrete expression
of the data model described in this specification which complies with the
relevant normative statements in [[[#data-model]]] and [[[#core-properties]]]. A
serialization format for the conforming document is deterministic,
bi-directional, and lossless, as described in [[[#representations]]].
</p>
<p>
A <dfn>conforming producer</dfn> is any algorithm realized as software and/or
hardware that generates [=conforming DIDs=] or [=conforming DID
Documents=] and complies with the relevant normative statements in [[[#representations]]].
</p>
<p>
A <dfn>conforming consumer</dfn> is any algorithm realized as software and/or
hardware that consumes [=conforming DIDs=] or [=conforming DID documents=]
and complies with the relevant normative statements in [[[#representations]]].
</p>
<p>
A <dfn class="export">conforming DID method</dfn> is any specification that
complies with the relevant normative statements in [[[#methods]]].
</p>
</section>
<section class="informative">
<h2>
Audience
</h2>
<p>
This specification has two primary audiences: implementers of conformant DID methods; and implementers of systems and services that wish to interact and interface with DIDs. The intended audience includes, but is not limited to, software architects, data modelers, application developers, service developers, testers, operators, and user experience (UX) specialists. Other people involved in a broad range of standards efforts related to decentralized identity, verifiable credentials, and secure storage might also be interested in reading this specification.
</p>
</section>
</section>
<section class="informative">
<h2>Terminology</h2>
<p>
This section defines the terms used in this specification and throughout
[=decentralized identifier=] infrastructure. A link to these terms is
included whenever they appear in this specification.
</p>
<dl class="termlist">
<dt><dfn data-lt="amplification">amplification attack</dfn></dt>
<dd>
A class of attack where the attacker attempts to exhaust a target system's
CPU, storage, network, or other resources by providing small, valid inputs into
the system that result in damaging effects that can be exponentially more costly
to process than the inputs themselves.
</dd>
<dt><dfn class="export" data-lt="decentralized identifiers|DID|DIDs">decentralized identifier</dfn> (DID)</dt>
<dd>
A globally unique persistent identifier that does not require a centralized
registration authority and is often generated and/or registered
cryptographically. The generic format of a DID is defined in <a
href="#did-syntax"></a>. A specific [=DID scheme=] is defined in a <a>DID
method</a> specification. Many—but not all—DID methods make use of
[=distributed ledger technology=] (DLT) or some other form of decentralized
network.
</dd>
<dt><dfn class="export" data-lt="did controllers|did controller(s)">DID controller</dfn></dt>
<dd>
An entity that has the capability to make changes to a [=DID document=]. A
[=DID=] might have more than one DID controller. The DID controller(s)
can be denoted by the optional `controller` property at the top level of the
[=DID document=]. Note that a DID controller might be the <a>DID
subject</a>.
</dd>
<dt><dfn>DID delegate</dfn></dt>
<dd>
An entity to whom a [=DID controller=] has granted permission to use a
[=verification method=] associated with a [=DID=] via a <a>DID document</a>. For
example, a parent who controls a child's [=DID document=] might permit the child
to use their personal device in order to [=authentication|authenticate=]. In
this case, the child is the [=DID delegate=]. The child's personal device would
contain the private cryptographic material enabling the child to
[=authentication|authenticate=] using the [=DID=]. However, the child might not
be permitted to add other personal devices without the parent's permission.
</dd>
<dt><dfn class="export" data-lt="DID documents">DID document</dfn></dt>
<dd>
A set of data describing the [=DID subject=], including mechanisms, such as
cryptographic public keys, that the [=DID subject=] or a [=DID delegate=] can
use to [=authentication|authenticate=] itself and prove its association with the
[=DID=]. A DID document might have one or more different [=representations=] as
defined in <a href="#representations"></a> or in the W3C [[[DID-EXTENSIONS]]].
</dd>
<dt><dfn data-lt="DID fragments">DID fragment</dfn></dt>
<dd>
The portion of a [=DID URL=] that follows the first hash sign character
(<code>#</code>). DID fragment syntax is identical to URI fragment syntax.
</dd>
<dt><dfn class="export" data-lt="DID methods">DID method</dfn></dt>
<dd>
A definition of how a specific [=DID method scheme=] is implemented. A DID method is
defined by a DID method specification, which specifies the precise operations by
which [=DIDs=] and [=DID documents=] are created, resolved, updated,
and deactivated. See <a href="#methods"></a>.
</dd>
<dt><dfn data-lt="DID paths">DID path</dfn></dt>
<dd>
The portion of a [=DID URL=] that begins with and includes the first forward
slash (<code>/</code>) character and ends with either a question mark
(<code>?</code>) character, a fragment hash sign (<code>#</code>) character,
or the end of the [=DID URL=]. DID path syntax is identical to URI path syntax.
See <a href="#path"></a>.
</dd>
<dt><dfn data-lt="DID queries">DID query</dfn></dt>
<dd>
The portion of a [=DID URL=] that follows and includes the first question
mark character (<code>?</code>). DID query syntax is identical to URI query
syntax. See <a href="#query"></a>.
</dd>
<dt><dfn class="export">DID resolution</dfn></dt>
<dd>
The process that takes as its input a [=DID=] and a set of resolution
options and returns a [=DID document=] in a conforming [=representation=]
plus additional metadata. This process relies on the "Read" operation of the
applicable [=DID method=]. The inputs and outputs of this process are
defined in [[?DID-RESOLUTION]].
</dd>
<dt><dfn class="export" data-lt="DID resolvers">DID resolver</dfn></dt>
<dd>
A [=DID resolver=] is a software and/or hardware component that performs the
[=DID resolution=] function by taking a [=DID=] as input and producing a
conforming [=DID document=] as output.
</dd>
<dt><dfn data-lt="DID schemes|DID method scheme">DID scheme</dfn></dt>
<dd>
The formal syntax of a [=decentralized identifier=]. The generic DID scheme
begins with the prefix <code>did:</code> as defined in <a
href="#did-syntax"></a>. Each [=DID method=] specification defines a specific
DID method scheme that works with that specific [=DID method=]. In a specific DID
method scheme, the DID method name follows the first colon and terminates with
the second colon, e.g., <code>did:example:</code>
</dd>
<dt><dfn data-lt="DID subjects">DID subject</dfn></dt>
<dd>
The entity identified by a [=DID=] and described by a [=DID document=].
Anything can be a DID subject: person, group, organization, physical thing,
digital thing, logical thing, etc.
</dd>
<dt><dfn data-lt="DID URLs">DID URL</dfn></dt>
<dd>
A [=DID=] plus any additional syntactic component that conforms to the
definition in <a href="#did-url-syntax"></a>. This includes an optional <a>DID
path</a> (with its leading <code>/</code> character), optional [=DID query=]
(with its leading <code>?</code> character), and optional [=DID fragment=]
(with its leading <code>#</code> character).
</dd>
<dt><dfn>DID URL dereferencing</dfn></dt>
<dd>
The process that takes as its input a [=DID URL=] and a set of input
metadata, and returns a [=resource=]. This resource might be a <a>DID
document</a> plus additional metadata, a secondary resource
contained within the [=DID document=], or a resource entirely
external to the [=DID document=]. The process uses [=DID resolution=] to
fetch a [=DID document=] indicated by the [=DID=] contained within the
[=DID URL=]. The dereferencing process can then perform additional processing
on the [=DID document=] to return the dereferenced resource indicated by the
[=DID URL=]. The inputs and outputs of this process are defined in
[[?DID-RESOLUTION]].
</dd>
<dt><dfn data-lt="DID URL dereferencers">DID URL dereferencer</dfn></dt>
<dd>
A software and/or hardware system that performs the [=DID URL dereferencing=]
function for a given [=DID URL=] or [=DID document=].
</dd>
<dt><dfn data-lt="distributed ledger technology|DLT">distributed ledger</dfn> (DLT)</dt>
<dd>
A non-centralized system for recording events. These systems establish
sufficient confidence for participants to rely upon the data recorded by others
to make operational decisions. They typically use distributed databases where
different nodes use a consensus protocol to confirm the ordering of
cryptographically signed transactions. The linking of digitally signed
transactions over time often makes the history of the ledger effectively
immutable.
</dd>
<dt><dfn data-lt="resources">resource</dfn></dt>
<dd>
A thing that is identified by a [=URI=], as defined in [[RFC3986]]. Similarly,
any resource might serve as a [=DID subject=] identified by a [=DID=].
</dd>
<dt><dfn data-lt="representations">representation</dfn></dt>
<dd>
A concrete expression of a [=resource=], as defined by [[RFC7231]]: "information
that is intended to reflect a past, current, or desired state of a given
resource, in a format that can be readily communicated via the protocol, and
that consists of a set of representation metadata and a potentially unbounded
stream of representation data." A [=DID document=] is a representation of
information describing a [=DID subject=]. See <a href="#representations"></a>.
</dd>
<dt><dfn data-lt="representation-specific entry|non-representation-specific