RFC011: add cryptographic hash to JSON-LD context URL to avoid tampering

[reinkrul]

When a JSON-LD document is processed, its contexts are resolved. These contexts are URLs pointing to a location where the JSON-LD context document can be found. When the context is changed (either by an attacker or accidentally) it becomes a vulnerability: it could give credentials a different meaning and/or changing what fields are included in the signature. Possible attacks:

• Denial of Service: existing VCs can't be validated anymore since signature calculation is altered, invalidating existing signatures
• Spoofing: setting the conditions to have critical data in newly issued VCs excluded from the signature, allowing it to be altered without invalidating the signature

This could be mitigated by adding a cryptographic hash of the context document, to the JSON-LD context URL. This means that after resolving a JSON-LD context, the resolver should hash the context and compare it with the hash in the URL.

[woutslakhorst]

This would also require allowlisting certain domains.

Downloading new contexts should require additional security checks.

[woutslakhorst]

Goal is to support additional contexts outside of our control. Governing parties of those context might want to update their contexts without we having to update our software.

Specs need to be defines for:

• naming the context and filename on the web
• rules on downloading the context: hash mismatch, maximum file size, etc
• versioning (v1 in URL, how do we handle backwards compatible changes? New URL?)

[woutslakhorst]

When downloaded, context need to be stored alongside the VCs. If past contexts are taken offline, that would be a big problem.