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

add context integrity capabilities to the core data model #1140

Merged
merged 32 commits into from
Jun 27, 2023
Merged
Changes from 10 commits
Commits
Show all changes
32 commits
Select commit Hold shift + click to select a range
09103b2
chore: add context integrity capabilities
mprorock Jun 2, 2023
71960a5
correct issue
mprorock Jun 2, 2023
4d8bbde
Update index.html
mprorock Jun 2, 2023
c361bf7
incorporate a better example
mprorock Jun 3, 2023
94b5aa1
chore: update to broaden context integrity to remote resources in gen…
mprorock Jun 5, 2023
bab6c6f
Apply suggestions from code review
mprorock Jun 7, 2023
b226e77
update to clarify encoding of hash
mprorock Jun 7, 2023
67e936c
chore: add media types reference
mprorock Jun 12, 2023
610b911
Apply suggestions from code review
mprorock Jun 13, 2023
a53c272
Apply suggestions from code review
mprorock Jun 13, 2023
aaba294
clarify hash encoding around trailing characters
mprorock Jun 13, 2023
8c21cc8
chore: re-rename id to resource. add clarifiation on multiple hashes
mprorock Jun 14, 2023
9e571a3
chore: make timestamp optional for resourceIntegrity objects
mprorock Jun 14, 2023
8694f7d
fix: missing quotes in an example
mprorock Jun 14, 2023
26e71e9
chore: bring resource integrity in line with SRI
mprorock Jun 15, 2023
84da94c
chore: clean up some language
mprorock Jun 15, 2023
1843865
chore: add language around selective disclosure
mprorock Jun 15, 2023
4b8ffbf
expand one example to include all optional properties
mprorock Jun 16, 2023
a15f29f
Apply suggestions from code review from msporny
mprorock Jun 18, 2023
07fd10d
remove an un-needed statement
mprorock Jun 18, 2023
774d696
change media type language from must to should
mprorock Jun 18, 2023
6c1ac58
updated name to relatedResource based on feedback
mprorock Jun 27, 2023
73f9490
remove timestamp from relatedResource
mprorock Jun 27, 2023
1bd4309
chore: adjust to digestSRI
mprorock Jun 27, 2023
90a43b8
chore: adjust line wrapping and format
mprorock Jun 27, 2023
3ecd1b8
chore: adjust titles in examples
mprorock Jun 27, 2023
91c514a
add advisement around mandatory context inclusion
mprorock Jun 27, 2023
abeba96
fixing one more example issue
mprorock Jun 27, 2023
8da92be
add a note regarding hash digest representations
mprorock Jun 27, 2023
4088c86
add some clarifying text
mprorock Jun 27, 2023
afb5879
correct typo
mprorock Jun 27, 2023
a4ef5eb
remove some double spaces
mprorock Jun 27, 2023
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
113 changes: 113 additions & 0 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -2595,6 +2595,119 @@ <h3>Data Schemas</h3>

</section>

<section>
<h2>External Resource Integrity</h2>
mprorock marked this conversation as resolved.
Show resolved Hide resolved
<p>
When including a link to an external resource in a VC, it is
mprorock marked this conversation as resolved.
Show resolved Hide resolved
desirable to know whether the resource that is pointed to is the
same at signing time as at verification time. This applies
mprorock marked this conversation as resolved.
Show resolved Hide resolved
to cases where there is an external resource that is
remotely retrieved as well as to cases where the issuer and/or
mprorock marked this conversation as resolved.
Show resolved Hide resolved
verifier may have local cached copies of a resource.
mprorock marked this conversation as resolved.
Show resolved Hide resolved
</p>
<p>
It is also desirable to know that the contents of the
context(s) used in the verifiable credential are the same when
mprorock marked this conversation as resolved.
Show resolved Hide resolved
used by both the issuer and verifier.
mprorock marked this conversation as resolved.
Show resolved Hide resolved
</p>
<p>
To validate that a resource referenced by a Verifiable Credential is
mprorock marked this conversation as resolved.
Show resolved Hide resolved
the same at verification time as at issuing time, an implementer
mprorock marked this conversation as resolved.
Show resolved Hide resolved
MAY include a property named <code>resourceIntegrity</code> that
mprorock marked this conversation as resolved.
Show resolved Hide resolved
stores an array of objects that describe additional integrity
metadata about each resource referenced by the VC. If
mprorock marked this conversation as resolved.
Show resolved Hide resolved
<code>resourceIntegrity</code>
mprorock marked this conversation as resolved.
Show resolved Hide resolved
is present, there MUST be an object in the array for each remote
resource.
</p>
<p>
mprorock marked this conversation as resolved.
Show resolved Hide resolved
Each object in the
<code>resourceIntegrity</code> array MUST contain the following:
mprorock marked this conversation as resolved.
Show resolved Hide resolved
the URL to the resource named <code>id</code>, a
<code>timestamp</code>
that indicates the time at which the hash was computed, the
<code>digest</code>
of the resource, and the <code>method</code> which indicates what
hashing algorithm was used as listed as the 'Hash Name String'
property from the <a
href="https://www.iana.org/assignments/named-information/named-information.xhtml">IANA
Named Information Hash Algorithm Registry</a>.
The <code>digest</code> property MUST be the base64url [[RFC 4648]]
encoded digest of the hash.
mprorock marked this conversation as resolved.
Show resolved Hide resolved
mprorock marked this conversation as resolved.
Show resolved Hide resolved
The <code>timestamp</code> property MUST be a string value of an
mprorock marked this conversation as resolved.
Show resolved Hide resolved
[[XMLSCHEMA11-2]] combined date-time string. An implementer MAY
include other fields in each object.
</p>
<p>
An object in the <code>resourceIntegrity</code> array MAY contain
mprorock marked this conversation as resolved.
Show resolved Hide resolved
a property named <code>mediaType</code> that indicates the
expected media type for the indicated <code>resource</code>.
If a <code>mediaType</code> is included it must be a valid
mprorock marked this conversation as resolved.
Show resolved Hide resolved
media type as listed in the
<a href="https://www.iana.org/assignments/media-types/media-types.xhtml">
IANA Media Types
</a> registry.
mprorock marked this conversation as resolved.
Show resolved Hide resolved
</p>
<p>
An object in the <code>resourceIntegrity</code> array MAY contain
additional properties.
</p>
mprorock marked this conversation as resolved.
Show resolved Hide resolved
<p>
Implementers SHOULD consult appropriate sources, such as the <a
href="https://www.iana.org/assignments/named-information/named-information.xhtml">IANA
Named Information Hash Algorithm Registry</a> to ensure that they
are chosing a current and reliable hash algorithm. At the time of
this writing `sha-256` SHOULD be considered the minimum strength
hash algorithm for use by implemnters.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
are chosing a current and reliable hash algorithm. At the time of
this writing `sha-256` SHOULD be considered the minimum strength
hash algorithm for use by implemnters.
are chosing a current and reliable hash algorithm. At the time of
this writing `sha-256` SHOULD be considered the minimum strength
hash algorithm for use by implementers.

This goes against the suggestion of the SRI spec (which suggests SHA-384, which we shouldn't suggest). Just flagging this as a deviation from SRI (which I think is fine).

I'll also note that SRI ONLY covers SHA-2, so this property will be stuck w/ SHA-2 forever, which seems problematic given that some government use cases are suggesting SHA-3 now. This is one of the arguments for a more flexible digest expression mechanism, such as digestMultibase, which would allow for other content integrity mechanisms (such as BLAKE-3, KECCAK, SHA-3, canonicalized hashes, and so on).

We should discuss this in the special topic call. Feels like only speaking to SHA-2 is unnecessarily limiting. We don't have to support the full breadth of multihash, but saying that a subset should be supported is probably what we're going for here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this was the reason for the original approach (inline with SRI, but pointing to current hash registry and separating method until SRI is updated) that was removed based on feedback from you and dlongley.

This increasinging feels like this PR is spinning in circles back to where it started, while also trying to be pulled into something that is not (multibase, etc) - @brentzundel @Sakurann i would request a special topic call on this to resolve. I also am frustrated by claims that this does not apply to data integrity proofs, as it most certainly does.

Copy link
Member

@msporny msporny Jun 18, 2023

Choose a reason for hiding this comment

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

this was the reason for the original approach (inline with SRI, but pointing to current hash registry and separating method until SRI is updated) that

Ok, so you agree that the SHA-2 only limitation is an issue and were looking for a way to address that issue?

was removed based on feedback from you and dlongley.

The splitting the method from the hash value was requested to be changed because it would result in weird data model statements. Subjects being assigned hash methods, instead of what was intended, which was a process by which you can take a subject URL, hash it, and get an integrity value from it.

One thing that we could do, that would probably get consensus is to allow this WG to extend the hash mechanisms. We might want to do that for SHA-3 today. So, the format still follows what's in the SRI spec, but allows this WG to add new hash mechanisms as it sees fit.

This increasinging feels like this PR is spinning in circles back to where it started

It's not, the initial PR wouldn't achieve consensus, but the direction you switched to would. If you end up switching back to the original proposal, I don't expect us to achieve consensus. However, if we keep going down the new path, I expect us to get to consensus.

while also trying to be pulled into something that is not (multibase, etc)

To be clear, the new path is doing almost exactly what digestMultibase does, but using a text-based format. That's why it's coming up, because the approaches are very similar.

I also am frustrated by claims that this does not apply to data integrity proofs, as it most certainly does.

Can you please elaborate on how using resourceIntegrity to protect @context values applies to Data Integrity Proofs given that if there is a mismatch between the contexts used to sign and the contexts used to verify that the signatures will not verify (vs. in VC-JWT, they will verify with mismatched contexts)?

</p>
<p class="issue">
The working group is discussing if we will adopt subresource integrity as defined in [[SRI]] is
adopted into the [[JSON-LD]] specification as noted in that
specifications <a
href="https://www.w3.org/TR/json-ld11/#security">current security
considerations</a> of that specification, this hash in the VC can
serve as an additional check towards ensuring that a cached
context used when issuing the VC matches the remote resource.
</p>
<p>
<aside
class="example"
title="resource integrity"
>
<p>An example of a resource integrity object referencing contexts</p>
<pre>
"resourceIntegrity": [{
mprorock marked this conversation as resolved.
Show resolved Hide resolved
"id": "https://www.w3.org/ns/credentials/v2",
mprorock marked this conversation as resolved.
Show resolved Hide resolved
"timestamp": "2023-06-07T19:23:24Z",
"digest": "zMxXZRc9wGRgtsdFaCaqluKtZbyEz-emTp4Y1k1wBvgKNYguD7qTACwjWOTUgB-A",
"method": "sha3-384"
},{
"id": "https://www.w3.org/ns/credentials/examples/v2",
mprorock marked this conversation as resolved.
Show resolved Hide resolved
"timestamp": "2023-06-07T17:32:15Z",
"digest": "STCt_TVvy-QH6PCA8IDH7tw0dsBsgkewEl9VjCDwvUCVPz5M10dUhrMG9f2Q82MA",
"method": "sha2-256"
}]
</pre>
</aside>
</p>
<p>
<aside
class="example"
title="resource integrity over image"
>
<p>An example of a resource integrity object refering to an image</p>
<pre>
mprorock marked this conversation as resolved.
Show resolved Hide resolved
"resourceIntegrity": [{
"id": "https://www.w3.org/Icons/w3c_home.png",
mprorock marked this conversation as resolved.
Show resolved Hide resolved
"timestamp": "2023-06-05T19:23:24Z",
"digest": "1yfsvHgO9SsCngATZ3r6NsFODzGzDfttlGc5gA3Qkm_08yJb4fepTXbAK6IRZ2C-",
"method": "sha3-384"
}]
</pre>
</aside>
</p>
</section>

<section>
<h3>Refreshing</h3>

Expand Down