Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
add context integrity capabilities to the core data model #1140
Changes from 10 commits
09103b2
71960a5
4d8bbde
c361bf7
94b5aa1
bab6c6f
b226e77
67e936c
610b911
a53c272
aaba294
8c21cc8
9e571a3
8694f7d
26e71e9
84da94c
1843865
4b8ffbf
a15f29f
07fd10d
774d696
6c1ac58
73f9490
1bd4309
90a43b8
3ecd1b8
91c514a
abeba96
8da92be
4088c86
afb5879
a4ef5eb
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
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.
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.
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.
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.
Ok, so you agree that the SHA-2 only limitation is an issue and were looking for a way to address that issue?
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.
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.
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.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)?