Add section on Context Validation. #1535
Conversation
msporny
added
normative
msporny
requested review from
davidlehn,
dlongley,
jandrieu,
longpd,
iherman,
dmitrizagidulin,
TallTed,
decentralgabe,
KDean-Dolphin and
brentzundel
| One such approach would be for a [=verifier=] to configure a JSON-LD Context | ||
| loader, sometimes referred to as a document loader, to use only local copies of | ||
| approved context files which would guarantee that 1) context files will never | ||
| change, and 2) the cryptographic hashes will never change, effectively | ||
| resulting in the same result as the algorithm above. | ||
| </p> | ||
|
|
||
| <p> | ||
| Another approach a [=verifier=] could use would be to use a list of well known | ||
| context URLs and their associated approved cryptographic hashes, without storing | ||
| every context file locally, which would allow contexts to be safely loaded and | ||
| cached from the network without compromising the security expectations of the | ||
| [=verifier=]. This approach would also be effectively equivalent to the | ||
| algorithm provided in this section. | ||
| </p> | ||
|
|
||
| <p> | ||
| Yet another valid approach would be for the [=holder=] to |
There was a problem hiding this comment.
Listing multiple ways to perform validation is good, but it then seems that the above MUST on the specific algorithm provided there should be a MAY instead -- or some other text should make it clear that either the algorithm can be run or one of these other equivalent approaches can be taken.
| This section contains an algorithm that [=verifiers=] MUST run after running the | ||
| algorithm in Section [[[#verification]]], when validating a [=verifiable | ||
| credential=] or a [=verifiable presentation=]. This algorithm takes a document |
There was a problem hiding this comment.
See my comment in w3c/vc-data-integrity#291 (comment). Any reason why this algorithm shouldn't be run before even touching verification?
There was a problem hiding this comment.
It seems to me that it should be up to an implementer whether it is run before or after verification. This an application-level check, and the best time to run it can be application / use-case dependent.
There was a problem hiding this comment.
Then the text should say so! It currently has a numbered list, which suggests mandatory ordering...
(Also for w3c/vc-data-integrity#291)
|
There's a lot of repeated text, here and in w3c/vc-data-integrity#291, which needs similar if not identical changes (which suggestions from myself and others do not currently reflect), possibly being adjusted to be said in one place, and referenced in the other. |
Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>
|
@TallTed wrote:
Yep, I had considered these issues:
So, the solution seems to be to put it in both places, even though most of the text is duplicated, OR, if we can get past the "VC JOSE COSE needs to be at the same level as DI", we could just ref DI from VCDM (at least). I don't think we will get to consensus on that approach, so duplicating the text in VCDM and DI is the best I think we can achieve. That said, happy to not duplicate the text, though the only reasonable path I see for that is to put this in DI (or maybe the JSON-LD spec, which you've raised as a concern @TallTed... but that doesn't happen before we get the VCWG specs to REC, IMHO). Anyone else see a better way through this? |
So where @TallTed should the core changes be made, e.g., in (w3c/vc-data-integrity#291) or (#1535) with the pointer from the other? |
That looks like the most pragmatic thing to do, that is, see if we can get consensus on referencing DI from VCDM, and if that's not possible then duplicating the text in VCDM and DI makes sense. We'll just have to insure (as best we can) that any changes to text VCDM are propagated to DI (and vice-versa) to they stay in sync. |
|
@longpd wrote:
Update... the text across both PRs are now wildly out of sync (which only underscores @TallTed's concern)! Let's try to focus getting the language right on the DI PR and I'll update the VCDM PR (this one) once the DI text settles. It's largely the algorithm that changed (and is improved in the DI PR). |
This PR attempts to address issue #1529 by adding normative text requiring verifiers to implement context validation.
Preview | Diff