Additional RDF validation of linked data proofs #241
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
clehner
force-pushed
the
feat/rdf-check
branch
7 times, most recently
from
35fdb5f to
f81a914
Compare
sbihel
approved these changes
Aug 6, 2021
clehner
force-pushed
the
feat/rdf-check
branch
from
9faa51e to
762d157
Compare
clehner
force-pushed
the
feat/rdf-check
branch
from
762d157 to
38f9c5e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This addresses #235 by adding checking of proof properties as RDF terms in addition to their handling as JSON. This is implemented for every proof type that uses JSON-LD to RDF conversion for signing. The processing is done on the proof object's RDF dataset just before creating the linked data proof verification hash.
Negative test cases are added, using JsonWebSignature2020, to demonstrate the validation.
The example VCs/VPs using RsaSignature2018 do not pass this validation, due to a bug in the Credentials v1 base context which resulted in proof objects of that type not using the expected IRIs: w3c/vc-data-model#778. Rather than working around this context bug (as in w3c/vc-data-model#778 (comment)), the example VCs/VPs are replaced with ones using JsonWebSignature2020, since RsaSignature2018 is deprecated.
The validation is done even for the proof types in the core Credentials v1 context, where their terms cannot be redefined due to using
@protected. It may be possible to relax this validation for certain proof types when certain context files are in effect. However, even with use of@protected, additional RDF statements may exist in the proof not using the expected compact terms, even as in fully expanded proof objects, which JSON-only parsing would not detect; the validation added here ensures that the RDF statements must match one-to-one with the JSON properties of the proof object. If we want to support proof objects in expanded form (full IRIs as property names), and/or aliased property names other than the commonly-defined terms, this validation would need to be relaxed, but could be repurposed for its RDF parsing which could be used instead of serde deserialization of the Proof struct.RDF validation is not added for proof types that do not use JSON-LD/RDF (i.e.
EthereumEip712Signature2021).