Add normative requirements related to context processing

[msporny]

This PR is an attempt at addressing #1185 by noting how the normative context is used and to make sure that if that optional processing is performed, if an error occurs, verification MUST fail.

---

Preview | Diff

[jandrieu]

The language here is fine. It wasn't touching on the aspect I thought you brought up in your summary during the meting.

Sorry for the confusion.

[iherman]

The issue was discussed in a meeting on 2023-09-14

• no resolutions were taken

View the transcript

1.11. Add normative requirements related to context processing (pr vc-data-model#1281)

See github pull request vc-data-model#1281.

Manu Sporny: Orie requested that, because context is normative, we explain what that means.
� this PR says that if you utilize the context when doing full json-ld processing, and it results in an error, then all further operations should also result in an error.
� In other words: if there is an error, you should bubble it up.
� We know exactly what the contents of the context should be, so errors should be detected and raised across the stack.

Sebastian Crane: From a security perspective you don't want to have errors leaking through. What is the difference between the context and any other validation?

Manu Sporny: One example is the daterange validFrom and validUntil. E.g. a validFrom value that said use "validFrom tuesday". It has nothing to do with context. It's a non-context based error. Validation would fails.
� We do have that throughout the spec. they have nothing to do with the context.
� That's separate from the context file. It comes into play when doing full json-ld processing. But it's something that's optional.
� not sure if that answers your question. Just noting that we have places in the spec where we expect errors to be raised.

Joe Andrieu: I think your question is the difference between verification vs validation. I don't think you can verify with an invalid context.

Sebastian Crane: Why is it so specific to the context file?

Manu Sporny: I think you are correct in suggesting "any validation errors should be bubbled up".
� Some orgs may keep processing the VC even if an error happens.
� the reason this PR doesn't call this out is because this is only about what @context should have.
� To Joe's point, the context comes into play when you're verifying, but only when you're doing full JSON-ld processing. When you're not doing it, you assume that the context is correct.
� This means that you might miss point in time errors for a VC.
� Validation is similar in this case.

Joe Andrieu: I want to disagree when the processing you're suggesting to do when you're not doing json-ld processing.
� My understanding was that you should fails if the context is something you don't expect to understand.

Manu Sporny: the full json-ld processor will utilize the full extent of the @context file.
� Without full processing, you presume that someone has done that elsewhere.

Joe Andrieu: I understand that nuance. You still need to understand that context even if you aren't doing full processing.

Manu Sporny: that does not happen. You presume it's valid.

Joe Andrieu: we are talking past each other.

Joe Andrieu: I'm not talking about processing in a JSON-LD manner, I'm talking about processing of the context property. If MUST be checked to confirm that you think you understand it. Not that you apply those contexts.

Manu Sporny: ah, yes ^.

Manu Sporny: It's happening in the web right now. the same file may yield different results depending on whether full processing is doing.

Brent Zundel: the VCDM already states that context needs to have certain values.

Joe Andrieu: yep.

Manu Sporny: I think Joe, you're saying that the @context property is always checked, even if you're not looking as the contents of the dereferenced file (or all the values).
� What changes do you think should be made, in order to address your concern?

Joe Andrieu: Not sure yet, but I think we need to still look at the property. Will look at the PR and m ake suggestions.

[msporny]

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