Skip to content

Commit

Permalink
Describe Christian L's suggested method of deriving DID value
Browse files Browse the repository at this point in the history 
Signed-off-by: Daniel Hardman <[email protected]>
  • Loading branch information
@dhh1128
dhh1128 committed May 8, 2019
1 parent 20d6df1 commit c807027
Showing 1 changed file with 21 additions and 13 deletions.
34 changes: 21 additions & 13 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -198,8 +198,7 @@ <h3>Namespace Specific Identifier (NSI)</h3>
<p><a name="gen_method"></a>
The Peer DID scheme is defined by the following <a href="ftp://ftp.rfc-editor.org/in-notes/std/std68.txt">ABNF</a>:<br><br>
<code>
peer-did = "did:peer:" keyfmtchar ":" idstring<br>
keyfmtchar = "1"<br>
peer-did = "did:peer:" idstring<br>
idstring = 21*22base58char<br>
base58char = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "A" / "B" / "C"<br/>
&nbsp;&nbsp;&nbsp;&nbsp;/ "D" / "E" / "F" / "G" / "H" / "J" / "K" / "L" / "M" / "N" / "P" / "Q"<br/>
Expand All @@ -220,22 +219,31 @@ <h3>Namespace Specific Identifier (NSI)</h3>
</section>
<section>
<h3>Namestring Generation Method</h3>
<p>The unique numeric value underlying a Peer DID MUST be generated by using a cryptographically robust
algorithm with secure randomness to create an Ed25519 keypair (or, when additional formats are supported,
an analogous keypair on a different curve), and then selecting as the NSI a subset of the public
verification key that is at least 128 bits, and that is dependent on <code>keyfmtchar</code>. For
<code>keyfmtchar</code> = "1", the NSI = the most significant 16 bytes of the public verification key.</p>
<p>In this way, the DID can be known to begin its existence already associated with keys, and the owner
of the new DID is guaranteed to be the only entity in the world who possesses the private key.
This guarantees the initial integrity of the DID's chain of custody.
</p>
<p>The unique numeric value underlying a Peer DID MUST be generated as follows:</p>
<ul>
<li>Create a <em>genesis</em> version of the DID Doc for the DID. The genesis version must include at
least one public key.</li>
<li>In the <code>id</code> field of the DID Doc, insert the special reserved string <code>thisdid</code>.
This creates a variant of the peer DID doc known as the <em>stored variant</em>, as opposed to the
<em>resolved variant</em> that would have an actual DID value in the <code>id</code> field.</li>
<li>Calculate the SHA256 hash of the bytes of the stored variant of the DID Doc, and select the first 16
bytes of the result as the DID's numeric value.</li>
</ul>
<p>By basing the numeric value of the DID on the genesis version of the DID Doc, the DID can begin its
lifecycle with any number of keys and endpoints, and when the doc is signed or auth-encrypted by one of
the keys, the recipient can know it has not been modified since creation. The guarantees the initial
integrity of the DID's chain of custody.</p>
<p>By using using <code>thisdid</code> and hashing the stored variant, we avoid the circular problem of
including the DID in the data that's being hashed. This means that a peer DID doc must be resolved by
converting the stored variant into a resolved variant by replacing <code>thisdid</code> with the
value of the DID being resolved, during resolution.</p>
</section>
<section>
<h3>Examples</h3>
<p>A convenient regex to match <code>peer</code> DIDs is: <br><br>
<code>^did:peer:1:[1-9A-HJ-NP-Za-km-z]{21,22}$</code>.
<code>^did:peer:[1-9A-HJ-NP-Za-km-z]{21,22}$</code>.
</p>
<p>A valid <code>peer</code> DID might be: <code>did:peer:1:YTEFYzByfU2RwJPyULfLLn</code>.</p>
<p>A valid <code>peer</code> DID might be: <code>did:peer:YTEFYzByfU2RwJPyULfLLn</code>.</p>
</section>
</section>
<section>
Expand Down

0 comments on commit c807027

Please sign in to comment.