-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
566 lines (531 loc) · 23.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
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>did:tag Method Specification</title>
<script
src="https://www.w3.org/Tools/respec/respec-w3c"
async
class="remove"
></script>
<script class="remove">
var respecConfig = {
specStatus: "unofficial",
shortName: "did-method-tag",
wg: "Credentials Community Group",
wgURI: "https://www.w3.org/community/credentials/",
latestVersion: null,
edDraftURI: "https://github.com/bobwyman/did_method_tag/",
wgPublicList: "public-credentials",
editors: [
{
name: "Bob Wyman",
email: "[email protected]",
company: "Self",
companyURL: "https://wyman.us",
},
],
authors: [
{
name: "Bob Wyman",
email: "[email protected]",
company: "Self",
companyURL: "https://wyman.us",
},
],
github: "https://github.com/bobwyman/did_method_tag",
localBiblio: {
"DID-PRIMER": {
title: "DID Primer",
href: "https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/did-primer.md",
authors: ["Drummond Reed", "Manu Sporny"],
publisher: "Rebooting the Web of Trust 2017",
},
"DID-DNS": {
title: "The Decentralized Identifier (DID) in the DNS",
href: "https://tools.ietf.org/html/draft-mayrhofer-did-dns-01",
authors: ["A. Mayrhofer", "D. Klesev", "M. Sabadello"],
status: "Internet Draft",
publisher: "IETF",
},
"OWASP-TRANSPORT": {
title: "Transport Layer Protection Cheatsheet",
href: "https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet",
},
"WEB-DID": {
title: "did:web Method Specification",
href: "https://w3c-ccg.github.io/did-method-web/",
},
"ZOOKOS-TRIANGLE": {
title: "Names: Distributed, Secure, Human-Readable: Choose Two",
authors: ["Zooko Wilcox-O'Hearn"],
href: "https://web.archive.org/web/20011020191610/http://zooko.com/distnames.html",
},
"ZOOKOS-TETRAHEDRON": {
title: "The Persistence of Identity (Updating Zooko's Pyramid)",
authors: ["Bob Wyman"],
href: "https://web.archive.org/web/20160331154849/https://wyman.us/main/2006/12/the_persistence.html",
},
},
};
</script>
</head>
<body>
<section id="abstract">
<p>
The did:tag DID method enables any controller of an HTTP accessible
domain or subdomain, or an email address, to create unique,
interoperable, persistent DIDs with minimal dependencies on other
technologies or systems. By leveraging a subset of the tagURI
specification [[RFC4151]], the did:tag DID method enables the creation
of DIDs which are "unique across space and time while being tractable to
humans," without preventing the creation of DIDs which are largely
intractable to humans. did:tag DIDs can be resolved either
synchronously, via the web, or asynchronously, via email or other
defined alternative resolution services.
</p>
</section>
<section id="sotd"></section>
<section>
<h1>Introduction</h1>
<p>
The goal of this proposal is to go beyond the already good work done
with other DID methods and address several issues for which solutions
are not already satisfactorially provided. The key issues addressed here
include:
</p>
<ol>
<li>The persistence of identifiers' uniqueness across time.</li>
<li>
Expanding the realm of DID issuers to include all those who have an
email addresses.
</li>
<li>Asynchronous access to DID documents.</li>
<li>The provision of alternative DID resolution mechanisms.</li>
</ol>
<p>
<b>Persistence:</b> It is generally accepted that ideal decentralized
identifiers would be memorable, secure from misuse, and globally unique.
But, an identifier should also not become less memorable as time passes,
or less secure, or less likely to be unique. Thus, to the set of three
basic naming qualities, we should add a fourth quality; that of
persistence. [[?ZOOKOS-TETRAHEDRON]]
</p>
<div style="display: flex; justify-content: center">
<img src="images/WymansTetrahedron.png" />
</div>
<p>
Unfortunately, as Zooko Wilcox-O'Hearn [[?ZOOKOS-TRIANGLE]] pointed out
in 2001, it is not possible to simultaneously optimize all of the base
qualities of decentralized identifiers. For example: identifiers may be
secure, global, and even likely to remain so for quite some time,
perhaps by using very long cryptographic hash functions to mint them,
but such names are typically not very memorable, at least not by human
beings. Thus, our process for creating names needs to incorporate a
tradeoff between the various desirable attributes of ideal identifiers.
</p>
<p>
Web DIDs do a good job of addressing three of the desirable qualities of
a decentralized identifier. [[?WEB-DID]] The DID Document provides the
data needed to make them secure, the ability to structure them with
human readable components allows them to be memorable, and their linkage
to DNS records provides an ability to ensure that they are unique by
limiting the number of those who can mint them.
</p>
<pre
class="example"
title="A Web DID, memorable, unique, secure, but not persistent."
>
did:web:example.com:user:alice
</pre>
<p>
However, while an issuer of Web DIDs may work hard to ensure that
duplicate DIDs are not issued, maintaining uniqueness over time can be
challenging. A Web DID might be issued to a user named Alice in one
year, but then Alice may cease to become a user in some future year.
Once that happens, some new Alice may wish to have the simple, memorable
identifer "user:alice," but be told that that identifier was issued to a
long-gone user in some previous year. Similarly, domain names tend to
change owners over time. Thus, a new service owner may not even be aware
that there had once been an Alice served by some previous owner. As a
result, a new DID might be issued to an Alice only to discover that it
appears to conflict with DID issued earlier.
</p>
<p>
These issues of identifier persistence were considered and addressed in
the preparation of the IETF's tagURI scheme. [[RFC4151]] The solution
was to define a scheme, very much like that used for Web DIDs, but with
an added component that specifies a date during which the issuer of the
identifier claims to have had authority to use the domain name
incorporated within the name. Using tagURIs, it then becomes possible to
create only slightly less memorable names for multiple Alice's at
different times. For instance, the following are several possible
tagURIs that might identify different Alice's without conflict. Each of
these DID could be minted by a different issuer without a need to know
of any earlier issuer who might have had authority to use the same
domain name.
</p>
<pre class="example" title="tagURIs for several unique Alices">
tag:example.com,2000:user:alice
tag:example.com,2050:user:alice
tag:example.com,2090-10-15:user:alice
tag:example.com,2090-10-16:user:alice
</pre
>
<p>
In order to gain the benefits of persistence provided by tagURIs, this
proposal describes a DID method that relies on tagURIs as its base
rather than the web URLs which were the focus of the Web DID.
</p>
<p>
<b>Enabling all to be issuers:</b> Ideally, everyone would be able to
generate useful DIDs without needing to rely on other issuers or needing
to invest in complex technical capabilities such as those provided by
virtue of obtaining a DNS domain name and operating a web site.
Unfortunately, most existing DID methods assume that an issuer has ready
access to capabilities that are not commanded by the vast majority of
users. Even something as "simple" as registering domain name and
maintaining a web site to host DID documents is far beyond the capacity
of many. Nonetheless, individuals will often need to generate
identifiers.
</p>
<p>
While only a small percentage of those who may need to issue DIDs
maintain, or could maintain, their own web sites, almost every user of
the Internet has a unique email address that can be used to exchange
content with others. And, crude as it may seem, the email protocol
provides much the same ability to engage in "request/response" exchanges
as is provided by the HTTP and similar protocols. Thus, the needs of
users without web sites could be addressed by providing a mechanism for
minting DIDs from tagURIs which incorporate an email address rather than
a domain name. For instance, the following are valid tagURIs
incorporating email addresses:
</p>
<pre class="example" title="tagURIs using email addresses">
tag:[email protected],2000:sender_key
tag:[email protected],2021:living_room_tv
tag:[email protected],2022:
</pre>
<p>
Each of these tagURIs can be easily converted into a DID, using the tag
method, by simply prepending the text <code>did:</code>.
</p>
<p>
The simplest way to support such email-based DIDs would be to define a
resolution method that allows one to send an appropriately structured
email message to the specified address/ The appropriate response to such
a message would be another email message containing the requested DID
Document as an attachment. Such a system could be implemented by having
custom software monitor and respond to messages sent to a particular
email inbox. It could also be implemented using completely manual means.
A "[email protected]" might receive a message with a subject of
<code>RESOLVE: did:tag:[email protected],2000:sender_key</code> and know
that the desired response was an email with the corresponding DID
document as an attachment. With only a little difficulty, the
appropriate response could be prepared and sent.
</p>
<p>
<b>Asynchronous Resolution:</b> An email based DID resolution method,
unlike a web-based method, allows asynchronous DID resolution. In some
cases, the resolution might occur hours, days, even weeks after a
resolution request was made. But, even a very slow response might
actually have been the fastest possible response. An asynchronous
resolution capability would be particularly useful in environments when
connectivity is difficult to maintain or where bandwidth is very slow.
As an extreme example, it is very unlikely that one would be successful
in using https to fetch a DID document from a web server in New York
City if one were making the request from a habitat on Mars or one of its
moons.
</p>
<p>
<b>Alternative DID resolution mechanisms. </b> Just as web addresses can
sometimes be temporarily unavailable due to technical issues, a web
address's availability is sometimes limited by local or regional
administrative policy. One's employer, or one's government, might block
web access to sites that traffic in either pornography or discussions of
human rights and liberty. However, even though a user may be blocked
from directly accessing a web site, and thus from resolving DIDs
normally resolved by doing so, it is often the case that it is possible
to exchange email with addresses on that site, if only because email
doesn't require direct, point-to-point connections. Thus, it is useful
to define a mechanism by which even a normally web-accessible DID
document could be retrieved via indirect, asynchronous email protocols.
In order to provide this mechanism, I propose that an ``AltResolution''
service be provided as a means to inform users of an alternative to web
based DID resolution.
</p>
<section>
<h2>Preface</h2>
<p>
The tag DID method specification conforms to the requirements
specified in the Decentralized Identifiers v1.0 Specification
[[DID-CORE]]. For more information about DIDs and DID method
specifications, please also see the [[?DID-PRIMER]]
</p>
</section>
<section id="conformance">
<!-- This section is filled automatically by ReSpec. -->
</section>
<section>
<h2>Example</h2>
<pre class="example" title="Example did:tag DID document">
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:tag:example.com,2021-10-26:Bob",
"verificationMethod": [{
"id": "did:tag:example.com,2021:faHiOpRlPVQcY_-tA4A",
"type": "JsonWebKey2020",
"controller": "did:tag:example.com,2021:123",
"publicKeyJwk": {
"crv": "Ed25519",
"x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
"kty": "OKP",
"kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
}
}],
"service": [{
"id": "did:tag:example.com,2021:asynch",
"type": "AltResolution",
"serviceEndpoint": "mailto:[email protected]"
}],
}
</pre>
</section>
</section>
<section>
<h1>tag DID Method Specification</h1>
<section>
<h2>Target system</h2>
<p>The target system of the tag DID method is either:</p>
<ul>
<li>
the web host that the domain name included in the DID resolves to
when queried through the Domain Name System (DNS), or,
</li>
<li>
the email server that the email address included in the DID resolves
to when queried through the Domain Name System (DNS).
</li>
</ul>
</section>
<section>
<h2>Method name</h2>
<p>
The namestring that shall identify this DID method is:
<code>tag</code>. A DID that uses this method MUST begin with the
following prefix: <code>did:tag</code>. Per the DID specification,
this string MUST be in lowercase. The remainder of the DID, after the
prefix, is specified below.
</p>
</section>
<section>
<h2>Method-specific identifier</h2>
<p>
The syntax of a did:tag method specific identifier is a subset of
tagURI syntax as defined in [[RFC4151]]. The following constraints are
applied in order to avoid conflict with DID URLs:
</p>
<ul>
<li>Fragments ('#') are not supported.</li>
<li>Query ('?') parameters are not supported.</li>
</ul>
<p>
The modified and constrained abnf for tagURIs supported as components
of DIDs using this method appears below:
</p>
<pre class="nohighlight">
tag-did = "did:" tagURI_subset
tagURI_subset = "tag:" taggingEntity ":" specific
taggingEntity = authorityName "," date
authorityName = DNSname / emailAddress
date = year ["-" month ["-" day]]
year = 4DIGIT
month = 2DIGIT
day = 2DIGIT
DNSname = DNScomp *( "." DNScomp ) ; see RFC 1035
DNScomp = alphaNum [*(alphaNum /"-") alphaNum]
emailAddress = 1*(alphaNum /"-"/"."/"_") "@" DNSname
alphaNum = DIGIT / ALPHA
specific = *( pchar / ":" ) ; pchar from RFC 3986
</pre>
<p class="issue" title="Internationalization">
The tagURI syntax pchar definition prevents the use of some email
addresses. This should be addressed.
</p>
<pre class="example nohighlight" title="Example tag Method DIDs">
did:tag:example.com,2021:Alice
did:tag:example.com,2021:Bob
did:tag:example.com,2021:user:Alice
did:tag:www.example.com,2021:user:Alice
did:tag:example.com,2021-10-26:C2AVvLMv6gmMNam3uVAjZpfkcJCwD
did:tag:yaml.org,2002:int
did:tag:[email protected],2021:Bob
</pre>
</section>
<section>
<h2>DID method operations</h2>
<section>
<h3>Create (Register)</h3>
<p>Creating a web-accessbile DID is done by:</p>
<ol>
<li>
applying at a domain name registrar for use of a domain name and
</li>
<li>
storing the location of a hosting service, the IP address at a DNS
lookup service
</li>
<li>
creating the DID document JSON-LD file and storing the file under
the <code>.well-known</code> URL to represent the entire domain,
or under the specified path if many DIDs will be resolved in this
domain.
</li>
</ol>
<p>
For example, for the domain name `www.example.com`, the DID document
will be available under the following URL:
</p>
<pre
class="example nohighlight"
title="Creating the web-accessible DID"
>
did:tag:www.example.com,2021:
-> https://www.example.com/.well-known/didtag2021.json
</pre>
<p>
If optional specific data is provided within the tagURI, the DID
Document will be available under the specified path:
</p>
<pre
class="example nohighlight"
title="Creating the web-accessible DID with optional specific data"
>
did:tag:www.example.com,2021:alice
-> https://www.example.com/alice/didtag2021.json
did:tag:www.example.com:user,2021-11-01:user:alice
-> https://w3c-ccg.github.io/user/alice/didtag2021-11-01.json
</pre>
</section>
<section>
<h3>Read (Resolve)</h3>
<section>
<h4>Reading/Resolving a web-accessible DID</h4>
<p>
The following steps MUST be executed to resolve the DID document
from a tag DID whose tagURI authorityName is a DNSname:
</p>
<ol>
<li>Extract the DNSname from the tagURI component.</li>
<li>
Generate an HTTPS URL to the expected location of the DID
document by prepending the DNSname with <code>https://</code>.
</li>
<li>
If the tagURI contains no specific component, append
<code>/.well-known/</code> to the HTTPS URL.
</li>
<li>
if the tagURI contains a specific component, replace all colons
within it with slashes ('/') and append it to the HTTPS URL.
</li>
<li>Append <code>didtag</code> to the string.</li>
<li>Append the date component to the string.</li>
<li>Append <code>.json</code> to complete the URL.</li>
<li>
Perform an HTTP <code>GET</code> request to the URL using an
agent that can successfully negotiate a secure HTTPS connection,
which enforces the security requirements as described in
<a href="#security-and-privacy-considerations"></a>.
</li>
</ol>
When performing the DNS resolution during the HTTP
<code>GET</code> request, the client SHOULD utilize [[RFC8484]] in
order to prevent Man-in-the-middle attacks as well as to prevent
tracking of the lookup.
</section>
<section>
<h4>Resolving a tag DID via email</h4>
<p>
The following steps MUST be executed to resolve the DID document
for a tag DID whose tagURI authorityName is an emailAddress:
</p>
<ol>
<li>Extract the emailAddress from the tagURI.</li>
<li>Replace the at-sign ('@') with <code>+tag@</code></li>
<li>
Send an email message to the modified emailAddress with a
subject line containing the string "RESOLVE: " prepended to the
tag DID.
</li>
<li>
If and when a response is delivered, the DID Document will be
found in an attachment to the response.
</li>
</ol>
<p class="issue" title="Email security">
Should S/MIME [[RFC8551]], PGP [[RFC4880]], DIDComm, or some other
means of sending and receiving signed email messages be identified
or recommended? Should message encryption be encouraged?
</p>
</section>
</section>
<section>
<h3>Update</h3>
<p>
Please note that when a DID document is updated, the DID will remain
the same, but the contents of the DID document will change, e.g., by
including a new verification key or adding service endpoints.
</p>
<p>
Please note that this DID method does not specify any authentication
or authorization mechanism for writing to the DID Document. It is
left to implementations to protect DID documents from unauthorized
modification.
</p>
</section>
<section>
<h3>Deactivate (Revoke)</h3>
<p>
To delete the DID document, it has to be removed or has to be
rendered no longer publicly available due to some other means.
</p>
</section>
</section>
<section class="informative">
<h2>Security and privacy considerations</h2>
<div TBD="">TBD</div>
<section>
<h3>Optional tagURI specific Data Considerations</h3>
<p>
When optional tagURI specific data is used to resolve DID documents
rather than just a bare taggingEntity, verification with signed data
proves that the entity in control of DID document has the private
keys. It neither proves nor implies that the operator of the service
identified by the authorityName has the private keys.
</p>
<p>This example:</p>
<pre class="nohighlight">
did:tag:example.com,2020:u:bob
</pre>
<p>resolves to the DID document at:</p>
<pre class="nohighlight">
https://example.com/u/bob/didtag2020.json
</pre>
<p>
In this scenario, it is probable that example.com has given user Bob
control over the DID in question, and proofs of control refer to Bob
rather than all of example.com.
</p>
</section>
</section>
</section>
<section class="appendix informative">
<h1>Reference implementations</h1>
<p>
A reference implementation will be provided at some future time if there
is any indication that doing so would be useful.
</p>
</section>
</body>
</html>