-
Notifications
You must be signed in to change notification settings - Fork 106
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
Changes from 11 commits
3de855a
5bb8f16
5604b06
1be081b
57f8238
349c53f
b5f633d
f4148b3
122c1b2
1bf153b
78d02e2
a2e1bfd
1dc5319
c52fd53
7e1e1c8
ca11418
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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"> | ||
|
@@ -1467,16 +1467,6 @@ <h3>Types</h3> | |
</td> | ||
</tr> | ||
|
||
<tr> | ||
<td> | ||
<a href="#proofs-signatures">Proof</a> object | ||
</td> | ||
<td> | ||
A valid proof [=type=]. For example,<br> | ||
`"type": "DataIntegrityProof"` | ||
</td> | ||
</tr> | ||
|
||
<tr> | ||
<td> | ||
<a href="#status">credentialStatus</a> object | ||
|
@@ -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"> | ||
selfissued marked this conversation as resolved.
Show resolved
Hide resolved
|
||
{ | ||
"@context": [ | ||
"https://www.w3.org/ns/credentials/v2", | ||
|
@@ -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", | ||
|
@@ -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", | ||
|
@@ -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> | ||
|
||
|
@@ -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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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> | ||
|
@@ -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> | ||
|
@@ -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 | ||
|
@@ -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" | ||
|
@@ -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 | ||
|
@@ -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> | ||
|
@@ -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 | ||
|
@@ -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> | ||
|
||
|
@@ -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 | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @iherman this is removing all notions that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point but, with this new setup, the fact that a 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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> | ||
|
There was a problem hiding this comment.
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.