forked from w3c-ccg/did-primer
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
464 lines (446 loc) · 20.3 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
<!DOCTYPE html>
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Apple macOS version 5.6.0">
<title>A Primer for Decentralized Identifiers</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 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-primer",
// subtitle
subtitle: "An introduction to self-administered identifiers for curious people",
// 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/w3c-ccg/did-primer/",
includePermalinks: false,
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://w3c-ccg.github.io/did-primer/",
// 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: "Andrew Hughes", url: "https://idimmusings.com/",
company: "ITIM Consulting", companyURL: "https://idimmusings.com/" },
{ name: "Manu Sporny", url: "http://manu.sporny.org/",
company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/" },
{ name: "Drummond Reed", url: "https://www.linkedin.com/in/drummondreed/",
company: "Evernym", companyURL: "https://evernym.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: "Credentials Community Group", url: "https://w3c-ccg.github.io/",
company: "W3C", companyURL: "https://www.w3.org/" }
],
// 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: "https://www.w3.org/community/about/agreements/cla/",
maxTocLevel: 4,
inlineCSS: true
};
</script>
</head>
<body>
<section id='abstract'>
<p>
A Decentralized Identifier (DID) is a new type of identifier that is
globally unique, resolvable with high availability, and cryptographically
verifiable. DIDs are typically associated with cryptographic material, such
as public keys, and service endpoints, for establishing secure communication
channels. DIDs are useful for any application that benefits from
self-administered, cryptographically verifiable identifiers such as
personal identifiers, organizational identifiers, and identifiers for
Internet of Things scenarios. For example, current commercial deployments of
W3C Verifiable Credentials heavily utilize Decentralized Identifiers to
identify people, organizations, and things and to achieve a number of
security and privacy-protecting guarantees. This document is an introduction
to the concept of Decentralized Identifiers.
</p>
</section>
<section id='sotd'>
<p>Comments regarding this document are welcome. Please file
issues directly on <a href=
"https://github.com/w3c-ccg/did-primer/issues/">GitHub</a>, or
send them to <a href=
"mailto:public-credentials@w3.org">public-credentials@w3.org</a>
(<a href=
"mailto:public-credentials-request@w3.org?subject=subscribe">subscribe</a>,
<a href=
"https://lists.w3.org/Archives/Public/public-credentials/">archives</a>).</p>
<p>Portions of the work on this specification have been funded
by the United States Department of Homeland Security's Science
and Technology Directorate under contracts
HSHQDC-16-R00012-H-SB2016-1-002 and HSHQDC-17-C-00019. 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 community facilitated by Christopher Allen,
Shannon Appelcline, Kiara Robles, Brian Weller, Betty Dhamers,
Kaliya Young, Manu Sporny, Drummond Reed, Joe Andrieu, Kim Duffy, and
Heather Vescent.</p>
</section>
<section>
<h2 id="introduction">Introduction</h2>
<p>At a superficial level, a <strong>decentralized
identifier</strong> (<strong>DID</strong>) is simply a new type
of globally unique identifier. But at a deeper level, DIDs are
the core component of an entirely new layer of decentralized
digital identity and public key infrastructure (PKI) for the
Internet. This <a href=
"https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/dpki.pdf">
<strong><em>decentralized public key
infrastructure</em></strong></a> (DPKI) could have as much
impact on global cybersecurity and cyberprivacy as the
development of the <a href=
"https://en.wikipedia.org/wiki/Transport_Layer_Security"><em>SSL/TLS
protocol</em></a> for encrypted Web traffic (now the largest
PKI in the world).</p>
<p>This primer is designed to give newcomers to DID
architecture the background they need to understand not just
the DID specification, but the overall architecture for
decentralized identity represented by the family of DID-related
specifications currently under development. It covers:</p>
<ul>
<li>
<p>Background on the origin of DIDs and the DID
specification.</p>
</li>
<li>
<p>How DIDs differ from other globally-unique
identifiers.</p>
</li>
<li>
<p>How the syntax of DIDs can be adapted to work with
decentralized networks.</p>
</li>
<li>
<p>How DIDs resolve to <strong>DID Documents</strong>
containing public keys and service endpoints.</p>
</li>
<li>
<p>The key role that <strong>DID Methods</strong> play in
the implementation of DID infrastructure.</p>
</li>
<li>
<p>Privacy considerations for the use of DIDs.</p>
</li>
<li>
<p>How DID infrastructure lays the foundation for
<strong>verifiable credentials</strong>.</p>
</li>
</ul>
</section>
<section>
<h2 id=
"how-dids-differ-from-other-globally-unique-identifiers">How
DIDs Differ from Other Globally Unique Identifiers</h2>
<p>The need for globally unique identifiers that do not require
a centralized registration authority is not new. <a href=
"https://en.wikipedia.org/wiki/Universally_unique_identifier"><em>
UUIDs</em></a> (Universally Unique Identifiers, also called
GUIDs, Globally Unique Identifiers) were developed for this
purpose in the 1980s and standardized first by the Open
Software Foundation and then by <a href=
"https://tools.ietf.org/html/rfc4122"><em>IETF RFC
4122</em></a>.</p>
<p>The need for persistent identifiers (identifiers that can be
assigned once to an entity and never need to change) is also
not new. This class of identifiers was standardized as <a href=
"https://en.wikipedia.org/wiki/Uniform_Resource_Name"><em>URNs</em></a>
(Uniform Resource Names) first by IETF <a href=
"https://www.ietf.org/rfc/rfc2141.txt"><em>RFC 2141</em></a>
and more recently by <a href=
"https://tools.ietf.org/html/rfc8141"><em>RFC
8141</em></a>.</p>
<p>One might ask why do we need DIDs when standards like UUIDs and
URNs already exist. Answer to this question lies in the concept of
<strong>self-sovereign identity</strong>. For self-sovereign identity,
which can be defined as a lifetime portable digital identity that does
not depend on any centralized authority, we need an identifier that
has four major characteristics: persistence, global resolvability,
cryptographic verifiability, and decentralization.</p>
<p>Unfortunately UUIDs and URNs do not fit that bill. As a rule UUIDs
are not globally resolvable and URNs – if resolvable – require a
centralized registration authority. In addition, neither UUIDs or URNs
inherently address a third characteristic that we desire – the ability to
<strong>cryptographically verify ownership of the
identifier</strong>.</p>
</section>
<section>
<h2 id="the-format-of-a-did">The Format of a DID</h2>
<p>In 2016 the developers of the DID specification agreed with
a suggestion from Christopher Allen that DIDs could be adapted
to work with multiple blockchains by following the same basic
pattern as the URN specification:</p>
<figure>
<img src="did-primer-diagrams/urn-format.png" alt=
"urn:uuid:fe0cde11-59d2-4621-887f-23013499f905">
<figcaption>
urn:uuid:fe0cde11-59d2-4621-887f-23013499f905
</figcaption>
</figure>
<p>The key difference is that with DIDs the namespace component
identifies a <strong>DID method</strong>, and a <strong>DID
method specification</strong> specifies the format of the
method-specific identifier.</p>
<figure>
<img src="did-primer-diagrams/did-format.png" alt=
"did:example:12345abcde">
<figcaption>
did:example:12345abcde
</figcaption>
</figure>
<p>DID methods (further explained below) define how DIDs work
with a specific blockchain. All DID method specs must define
the format and generation of the method-specific identifier.
Note that the method specific identifier string
<strong>must</strong> be unique in the namespace of that DID
method.</p>
</section>
<section>
<h2 id="did-documents">DID Documents</h2>
<p>DID infrastructure can be thought of as a global <a href=
"https://en.wikipedia.org/wiki/Key-value_database"><em>key-value
database</em></a> in which the database is all DID-compatible
blockchains, distributed ledgers, or decentralized networks. In
this virtual database, the key is a DID, and the value is a
<strong>DID document</strong>. The purpose of the DID document
is to describe the public keys, authentication protocols, and
service endpoints necessary to bootstrap
cryptographically-verifiable interactions with the identified
entity.</p>
<p>A DID document is a valid <a href=
"https://json-ld.org/spec/latest/json-ld/"><em>JSON-LD
object</em></a> that uses the <strong>DID context</strong> (the
RDF vocabulary of property names) defined in the DID
specification. This includes six components (all optional):</p>
<ol type="1">
<li>
<p><strong>The DID itself</strong>, so the DID document is
fully self-describing.</p>
</li>
<li>
<p><strong>A set of cryptographic material</strong>, such
as public keys, that can be used for authentication or
interaction with the DID subject.</p>
</li>
<li>
<p><strong>A set of cryptographic protocols</strong> for
interacting with the DID subject, such as authentication
and capability delegation.</p>
</li>
<li>
<p><strong>A set of service endpoints</strong> that
describe where and how to interact with the DID
subject.</p>
</li>
<li>
<p><strong>Timestamps</strong> for auditing.</p>
</li>
<li>
<p><strong>A optional JSON-LD signature</strong> if needed
to verify the integrity of the DID document.</p>
</li>
</ol>
<p>See the <a href=
"https://w3c-ccg.github.io/did-spec/"><em>DID
specification</em></a> for several examples of DID
documents.</p>
</section>
<section>
<h2 id="did-methods">DID Methods</h2>
<p>DIDs and DID documents can be adapted to any modern
blockchain, distributed ledger, or other decentralized network
capable of resolving a unique key into a unique value. It does
not matter whether the blockchain is public, private,
permissionless, or permissioned.</p>
<p>Defining how a DID and DID document are created, resolved,
and managed on a specific blockchain or “target system” is the
role of a <strong>DID method specification</strong>. DID method
specifications are to the generic DID specification as URN
namespace specifications (UUID, ISBN, OID, LSID, etc.) are to
the generic IETF URN specification (<a href=
"https://tools.ietf.org/html/rfc8141"><em>RFC
8141</em></a>).</p>
<p>DID method specifications typically define at least the
following operations for a particular target system:</p>
<ol type="1">
<li>
<p><strong>Create.</strong> Some DID methods may generate a
DID directly from a cryptographic key pair. Others may use
the address of a transaction or a smart contract on the
blockchain itself.</p>
</li>
<li>
<p><strong>Read.</strong> Some DID methods use blockchains
that can store DID documents directly on the blockchain.
Others may instruct DID resolvers to construct them
dynamically based on attributes of a blockchain record.
Still others may store a pointer on the blockchain to a DID
document stored in one or more parts on other decentralized
storage networks such as <a href=
"https://en.wikipedia.org/wiki/InterPlanetary_File_System"><em>
IPFS</em></a> or <a href=
"https://en.wikipedia.org/wiki/STORJ"><em>STORJ</em></a>.</p>
</li>
<li>
<p><strong>Update.</strong> The update operation is the
most critical from a security standpoint because control of
a DID document represents control of the public keys or
proofs necessary to authenticate an entity (and therefore
for an attacker to impersonate the entity). Since
verification of DID document update permissions can only be
enforced by the target blockchain, the DID method
specification must define precisely how authentication and
authorization are performed for any update operation.</p>
</li>
<li>
<p><strong>Delete.</strong> DID entries on a blockchain are
by definition immutable, so they can never be “deleted” in
the conventional database sense. However they can be
<strong>revoked</strong> in the cryptographic sense. A DID
method specification must define how this termination is
performed, e.g., by writing a null DID document.</p>
</li>
</ol>
<p>See the <a href=
"https://w3c-ccg.github.io/did-method-registry/">DID Method
Registry</a> for a complete list of all known DID Method
specifications.</p>
</section>
<section>
<h2 id="dids-and-privacy-by-design">DIDs and Privacy by
Design</h2>
<p>Privacy is an essential component of any identity management
solution; it is especially critical for a global identity
system that uses immutable public blockchains. Thankfully DID
architecture can incorporate <a href=
"https://en.wikipedia.org/wiki/Privacy_by_design"><em>Privacy
by Design</em></a> at the very lowest levels of infrastructure
and thus become a powerful, new, privacy-preserving technology
if deployed using best practices such as:</p>
<ol type="1">
<li>
<p><strong>Pairwise-pseudonymous DIDs.</strong> While DIDs
can be used as well-known public identifiers, they can also
be used as private identifiers issued on a per-relationship
basis. So rather than a person having a single DID, like a
cell phone number or national ID number, she can have
thousands of pairwise-unique DIDs that cannot be correlated
without her consent, yet can still be managed as easily as
an address book.</p>
</li>
<li>
<p><strong>Off-chain private data.</strong> Storing any
type of PII on a public blockchain, even encrypted or
hashed, is dangerous for two reasons: 1) the encrypted or
hashed data is a global correlation point when the data is
shared with multiple parties, and 2) if the encryption is
eventually broken (e.g., <a href=
"https://en.wikipedia.org/wiki/Quantum_computing"><em>quantum
computing</em></a>), the data will be forever accessible on
an immutable public ledger. So the best practice is to
store all private data off-chain and exchange it only over
encrypted, private, peer-to-peer connections.</p>
</li>
<li>
<p><strong>Selective disclosure.</strong> The decentralized
PKI (DPKI) that DIDs make possible opens the door to
individuals gaining greater control over their personal
data in two ways. First, it enables it to be shared using
encrypted digital credentials (see below). Second, these
credentials can use <a href=
"https://en.wikipedia.org/wiki/Zero-knowledge_proof"><em>zero-knowledge
proof cryptography</em></a> for <a href=
"https://www.forbes.com/sites/bernardmarr/2016/03/16/why-data-minimization-is-an-important-concept-in-the-age-of-big-data/">
<em>data minimization</em></a>, e.g., you can disclose that
you are over a certain age without disclosing your exact
birthdate.</p>
</li>
</ol>
</section>
<section>
<h2 id="dids-and-verifiable-credentials">DIDs and Verifiable
Credentials</h2>
<p>DIDs are only the base layer of decentralized identity
infrastructure. The next higher layer – where most of the value
is unlocked – is <strong>verifiable credentials</strong>. This
is the technical term for a digitally signed electronic
credential that conforms to the interoperability standards
being developed by the <a href=
"https://www.w3.org/2017/vc/charter.html"><em>W3C Verifiable
Claims Working Group</em></a>.</p>
<p>DIDs can be used to identify various entities in the
Verifiable Credentials ecosystem such as issuers, holders,
subjects, and verifiers. More generally, DIDs can be used as
identifiers for people, devices, and organizations.</p>
<p>See the <a href=
"verifiable-credentials-primer.md"><em>Verifiable Credentials
Primer</em></a> for a brief introduction to the topic.</p>
</section>
<section>
<h2 id="appendix-a-did-community-resources">Appendix A: DID
Community Resources</h2>
<p>Besides the links throughout this primer, these additional
resources are available to anyone interested in joining the
communities that are actively developing specifications,
experiments, and pilot projects.</p>
<ul>
<li>
<p><a href=
"https://www.w3.org/community/credentials/"><em>W3C
Verifiable Claims Working Group mailing list</em></a></p>
</li>
<li>
<p><a href="https://w3c-ccg.github.io"><em>W3C Credentials
Community Group</em></a></p>
</li>
<li>
<p><a href=
"https://github.com/w3c-ccg/did-spec/issues/"><em>DID
specification issues list</em></a></p>
</li>
<li>
<p><a href="http://www.weboftrust.info/"><em>Rebooting the
Web of Trust event</em></a> (held every six months)</p>
</li>
<li>
<p><a href=
"http://www.internetidentityworkshop.com/"><em>Internet
Identity Workshop event</em></a> (held every six
months)</p>
</li>
</ul>
</section>
</section>
</body>
</html>