Data Integrity -> external resources

[alenhorvat]

Dear,

the following references that some issuer are using in the VCs are NOT available, meaning that verification of those credentials is impossible if the contexts are not stored locally by the verifier.

Furthermore, if the verifier wants to include them, the references cannot be easily found.

References:
https://w3c-ccg.github.io/did-resolution/contexts/did-resolution-v1.json
https://w3id.org/did-resolution/v1

This is a critical issue for the signature design. I urge the authors to consider defining a method of how the contexts CAN/SHOULD/MUST be included in the protected or unprotected signature part and what are the rules for 3rd parties hosting the contexts to ensure longevity.

Thank you for your understanding.

Alen

[msporny]

Hi Alen, we have discussed the issue you are raising before and it took 6+ months to debate in the group, the previous issue can be seen here:

#272

... and the changes we made can be found here:

#272 (comment)

the following references that some issuer are using in the VCs are NOT available, meaning that verification of those credentials is impossible if the contexts are not stored locally by the verifier.

Yes, in this case, a verifier MUST NOT verify a VC that it doesn't understand in a production setting. We have text to this effect in the spec today:

https://www.w3.org/TR/vc-data-integrity/#validating-contexts

I urge the authors to consider defining a method of how the contexts CAN/SHOULD/MUST be included in the protected or unprotected signature part and

This is application specific, for example, the rules for VCs can be found here:

https://w3c.github.io/vc-data-model/#integrity-of-related-resources

specifically, this text:

A conforming verifier implementation that makes use of a resource based on the id of a relatedResource object inside a conforming document with a corresponding cryptographic digest appearing in a relatedResource object value MUST compute the digest of the retrieved resource. If the digest provided by the issuer does not match the digest computed for the retrieved resource, the conforming verifier implementation MUST produce an error.

So, if an issuer includes the hash for a context, then a verifier MUST ensure that the value it has matches or throw an error.

what are the rules for 3rd parties hosting the contexts to ensure longevity.

The rules are the same for any long-lived content on the Web: Publish it to a URL that won't change and don't change the content. We do have some other guidance that we might put in an implementation guide, but we don't have consensus yet on exactly what we should say (other than what should already be obvious to developers that want to ensure long-lived content at long-lived URLs.

Does the above answer your questions, @alenhorvat?

[alenhorvat]

Hi. Thank you for the exhaustive answer, but I would expect that specification defines how to embed (either in a protected or unprotected way) the context if it is unavailable. In an open ecosystem, where an verifier may ask for a set of claims, without referring to a specific VC type, it may happen that a holder presents a VC with a context where the full context is not cached by the verifier.

The main issue is that a signature can be invalidated due to unavailable remote content, even though the signature/credential are actually valid.

AdES signature profiles, for example, define how to embed additional content/metadata. If possible, I would kindly ask the WG to define how to embed remote content when connectivity might be limited.