Should JOSE/COSE verification strip out or inline @context values?

[jyasskin]

Based on @peacekeeper's https://medium.com/@markus.sabadello/json-ld-vcs-are-not-just-json-4488d279be43, I'm worried that this spec's verification could succeed, but then the application using the VC could process it as JSON-LD, fetch a context, and get something different from what the issuer meant to sign. The VC data model defines relatedResource and digestSRI, but because those aren't native JSON-LD properties (https://github.com/w3c/json-ld-syntax/issues/422), a generic JSON-LD processor won't necessarily enforce them.

I could imagine this spec either removing all the @context values that aren't pinned by https://w3c.github.io/vc-data-model/#base-context (which would likely prevent JSON-LD processing), or fetching them, checking that their digest matches their digestSRI value, and then inlining them in the result. Or you could think of another way to ensure the verified content matches the issuer's intent.

[OR13]

This document does not do "application specific processing" related to the media types requested for registration in the core data model.

Specifically, in the context of this specification:

application/vc+ld+json and application/vp+ld+json are treated as JSON, and not processed with JSON-LD / RDF processing that might normally rely on remote document loaders.

Validation of the conforming document ends with checking conformance to the core data model, which does not require that embedded contexts, remote contexts or RDF annotations be well formed beyond the minimal requirements defined in https://www.w3.org/TR/vc-data-model-2.0/#conformance

Any application might choose to do additional media type specific processing after verification and validation, but that would be a verifier specific policy, not a requirement from the core specification or this specification.

I don't know how to take an action on this issue in this repo, but I could see text giving normative guidance on validation being attempted in the core data model.

However, based on the discussions on issues and in working group calls, I believe that normatively defining validation, or requiring dynamic JSON-LD processing would not reach consensus, and I respectfully request that this issue be closed on that basis.

[OR13]

Or you could think of another way to ensure the verified content matches the issuer's intent.

Just to reply to this directly, if the issuer chose to sign JSON-LD using a JWS or COSE Sign 1, those are the bytes they want the verifier to be checking for tampering... doing anything beyond this, would be a violation of the issuer's intent.

If issuer's want to do dynamic processing prior to issuance and prior to verification, they should review:

https://w3c.github.io/rdf-canon/spec/#dataset-poisoning

and it they still feel comfortable proceeding, they should use data integrity proofs.

[selfissued]

The securing specification shouldn't be modifying the content being secured. I propose that we close this issue on that basis.

[jyasskin]

That's plausible, although I think there's a difference between generic JOSE or SD-JWT and this spec about how to apply them to VCs, which could justify some manipulation of the returned VC object.

There's also https://github.com/w3c/vc-data-model/issues/1388 to discuss the underlying problem that this issue was trying to fix. I'm not tied to fixing it in any particular place, as long as there's some solution that the WG thinks is likely to avoid the problem.

[selfissued]

Closing, per the pending-close in December. There's no consensus to modify payloads.