Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Method 2 #26

Merged
merged 6 commits into from Mar 20, 2021
Merged

Method 2 #26

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
f97b972
Method 3 Initial
TelegramSam Jan 14, 2021
593cb53
Full Multi-key Example
TelegramSam Jan 16, 2021
0b41731
Added purpose indicators
TelegramSam Feb 10, 2021
712abc2
Addition of endpoints
TelegramSam Feb 19, 2021
07e6fd3
fixed service encoding
TelegramSam Mar 6, 2021
0b8a06b
Update core.html
TelegramSam Mar 19, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
118 changes: 116 additions & 2 deletions core.html
View file
Open in desktop
Expand Up @@ -35,7 +35,7 @@ <h2>Method Specific Identifier</h2>
<p>The peer DID scheme is defined by the following ABNF (see [[RFC5234]] for syntax):</p>
<pre class="example" class="ABNF" title="ABNF for peer DIDs">
peer-did = "did:peer:" numalgo transform encnumbasis
numalgo = "0" / "1"
numalgo = "0" / "1" / "2"
transform = "z"
encnumbasis = 46*BASE58BTC
</pre>
Expand Down Expand Up @@ -84,7 +84,7 @@ <h2>Method Specific Identifier</h2>
<section class="normative">
<h2>Generation Method</h2>

<p>The unique <em>numeric basis</em> underlying a Peer DID MUST be generated in one of the following two ways:</p>
<p>The unique <em>numeric basis</em> underlying a Peer DID MUST be generated in one of the following ways:</p>

<h3>Method 0: inception key without doc</h3>
<p>If <code>numalgo</code> == <code>0</code>, a single keypair is chosen, having all possible privileges with respect
Expand Down Expand Up @@ -137,6 +137,120 @@ <h3>Method 1: genesis doc</h3>
is susceptible to attacks early in the DID's lifecycle. See <a target="_blank"
href="https://github.com/openssi/peer-did-method-spec/issues/112">this github issue</a> for more discussion.
</p>

<h3>Method 2: multiple inception key without doc</h3>
<p>If <code>numalgo</code> == <code>2</code>, the generation mode is similar to Method 0 (and therefore also did:key)
with the ability to specify additional keys in the generated DID Document. This method is necessary when both an encryption
key and a signing key are required.</p>

<pre class="example" class="ABNF" title="ABNF for peer DIDs">
peer-did-method-2 = "did:peer:2" 1*elment
element = "." ( purposecode transform encnumbasis / service )
purposecode = "A" / "E" / "V" / "I" / "D" / "S"
keypurpose =
transform = "z"
encnumbasis = 46*BASE58BTC
service = "S" 1*B64URL
</pre>

<ul>
<li>Start with the did prefix <pre>did:peer:2</pre></li>
<li>Construct a multibase encoded, multicodec-encoded form of each public key to be included.</li>
<li>Prefix each encoded key with a period character (.) and single character from the purpose codes table below.</li>
<li>Append the encoded key to the DID.</li>
<li>Encode and append a service type if desired as described below.</li>
</ul>
<p>Service encoding</p>
<ul>
<li>Start with the JSON structure for your service.</li>
<li>Replace common strings in key names and type value with appreviations from the abbreviations table below.</li>
<li>Convert to string, and remove unnecessary whitespace, such as spaces and newlines.</li>
<li>Base64URL Encode String</li>
<li>Add the period (.) and S (for the service) </li>
</ul>

<p>Service decoding</p>
<ul>
<li>Remove the period (.) and S prefix</li>
<li>Base64URL Decode String</li>
<li>Parse as JSON.</li>
<li>Replace abbreviations in key names and type value with common names from the abbreviations table below.</li>
<li>Add id attribute according to the form <pre><did>#service<type></li>
</ul>

<p>Common String Abbreviations</p>
<table>
<tr><th>Common String</th><th>Abbreviation</th></tr>
<tr><td>type</td><td>t</td></tr>
<tr><td>didcommmessaging</td><td>dm</td></tr>
<tr><td>serviceEndpoint</td><td>s</td></tr>
<tr><td>routingKeys</td><td>r</td></tr>
</table>


<p>Purpose Code List</p>
<ul>
<li><b>A</b> - Assertion</li>
<li><b>E</b> - Encryption (Key Agreement)</li>
<li><b>V</b> - Verification</li>
<li><b>I</b> - Capability Invocation</li>
<li><b>D</b> - Capability Delegation</li>
<li><b>S</b> - Service</li>
</ul>

<pre class="example nohighlight" title="Example Multi-key Peer DID" id="multi-key-creation">
Encoded Encryption Key: .Ez6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH
Encoded Signing Key: .VzXwpBnMdCm1cLmKuzgESn29nqnonp1ioqrQMRHNsmjMyppzx8xB2pv7cw8q1PdDacSrdWE3dtB9f7Nxk886mdzNFoPtY
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you taken any consideration into how you would encode an uncompressed public key? For example, P-256 keys often include both an x and y coordinate rather than using a compressed form made possible with Ed25519 keys. In the case where the key is 2 coordinate points can we specify how ordering of the points should be handled? Additionally with RSA keys do we want to assume that the exponent ("e" in JWK) would always be "AQAB" and that the encoded value will always be the modulus parameter (n in a JWK)? Some more info on how to encode different key types would help here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

using multi-base multi-codec keys allows us to support any key that can be encoded in those methods. Is that not sufficient?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've not found anywhere that defines how it should work. Can you point me to where you're finding them defining how those questions are specified? Even Ed25519/X25519 keys are not defined well anywhere from what I can find. All of the multicodec bytes are registered, but I can't find anywhere that specifies things for the questions I raised.

Service Block:
{
"type": "didcommmessaging",
"serviceEndpoint": "https://example.com/endpoint",
"routingKeys": ["did:example:somemediator#somekey"]
}
Service Block, after whitespace removal and common word substitution:
{"t":"dm","s":"https://example.com/endpoint","r":["did:example:somemediator#somekey"]}
Encoded Service Endpoint: .SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9lbmRwb2ludCIsInIiOlsiZGlkOmV4YW1wbGU6c29tZW1lZGlhdG9yI3NvbWVrZXkiXX0=
Method 3 peer DID: did:peer:2.Ez6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH.VzXwpBnMdCm1cLmKuzgESn29nqnonp1ioqrQMRHNsmjMyppzx8xB2pv7cw8q1PdDacSrdWE3dtB9f7Nxk886mdzNFoPtY.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9lbmRwb2ludCIsInIiOlsiZGlkOmV4YW1wbGU6c29tZW1lZGlhdG9yI3NvbWVrZXkiXX0=
</pre>


<p>When Resolving the peer DID into a DID Document, the process is reversed.</p>
<ul>
<li>Split the DID string into element.</li>
<li>Extract element purpose and decode each key or service.</li>
<li>Insert each key or service into the document according to the designated purpose.</li>
</ul>

<pre class="example" title="Example Multi-key Peer DID" id="multi-key-creation">
{
"@context": "https://w3id.org/did/v1",
"id": "did:peer:2.Ez6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH.VzXwpBnMdCm1cLmKuzgESn29nqnonp1ioqrQMRHNsmjMyppzx8xB2pv7cw8q1PdDacSrdWE3dtB9f7Nxk886mdzNFoPtY.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9lbmRwb2ludCIsInIiOlsiZGlkOmV4YW1wbGU6c29tZW1lZGlhdG9yI3NvbWVrZXkiXX0=",
"authentication": [{
"id": "did:peer:2.Ez6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH.VzXwpBnMdCm1cLmKuzgESn29nqnonp1ioqrQMRHNsmjMyppzx8xB2pv7cw8q1PdDacSrdWE3dtB9f7Nxk886mdzNFoPtY.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9lbmRwb2ludCIsInIiOlsiZGlkOmV4YW1wbGU6c29tZW1lZGlhdG9yI3NvbWVrZXkiXX0=#Vz6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
"type": "JsonWebKey2020",
"controller": "did:peer:2.Ez6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH.VzXwpBnMdCm1cLmKuzgESn29nqnonp1ioqrQMRHNsmjMyppzx8xB2pv7cw8q1PdDacSrdWE3dtB9f7Nxk886mdzNFoPtY.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9lbmRwb2ludCIsInIiOlsiZGlkOmV4YW1wbGU6c29tZW1lZGlhdG9yI3NvbWVrZXkiXX0=",
"publicKeyJwk": {
"kty": "EC",
"crv": "P-256",
"x": "38M1FDts7Oea7urmseiugGW7tWc3mLpJh6rKe7xINZ8",
"y": "nDQW6XZ7b_u2Sy9slofYLlG03sOEoug3I0aAPQ0exs4"
}
}],
"keyAgreement": [{
"id": "did:peer:2.Ez6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH.VzXwpBnMdCm1cLmKuzgESn29nqnonp1ioqrQMRHNsmjMyppzx8xB2pv7cw8q1PdDacSrdWE3dtB9f7Nxk886mdzNFoPtY.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9lbmRwb2ludCIsInIiOlsiZGlkOmV4YW1wbGU6c29tZW1lZGlhdG9yI3NvbWVrZXkiXX0=#EzXwpBnMdCm1cLmKuzgESn29nqnonp1ioqrQMRHNsmjMyppzx8xB2pv7cw8q1PdDacSrdWE3dtB9f7Nxk886mdzNFoPtY",
"type": "X25519KeyAgreementKey2019",
"controller": "did:peer:2.Ez6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH.VzXwpBnMdCm1cLmKuzgESn29nqnonp1ioqrQMRHNsmjMyppzx8xB2pv7cw8q1PdDacSrdWE3dtB9f7Nxk886mdzNFoPtY.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9lbmRwb2ludCIsInIiOlsiZGlkOmV4YW1wbGU6c29tZW1lZGlhdG9yI3NvbWVrZXkiXX0=",
"publicKeyBase58": "JhNWeSVLMYccCk7iopQW4guaSJTojqpMEELgSLhKwRr"
}],
"service": [{
"id": "did:peer:2.Ez6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH.VzXwpBnMdCm1cLmKuzgESn29nqnonp1ioqrQMRHNsmjMyppzx8xB2pv7cw8q1PdDacSrdWE3dtB9f7Nxk886mdzNFoPtY.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9lbmRwb2ludCIsInIiOlsiZGlkOmV4YW1wbGU6c29tZW1lZGlhdG9yI3NvbWVrZXkiXX0=#didcommmessaging",
"type": "didcommmessaging",
"serviceEndpoint": "https://example.com/endpoint",
"routingKeys": ["did:example:somemediator#somekey"]
}]
}
</pre>

</section>

<section class="informative">
Expand Down