Add section on Context Validation. #1535

msporny · 2024-07-21T18:59:46Z

This PR attempts to address issue #1529 by adding normative text requiring verifiers to implement context validation.

index.html

dlongley · 2024-07-21T21:07:00Z

index.html

+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


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.

Fixed in 8dbad0b.

iherman · 2024-07-23T11:25:52Z

index.html

+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


See my comment in w3c/vc-data-integrity#291 (comment). Any reason why this algorithm shouldn't be run before even touching verification?

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.

Then the text should say so! It currently has a numbered list, which suggests mandatory ordering...

(Also for w3c/vc-data-integrity#291)

Fixed in 8dbad0b.

TallTed · 2024-07-23T17:20:47Z

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 <[email protected]>

msporny · 2024-07-24T21:10:53Z

@TallTed wrote:

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.

Yep, I had considered these issues:

We duplicate this text in DI and VC JOSE COSE (because the VC JOSE COSE folks have historically not wanted to refer to DI and also because it would be weird for DI or VC JOSE COSE, which don't reference each other for anything, to cross-reference either way on this particular point... and then VCDM needs to pick one of those places to point to?
We have DI and VC JOSE COSE point to the language in this VCDM PR, which would be a bit of a strange layering violation since they're both at a lower architectural level than VCDM (it would be weird to ref "up" to VCDM from DI).
DI stands on it's own... you don't have to use it with VCDM, but this guidance is generally applicable to any JSON-LD document secured using DI, so it should probably exist over there even if it didn't exist in VCDM.

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?

longpd · 2024-07-24T21:11:45Z

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.

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?

longpd · 2024-07-24T21:34:48Z

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 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.

msporny · 2024-07-24T22:19:43Z

@longpd wrote:

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.

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).

msporny · 2024-07-27T19:29:28Z

@longpd wrote:

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.

Alright, that is what this PR now does. The spec text asserting that context validation MUST happen was already in the spec. This PR now just points to the DI spec, whose Context Validation section is quite thorough now with an explanation and a normative algorithm, to say how to do it. This doesn't change the normative reference to DI (we already had that). IOW, this is now an editorial PR and I'm merging it as such.

If folks object to that, we can duplicate the text in the DI spec into the VCDM spec.

msporny · 2024-07-27T19:29:58Z

Editorial, multiple reviews, changes requested and made, no objections, merging.

Add section on Context Validation.

cb2306e

msporny added normative The PR is a normative change to the CR specification CR1 This item was processed during CR1 labels Jul 21, 2024

msporny requested review from davidlehn, dlongley, jandrieu, longpd, iherman, dmitrizagidulin, TallTed, decentralgabe, KDean-Dolphin and brentzundel July 21, 2024 18:59

msporny requested a review from selfissued as a code owner July 21, 2024 18:59

msporny mentioned this pull request Jul 21, 2024

Enhance Context Validation #1529

Closed

dlongley reviewed Jul 21, 2024

View reviewed changes

index.html Outdated Show resolved Hide resolved

dlongley reviewed Jul 21, 2024

View reviewed changes

index.html Outdated Show resolved Hide resolved

dlongley reviewed Jul 21, 2024

View reviewed changes

dlongley mentioned this pull request Jul 21, 2024

Add sections on Processing Model and Context Validation w3c/vc-data-integrity#291

Merged

msporny mentioned this pull request Jul 21, 2024

Multiple significant security vulnerabilities in the design of data integrity w3c/vc-data-integrity#272

Closed

iherman reviewed Jul 23, 2024

View reviewed changes

msporny and others added 2 commits July 24, 2024 16:57

Fix grammar and flow in context validation section.

bdd13ed

Co-authored-by: Dave Longley <[email protected]>

Clarify that different approaches are allowed for context checks.

8dbad0b

iherman self-requested a review July 25, 2024 06:44

iherman approved these changes Jul 25, 2024

View reviewed changes

msporny added 2 commits July 27, 2024 15:23

Refer to context validation in Data Integrity.

742019a

Remove text on context validation and refer to DI instead.

71e3446

msporny added editorial Purely editorial changes to the specification. and removed normative The PR is a normative change to the CR specification labels Jul 27, 2024

msporny merged commit fea8cbc into main Jul 27, 2024
1 check passed

msporny deleted the msporny-ctx-validation branch July 27, 2024 19:30

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add section on Context Validation. #1535

Add section on Context Validation. #1535

msporny commented Jul 21, 2024 •

edited by pr-preview bot

Loading

dlongley Jul 21, 2024

msporny Jul 24, 2024

iherman Jul 23, 2024

dlongley Jul 23, 2024 •

edited

Loading

iherman Jul 23, 2024 •

edited

Loading

msporny Jul 24, 2024

TallTed commented Jul 23, 2024

msporny commented Jul 24, 2024 •

edited

Loading

longpd commented Jul 24, 2024

longpd commented Jul 24, 2024

msporny commented Jul 24, 2024

msporny commented Jul 27, 2024

msporny commented Jul 27, 2024

Add section on Context Validation. #1535

Add section on Context Validation. #1535

Conversation

msporny commented Jul 21, 2024 • edited by pr-preview bot Loading

dlongley Jul 21, 2024

Choose a reason for hiding this comment

msporny Jul 24, 2024

Choose a reason for hiding this comment

iherman Jul 23, 2024

Choose a reason for hiding this comment

dlongley Jul 23, 2024 • edited Loading

Choose a reason for hiding this comment

iherman Jul 23, 2024 • edited Loading

Choose a reason for hiding this comment

msporny Jul 24, 2024

Choose a reason for hiding this comment

TallTed commented Jul 23, 2024

msporny commented Jul 24, 2024 • edited Loading

longpd commented Jul 24, 2024

longpd commented Jul 24, 2024

msporny commented Jul 24, 2024

msporny commented Jul 27, 2024

msporny commented Jul 27, 2024

msporny commented Jul 21, 2024 •

edited by pr-preview bot

Loading

dlongley Jul 23, 2024 •

edited

Loading

iherman Jul 23, 2024 •

edited

Loading

msporny commented Jul 24, 2024 •

edited

Loading