VCR: Returning normalized VCs: compact before storing, or retrieval?

[reinkrul]

When an application or users retrieves a VC from the Nuts Node (either by resolving or searching), it is now returned as it was created. This seems good at first glance, but VCs often come from an external source (issued by another node). When it contains data not defined by the JSON-LD context it is not protected by the signature, allowing tampering attacks. This might lead to the local user or application making false assumptions about the validness of these unprotected fields.

Although the attack is unlikely for VCs transmitted over the Nuts network (because they're contained in transactions, which is a signed envelope), it is still possible to attack VCs exchanged out-of-band (via other means than the Nuts network). And data-at-rest (VCs in the VCR database) can still be altered.

As such, before returning a credential, it should be normalized and its signature checked. Question arises whether the credential should be normalized before storage, or on retrieval.

Proposal As data should be stored in its original form when possible, we should store it as received (either when issued by the local node or received over the network), and normalize it when retrieved (JSON-LD compaction).

Also, as normalization is a form of sanitizing, it is preferred to validate input VCs before storing them, rather than storing a sanitized form ("validate, don't sanitize", Threat Modeling by Adam Shostack).

Related to https://github.com/nuts-foundation/nuts-node/issues/1561

[gerardsn]

Currently the network and VCR use the same storage for VCs. (VCR only keeps indexes for data in the network layer.) Since the VC is protected by the transaction envelope signature, we need to keep the original VC in case it is requested by another node. So storing a VC in the original form should also prevent duplication of data.

[woutslakhorst]

I disagree since this will require both issuer and holder to have the same context loaded. This introduces an update order problem. The verifier must check the signature. The holder should generate warnings in the log when receiving VCs that won't validate. The search API could get an extra feature for sanitisation.

[reinkrul]

I disagree since this will require both issuer and holder to have the same context loaded.

All parties involved in a certain credential (either issuing, using or verifying) need to understand the credential, thus have all specified contexts?

But for the sake of preserving history and performance, maybe VCR should store the credential in expanded form: then it doesn't have to be re-resolved the next time it is used.

[woutslakhorst]

This will become easier when contexts are not included in the software but are part of the governance and can thus be configured/distributed

[woutslakhorst]

VCs stored in SQL use the raw form