This repository has been archived by the owner on Sep 9, 2021. It is now read-only.
forked from w3c-ccg/did-spec
-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
2837 lines (2141 loc) · 80.4 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) 1.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='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
<script src="./common.js"></script>
<script type="text/javascript" class="remove">
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "CG-DRAFT",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "did",
// subtitle
subtitle: "Data Model and Syntaxes for Decentralized Identifiers (DIDs)",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "1977-03-15",
// previousMaturity: "WD",
// extend the bibliography entries
localBiblio: ccg.localBiblio,
github: "https://github.com/opencreds/did-spec",
includePermalinks: false,
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://opencreds.github.io/did-spec/",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Drummond Reed", url: "https://www.linkedin.com/in/drummondreed/",
company: "Evernym", companyURL: "https://evernym.com/"},
{ name: "Manu Sporny", url: "http://manu.sporny.org/",
company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/" }
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
authors:
[
{ name: "Drummond Reed", url: "https://www.linkedin.com/in/drummondreed/",
company: "Evernym", companyURL: "https://evernym.com/"},
{ name: "Manu Sporny", url: "http://manu.sporny.org/",
company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/" },
{ name: "Dave Longley", url: "",
company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/"},
{ name: "Christopher Allen", url: "https://www.linkedin.com/in/christophera",
company: "Blockstream", companyURL: "https://blockstream.com/team/" },
{ name: "Ryan Grant", url: "",
company: "", companyURL: "" },
{ name: "Les Chasen", url: "",
company: "", companyURL: "" },
{ name: "Markus Sabadello", url: "https://www.linkedin.com/in/markus-sabadello-353a0821",
company: "Danube Tech", companyURL: "https://danubetech.com/" }
],
// name of the WG
wg: "Credentials Community Group",
// URI of the public WG page
wgURI: "https://www.w3.org/community/credentials/",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-credentials",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "",
maxTocLevel: 4,
inlineCSS: true
};
</script>
</head>
<body>
<section id='abstract'>
<p>
DIDs (decentralized identifiers) are a new type of identifier intended
for verifiable digital identity that is "self-sovereign", i.e., fully
under the control of the identity owner and not dependent on a
centralized registry, identity provider, or certificate authority. DIDs
resolve to DDOs (DID descriptor objects)—simple JSON documents that
contain all the metadata needed to prove ownership and control of a DID.
Specifically, a DDO contains a set of key descriptions, which are
machine-readable descriptions of the identity owner’s public keys, and a
set of service endpoints, which are resource pointers necessary to
initiate trusted interactions with the identity owner. Each DID uses a
specific DID method, defined in a separate DID method specification, to
define how the DID is registered, resolved, updated, and revoked on a
specific distributed ledger or network.
</p>
</section>
<section id='sotd'>
<p>
Comments regarding this document are welcome. Please file issues
directly on <a href="https://github.com/opencreds/did-spec/issues/">GitHub</a>,
or send them to
<a href="mailto:[email protected]">[email protected]</a>
(<a href="mailto:[email protected]?subject=subscribe">subscribe</a>,
<a href="https://lists.w3.org/Archives/Public/public-credentials/">archives</a>).
</p>
<p>
Work on this specification has been funded in part by the United States
Department of Homeland Security's Science and Technology Directorate under
contract HSHQDC-16-R00012-H-SB2016-1-002. The content of this specification
does not necessarily reflect the position or the policy of the U.S.
Government and no official endorsement should be inferred.
</p>
<p>
Work on this specification has also been supported by the Rebooting the
Web of Trust group facilitated by Christopher Allen, Brian Weller,
Kiara Robles, and Shannon Appelcline.
</p>
</section>
<section>
<h1>Introduction</h1>
<section>
<h2>Overview</h2>
<p>
Conventional <a href=
"https://en.wikipedia.org/wiki/Identity_management">identity
management</a> systems are based on centralized authorities such as
corporate <a href=
"https://en.wikipedia.org/wiki/Directory_service">directory services</a>
, <a href=
"https://en.wikipedia.org/wiki/Certificate_authority">certificate
authorities</a> , or <a href=
"https://en.wikipedia.org/wiki/Domain_name_registry">domain name
registries</a> . From the standpoint of cryptographic trust
verification, each of these centralized authorities serves as its own
<a href="https://en.wikipedia.org/wiki/Trust_anchor">root of trust</a> .
To make identity management work across these systems requires
implementing <a href=
"https://en.wikipedia.org/wiki/Federated_identity">federated identity
management</a> .
</p>
<p>
The emergence of distributed ledger technology (DLT), sometimes referred
to as blockchain technology, provides the opportunity to implement fully
decentralized identity management. In this ecosystem, all participants
with identities (called identity owners) share a common root of trust in
the form of a globally distributed ledger (or a decentralized P2P
network that provides similar capabilities).
</p>
<p>
Each identity owner can be identified on a ledger with a <a href=
"https://en.wikipedia.org/wiki/Attribute%25E2%2580%2593value_pair">key-value
pair</a> . The index key is a DID (decentralized identifier) and the
value is its associated DDO (DID description object). Together these
form a DID record. Each DID record is cryptographically secured by
private keys under the control of an identity owner (in the case of an
owner-managed identity) or a guardian (in the case of a guardian-managed
identity). A corresponding public key is published in the DDO using a
key description. A DDO may also contain a set of service endpoints for
interacting with the identity owner. Following the dictums of <a href=
"https://en.wikipedia.org/wiki/Privacy_by_design">Privacy by Design</a>
, each identity owner may have as many DID records as necessary, to
respect the identity owner’s desired separation of identities, personas,
and contexts.
</p>
<p>
To use a DID with a particular distributed ledger or network requires
defining a DID method in a separate DID method specification. A DID
method specifies the set of rules for how a DID is registered, resolved,
updated, and revoked on that specific ledger or network.
</p>
<p>
This design eliminates dependence on centralized registries for
identifiers as well as centralized certificate authorities for key
management—the standard pattern in hierarchical <a href=
"https://en.wikipedia.org/wiki/Public_key_infrastructure">PKI (public
key infrastructure</a> ). Because DID records are on a distributed
ledger, each identity owner may serve as its own root authority—an
architecture referred to as <a href=
"https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/dpki.pdf">
DPKI (decentralized PKI)</a> .
</p>
<p>
Note that DID methods may also be developed for identities registered in
federated identity management systems. For their part, federated
identity systems may add support for DIDs. This creates an
interoperability bridge between the worlds of centralized, federated,
and decentralized identity.
</p>
</section>
<section>
<h2>URIs, URLs, and URNs</h2>
<p>
DIDs have a foundation in URIs, so it's important to understand how the
W3C <a href="https://www.w3.org/TR/uri-clarification/">clarified</a>
the terms URI (Uniform Resource Identifier), URL (Uniform Resource
Locator), and URN (Uniform Resource Name) in September 2001. The key
difference between these three categories of identifiers are:
</p>
<ol start="1">
<li>
URI is the term for any type of identifier used to identify a
resource on the Web.
</li>
<li>
URL is the term for any type of URI that can be resolved or
de-referenced to locate a representation of a resource on the Web (e.g.,
Web page, file, image, etc.)
</li>
<li>
URN is the term for a specific type of URI intended to persistently
identify a resource, i.e., an identifier that will never change no
matter how often the resource moves, changes names, changes owners, etc.
URNs are intended to last forever.
</li>
</ol>
</section>
<section>
<h2>Motivations for DIDs</h2>
<p>
The growing need for decentralized identity has produced three specific
requirements for a new type of URI that still fits within URI/URL/URN
architecture but in a less than traditional way:
</p>
<ol start="1">
<li>
A URI that is persistent like a URN yet can be resolved or
de-referenced to locate a resource like a URL. In essence, a DID is a
URI that serves both functions.
</li>
<li>
A URI that does not require a centralized authority to register,
resolve, update, or revoke. The overwhelming majority of URIs today are
based on DNS names or IP addresses that depend on centralized
authorities for registration and ultimate control. DIDs can be created
and managed without any such authority.
</li>
<li>
A URI whose ownership and associated metadata, including public
keys, can be cryptographically verified. Control of DIDs and DDOs
leverages the same public/private key cryptography as distributed
ledgers.
</li>
</ol>
</section>
<section>
<h2>The Role of Human-Friendly Identifiers</h2>
<p>
DIDs achieve global uniqueness without the need for a central
registration authority. This comes, however, at the cost of human
memorability. The algorithms capable of generating globally unique
identifiers automatically produce random strings of characters that have
no human meaning. This demonstrates the axiom about identifiers known as
<a href="https://en.wikipedia.org/wiki/Zooko%2527s_triangle">Zooko’s
Triangle</a> : "human-meaningful, decentralized, secure—pick any two".
</p>
<p>
There are of course many use cases where it is desirable to discover a
DID when starting from a human-friendly identifier—a natural language
name, a domain name, or a conventional address for a DID owner such as a
mobile telephone number, email address, Twitter handle, or blog URL.
However, the problem of mapping human-friendly identifiers to DIDs (and
doing so in a way that can be verified and trusted) is out-of-scope for
this specification.
</p>
<p>
Solutions to this problem (and there are many) should be defined in
separate specifications that reference this specification. It is
strongly recommended that such specifications carefully consider: (a)
the numerous security attacks based on deceiving users about the true
human-friendly identifier for a target entity, and (b) the privacy
consequences of using human-friendly identifiers that are inherently
correlatable, especially if they are globally unique.
</p>
</section>
<section>
<h2>Purpose of This Specification</h2>
<p>
The first purpose of this specification is to define the generic DID
scheme and a generic set of operations on DID records that can be
implemented for any distributed ledger or network capable of accepting
DID records. The second purpose of this specification to define the
conformance requirements for a DID method specification—a separate
specification that defines a specific DID scheme and specific set of DID
record operations for a specific distributed ledger or network.
</p>
<p>
Conceptually, the relationship of this specification and a DID method
specification is similar to the relationship of the IETF generic URI
specification ( <a href="https://www.ietf.org/rfc/rfc3986.txt">RFC
3986</a> ) and a specific <a href=
"http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml">URI
scheme</a> (such as the http: and https: schemes specified in <a href=
"http://www.iana.org/go/rfc7230">RFC 7230</a> ). It is also similar to
the relationship of the IETF generic URN specification ( <a href=
"https://www.ietf.org/rfc/rfc2141.txt">RFC 2141</a> ) and a specific URN
namespace definition (such as the UUID URN namespace defined in <a href=
"https://tools.ietf.org/html/rfc4122">RFC 4122</a> ). The difference is
that a DID method specification, in addition to defining a specific DID
scheme, must also specify the methods for reading, writing, and revoking
DID records on the network for which it is written.
</p>
<p>
For a list of DID method specifications, see Appendix A.
</p>
</section>
</section>
<section>
<h1>Example DIDs and DDOs</h1>
<p>
This is an example of a DID:
</p>
<p>
did:example:21tDAKCERh95uGgKbJNHYp
</p>
<section>
<h2>Example Owner-Managed DDO</h2>
<p>
Following is an example of a DDO that describes the DID above. This
example assumes that the identity owner—the entity that controls the
private keys for this identity—is authoritative for the DDO. See section
2.2 for an example of a DDO created by a guardian. For the authoritative
JSON-LD context definition, see Appendix B (the URL for the @context
property below is just for illustration).
</p>
<pre>
{
"@context": "https://example.org/did/v1",
"id": "did:example:21tDAKCERh95uGgKbJNHYp",
"owner": [{
"id": "did:example:21tDAKCERh95uGgKbJNHYp#key-1",
"type": ["CryptographicKey", "EdDsaPublicKey"],
"curve": "ed25519",
"expires": "2017-02-08T16:02:20Z",
"publicKeyBase64": "lji9qTtkCydxtez/bt1zdLxVMMbz4SzWvlqgOBmURoM="
}, {
"id": "did:example:21tDAKCERh95uGgKbJNHYp#key-2",
"type": ["CryptographicKey", "RsaPublicKey"],
"expires": "2017-03-22T00:00:00Z",
"publicKeyPem": "----BEGIN PUBLIC KEY-----\r\nMIIB..
... sGbFmgQaRyV\r\n-----END PUBLIC KEY-----"
}],
"control": [{
"type": "OrControl",
"signer": [
"did:example:21tDAKCERh95uGgKbJNHYp",
"did:example:8uQhQMGzWxR8vw5P3UWH1j"
]
}],
"service": {
"openid": "https://openid.example.com/456",
"xdi": "https://xdi.example.com/123"
},
"created": "2002-10-10T17:00:00Z",
"updated": "2016-10-17T02:41:00Z",
"signature": {
"type": "RsaSignature2016",
"created": "2016-02-08T16:02:20Z",
"creator": "did:example:8uQhQMGzWxR8vw5P3UWH1j#key/1",
"signatureValue": "IOmA4R7TfhkYTYW8...CBMq2/gi25s="
}
}
</pre>
</section>
<section>
<h2>Example Guardian-Managed DDO</h2>
<p>
Following is a second example of a DDO that describes the DID above. In
this case the DDO describes a dependent—an entity who is not currently
in a position to control the private keys for this identity. This DDO
was created by a guardian—a separate identity owner with its own DID
that serves as a trustee for the dependent. Note that while this DDO
asserts a set of service endpoints, it does not yet contain a set of key
descriptions because the dependent does not yet have its own set of
private keys.
</p>
<pre>
{
"@context": "https://example.org/did/v1",
"id": "did:example:21tDAKCERh95uGgKbJNHYp",
"guardian": "did:example:8uQhQMGzWxR8vw5P3UWH1j",
"control": [ "did:example:8uQhQMGzWxR8vw5P3UWH1j" ],
"service": {
"openid": "https://openid.example.com/456",
"xdi": "https://xdi.example.com/123"
},
"type": "http://schema.org/Person",
"created": "2002-10-10T17:00:00Z",
"updated": "2016-10-17T02:41:00Z",
"signature": {
"type": "RsaSignature2016",
"created": "2016-02-08T16:02:20Z",
"creator": "did:example:8uQhQMGzWxR8vw5P3UWH1j#key-1",
"signatureValue": "IOmA4R7Tf...3CBMq2/gi25s="
}
}
</pre>
<p>
</p>
</section>
</section>
<section>
<h1>Terminology and Acronyms</h1>
<p>
This specification defines the requirements of a conformant DID method
specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a> .
</p>
<p>
All other terms used in this specification are defined in this glossary.
</p>
<p>
Blockchain. A specific type of distributed ledger technology (DLT) that
stores ledger entries in blocks of transactions that are grouped
together and hashed into a cryptographic chain. Because this type of DLT
was introduced by <a href=
"https://en.wikipedia.org/wiki/Bitcoin">Bitcoin</a> , the term
"blockchain" is sometimes used to refer specifically to the Bitcoin
ledger.
</p>
<p>
Decentralized identifier (DID). A globally unique identifier that does
not require a centralized registration authority because it is
registered with distributed ledger technology or other form of
decentralized network. The generic format of a DID is defined in this
specification. A specific DID scheme is defined in a DID method
specification.
</p>
<p>
Decentralized identity management (DIDM). <a href=
"https://en.wikipedia.org/wiki/Identity_management">Identity
management</a> based on decentralized identifiers. DIDM extends
identifier creation authority beyond the traditional roots of trust
required by <a href="https://en.wikipedia.org/wiki/X.500">X.500
directory services</a> , the <a href=
"https://en.wikipedia.org/wiki/Domain_Name_System">Domain Name
System</a> , national ID systems, etc.
</p>
<p>
Decentralized PKI (DPKI). Public key infrastructure based on
decentralized identifiers and identity records (e.g., DDOs) containing
verifiable public key descriptions.
</p>
<p>
DDO. Acronym for DID descriptor object.
</p>
<p>
Dependent. A person, organization, or thing whose DID record is
registered and maintained by a guardian because the dependent is not in
a position to control the private keys. A dependent becomes an identity
owner when the dependent takes control of the private keys.
</p>
<p>
DID. Acronym for decentralized identifier.
</p>
<p>
DID descriptor object (DDO). A JSON data structure containing metadata
describing an identity owner, including the cryptographic key material
required for the identity owner to prove ownership and control of the
DID record. A DDO may also contain other <a href=
"https://en.wikipedia.org/wiki/Attribute_(computing)">attributes</a> or
<a href="https://en.wikipedia.org/wiki/Claims-based_identity">claims</a>
describing the identity owner.
</p>
<p>
DID fragment. The portion of a DID reference that follows the first hash
sign character ("#"). A DID fragment uses the same syntax as a URI
fragment. See section 5.5. Note that a DID fragment MUST immediately
follow a DID. If a DID reference includes a DID path followed by a
fragment, that fragment is NOT a DID fragment.
</p>
<p>
DID method. A definition of how a specific DID scheme can be implemented
on a specific distributed ledger or network, including the precise
method(s) by which DIDs and DDOs can be read, written, and revoked.
</p>
<p>
DID method conformance profile. A specification (or section of a
specification) that defines the rules an implementer must follow in
order to conform with another DID method specification. A conformance
profile narrows the set of options that may be used in order to meet a
specific implementation goal.
</p>
<p>
DID method specification. The specification for a specific DID scheme
and DID method that is conformant with the requirements of this
specification.
</p>
<p>
DID path. The portion of a DID reference that follows the first forward
slash character. A DID path uses the identical syntax as a URI path. See
section 5.4. Note that if a DID path is followed by a fragment, that
fragment is NOT a DID fragment.
</p>
<p>
DID record. The combination of a DID and a DDO that forms the "root
identity record" for an identity owner. From the standpoint of <a href=
"https://en.wikipedia.org/wiki/Claims-based_identity">claims-based
identity</a> , a DID record is the “genesis claim” for an identity.
</p>
<p>
DID reference. A DID plus an optional DID path or DID fragment.
</p>
<p>
DID scheme. The formal syntax of a DID identifier. The generic DID
scheme is defined in this specification. A DID method specification
defines a specific DID scheme that works with a specific DID method.
</p>
<p>
DIDM. Acronym for decentralized identity management.
</p>
<p>
Distributed ledger technology (DLT). A <a href=
"https://en.wikipedia.org/wiki/Distributed_database">distributed
database</a> in which the various nodes use a <a href=
"https://en.wikipedia.org/wiki/Consensus_(computer_science)">consensus
protocol</a> to maintain a shared ledger in which each transaction is
cryptographically signed and chained to the previous transaction. See
also blockchain.
</p>
<p>
DLT. Acronym for distributed ledger technology.
</p>
<p>
DPKI. Acronym for decentralized PKI.
</p>
<p>
Guardian. An identity owner who creates a DID record for a dependent who
does not yet have the capacity to control the private keys. The
dependent must rely on the guardian to safeguard the private keys until
the dependent can assume control and become an identity owner.
</p>
<p>
Identity owner. The natural person, party, organization, or thing whose
identity is represented by a DID record and who directly controls the
private keys to control that record. (Note: this specification avoids
the term "user" since an identity owner is not always an individual
person.)
</p>
<p>
Identity record. Another name for a DID record.
</p>
<p>
JSON-LD (JSON Linked Data). A method of encoding <a href=
"https://en.wikipedia.org/wiki/Linked_data">Linked Data</a> using JSON.
The <a href="https://www.w3.org/TR/json-ld/">W3C JSON-LD 1.0
specification</a> enables object properties in a JSON document to be
linked to concepts in an RDF <a href=
"https://en.wikipedia.org/wiki/Ontology_(information_science)">ontology</a>
.
</p>
<p>
Key description. A JSON object contained inside a DDO that contains all
the metadata necessary to use a public key or verification key. A list
of standard key descriptions is included in Appendix C.
</p>
<p>
Ledger. In the context of this specification, a shared database of
transactions maintained via distributed ledger technology.
</p>
<p>
PKI. Acronym for <a href=
"https://en.wikipedia.org/wiki/Public_key_infrastructure">public key
infrastructure</a> .
</p>
<p>
RDF (Resource Description Framework). A semantic graph model defined by
the <a href="https://www.w3.org/2011/rdf-wg/">W3C RDF Working Group</a>
.
</p>
<p>
Service endpoint. A network address at which a service operates on
behalf of an identity owner. Examples of specific DIDM services include
discovery services, authentication services, authorization services,
interaction services, etc. A DIDM service endpoint may also be provided
by a generalized data interchange protocol such as XDI.
</p>
<p>
UUID. Universally Unique Identifier as specified by <a href=
"https://www.ietf.org/rfc/rfc4122.txt">RFC 4122</a> .
</p>
<p>
URI (Uniform Resource Identifier). The official name for all Web
identifiers as defined by IETF <a href=
"https://www.ietf.org/rfc/rfc3986.txt">RFC 3986</a> . See section 1.2.
</p>
<p>
URL (Uniform Resource Locator). Any URI that can be resolved or
de-referenced to locate a specific resource on the Web. See section 1.2.
</p>
<p>
URN (Uniform Resource Name). A URI intended to serve as a persistent,
location-independent identifier of a resource, i.e., an identifier that
will always represent the same resource and never change (ideally
forever). URN syntax is defined by IETF <a href=
"https://www.ietf.org/rfc/rfc2141.txt">RFC 2141</a> . In general URNs
cannot directly be resolved or de-referenced to locate the resource they
identify. See section 1.2.
</p>
<p>
XDI (Extensible Data Interchange) (also XRI Data Interchange)—a semantic
graph format and semantic data interchange protocol defined by the
<a href="https://www.oasis-open.org/committees/xdi/">OASIS XDI Technical
Committee</a> .
</p>
</section>
<section>
<h1>Design Goals & Principles</h1>
<p>
This section summarizes the design goals and principles of DID
architecture.
</p>
<table>
<tbody>
<tr>
<td colspan="1" rowspan="1">
<p>
#
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Principle
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Description
</p>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<p>
1
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Decentralization
</p>
</td>
<td colspan="1" rowspan="1">
<p>
DID architecture should eliminate the requirement for
centralized authorities or single points of failure in identity
management, including the registration of globally unique
identifiers, public verification keys, service endpoints, and
other metadata.
</p>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<p>
2
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Self-Sovereignty
</p>
</td>
<td colspan="1" rowspan="1">
<p>
DID architecture should give identity owners the power to
directly own and control their own digital identities without
the need to rely on external authorities.
</p>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<p>
3
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Privacy
</p>
</td>
<td colspan="1" rowspan="1">
<p>
DID architecture should enable identity owners to control the
privacy of their digital identities, including selective
disclosure of attributes or other identity data.
</p>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<p>
4
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Security
</p>
</td>
<td colspan="1" rowspan="1">
<p>
DID architecture should provide sufficient security for relying
parties to rely on DID records to their required level of
assurance.
</p>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<p>
5
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Cryptography
</p>
</td>
<td colspan="1" rowspan="1">
<p>
DID architecture should enable an identity owner to provide
cryptographic proof of ownership and proof of access control
rights.
</p>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<p>
6
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Discoverability
</p>
</td>
<td colspan="1" rowspan="1">
<p>
DID architecture should make it possible for entities to
discover DID records for other entities to learn more about or
interact with those entities.
</p>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<p>
7
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Interoperability
</p>
</td>
<td colspan="1" rowspan="1">
<p>
DID architecture should use interoperable standards so DIDs and
DID record infrastructure can make use of existing tools and
software libraries designed for interoperability.
</p>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<p>
8
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Portability
</p>
</td>
<td colspan="1" rowspan="1">
<p>
DID architecture should be system-independent and enable
identity owners to use their digital identities with any system
that supports DIDs and DIDM.
</p>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<p>
9
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Simplicity
</p>
</td>
<td colspan="1" rowspan="1">
<p>
To meet these design goals, DID architecture should be (to
paraphrase Albert Einstein) "as simple as possible but no
simpler".
</p>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<p>
10
</p>
</td>
<td colspan="1" rowspan="1">
<p>
Extensibility
</p>
</td>
<td colspan="1" rowspan="1">
<p>
When possible, DID architecture should enable extensibility
provided it does not hinder interoperability, portability or
simplicity.
</p>
</td>
</tr>
</tbody>
</table>
</section>
<section>
<h1>DIDs (Decentralized Identifiers)</h1>
<p>
The foundation of DID architecture is the concept of the decentralized
identifier. This concept is not new; <a href=
"https://en.wikipedia.org/wiki/Universally_unique_identifier">UUIDs</a>
(Universally Unique IDentifiers) were first developed in the 1980s and
later became a standard feature of the Open Software Foundation’s
<a href=
"https://en.wikipedia.org/wiki/Distributed_Computing_Environment">Distributed
Computing Environment</a> . UUIDs achieve global uniqueness without a
centralized registry service by using an algorithm that generates
128-bit values with sufficient entropy that the chance of collision are
infinitesimally small. UUIDs are formally a URN namespace specified in
<a href="https://tools.ietf.org/html/rfc4122">IETF RFC 4122</a> .
</p>
<p>
A DID is similar to a UUID except: (a) it can be resolved or
dereferenced to a standard resource describing the identity owner (a
DDO—see section 6), and (b) the DDO may contain public key descriptions
that enable cryptographic verification of DID ownership.
</p>
<section>
<h2>The Generic DID Scheme</h2>
<p>
The generic DID scheme is a URI scheme conformant with <a href=
"https://www.ietf.org/rfc/rfc3986.txt">RFC 3986</a> . It consists of a
DID followed by an optional path and/or fragment. The term DID refers
only to the identifier conforming to the did rule in the ABNF below;
when used alone, it does not include a path or fragment. A DID that may
optionally include a path and/or fragment is called a DID reference.
</p>
<p>
Following is the ABNF definition using the syntax in <a href=
"https://tools.ietf.org/html/rfc5234">RFC 5234</a> (which defines ALPHA
as upper or lowercase A-Z).
</p>
<pre class="nohighlight">
did-reference = did [ "/" did-path ] [ "#" did-fragment ]
did = "did:" method ":" specific-idstring
method = 1*methodchar
methodchar = %x61-7A / DIGIT
specific-idstring = idstring *( ":" idstring )
idstring = 1*idchar
idchar = ALPHA / DIGIT / "." / "-"
</pre>
<p>
See sections 5.3 and 5.4 for the ABNF rules defining DID paths and
fragments.
</p>
</section>