This repository has been archived by the owner on Apr 29, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1
/
index.html
369 lines (364 loc) · 16.9 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
<!DOCTYPE html>
<html>
<head>
<meta charset='utf-8'>
<title>Doge DID Method Specification</title>
<script
src='https://www.w3.org/Tools/respec/respec-w3c-common'
class='remove'></script>
<script class='remove'>
const respecConfig = {
specStatus: "unofficial",
editors: [{
name: "Wayne Chang",
url: "https://spruceid.com",
}, {
name: "Gregory Rocco",
url: "https://spruceid.com",
},
],
processVersion: 2017,
edDraftURI: "https://github.com/spruceid/did-doge",
shortName: "did-doge",
logos: [{
src: "./docs/dogeDID.png",
url: "./docs/dogeDID.png",
alt: "doge DID",
width: 100,
height: 42,
id: "doge DID",
}]
};
</script>
</head>
<body>
<section id='abstract'>
<p> This specification defines a DID method (did:doge) that supports DIDs
based on the public <a href="https://dogecoin.com/">Dogecoin</a>
blockchain. Dogecoin is an open-source is a cryptocurrency,
blockchain, and payment system that is instant, fun, and free from
traditional banking fees.</p>
</section>
<section id='sotd'></section>
<!-- introduction -->
<section class='informative'> <!-- h2 -->
<h2>Introduction</h2>
<section>
<h3>Prior Work and Enhancements</h3>
<p> We draw heavily from prior work by Christopher Allen and Kim Hamilton
Duffy within the W3C Credentials Community Group on the <a
href="https://w3c-ccg.github.io/didm-btcr/">BTCR DID Method</a> due to
strong architectural similarities between the Bitcoin and Dogecoin
blockchains.</p>
<p> However, there are some key differences that enable new
privacy-preserving benefits. Namely, the did:doge method-specific
identifier is the Base58Check-encoded Dogecoin address itself, allowing
for DID usage even in the absence of any public transaction histories
and only relying upon them for rotation events for verification methods
and service endpoints. This specification defines the resolution of the
did:doge method-specific identifier to an optional "genesis" transaction
for DID document updates, which then follows the linear transaction
history "tip" in the same style of did:btcr using "update" transactions.
<p> In summary, while did:btcr requires a cleared transaction prior to
first use, did:doge does not, allowing users use of decentralized
identifiers even if they do not own cryptocurrencies.</p>
</section> <!-- h3 -->
</section> <!-- h2 -->
<section>
<h2>Core Concepts</h2>
<section>
<h3>Doge DID Scheme</h3>
<p> The namestring that shall identify this DID method is: <code>doge</code>.
A DID that uses this method MUST begin with the prefix
<code>did:doge</code>. As per the DID specification, this string MUST be
in lowercase.</p>
<p> The full Doge DID scheme is defined by the following
<a href="https://tools.ietf.org/html/std68">ABNF</a>:</p>
<pre><code>
doge-did = "did:doge:" address
address = "D" 33*33base58-char
base58-char = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
"A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "J" / "K" /
"L" / "M" / "N" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" /
"W" / "X" / "Y" / "Z" /
"a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" /
"k" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" /
"v" / "w" / "x" / "y" / "z"
</code></pre>
<p> All Doge DID method-specific identifiers are Dogecoin addresses,
which are Base58Check encoded P2PKH and P2SH prefixed by a
<code>"D"</code>.</p>
<p> Example Doge DID: <code>did:doge:DH5yaieqoZN36fDVciNyRueRGvGLR3mr7L</code>.</p>
</section>
<section>
<h3>Implicit Resolution</h3>
<p> Every Dogecoin address, whether it has a transaction on the public
Dogecoin blockchain or not, is a valid did:doge by default. If a
Dogecoin address does not have any did:doge genesis transactions,
then a DID resolver MUST generate a default DID Document using the
Dogecoin address as its only input into the following template,
substituting the input for the placeholder <code>[DOGECOIN_ADDRESS]</code>:</p>
<pre class='example'>
{
"@context": ["https://w3id.org/did", "https://w3id.org/doge/v1"],
"id": "did:doge:[DOGECOIN_ADDRESS]",
"publicKey": [
{
"id": "did:doge:[DOGECOIN_ADDRESS]#wow",
"controller": "did:doge:[DOGECOIN_ADDRESS]",
"type": "EcdsaSecp256k1RecoverySignature2020",
"dogecoinAddress": "[DOGECOIN_ADDRESS]"
},
{
"id": "did:doge:[DOGECOIN_ADDRESS]#vckey-0",
"controller": "did:doge:[DOGECOIN_ADDRESS]",
"type": "EcdsaSecp256k1RecoverySignature2020",
"dogecoinAddress": "[DOGECOIN_ADDRESS]"
}
],
"authentication": ["#wow"],
"assertionMethod": ["#vckey-0"]
}
</pre>
<p> A resolver MUST search the Dogecoin public blockchain exhaustively for
did:doge genesis transactions as part of implicit resolution.</p>
</section>
<section>
<h3>did:doge Genesis Transactions</h3>
<p> To initiate key and service input rotations, a did:doge DID controller
MUST sign and clear a transaction to the public Dogecoin blockchain
conforming to the following requirements.</p>
<ol>
<li>The transaction MUST contain in the <code>scriptSig</code> within the
<code>txin</code> at index 0 a valid P2PKH unlocking Script with a
public key corresponding to the did:doge method-specific identifier
when interpreted as a Dogecoin address.</li>
<li>The transaction MAY contain other <code>txin</code> entries as
necessary for paying transaction fees.</li>
<li>The transaction MUST contain in the <code>scriptPubKey</code> within
the <code>txout</code> at index 0 a valid P2PKH locking Script with the
corresponding Dogecoin address's <code>pubKeyHash</code> as the
recipient, specifically by substituting the
<code>publicKeyHash</code> for the placeholder
<code>[DOGECOIN_ADDRESS_PKH]</code> in the Script template:
<pre class='example'>
OP_DUP
OP_HASH160
[DOGECOIN_ADDRESS_PKH]
OP_EQUALVERIFY
OP_CHECKSIG
</pre>
</li>
<li>The transaction MUST contain in the <code>scriptPubKey</code> within
the <code>txout</code> at index 1 the following Script exactly:
<pre class='example'>
OP_RETURN OP_PUSHBYTES_49
5468652054696d65732032372f4a616e2f32303231202744756d62204d6f6e657927204973206f6e2047616d6553746f70
</pre>
This unique value is meant to signify an intentful did:doge genesis
transaction, and has been selected because it has not been used
previously to this specification's existence.
</li>
<li>The transaction MAY contain other <code>txout</code> entries.</li>
</ol>
<p> The did:doge genesis transaction is defined as the transaction matching
the criteria above found on the public Dogecoin blockchain with the
lowest block height, and in the case of multiple matching transactions
in the same block, the most preceding transaction in the transaction
list.</p>
</section>
<section>
<h3>did:doge Update Transactions</h3>
<p> To conduct key and service input rotations using did:doge update
transactions for a DID, there must exist a corresponding did:doge genesis
transaction as specified in the previous section. A did:doge update
transaction MUST be produced in the manner described below and cleared on
the public Dogecoin blockchain.</p>
<ol>
<li>The transaction MUST contain in the <code>scriptSig</code> within the
<code>txin</code> at index 0 a valid P2PKH unlocking Script with a
public key corresponding to the did:doge method-specific identifier
when interpreted as a Dogecoin address. Furthermore, the
<code>txin</code> at index 0 MUST refer to the <code>OutPoint</code> of
of a valid did:doge genesis transaction or valid did:doge update
transaction.</li>
<li>The transaction MAY contain other <code>txin</code> entries as
necessary for paying transaction fees.</li>
<li>The transaction MUST contain in the <code>scriptPubKey</code> within
the <code>txout</code> at index 0 a P2PKH locking Script with the
next did:doge active keypair's corresponding <code>pubKeyHash</code> as
the recipient, specifically by substituting the
<code>publicKeyHash</code> for the placeholder
<code>[NEXT_ACTIVE_KEY_PKH]</code> in the Script template:
<pre class='example'>
OP_DUP
OP_HASH160
[NEXT_ACTIVE_KEY_PKH]
OP_EQUALVERIFY
OP_CHECKSIG
</pre>
The next did:doge active keypair MAY be the current did:doge active keypair.
</li>
<li>The transaction MUST contain in the <code>scriptPubKey</code> within
the <code>txout</code> at index 1 the following Script template,
substituing a desired service endpoint URI encoded as hex (no longer
than 79 bytes) for <code>[SERVICE_ENDPOINT_URI]</code> and the decimal
length of the URI in bytes for <code>[NUM_BYTES]</code>:
<pre class='example'>
OP_RETURN OP_PUSHBYTES_[NUM_BYTES] [SERVICE_ENDPOINT_URI]
</pre>
If no service endpoint is desired, an empty value MAY be chosen for
<code>[SERVICE_ENDPOINT_URI]</code>. The <code>OP_RETURN</code>
instruction MUST be included, otherwise this transaction will be
considered a did:doge deactivation transaction instead, permanently and
irreversibly deactivating the DID.
</li>
<li>The transaction MAY contain other <code>txout</code> entries.</li>
</ol>
</section>
<section>
<h3>did:doge Deactivation Transactions</h3>
<p> To deactivate a DID permanently and irreversibly, there must first exist
a corresponding did:doge genesis transaction as specified in the previous
section. There MAY also exist did:doge update transactions. To deactivate
the DID, a deactivation transaction MUST be produced in the manner
described below and cleared on the public Dogecoin blockchain.</p>
<ol>
<li>The transaction MUST contain in the <code>scriptSig</code> within the
<code>txin</code> at index 0 a valid P2PKH unlocking Script with a
public key corresponding to the did:doge method-specific identifier
when interpreted as a Dogecoin address. Furthermore, the
<code>txin</code> at index 0 MUST refer to the <code>OutPoint</code> of
of a valid did:doge genesis transaction or valid did:doge update
transaction.</li>
<li>The transaction MAY contain other <code>txin</code> entries as
necessary for paying transaction fees.</li>
<li>The transaction MAY contain other <code>txout</code> entries. However,
the transaction MUST NOT contain the Script instruction
<code>OP_RETURN</code> within the <code>scriptPubKey</code> of any of
its <code>txout</code> entries.
</li>
</ol>
</section>
<section>
<h3>Additional Terminology</h3>
<p> The <dfn>following did:doge update transaction</dfn> with respect to a
did:doge genesis transaction or did:doge update transaction is defined as
the conforming did:doge update transaction on the public Dogecoin
blockchain that uses the current transaction's <code>txout</code> at
index 0 as its <code>txin</code> at index 0.</p>
<p> The <dfn>did:doge active update transaction</dfn> is the last
transaction obtained by starting at a did:doge genesis transaction or
did:doge update transaction and recursively identifying the following
did:doge update transaction until none exists.</p>
<p> The <dfn>did:doge active keypair</dfn> is the corresponding keypair to
the signature produced via private key signing of the did:doge active
update transaction, or the corresponding keypair to the DID
method-specific identifier if no update transactions exist.</p>
<p> The <dfn>did:doge active service endpoint</dfn> is the parameter of
<code>OP_RETURN</code> in the <code>scriptPubKey</code> of the
<code>txout</code> at index 1 of the did:doge active update
transaction, or it is empty if no update transactions exist or the
<code>OP_RETURN</code> has no following data.</p>
</p>
</section>
</section> <!-- h2 -->
<section>
<h2>Operations</h2>
<section>
<h3>Create (Register)</h3>
<p> Doge DIDs exist per each Dogecoin address by default.</p>
<p> However, to enable key rotation and specification of a service
endpoint, the following steps MUST be followed:</p>
<ol>
<li>Ensure no valid did:doge genesis transactions exist.</li>
<li>Construct a did:doge genesis transaction for desired DID as described
in Section 2.3.</li>
</ol>
</section>
<section>
<h3>Read (Resolve)</h3>
<p> To resolve a did:doge DID, the following steps MUST be followed:</p>
<ol>
<li>Search the public Dogecoin blockchain exhaustively for a did:doge
genesis transaction as defined in Section 2.3.
<li>If the did:doge genesis transaction does not exist, then resolve the
DID document implicitly as specified in 2.2. At this point,
resolution is considered to be completed successfully and any
additional steps MUST NOT be followed.</li>
<li>If the did:doge deactivation transaction exists, then the DID is
considered deactivated, resolution is considered to be a failure, and
any additional steps MUST NOT be followed.</li>
<li>Construct a DID document substituting the Dogecoin address
corresponding to the did:doge active keypair (as defined in 2.5) in
the template specified within 2.2.</li>
<li>If the did:doge active service endpoint exists, define a single
service endpoint within the DID document, populating the
<code>id</code> with <code>did:doge:[DOGECOIN_ADDRESS]#service</code>
(where <code>[DOGECOIN_ADDRESS]</code> is the Dogecoin address
corresponding to the method-specific identifier), <code>type</code>
with <code>DidDogeService</code>, and <code>serviceEndpoint</code> of
the did:doge active service endpoint.</li>
</ol>
</section>
<section>
<h3>Update (Replace)</h3>
<p> To update a did:doge DID document, the following steps MUST be
followed.</p>
<ol>
<li>Ensure that a did:doge genesis transaction exists.</li>
<li>Construct a did:doge update transaction as described in 2.4
referencing the did:doge active update transaction, or the did:doge
genesis transaction if none exists, in its <code>txin</code> at index
0.</li>
</ol>
</section>
<section>
<h3>Delete (Revoke)</h3>
<p> To deactivate a did:doge DID, the following steps MUST be followed.</p>
<ol>
<li>Ensure that a did:doge genesis transaction exists.</li>
<li>Construct a did:doge deactivation transaction as described in 2.5
referencing the did:doge active update transaction, or the did:doge
genesis transaction if none exists, in its <code>txin</code> at index
0.</li>
</ol>
</section>
</section>
<section>
<h2>Security & Privacy</h2>
<section>
<h3>Security Considerations</h3>
<p> DID method specifications MUST include their own Security
Considerations sections. This section MUST consider all the
requirements mentioned in section 5 of [RFC3552] (page 27) for the DID
operations defined in the specification, including eavesdropping,
replay, message insertion, deletion, modification, and
man-in-the-middle. Potential denial of service attacks MUST be
identified as well.</p>
<p> A full list of requirements for this section may be found at
<a href="https://www.w3.org/TR/did-core/#security-requirements">
W3C Decentralized Identifiers 7.3</a></p>
</section>
<section>
<h3>Privacy Considerations</h3>
<p> DID method specifications MUST include their own Privacy Considerations
sections to discuss any subsection of section 5 of [RFC6973] that could
apply in a method-specific manner. The subsections to consider are:
surveillance, stored data compromise, unsolicited traffic, misattribution,
correlation, identification, secondary use, disclosure, exclusion.</p>
<p> A full list of requirements for this section may be found at
<a href="https://www.w3.org/TR/did-core/#privacy-requirements">
W3C Decentralized Identifiers 7.4</a></p>
</section>
</section>
<section>
<h2>Reference Implementations</h2>
<p> Spruce Systems, Inc. is developing a referencing implementation in Rust
at <a href="https://github.com/spruceid/did-doge/">github.com/spruceid/did-doge</a>.</p>
</section>
<section>
<h2>Resources</h2>
</section>
</body>
</html>