search

w3c / vc-data-integrity

W3C Data Integrity Specification
https://w3c.github.io/vc-data-integrity/
Other
41 stars 18 forks source link

Add section on Resource Integrity and `digestMultibase`. #174

Closed msporny closed 1 year ago

msporny commented 1 year ago

This PR attempts to address issue #170, raised by PING and security review, by adding a mechanism to identify resources by cryptographic hash such that they can be permanently cached, or not retrieved from the network if they already exist in a cache. This PR builds on top of PR #172 and adds appropriate warnings that the digest mechanism might change during CR based on implementer feedback.

/cc @kdenhartog

Preview | Diff

msporny commented 1 year ago
  1. We should make a note that the digestMultibase should be added as a new property into the vocabulary. The domain is unlimited, the range is... I guess a new datatype to be defined...

The domain and range are unlimited (the property can be used with any subject). The datetype is multibase.

  1. I wonder whether the (new) term, ie, digestMultibase should not be defined as "reserved" in the vocabulary at least until the discussion on SRI is closed.

Sure, we could do that, but if we do that, we should also put digestSRI as reserved as well.

msporny commented 1 year ago

+1 to defining this feature within data-integrity. I could see it as being useful within then entire vc-data-model as well for claims. Since this text seems to be focused on handling of claims URLs, would it be possible to also highlight how this would be used for URLs within the @context property as well or for other URLs which can't rely on additional JSON-LD properties?

We have a section in the VC Data Model on resource integrity as well, covering the use cases you mention:

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

I suspect this has already been considered and I've just not been up to date on the different arguments being made on it so far.

Yep, we already support what you suggest w/ VCs. Since the Data Integrity specification is at a lower level (and doesn't define application contexts), we provide at least two types of guidance: 1) provide cryptographic digests for your application contexts, and 2) permacache contexts; don't load them from the network. Those two types of guidance make it such that you shouldn't need the relatedResource feature for JSON-LD contexts... but, if for some reason you do, you can just define the feature in your application context and use that.

msporny commented 1 year ago

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