Skip to content

Commit

Permalink
Informative appendix explaining proof sets and chains: wording, gramm…
Browse files Browse the repository at this point in the history 
…ar, punctuation, and formatting improvements.

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
  • Loading branch information
@Wind4Greg @TallTed @msporny
2 people authored and msporny committed Feb 19, 2024
1 parent 88e1252 commit 5ffd05e
Showing 1 changed file with 81 additions and 79 deletions.
160 changes: 81 additions & 79 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4386,134 +4386,136 @@ <h2>Understanding Proof Sets and Proof Chains</h2>
</p>
<p>
We consider a scenario with three signatories: a CEO, a CFO, and a VP of
Engineering. Each will need to have a public and private key pair for signing a
document. We denote the private/public keys of each of these signatories by
<em>priv/pubCEO</em>, <em>priv/pubCFO</em>, and <em>priv/pubVPE</em>
Engineering. Each will need to have a public key and secret key pair for signing a
document. We denote the secret/public keys of each of these signatories by
<em>secretCEO/pubCEO</em>, <em>secretCFO/pubCFO</em>, and <em>secretVPE/pubVPE</em>,
respectively.
</p>
<p>
When constructing a <em>proof set</em> where each of the signatories signs a
document without concern we construct a proof symbolically as:
document without concern, we construct a proof symbolically as:
</p>
<pre><code class="language-javascript">
{
&quot;type&quot;: &quot;DataIntegrityProof&quot;,
&quot;cryptosuite&quot;: &quot;jcs-eddsa-2022&quot;,
&quot;created&quot;: &quot;2023-03-05T19:23:24Z&quot;,
&quot;proofPurpose&quot;: &quot;assertionMethod&quot;,
&quot;verificationMethod&quot;: pubCEO,
&quot;proofValue&quot;: signature(privCEO, document)
"type": "DataIntegrityProof",
"cryptosuite": "jcs-eddsa-2022",
"created": "2023-03-05T19:23:24Z",
"proofPurpose": "assertionMethod",
"verificationMethod": pubCEO,
"proofValue": signature(secretCEO, document)
}
</code></pre>
<p>
Where <em>pubCEO</em> is used as a placeholder for a reference that resolves to
the CEO's public key and <code>signature(priv, doc)</code> denotes the
the CEO's public key and `signature(secret, doc)` denotes the
computation of a digital signature by a particular data integrity cryptosuite
using a particular private key over a particular document. The <em>type</em>,
using a particular secret key over a particular document. The <em>type</em>,
<em>cryptosuite</em>, <em>created</em>, and <em>proofPurpose</em> attributes do
not factor into our discussion so we will omit them. In particular below we show
not factor into our discussion so we will omit them. In particular, below we show
all the proofs in a <em>proof set</em> on a document that has been signed by the
VP of engineering, CFO, and CEO:
VP of Engineering, the CFO, and the CEO:
</p>
<pre><code class="language-javascript">
{ // Rest of VC document not shown, this proof set will verify
&quot;proof&quot;: [
{&quot;verificationMethod&quot;: pubVPE, &quot;proofValue&quot;: signature(privVPE, document)},
{&quot;verificationMethod&quot;: pubCFO, &quot;proofValue&quot;: signature(privCFO, document)},
{&quot;verificationMethod&quot;: pubCEO, &quot;proofValue&quot;: signature(privCEO, document)}]
{ // Remainder of verifiable credential document not shown; this proof set will verify
"proof": [
{"verificationMethod": pubVPE, "proofValue": signature(secretVPE, document)},
{"verificationMethod": pubCFO, "proofValue": signature(secretCFO, document)},
{"verificationMethod": pubCEO, "proofValue": signature(secretCEO, document)}]
}
</code></pre>
<p>
The <em>holder</em> or any other intermediary receiving a signed VC containing a
A <em>holder</em> or any other intermediary receiving a signed verifiable credential containing a
<em>proof set</em> is able to remove any of the <em>proofs</em> within the set
prior to passing it on to another entity and this VC will still verify. This may
or may not be the intent. For the signatories sending a birthday card to a
valued employee this is probably fine. If we are trying to model a business
process where approvals ascend the company hierarchy this would not be ideal
prior to passing it on to another entity and this verifiable credential will still verify. This might
or might not have been the intent. For the signatories sending a birthday card to a
valued employee, this is probably fine. If we are trying to model a business
process where approvals ascend the company hierarchy, this would not be ideal,
since any intermediary could remove signatures from the <em>proof set</em> and
still have it verify, i.e., below it looks like the CFO and CEO just approved
something without the VP of engineering's concurrence.
still have it verify; for instance, below it looks like the CFO and CEO approved
something without the VP of Engineering's concurrence.
</p>
<pre><code class="language-javascript">
{ // Rest of VC document not shown, this proof set will also verify
&quot;proof&quot;: [
{&quot;verificationMethod&quot;: pubCFO, &quot;proofValue&quot;: signature(privCFO, document)},
{&quot;verificationMethod&quot;: pubCEO, &quot;proofValue&quot;: signature(privCEO, document)}]
{ // Remainder of verifiable credential document not shown; this proof set will also verify
"proof": [
{"verificationMethod": pubCFO, "proofValue": signature(secretCFO, document)},
{"verificationMethod": pubCEO, "proofValue": signature(secretCEO, document)}]
}
</code></pre>
<p>
We can introduce a &quot;dependency relation&quot; between <em>proofs</em> in a
<em>proof set</em> by assigning the proof that another proof relies on, i.e.,
the <em>dependent proof</em>, an <em>id</em> and the <em>relying proof</em> will
have a list (or single item) denoting <em>previousProofs</em>. Such
We can introduce a "dependency relation" between <em>proofs</em> in a
<em>proof set</em> by assigning an <em>id</em> to each proof that another
proof relies on, i.e., each <em>dependent proof</em>, and the <em>relying proof</em>
will have a list (or single item) denoting <em>previousProofs</em>. Such
<em>dependency chains</em> can have arbitrary depth. The <strong>intent</strong>
of such a <em>proof chain</em> is to model an approval chain in a business
process or a notary witnessing analog signatures. In such cases we CANNOT allow
the <em>proofs</em> that are relied upon to be <strong>substituted</strong> with
other proofs or removed.
process or a notary witnessing analog signatures. Implementers are cautioned
against allowing <em>supporting proofs</em> to be removed or
<strong>substituted</strong> by other proofs.
</p>
<p>
Let's see how a <em>proof chain</em> is constructed where the VP of Engineering
signs off on the document first, based on the VP of engineering's signature and
a review the CFO then signs off of the document, finally based on both the prior
signatures and a review the CEO signs off on the document. Since others will be
referring to the VP of engineering's signature we need to add a <em>id</em> to
the proof options. First the VC of engineering signs the VC:
Let's see how a <em>proof chain</em> is constructed when the VP of Engineering
signs off on the document first; based on the VP of Engineering's signature and
a review, the CFO then signs off on the document; and finally, based on both prior
signatures and a review, the CEO signs off on the document. Since others will be
referring to the VP of Engineering's signature, we need to add an <em>id</em> to
the proof options. First the VP of Engineering signs the verifiable credential:
</p>
<pre><code class="language-javascript">
{ // Rest of VC document not shown, this proof set will verify
&quot;proof&quot;: {&quot;id&quot;: &quot;urn:proof-0&quot;, &quot;verificationMethod&quot;: pubVPE,
&quot;proofValue&quot;: signature(privVPE, document)}
{ // Remainder of verifiable credential document not shown; this proof set will verify
"proof": {&quot;id&quot;: "urn:proof-0", "verificationMethod": pubVPE,
"proofValue": signature(privateVPE, document)}
}
</code></pre>
<p>
Next, the CFO receives the document, verifies that the VP of engineering signed
it and signs it based on a review and on the VP of Engineering signing. For this
Next, the CFO receives the document, verifies that the VP of Engineering signed
it, and signs it based on a review and on the signature of the VP of Engineering. For this,
we need to set up the <em>proof chain</em> by indicating a dependency on the
proof in the document just received, i.e.,
<code>previousProof = &quot;urn:proof-0&quot;</code>. The
processing algorithm has us &quot;bind&quot; the previous proof to the unsigned
document. Denote the this proof by <em>proof0</em> and &quot;binding&quot; this
information to the document by <code>document + proof0</code>:
`previousProof = "urn:proof-0"`. The
processing algorithm has us "bind" the previous proof to the unsigned
document. Denote the dependency on this proof by <em>proof0</em> and "binding" this
information to the document by `document + proof0`:
</p>
<pre><code class="language-javascript">
{ // Rest of VC document not shown
&quot;proof&quot;: [
{&quot;id&quot;: &quot;urn:proof-0&quot;, &quot;verificationMethod&quot;: pubVPE,
&quot;proofValue&quot;: signature(VP_Eng, document)},
{&quot;id&quot;: &quot;urn:proof-1&quot;, &quot;verificationMethod&quot;: pubCFO, &quot;previousProof&quot;: &quot;urn:proof-0&quot;,
&quot;proofValue&quot;: signature(privCFO, document + proof0)}]
{ // Remainder of verifiable credential document not shown
"proof": [
{"id": "urn:proof-0", "verificationMethod": pubVPE,
"proofValue": signature(VP_Eng, document)},
{"id": "urn:proof-1", "verificationMethod": pubCFO, "previousProof": "urn:proof-0",
"proofValue": signature(secretCFO, document + proof0)}]
}
</code></pre>
<p>
Now when the CEO validates the received the VC with the above <em>proof
chain</em> they will check that the CFO signed based on the VP of Engineering
signing it. First, they will check the proof/signature with
<code>id = 0</code> against the public key of the VP of Engineering. Note that
this proof/signature is over the original document. Next, the CEO will check
the proof/signature <code>id = &quot;urn:proof-1&quot;</code> against the public
key of the CFO.
However, to make sure that the CFO signed with the document knowing, and with
proof, that the VP of engineering signed we verify this signature/proof over
Now, when the CEO validates the received the verifiable credential with the above <em>proof
chain</em>, they will check that the CFO signed based on the signature of the
VP of Engineering. First, they will check the proof/signature with
`id = 0` against the public key of the VP of Engineering. Note that
this proof/signature is over the original document.
</p>
<p>
Next, the CEO will check the proof/signature `id = "urn:proof-1"` against the
public key of the CFO. However, to make sure that the CFO signed with the
document knowing, and with proof, that the VP of engineering signed we verify
this signature/proof over
the combination of the document and <em>proof0</em>. If validation is
successful the CEO signs producing a proof over the document and
<em>proof1</em> (the proof with <code>id = &quot;urn:proof-1&quot;</code>).
The final signed chain looks like:
successful, the CEO signs producing a proof over the document and
<em>proof1</em> (the proof with `id = "urn:proof-1"`).
The final signed chain looks like this:
</p>
<pre><code class="language-javascript">
{ // Rest of VC document not shown
&quot;proof&quot;: [
{&quot;id&quot;: &quot;urn:proof-0&quot;, &quot;verificationMethod&quot;: pubVPE,
&quot;proofValue&quot;: signature(VP_Eng, document)},
{&quot;id&quot;: &quot;urn:proof-1&quot;, &quot;verificationMethod&quot;: pubCFO, &quot;previousProof&quot;: &quot;urn:proof-0&quot;,
proofValue: signature(privCFO, document + proof0)},
{&quot;id&quot;: &quot;urn:proof-2&quot;, &quot;verificationMethod&quot;: pubCEO, &quot;previousProof&quot;: &quot;urn:proof-1&quot;,
&quot;proofValue&quot;: signature(privCEO, document + proof1)},
{ // Remainder of verifiable credential document not shown
"proof": [
{"id": "urn:proof-0", "verificationMethod": pubVPE,
"proofValue": signature(VP_Eng, document)},
{"id": "urn:proof-1", "verificationMethod": pubCFO, "previousProof": "urn:proof-0",
"proofValue": signature(secretCFO, document + proof0)},
{"id": "urn:proof-2", "verificationMethod": pubCEO, "previousProof": "urn:proof-1",
"proofValue": signature(secretCEO, document + proof1)},
]
}
</code></pre>
<p>
The recipient of this VC then validates it in a similar way as above but with one extra step.
The recipient of this verifiable credential then validates it in a similar way as above, but with one extra step.
</p>
</section>

Expand Down

0 comments on commit 5ffd05e

Please sign in to comment.