forked from w3c/did-use-cases
-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
1137 lines (1085 loc) · 59.6 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>
<meta charset="utf-8">
<title>Use Cases and Requirements for Decentralized Identifiers</title>
<script
src="https://www.w3.org/Tools/respec/respec-w3c-common"
class="remove"></script>
<script class='remove' src="./common.js">
</script>
<script class="remove">
var respecConfig = {
// specification status (e.g., WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "did-use-cases",
// subtitle
//subtitle: "Draft 11 February 2019",
// if you wish the publication date to be other than today, set this
// publishDate: "2019-11-21",
// 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: didwg.localBiblio,
github: "https://github.com/w3c/did-use-cases",
includePermalinks: false,
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://w3c.github.io/did-use-cases/",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
editors: [{
name: "Joe Andrieu",
company: "Invited Expert",
url: "http://legreq.com",
w3cid: 97261
},
{
name: "Phil Archer",
url: "https://philarcher.org/",
companyURL: "https://www.gs1.org",
company: "GS1",
w3cid: 101627
}],
wgPublicList: "public-did-wg",
wg: "Decentralized Identifier Working Group",
wgURI: "https://www.w3.org/2019/did-wg/",
wgPatentURI: "https://www.w3.org/2004/01/pp-impl/117488/status",
maxTocLevel: 4,
inlineCSS: true,
noRecTrack: true,
localBiblio: {
"DID-RESOLUTION" : {
title : "Decentralized Identifier Resolution (DID Resolution)",
href : "https://w3c-ccg.github.io/did-resolution/",
authors: ["Markus Sabadello", "Dmitri Zagidulin"],
status: "W3C Community Group Report"
},
"DID-Auth" : {
title: "Introduction to DID Auth",
href: "https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md",
authors: ["Markus Sabadello", "Kyle Den Hartog", "Christian Lundkvist", "Cedric Franz", "Alberto Elias", "Andrew Hughes", "John Jordan", "Dmitri Zagidulin"]
},
"QR" : {
title: "Information technology — Automatic identification and data capture techniques — QR Code bar code symbology specification",
href: "https://www.iso.org/standard/62021.html",
authors: ["ISO/IEC JTC 1/SC 31 Automatic identification and data capture techniques"],
status: "ISO/IEC standard",
date: "February 2015"
}
}
};
</script>
<style>
table.feature_grid { border: 1px solid; width: 1000px; }
table.feature_grid td { border: 1px solid; text-align: center; }
table.feature_grid th { border: 1px solid; }
table.feature_grid th[scope=row] { text-align: left; }
dl.feature_definitions dt { font-weight: 400; }
.highlight {background-color:yellow}
</style>
</head>
<body>
<section id="abstract">
<p>This document sets out use cases and requirements for a new type of identifier that has 4 essential characteristics:</p>
<ol>
<li><strong>decentralized</strong>: there should be no central issuing
agency;</li>
<li><strong>persistent</strong>: the identifier should be inherently
persistent, not requiring the continued operation of an underling organization;</li>
<li><strong>crytopgraphically verifiable</strong>: it should be possible
to prove control of the identifier cryptographically;</li>
<li><strong>resolvable</strong>: it should be possible to discover
metadata about the identifier.</li>
</ol>
<p>Although existing identifiers may display some of these characteristics, none currently displays all four.</p>
</section>
<section id="sotd"></section>
<section id="intro">
<h2>Introduction</h2>
<p>The need for globally unique identifier schemes has been addressed many
times. Globally unique ID schemes typically rely on a central authority
controlling a 'root' space that is then delegated to local organizations
who in turn delegate to further organizations who eventually add the final
string to complete the identifer. Even if we restrict ourseleves to online
identifiers, there are many examples of this.</p><ul>
<li>IANA controls the root namespace of the Internet's Domain Name System;
registrars operate the top level domains and then license specific domain
names to their clients, and it's these clients who create the actual
identifiers for online resources (URLs). The example below shows who
controls what in a typical URL.
<pre class="example">
IANA
↓
https://example.com/page.html
↑ ↑
Registrar Licensee
</pre></li>
<li><abbr title="Digital Object Identifier">DOI</abbr>s have the form
<code>10.{registrant}/{suffix}</code> where 'registrant' is defined by the
DOI organization and the suffix by the registrant.</li>
<li>Global Trade Item Numbers (GTINs) seen on many of the world's barcodes
are managed in a similar way, as are Legal Entity Identifiers,
<abbr title="International Standard Book Number">ISBN</a>s and more.</li>
</ul>
<p>In all these cases, ultimately, there is a central authority on which the
identifier system depends. Those central authorities go to significant
efforts to make their identifiers persistent and resolvable, however,
should they cease to exist, the long term integrity of the identifier
is at least questionable to a greater or lesser extent. For as long as
those organizations exist (and they are generally well established with no
immediate threat to their survival), the way to assess whether a particular
identifier is in some way 'valid' is to query the issuing authority.</p>
<p>These factors point to a need in some circumstances for a globally unique
identifier that is 'self sovereign', that is, one that does not depend on
any issuing authority. Universally unique identifiers (<a>UUID</a>s) [[RFC4122]]
fulfill this role, however, there is no way to <em>prove</em> control of
a <abbr title="Universally unique identifier">UUID</abbr>.</p>
<p>This document sets out use cases and requirements for a new kind of
identifier that meets all these basic requirements:</p>
<ol>
<li><strong>decentralized</strong>: there should be no central issuing
agency;</li>
<li><strong>persistent</strong>: the identifier should be inherently
persistent, not requiring the continued operation of an underling organization;</li>
<li><strong>crytopgraphically verifiable</strong>: it should be possible
to prove control of the identifier cryptographically;</li>
<li><strong>resolvable</strong>: it should be possible to discover
metadata about the identifier.</li>
</ol>
<section id="existingWork">
<h3>Existing Work</h3>
<p>The use cases and requirements set out below have not been created <i>a
priori</i>. Substantial work has been done within W3C and elsewhere
leading, in particular, to <a href="https://www.w3.org/2019/08/did-20190828/">Decentralized
Identifiers (DIDs) Data Model and Syntaxes</a> published as a Community
Group Report by the <a href="https://www.w3.org/community/credentials/">Credentials
Community Group</a> in August 2019. That work provides a framework —
a set of concepts — that have proved to be useful when discussing
<abbr title="Decentralized Identifier">DID</abbr>s and the problems they
can solve (see below). Those concepts are used within this document to
set out the detail of the problem that the Decentralized Identifier Working
Group is <a href="https://www.w3.org/2019/09/did-wg-charter">chartered</a>
to solve. It is the nature of the standardization process that these
terms may be modified within the standard itself and therefore, their
use here should not be seen as authoritative.</p>
</section>
<section>
<h2 id="concepts">Concepts of Decentralized Identity</h2>
<p class="issue" data-number="39">Terminology in this opening prose is being discussed, in particular
the term 'relying party'</p>
<p>A decentralized system will enable several key actions by three
distinct entities: the Controller, the <span class="highlight">Relying Party</span>, and the Subject.</p>
<p>Controllers create and control <abbr title="Decentralized Identifier">DID</abbr>s,
while <span class="highlight">Relying Parties</span> rely on <abbr title="Decentralized Identifier">DID</abbr>s
as an identifier for interactions related to the <a>DID Subject</a>.</p>
<p>The Subject is the entity referred to by the <abbr title="Decentralized
Identifier">DID</abbr>, which can be anything: a person, an organization,
a device, a location, even a concept. Typically, the Subject is also
the Controller, but in cases of guardianship, agents (human or software),
and inanimate Subjects, this is not possible. As such, the Subject has
no functional role. When the Subject is, in fact, the <a>DID Controller</a>, we
consider the action to be taken by the Controller on their own behalf
as the Subject. When the Subject is not the DID Controller, the Controller
is said to be taking action on behalf of the Subject, such as when an
employee manages a <abbr title="Decentralized Identifier">DID</abbr>
on behalf of their employer or a parent uses a <abbr title="Decentralized
Identifier">DID</abbr> on behalf of their child.</p>
<p>The DID Controller and <span class="highlight">Relying Party</span> may be individuals or interactive
systems, but for simplicity in this document, we refer to both as if
they were individual persons performing these actions. </p>
<p>Only a <a>DID Controller</a> can perform the actions that control a <abbr
title="Decentralized Identifier">DID</abbr>, however, anyone can act
as a <span class="highlight">Relying Party</span> for any <abbr title="Decentralized Identifier">DID</abbr>
they know, including the DID Controller, should they wish to inspect or
verify their own <abbr title="Decentralized Identifier">DID</abbr>.</p>
<p>This use case document defines these actions in terms of the eventual
systems we anticipate using the resultant specification.</p>
<p>Perhaps the most salient point about <a>Decentralized Identifiers</a> is
that there are no "Identity Providers". Instead, this role is subsumed
in the decentralized systems that Controllers use to manage <abbr
title="Decentralized Identifier">DID</abbr>s and, in turn, <span class="highlight">Relying
Parties</span> use to apply <abbr title="Decentralized Identifier">DID</abbr>s.
These decentralized systems, which we refer to as <abbr
title="Decentralized Identifier">DID</abbr> registries, are designed to
operate independently from any particular service provider and hence,
free from any given platform authority. It is anticipated that <abbr
title="Decentralized Identifier">DID</abbr>s will be registered using
distributed ledger technology (<a>DLT</a>).
<p>In practice, the definition and operation of all current decentralized
systems retain some elements of centralized control. Depending on the
criteria one uses to evaluate such systems — from who controls
the most widely used code base to who controls the specification —
where a system resides on the spectrum of centralized and decentralized
varies. However, the design of any decentralized identity system is
separate from the academic debate about how decentralized it may be
in practice.</p>
<p>The use cases presented below make use of a number of high level
concepts as follows.</p>
<div class="note" title="Shared terminology">
<p>This section is automatically synchronised with the terminology section in
the <a href="https://w3c.github.io/did-core/">DID Core</a> specification.</p></div>
<div data-include="https://w3c.github.io/did-core/terms.html"
data-oninclude="restrictReferences">
</div>
<p class="issue" data-number="14">The term DID registry is under discussion within the Working Group.
A particular point to bear in mind is that not all DID methods require DIDs to be registered to be functional.</p>
<p>When we refer to <em>methods</em> and <em>registries</em>, we mean <a><abbr
title="Decentralized Identifier">DID</abbr> methods</a> and <a><abbr title="Decentralized
Identifier">DID</abbr> registries</a>. A working assumption for the use cases is that all
<abbr title="Decentralized Identifier">DID</abbr>s resolve to <abbr title="Decentralized
Identifier">DID</abbr> Documents. <abbr title="Decentralized Identifier">DID</abbr>
Documents contain the cryptographic material to perform the functions related to
that particular <abbr title="Decentralized Identifier">DID</abbr>, including
associated proof methods and any service endpoints, that is, services that can
make use of the <abbr title="Decentralized Identifier">DID</abbr>.</p>
</section>
</section>
<section id="uc">
<h2>Use Cases</h2>
<section id="onlineShopper">
<h3>Online shopper</h3>
<p>Traditionally, a shopper frequents a trusted retailer and can physically hold the products they wish to purchase.
The product and the information about it is trusted because it is put there by the brand, and the shopper trusts that
the retailer has received the product through trusted supply chain partners. Today, there is a multitude of
channels and platforms for selling and buying products. The internet has changed consumer purchasing behavior
as more and more commerce is conducted digitally. This introduces new challenges for brands, retailers and consumers,
as the relationship is not as direct as the traditional mode of shopping.</p>
<p>Online shopping, especially through 3rd party marketplaces, creates a proliferation of digital records about that product
across platforms. Unlike a physical product, a consumer cannot be assured that the record (and the information
presented about that product) came from the brand or other authoritative source. Product identification and information
and the source of the product itself is less reliable, and introduces trust issues with representations of products
bought and sold online. Additionally, unique identification is critical to business processes, but also to online
purchasing. Very often two different products share the same identifier across the supply chain, and so what a
consumer purchases and what ultimately is received may be different.</p>
<p>Mechanisms are required for the following to provide trust in the digital representation of a product across platforms:</p>
<ol>
<li>validation of the legitimacy of an online listing — in particular on third party marketplaces;</li>
<li>assurance of identification uniqueness and key identifying data element accuracy.</li>
</ol>
</section><!-- Online shopper-->
<section id="vehicleAssemblies"><h3>Vehicle assemblies</h3>
<p>Manufactured goods are usually the output of multiple processes carried out by multiple actors. Think of a vehicle
(be it a ship, a train, a car or a plane) with
components and assemblies of components from multiple suppliers that are then added to the emerging vehicle as it makes its
way along the production line. During the lifetime of that vehicle, components will be replaced and serviced, and this work
can be carried out by any number of different agents.</p>
<p>A mechanism that allows each agent to make independent assertions about their work – the components created or replaced,
the tests carried out, which part was married up to which other part and so on – would allow the complete manufacturing and
service history of the vehicle to be computed.</p>
<p>The independent aspect is important. A decentralized identifier created and applied to each component or assembly can be
cryptographically verified without the need to call home to a supply company that may or may not continue to exist. Moreover, there
is no requirement for the overall vehicle manufacturer to maintain an aggregated database concerning a vehicle that, in a
traditional system, is not only a single point of failure but that is immediately out of date as soon as the vehicle goes in
for its first service. A decentralized system allows each component of the vehicle to have its own history, its own credentials
and its own lifecycle, independent of other components and the vehicle – or vehicles – of which it is a part over time.</p>
<p>The vehicle itself has its own identifier too. This would allow that particular vehicle to be a reference for the components
and any licensing, insurance, servicing etc. Again, the decentralized nature of DIDs promises <em>subsequent owners</em> control
over the identifier without dependency on any central agency allowing the maintenance record(s) to transition smoothly throughout
the entire lifecycle of the vehicle.</p>
</section> <!-- Vehicle assemblies -->
<p class="ednote">More short use cases to be added</p>
</section>
<section id="actions">
<h2>DID Actions</h2>
<p>Here are the thirteen (13) actions envisioned in earlier work by
<a href="https://www.w3.org/community/credentials/">Credentials Community Group</a> as being necessarily supported by
<abbr title="Decentralized Identifier">DID</abbr>s. In the diagram, actions have been grouped by Create,
Read, Update, and Delete (CRUD) as well as Use.</p>
<img src="images/did_actions.png" alt="Actions supported by DIDs, grouped by type, and related to the entity which carries out the action"/>
<section id="create">
<h2>Create</h2>
<p class="issue" data-number="14">This section refers to recording in a registry. I've changed it to say
'may be' but this can only be finalized when Issue-14 is resolved.</p>
<p>Controllers create DIDs, uniquely binding cryptographic proofs with the identifier, typically using
public-private key-pairs. These DIDs may be recorded in a registry in such a manner as to be able to
resolve to a DID Document. The DID Document may be dynamically and deterministically generated through resolution or
it may be explicitly constructed as a stand-alone resource and either stored or referenced in the registry.
In this scenario, the process will need access to any registry, ideally a decentralized system, and like the
rest of the DID CRUD actions, it shold be possible to create the DID without interaction with any particular authority.</p>
</section>
<section id="present">
<h2>Present</h2>
<p>DIDs are <a>URI</a>s, which is to say a string of characters. As such, they may be presented in the same manner as
URIs by simply transmitting or presenting that string of characters. There is no requirement, however,
that DIDs be human readable. Thus they may contain long, complex numbers represented in various formats. For
ease of use, implementations may rely on data carriers such as QR codes [[QR]] for ease of capture using a camera-enabled device
such as a smart phone.</p>
</section>
<section id="authenticate">
<h2>Authenticate</h2>
<p><span class="highlight">Relying Parties</span> may wish to prove that the individual presenting a DID is in fact its <a>DID Controller</a> or
specified as a Controller for a particular service endpoint. This authentication process should use the cryptographic
material in the DID Document to test if the claimed Controller can, in fact, prove control, typically through some
sort of challenge-response. DID Documents and methods may allow for separate proofs for different service endpoints,
distinct from update and delete actions. This separation would support transactional proofs that are expected to be
used frequently, while controlling proofs are expected to be used rarely.</p>
</section>
<section id="sign">
<h2>Sign</h2>
<p>Using cryptographic material associated with that found in a <a>DID Document</a>, <a>DID Controller</a>s may sign digital
assets or documents. This signature can <a href="#verifySignature">later be verified</a> to demonstrate the
authenticity of the asset. In this way, it should be possible to refer to the asset as "signed by the DID".</p>
</section>
<section id="resolve">
<h2>Resolve</h2>
<p>The first step in using a DID for anything other than presentation is to resolve the DID to a specific <a>DID Document</a>,
to reveal the cryptographic material and service endpoints associated with that DID. How this occurs should be
method-specific and is out of scope for the DID Working Group.</p>
</section>
<section id="dereference">
<h2>Dereference</h2>
<p>Dereferencing a DID uses the material in its DID Document to return a resource. The expectation is that, by default, dereferencing
a DID without a reference to a service endpoint will return the <a>DID Document</a> itself. When a DID is combined with a
<code>service</code> <a href="https://www.w3.org/TR/2019/WD-did-core-20191113/#generic-did-parameter-names">parameter</a>
(forming a <a>DID URL</a>), dereferencing will return the resource pointed to from the named service endpoint, which was
discovered by resolving the DID to its DID Document and looking up the endpoint by name. In this way, a
<span class="highlight">Relying Party</span> may dynamically discover and interact with the current service endpoints for a
given DID. Services can therefore be given persistent identifiers that do not change even when the underlying service
endpoints change.</p>
</section>
<section id="verifySignature">
<h2>Verify Signature</h2>
<p>Given a digital asset signed by a DID, a <span style="background-color:yellow">Relying Party</span> may use the
cryptographic material in the DID Document to verify the signature.</p>
</section>
<section id="rotate">
<h2>Rotate</h2>
<p>Controllers may rotate the cryptographic material for a DID by updating the DID Document as
<span class="highlight">recorded in its registry</span>. Different methods should be able to handle this differently, but
the result would be an update to the core cryptographic proof required to prove control of the DID and the DID Document.</p>
</section>
<section id="modifyServiceEndpoint">
<h2>Modify Service Endpoint</h2>
<p><a>DID Controllers</a> should be able to change service endpoints associated with a DID, including the proof mechanism
for authenticating as the Subject for any given endpoint. The process for doing this is method specific, but is designed to
allow Controllers to make these changes without necessarily changing the primary proof mechanism for control of the DID itself.</p>
</section>
<section id="forwardMigrate">
<h2>Forward / Migrate</h2>
<p>To support interoperability, some methods may provide a way for <a>DID Controllers</a> to record in their registry (by updating the
DID Document), that the DID should be redirected to another DID, which now has full authority to represent the originating
DID. This mechanism would allow <a>DID Controllers</a> to migrate a DID from one method or registry to another.</p>
</section>
<section id="recover">
<h2>Recover</h2>
<p>Some methods may provide a means for recovering control of a DID if its existing private cryptographic material is lost. These
means will vary by method but can include social recovery, <span class="highlight">multi-signature</span>,
<a href="https://en.wikipedia.org/wiki/Shamir's_Secret_Sharing">Shamir sharing</a>, or pre-rotated keys. In general,
recovery triggers a rotation to a new proof, allowing the <a>DID Controller</a> of that new proof to recover control of the
DID without interacting with any <span class="highlight">Relying Parties</span>.</p>
</section>
<section id="audit">
<h2>Audit</h2>
<p>Some methods may provide an explicit audit trail of all <abbr title="Create, Read, Update, Delete/Deactivate">CRUD</abbr>
actions on that DID, including a timestamp for when the actions took place. For distributed ledger-based
registries, this audit trail is fundamental to the way the ledgers record transactions. This would allow
<span class="highlight">relying parties</span> to see, for example, how recently a DID was rotated or its service
endpoints updated, which may inform certain analytics regarding the reliability of the DID's cryptographic material.</p>
</section>
<section id="deactivate">
<h2>Deactivate</h2>
<p>Instead of deleting a DID, Controllers should be able to deactivate a DID such that downstream processes like authentication and
dereferencing are no longer functional. Most decentralized systems cannot guarantee actual deletion of a record.
Indeed, distributed ledgers are often touted as "immutable". Methods should define deactivation processes to achieve
the same effect as deletion. The mechanisms for deactivation will vary based on the method.</p>
</section>
</section>
<section id="featureBenefitGrid">
<h2>Feature/Benefit Grid</h2>
<p>In collecting and evaluating potential use cases, we have
identified fifteen (15) key features supported by the DID specification,
which provide benefits in the areas of anti-censorship, anti-exploitation,
ease of use, privacy, and sustainability.<p>
<p>The features and their associated benefits can be seen in the following
grid. A brief definition of each feature follows.</p>
<table id="feature_benefit_grid" class="feature_grid">
<tbody>
<tr>
<th scope="col">Feature </th>
<th scope="col">Anti-censor</th>
<th scope="col">Anti-exploitation</th>
<th scope="col">Ease of Use</th>
<th scope="col">Privacy</th>
<th scope="col">Sustainability</th>
</tr>
<tr>
<th scope="row"> <a href="#f1">1. Inter-jurisdictional</a></th>
<td class="a-censor">X</td>
<td class="a-exploit"> </td>
<td class="ease"> </td>
<td class="privacy"> </td>
<td class="sustainability">X</td>
</tr>
<tr>
<th scope="row"><a href="#f2">2. Can't be administratively denied</a></th>
<td class="a-censor">X</td>
<td class="a-exploit"> </td>
<td class="ease"> </td>
<td class="privacy"> </td>
<td class="sustainability"> </td>
</tr>
<tr>
<th scope="row"><a href="#f3">3. Minimized rents</a></th>
<td class="a-censor"> </td>
<td class="a-exploit">X</td>
<td class="ease"> </td>
<td class="privacy"> </td>
<td class="sustainability">X</td>
</tr>
<tr>
<th scope="row"><a href="#f4">4. No vendor lock in</a></th>
<td class="a-censor"> </td>
<td class="a-exploit">X</td>
<td class="ease"> </td>
<td class="privacy"> </td>
<td class="sustainability">X</td>
</tr>
<tr>
<th scope="row"><a href="#f5">5. Self-issued, self-managed</a></th>
<td class="a-censor">X</td>
<td class="a-exploit">X</td>
<td class="ease"> </td>
<td class="privacy">X</td>
<td class="sustainability"> </td>
</tr>
<tr>
<th scope="row"><a href="#f6">6. Streamlined rotation</a></th>
<td class="a-censor"> </td>
<td class="a-exploit"> </td>
<td class="ease">X</td>
<td class="privacy"> </td>
<td class="sustainability"> </td>
</tr>
<tr>
<th scope="row"><a href="#f7">7. No phone home</a></th>
<td class="a-censor"> </td>
<td class="a-exploit"> </td>
<td class="ease"> </td>
<td class="privacy">X</td>
<td class="sustainability"> </td>
</tr>
<tr>
<th scope="row"><a href="#f8">8. No surveillance capitalism</a></th>
<td class="a-censor"> </td>
<td class="a-exploit">X</td>
<td class="ease"> </td>
<td class="privacy">X</td>
<td class="sustainability">X</td>
</tr>
<tr>
<th scope="row"><a href="#f9">9. Cryptographic future proof</a></th>
<td class="a-censor"> </td>
<td class="a-exploit"> </td>
<td class="ease"> </td>
<td class="privacy"> </td>
<td class="sustainability">X</td>
</tr>
<tr>
<th scope="row"><a href="#f10">10. Survives issuing organization mortality</a></th>
<td class="a-censor"> </td>
<td class="a-exploit"> </td>
<td class="ease">X</td>
<td class="privacy"> </td>
<td class="sustainability">X</td>
</tr>
<tr>
<th scope="row"><a href="#f11">11. Survives deployment end-of-life</a></th>
<td class="a-censor"> </td>
<td class="a-exploit"> </td>
<td class="ease"> </td>
<td class="privacy"> </td>
<td class="sustainability">X</td>
</tr>
<tr>
<th scope="row"><a href="#f12">12. Survives relationship with service provider</a></th>
<td class="a-censor"> </td>
<td class="a-exploit"> </td>
<td class="ease">X</td>
<td class="privacy"> </td>
<td class="sustainability">X</td>
</tr>
<tr>
<th scope="row"><a href="#f13">13. Cryptographic authentication and communication</a></th>
<td class="a-censor">X</td>
<td class="a-exploit">X</td>
<td class="ease"> </td>
<td class="privacy">X</td>
<td class="sustainability"> </td>
</tr>
<tr>
<th scope="row"><a href="#f14">14. Service Discovery</a></th>
<td class="a-censor"> </td>
<td class="a-exploit"> </td>
<td class="ease">X</td>
<td class="privacy"> </td>
<td class="sustainability">X</td>
</tr>
<tr>
<th scope="row"><a href="#f15">15. Registry agnostic</a></th>
<td class="a-censor">X</td>
<td class="a-exploit">X</td>
<td class="ease"> </td>
<td class="privacy">X</td>
<td class="sustainability">X</td>
</tr>
</tbody>
</table>
</section>
<section id="requiredFeatures">
<h2>Required Features</h2>
<dl id="feature_definitions">
<dt id="f1">1. Inter-jurisdictional</dt>
<dd>Inter-jurisdictional identifiers do not depend on the legal jurisdiction
in which they are issued. They are valid for uses anywhere without loss
of fidelity or reliability. No jurisdiction is directly able to prevent
their use. (Anti-censorship and Sustainable).</dd>
<dt id="f2">2. Can't be administratively denied</dt>
<dd>These identifiers can't be denied or taken away by administrative
function. This prevents shifting politics and bad actors from
interfering. (Anti-censorship).</dd>
<dt id="f3">3. Minimized rents</dt>
<dd>These identifiers don't incur ongoing expenses if unused nor on a per
transaction basis. Fees based on updates—which incurs network and
computational costs to verify—are considered "minimal". (Anti-exploitation
and Sustainable).</dd>
<dt id="f4">4. No vendor lock in</dt>
<dd>These identifiers are not dependent on any given vendor. Vendor-specific
identifiers restrict usage to that which is acceptable to the vendor and
may allow vendors to extract disproportionate rents for usage.
(Anti-exploitation, Privacy, and Sustainable).</dd>
<dt id="f5">5. Self-issued, self-managed</dt>
<dd>These identifiers are created and managed by the subject of the identifier.
They are not assigned, given, sold, or rented to the individual using them.
The party relying on the identifier for identification, authentication, and
authorization, does not need to manage the creation, update, and recovery of
these identifiers. (Anti-censorship, Ease of use, and Privacy)</dd>
<dt id="f6">6. Streamlined rotation</dt>
<dd>When authentication materials need to be updated, these identifiers can
update without direct intervention with relying parties and with minimal
individual interaction. (Ease of use)</dd>
<dt id="f7">7. No phone home</dt>
<dd>When using these identifiers, there is no need to contact the issuer of the
identifier to verify it. Verification and authentication can occur without
further communication with the issuer. (Privacy)</dd>
<dt id="f8">8. No surveillance capitalism</dt>
<dd>These identifiers limit the effectiveness of surveillance capitalism by
minimizing cross-service correlatability. Individuals may use these
identifiers at multiple service providers without their activity being
tracked for collusion or third party embedded surveillance techniques like
cookies. (Anti-exploitation and Privacy).</dd>
<dt id="f9">9. Cryptographic future proofing</dt>
<dd>These identifiers are capable of being updated as technology evolves. Current
cryptography techniques are known to be susceptible to quantum computational
attacks. Future-proofed identifiers provide a means to continue using the same
identifier with updated, advanced authentication and authorization technologies.
(Sustainable)</dd>
<dt id="f10">10. Survives organizational mortality</dt>
<dd>These identifiers survive the demise of the organization that issued them. They
usefulness of these identifiers survive organizations going out of business,
being purchased (and potentially losing domain names or root credentials), and
even the internal decay of an organization that no longer has the ability to
verify the authenticity of records they once issued.</dd>
<dt id="f11">11. Survives deployment end-of-life</dt>
<dd>These identifiers are usable even after the systems deployed by relying parties
move past their useful lifetime. They are robust against technology fads and can
seamlessly work with both legacy and next-generation systems.</dd>
<dt id="f12">12. Survives relationship with service provider</dt>
<dd>These identifiers are not dependent on the tenure of the relationship with a
service provider. This contrasts with identifiers like service-centric emails,
e.g., [email protected], which when used as identifiers in other systems can cause
problems when individuals no longer use the service provider.</dd>
<dt id="f13">13. Cryptographic authentication and communication</dt>
<dd>These identifiers enable cryptographic techniques to authenticate individuals
and to secure communications with the subject of the identifier, typically using
public-private key pairs.</dd>
<dt id="f14">14. Service discovery</dt>
<dd>These identifiers allow relying parties to look up available service endpoints
for interacting with the subject of the identifier. (Ease of use and Sustainable)</dd>
<dt id="f15">15. Registry agnostic</dt>
<dd>These identifiers are free to reside on any registry implementing a compatible
interface. They are not beholden to any particular technology or vendor.</dd>
</dl>
</section>
<section id="featureCoverage">
<h2>Feature Coverage</h2>
<p>Not all use cases illustrate each feature, and not all DID methods
support all features. However, we are gathering
use cases to make sure all key features are clearly described. The
following chart shows which features are explicitly illustrated in
the <a href="#focalUseCases">Focal Use Cases</a>.</p>
<table class="feature_grid">
<tbody>
<tr>
<th scope="col">Feature </th>
<th scope="col">Corporate</th>
<th scope="col">Educational<br/>credentials</th>
<th scope="col">Prescriptions</th>
<th scope="col">Digital<br/>Executor</th>
<th scope="col">Single<br/>Sign On</th>
</tr>
<tr>
<th scope="row"> <a href="#f1">1. Inter-jurisdictional</a></th>
<td class="corporate">X</td>
<td class="education">X</td>
<td class="prescriptions"> </td>
<td class="executor">X</td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f2">2. Can't be administratively denied</a></th>
<td class="corporate">X</td>
<td class="education"> </td>
<td class="prescriptions">X</td>
<td class="executor">X</td>
<td class="sso">X</td>
</tr>
<tr>
<th scope="row"><a href="#f3">3. Minimized rents</a></th>
<td class="corporate"> </td>
<td class="education"> </td>
<td class="prescriptions">X</td>
<td class="executor"> </td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f4">4. No vendor lock in</a></th>
<td class="corporate">X</td>
<td class="education">X</td>
<td class="prescriptions">X</td>
<td class="executor">X</td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f5">5. Self-issued, self-managed</a></th>
<td class="corporate">X</td>
<td class="education">X</td>
<td class="prescriptions">X</td>
<td class="executor">X</td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f6">6. Streamlined rotation</a></th>
<td class="corporate"> </td>
<td class="education">X</td>
<td class="prescriptions"> </td>
<td class="executor">X</td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f7">7. No phone home</a></th>
<td class="corporate"> </td>
<td class="education">X</td>
<td class="prescriptions">X</td>
<td class="executor"> </td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f8">8. No surveillance capitalism</a></th>
<td class="corporate"> </td>
<td class="education"> </td>
<td class="prescriptions">X</td>
<td class="executor"> </td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f9">9. Cryptographic future proof</a></th>
<td class="corporate">X</td>
<td class="education">X</td>
<td class="prescriptions"> </td>
<td class="executor"> </td>
<td class="sso">X</td>
</tr>
<tr>
<th scope="row"><a href="#f10">10. Survives issuing organization mortality</a></th>
<td class="corporate"> </td>
<td class="education">X</td>
<td class="prescriptions"> </td>
<td class="executor"> </td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f11">11. Survives deployment end-of-life</a></th>
<td class="corporate"> </td>
<td class="education">X</td>
<td class="prescriptions"> </td>
<td class="executor"> </td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f12">12. Survives relationship with service provider</a></th>
<td class="corporate">X</td>
<td class="education">X</td>
<td class="prescriptions"> </td>
<td class="executor"> </td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f13">13. Cryptographic authentication and communication</a></th>
<td class="corporate">X</td>
<td class="education">X</td>
<td class="prescriptions">X</td>
<td class="executor">X</td>
<td class="sso">X</td>
</tr>
<tr>
<th scope="row"><a href="#f14">14. Service Discovery</a></th>
<td class="corporate"> </td>
<td class="education"> </td>
<td class="prescriptions"> </td>
<td class="executor"> </td>
<td class="sso"> </td>
</tr>
<tr>
<th scope="row"><a href="#f15">15. Registry agnostic</a></th>
<td class="corporate"> </td>
<td class="education"> </td>
<td class="prescriptions"> </td>
<td class="executor"> </td>
<td class="sso"> </td>
</tr>
</tbody>
</table>
</section>
<section id="focalUseCases">
<h2>Focal Use Cases</h2>
<section id="didEnterprise">
<h3>Decentralized Corporate Identifiers (enterprise)</h3>
<section>
<h4>Background</h4>
<p>
There are many types of identifiers that corporations use today
including tax identification numbers (e.g. 238-42-3893), Legal
Entity Identifiers (e.g. 5493000IBP32UQZ0KL24), Data Universal
Numbering System identifiers (aka. DUNS Number) (e.g. 150483782),
and many more that communicate the unique identity of an organization.
None of these numbers enable an organization to self-issue an
identifier or to use the number to cryptographically authenticate or
digitally sign agreements. A great number of business to business
and business to customer transactions could be executed more quickly
and with greater assurance of the validity of the transaction if a
mechanism to self-issue cryptographic identifiers were created.
</p>
</section>
<section id="didEnterpriseDescrption">
<h4>Description</h4>
<p>
A North American government would like to ensure that the supply
chain that feeds electronic products into the country is secure. As
a result, a new method of submitting digital documentation to Customs
is enabled that requires that all documentation is provided as
machine-readable digitally signed data. Digitally signed documentation
is collected at each stage of the manufacturing, packaging, and
shipping process. This documentation is then submitted to Customs
upon the products entry into the country where all digital signatures
are verified on the documentation. Some aspects of the signed
documentation, such as firmware hashes and checksums, are then used
by Customs and downstream customers to verify that the products have
not been tampered with after leaving the manufacturing facility.
</p>
<p>
Decentralized Identifiers should ensure 1) low
management overhead for the government, 2) self-management of
identifiers and cryptographic key material, and 3) a competitive
marketplace.
</p>
</section>
<section id="didEnterpriseChallenges">
<h4>Challenges</h4>
<p>
The requirement of downstream customers to use the same documentation
and digital signature mechanisms that were provided to Customs is
potentially problematic in this scenario. Governments often create ad-hoc
solutions for their import solutions, which make securing the global
supply chain difficult as each government has their own method of
securing the supply chain and identifying corporations that downstream
customers need to integrate with. If you are a global company, that
means integrating with many supply chain systems (each with different
capabilities). As such, any securing of the supply chain with downstream
customers must then depend on the country-specific corporate
identification and PKI solution, which leads to ad-hoc solutions that
drive up the cost of doing business across borders.
</p>
<p>
A supply chain identifier solution that is simple, self-administered,
built on global standards, is flexible in the cryptographic mechanisms
used to authenticate, and can be used by governments and downstream
customers with little to no modification to the regional government
or corporate systems does not exist today.
</p>
</section>
<section id="didEnterpriseDistinctions">
<h4>Distinctions</h4>
<p>
Many Decentralized Identifier use cases focus on Self-Sovereign
Identity and individuals. This use case focuses on organizations and
their departments as entities that would also benefit from
Decentralized Identifiers.
</p>
</section>
</section>
<section id="edu">
<h3>Life-long, recipient-managed Credentials (education)</h3>
<section id="eduBackground">
<h4>Background</h4>
<p>Educational Verifiable Credentials [[VC-DATA-MODEL]] offer benefits over traditional
educational credentials in that the recipient is able to store and
share their credentials, and a third party may independently verify
the credential (including authenticating the identity of the recipient),
without necessarily consulting the issuer, and without dependence on
centuries old treaty-based bureaucratic process for the international
verification of credentials. This provides the promise of recipient-owned
long-lived credentials that the recipient may use in any country,
even if the issuing institution goes out of business.
</p>
<p> However, traditional public-private key pair-based identifiers
present challenges for rotating keys, especially if
the identifier in a credential is simply the public key (with
the private key used for authentication).</p>
<ol>
<li>With the public key embedded in the digitally signed credential,
it is literally impossible to update the signing key; a recipient
must contact the issuer and request re-issuing with a new
identifer. If the issuer is not reachable, or is unwilling
or unable to issue a new credential, the recipient cannot
update the cryptographic material.</li>
<li>If the credential relies on a centralized key registry or
authority for managing rotation, then that registry becomes
the centralized point of failure. This may or may not be an
improvement, especially for longer held credentials.</li>
<li>If the credential's cryptographic technology becomes outdated,
there is no way to update the credential to use a more robust
technology; a recipient must contact the issuer for reissuance.</li>
</ol>
<p>The key rotation is particularly problematic for credentials
expected to last a lifetime. It should be anticipated that
a given individual will change their key management strategy and
systems several times over the course of their life, e.g. relying
on a cloud wallet, a mobile wallet, or a dedicated hardware wallet,
as their needs change.</p>
<p>By issuing an educational credential to a recipient's DID, the
recipient has the ability to prove ownership of a credential even
if the cryptographic material used for authenticating changes over time.
</p>
</section>
<section id="eduDescription">
<h4>Description</h4>
<p>When Sally earned her master’s degree at Oxford, she received a
digital diploma that contained a decentralized identifier she provided.
Over time, she updates the cryptographic material associated with that
DID to use her latest hardware wallet, with biometric protections and a
quantum resistant algorithm. A decade after graduation, she applies for
a job in Japan, for which she provides her digital diploma by uploading
it to the prospective employee’s website. To verify she is the
actual recipient of that degree, she uses the decentralized identifier
to authenticate, using her current hardware wallet (with rotated keys).
In addition to the fact that her name matches the name on the diploma,
the cryptographic authentication provides a robust verification of her
claim, allowing the employer to rely on Sally’s assertion that she
earned a master’s degree from Oxford. </p>
</section>
<section id="eduChallenges">
<h4>Challenges</h4>
<p>Rotating keys without invalidating Sally's educational credentials and
providing acceptable proof of education internationally.</p>
</section>
<section id="eduDistinction">
<h4>Distinction</h4>
<p>Oxford had no need to provide services for resetting or updating
Sally’s username or password; they had no role in managing
Sally’s changes to her authentication credentials. The potential
employer did not need to contact Oxford to verify Sally’s claim of
a master’s degree; they were able to verify the credential and
authenticate Sally’s identity with information retrieved over the
Internet.</p>
</section>
</section>
<section id="prescriptions">
<h3>Prescriptions (healthcare)</h3>
<section id="prescriptionsBackground">
<h4>Background</h4>
<p>
Alicia wants help with her urinary tract infection (UTI) and is a bit
touchy about her privacy. In the old days, she would have to make an
appointment in-person and get a paper prescription to take to a
pharmacy. She wants to save money and have peace of mind.
</p>
</section>
<section id="prescriptionsDescription">
<h4>Description</h4>
<p>
Alicia is in a state that allows an online service to diagnose and
prescribe medication. She uses the identity wallet on her smartphone
to register with the online medical practice. She tells the online
practice her name is Althea (a pseudonym)
with password-less authentication and a verified driver's license
credential to prove that she's a resident of the state. The remote physician,
Barkley, is licensed by the state Board of Medicine and credentialed by the
online service. He's securely signed in using the
identity wallet on his smartphone. Barkley issues Alicia a digital
prescription in the form of a verifiable credential and allows Alicia
to download it however she pleases. Alicia is a librarian and trusts
her local public library to erase their logs as allowed by law. She
uses one of their computers to sign-in and do all of this. She snaps
a picture of the QR code that is the prescription to take to the
pharmacy. Connor, the licensed pharmacist, scans the prescription
QR code and fills the prescription. Alicia pays cash.
</p>
</section>
<section id="prescriptionsChallenges">
<h4>Challenges</h4>
<p>The challenge of this particular use-case is that only Barkley and
Connor are verified identities and accountable for their interaction
with Alicia. Alicia can be anonymous or pairwise-pseudonymous with both
Barkley and Connor and everything just works. Alicia, Barkley, and Connor
all keep separate and legally authentic copies of the records of their
interaction in case of dispute.
</p>
</section>
<section id="prescriptionsDistinction">
<h4>Distinction</h4>
<p>
The Prescription use-case is a common and high-value example of
privacy engineering as we shift to convenient and cost-effective
online commerce among licensed and unlicensed individuals as peers.
Barkley and Connor benefit by reducing or even eliminating the influence
of their respective institutions or employers and therefore make more
money. They pass some savings to Alicia who also gets increased peace
of mind.
</p>
</section>