Enhance Context Validation

[msporny]

From w3c/vc-data-integrity#272 (comment), @decentralgabe wrote:

Add normative language to the DI specification requiring implementers to rigorously validate @context values. This should include:
a) Checking against a list of trusted contexts
b) Verifying the integrity of context contents using cryptographic hashes
c) Rejecting or transforming documents with untrusted contexts before processing

From https://github.com/w3c/vc-data-model/pull/1524/files#r1669382600, @TallTed wrote:

Applications MAY use JSON-LD compaction algorithms to transform a document that uses an unknown JSON-LD context to one that does not, so the new document's terms will match expectations.

Some additional detail might be needed, with the addition of that sentence. I think this, because I don't know (and I haven't been able to figure it out, after more than a few minutes reading the linked page and others. I had thought I had a good grasp of JSON-LD mechanics, but this makes me wonder!) how the suggested transformation would work. Maybe add some more-descriptive, psuedo-algorithmic language here, with fewer low-level details than the linked page?

[iherman]

The issue was discussed in a meeting on 2024-07-17

• no resolutions were taken

View the transcript

3.6. Enhance Context Validation (issue vc-data-model#1529)

See github issue vc-data-model#1529.

Brent Zundel: enhanced context validation.

Manu Sporny: Gave made a proposal that we add normative language to data integrity spec, but it might be good to put in VCDM.
… some sort of normative language to say you are checking issuers.
… Ted also suggested some detail on how you can use compaction algorithms to get rid of untrusted contexts.
… This PR is creating new normative language to doing that.
… We would be testing for that at the application layer, which we haven't done before.
… But it seems that the group is willing to go there.
… action is to raise a PR that does that.

Brent Zundel: any concerns, speak up now.

Manu Sporny: I do have a question to the group. The specs we are creating have architectural layers, e.g., the securing layer is lower on the stack and validation is higher.
… I'm trying to figure out if it is worth using this language in the data integrity specification.
… Note that data integrity can work on things without @context.
… we describe the challenges with that.
… Would people object to duplication that language? If we put it in Data Integrity, that's likely a layer violation.

Ivan Herman: I sort of understand the layering problem. But for me, the language seems more natural in the DI spec than VCDM. Just my instinct.

Manu Sporny: If we only put the language in the DI spec, VC-JOSE-COSE would have no language in it to ensure they understand the context.
… the layering here is that "these statements are things the application layer should be doing" they don't have much to do with data integrity. They have more to do with VCDM.
… The root issue was ignoring contexts.
… So we had to tell people, "When you process an incoming document, you have to understand what it means".
… One way to do that, with @context is to make sure you understand and trust the @contexts.
… That is an application-layer instruction. At the validation layer.

Dave Longley: i.e., don't just guess what JSON keys refer to.

Manu Sporny: That's why it would be a layer violation.

Ivan Herman: that makes sense. My first instinct then is that something needs to be added to VC-JOSE-COSE, but I will not object if it is in the VCDM. We should not spend too much time on it.

Dave Longley: the string "cats" could refer to many different things.

Joe Andrieu: The validation of the issues definitely doesn't seem like it's about securing, I am convinced of the layering violation.

Brent Zundel: next week's meeting is canceled.

---

[msporny]

PR #1535 has been raised to address this issue. This issue will be closed once PR #1535 has been merged.

[msporny]

PR #1535 has been merged, closing.