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

Correct layering violations related to the proof property #1397

Merged
merged 16 commits into from
Jan 12, 2024
Merged
Show file tree
Hide file tree
Changes from 11 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 22 additions & 45 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -1226,7 +1226,7 @@ <h3>Contexts</h3>
</dd>
</dl>
<p class="note">
This specification requires for a `@context` [=property=]
This specification requires a `@context` [=property=]
to be present; this property is defined by [[JSON-LD11]].
</p>
<pre class="example nohighlight" title="Usage of the @context property">
Expand Down Expand Up @@ -1467,16 +1467,6 @@ <h3>Types</h3>
</td>
</tr>

<tr>
<td>
<a href="#proofs-signatures">Proof</a>&nbsp;object
</td>
<td>
A valid proof [=type=]. For example,<br>
`"type": "DataIntegrityProof"`
</td>
</tr>

<tr>
<td>
<a href="#status">credentialStatus</a>&nbsp;object
Expand Down Expand Up @@ -2331,7 +2321,7 @@ <h3>Presentations</h3>
The example below shows a [=verifiable presentation=]:
</p>

<pre class="example nohighlight" title="Basic structure of a presentation">
<pre class="example nohighlight" title="Basic structure of a presentation secured with Data Integrity">
Copy link
Member

Choose a reason for hiding this comment

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

I do not think it is necessary for this example. Example 18 does not use any proof mechanisms, so the reference to DI looks irrelevant.

selfissued marked this conversation as resolved.
Show resolved Hide resolved
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
Expand Down Expand Up @@ -2475,7 +2465,7 @@ <h4>Presentations Including Holder Claims</h4>
mechanism as the [=verifiable presentation=].
</p>

<pre class="example nohighlight" title="A verifiable presentation, secured with an embedded proof, with a self-asserted verifiable credential">
<pre class="example nohighlight" title="A verifiable presentation, secured with an embedded Data Integrity proof, with a self-asserted verifiable credential">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
Expand All @@ -2502,7 +2492,7 @@ <h4>Presentations Including Holder Claims</h4>
[=verifiable presentation=].
</p>

<pre class="example nohighlight" title="A verifiable presentation, secured with an embedded proof, with a self-asserted verifiable credential about the verifiable presentation">
<pre class="example nohighlight" title="A verifiable presentation, secured with an embedded Data Integrity proof, with a self-asserted verifiable credential about the verifiable presentation">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
Expand Down Expand Up @@ -2664,8 +2654,7 @@ <h3>Data Schemas</h3>
<span class="highlight">"credentialSchema": {
"id": "https://example.org/examples/degree",
"type": "ZkpExampleSchema2018"
}</span>,
"proof": { <span class="comment">...</span> }
}</span>
}
</pre>

Expand Down Expand Up @@ -2845,7 +2834,7 @@ <h3>Trust Model</h3>
it received. To establish this trust, a [=credential=] is expected to either:
<ul>
<li>
Include a <a href="#proofs-signatures">proof</a> establishing that the
Secure the [=credential=] with a <a href="#proofs-signatures">proof</a> establishing that the
selfissued marked this conversation as resolved.
Show resolved Hide resolved
[=issuer=] generated the [=credential=] (that is, it is a
[=verifiable credential=]), or
Copy link
Member

Choose a reason for hiding this comment

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

We will want to just reword this to refer to the "Securing Mechanisms" section. This is not blocking feedback, and it's editorial, but while we're in here we might as well change this/update it to point to a better place.

</li>
Expand Down Expand Up @@ -3597,15 +3586,15 @@ <h3>Evidence</h3>
</p>

<p class="note">
The `evidence` [=property=] provides different and complementary
information to the `proof` [=property=]. The `evidence`
The `evidence` [=property=] provides information that is different from and
information to the securing mechanism utilized. The `evidence`
[=property=] is used to express supporting information, such as documentary
evidence, related to the integrity of the [=verifiable credential=]. In
contrast, the `proof` [=property=] is used to express
contrast, the securing mechanism is used to express
machine-verifiable mathematical proofs related to the authenticity of the
[=issuer=] and integrity of the [=verifiable credential=]. For more
information about the `proof` [=property=], see Section
<a href="#proofs-signatures"></a>.
information about securing mechanisms, see Section
<a href="#securing-mechanisms"></a>.
</p>

</section>
Expand Down Expand Up @@ -4032,9 +4021,9 @@ <h3>Securing Mechanism Specifications</h3>
Securing mechanism specifications MUST provide a verification mechanism that
returns only the information in the [=conforming document=] that has been
secured, without any securing mechanism information included, such as `proof` or
JOSE/COSE metadata. Specifications MAY provide additional mechanisms to convey
JOSE/COSE header parameters and signatures. Specifications MAY provide additional mechanisms to convey
other information that might be helpful (for example, during validation or for
debugging purposes), such as securing mechanism metadata. A securing mechanism's
debugging purposes), such as securing mechanism data. A securing mechanism's
verification algorithm MUST provide an interface that receives a sequence of
bytes ([=byte sequence=] |inputBytes|) or a document ([=map=] |inputDocument|)
and a media type ([=string=] |inputMediaType|) as inputs and returns a
Expand All @@ -4056,15 +4045,6 @@ <h3>Securing Mechanism Specifications</h3>
A media type as defined in [[RFC6838]].
</dd>
<dt>[=string=] |controller|</dt>
selfissued marked this conversation as resolved.
Show resolved Hide resolved
<dd>
A verification method controller as defined in [[VC-DATA-INTEGRITY]] or
[[VC-JOSE-COSE]].
</dd>
<dt>[=map=] |controllerDocument|</dt>
<dd>
A controller document as defined in [[VC-DATA-INTEGRITY]] or
[[VC-JOSE-COSE]].
</dd>
selfissued marked this conversation as resolved.
Show resolved Hide resolved
</dl>

<p class="issue atrisk"
Expand Down Expand Up @@ -4295,10 +4275,10 @@ <h3>Syntactic Sugar</h3>
require them.
</li>
<li>
The `verifiableCredential` and `proof` [=properties=]
are defined as
The `verifiableCredential` [=property=]
is defined as a
<a href="https://www.w3.org/TR/json-ld11/#graph-containers">JSON-LD 1.1 graph
containers</a>. This means the creation of [=named graphs=] used to isolate
container</a>. This requires the creation of [=named graphs=], used to isolate
sets of data asserted by different entities. This ensures, for example, proper
cryptographic separation between the data graph provided by each [=issuer=]
and the one provided by the [=holder=] presenting the <a>verifiable
Expand Down Expand Up @@ -5003,12 +4983,10 @@ <h3>Identifier-Based Correlation</h3>
<h3>Signature-Based Correlation</h3>

<p>
The contents of [=verifiable credentials=] are secured using the
`credential.proof` field. The [=properties=] in this field
The contents of a [=credential=] are secured using a securing mechanism.
Values used to represent the securing method
selfissued marked this conversation as resolved.
Show resolved Hide resolved
create a greater risk of correlation when the same values are used across more
than one session or domain and the value does not change. Examples include the
`verificationMethod`, `created`,
`proofPurpose`, and `jws` fields.
than one session or domain and the value does not change.
</p>

<p>
Expand Down Expand Up @@ -5885,7 +5863,7 @@ <h3>Content Integrity Protection</h3>
<h3>Unsigned Claims</h3>

<p>
This specification allows [=credentials=] to be produced that do not contain
This specification allows [=credentials=] to be produced that are not secured by
signatures or proofs of any kind. These types of [=credentials=] are often
useful for intermediate storage, or self-asserted information, which is
analogous to filling out a form on a web page. Implementers should be aware that
Expand Down Expand Up @@ -6509,9 +6487,7 @@ <h3>Proofs (Signatures)</h3>
The cryptographic signature is expected to verify.
</li>
<li>
If the cryptographic suite expects a `proofPurpose` [=property=],
it is expected to exist and be a valid value, such as
`assertionMethod`.
Any additional requirements defined by the securing mechanism are satisfied.
</li>
</ul>

Expand All @@ -6522,6 +6498,7 @@ <h3>Proofs (Signatures)</h3>
before which the [=credential=] should not be considered [=verified=],
distinct from the validity period of the credential. This property describes the
validity of the proof, not of the credential.
The JWT <code>iat</code> claim likewise provides the time that the signature was made.
selfissued marked this conversation as resolved.
Show resolved Hide resolved
<br/><br/>
The `verificationMethod` [=property=] specifies, for example, the
public key that can be used to verify the digital signature. Dereferencing a
Expand Down
2 changes: 1 addition & 1 deletion terms.html
Original file line number Diff line number Diff line change
Expand Up @@ -116,7 +116,7 @@
<dt><dfn data-lt="named graphs">named graph</dfn></dt>
<dd>
A <a>graph</a> associated with specific properties, such as
`verifiableCredential` or `proof`. These properties
`verifiableCredential`. These properties
Copy link
Member

Choose a reason for hiding this comment

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

@iherman this is removing all notions that proof is a separate graph, which doesn't seem like a good idea. You added this text, thoughts?

Copy link
Member

@iherman iherman Jan 11, 2024

Choose a reason for hiding this comment

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

Good point but, with this new setup, the fact that a proof creates a new named graph must be added somewhere to the DI spec, and it is ok not to have it there.

At this point we probably should raise a new issue in the DI repo to remind us that this MUST be done, and leave this change as is.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree with @iherman that this information belongs in DI - not VCDM.

result in separate <a>graphs</a> that contain all <a>claims</a> defined in the
corresponding JSON objects.
</dd>
Expand Down