Add `relatedResource` to `VerifiablePresentation`

[OR13]

Originally discussed in:

• Sync and fix bugs in v2 context. #1259 (comment)
• are domain and range correct for all properties in data model? #1263 (comment)

This would allow a VerifiablePresentation or VerifiableCredential to point to "other graph nodes by id", instead of pointing to "VerifiableCredentialGraph" containers.

See also the discussion on the different between the two here:

#1240

[msporny]

+1, this feels like a useful thing to do.

I have since changed my mind based on the conversations at W3C TPAC; -1, new feature, not clear what the use case is.

[dmitrizagidulin]

+1 excellent idea.

[iherman]

I am of course fine with adding this property, which is indeed missing. But there is more, see below

Here is what I think must be done (see also #1263 (comment)):

• The formal definition of the property is at § 5.4, but that is a complete section. For all the other properties there is, somewhere in the spec, an anchor, usually a <dfn> statement for the term, which is the proper anchor for the property to refer to from the vocabulary. I would think that, at least, the first occurrence of <code>relatedResource</code> should be enclosed in a <dfn> tag.
• The current interpretation of the text clearly says that the domain is a verifiable credential. Just as for issuer, as described in my comment elsewhere, there is nothing in the text that would allow me to also add a verifiable presentation to the domain. I understand this is part of the current issue; what I am saying that this statement must be part of the VCDM spec for this to be added to the vocabulary.
• The range of this property is any Resource (but not a BNode).

However, it turns out that the VCDM spec includes two more properties:

• digestSRI's domain is any Resource (but not a BNode), range is, at first approximation, xsd:string (ideally, a datatype that describes exactly what the value looks like).
• mediaType's domain is any Resource (but not a BNode), range is, at first approximation, xsd:string (ideally, a datatype that describes exactly the media type string).

These two properties are not only missing from the vocabulary, but also missing from the context!

Note that, for the mediaType, an alternative would be to use the term encodingFormat instead, referring to http://schema.org/encodingFormat. Do not reinvent the wheel, and all that... That would mean just add an entry to the context file, and this property is oblivious to the vocabulary.

I am happy to create a PR with all these changes, if we have an agreement.

@dlongley @msporny

[jandrieu]

This feels like a new feature. Am I missing something?

[Sakurann]

I think one question raised during TPAC WG mtg was "what use-cases relatedResource in presentations are not addressed by relatedResouce in credentials"

To validate that a resource referenced by a verifiable credential is the same at verification time as it is at issuing time, an implementer MAY include a property named relatedResource that stores an array of objects that describe additional integrity metadata about each resource referenced by the verifiable credential. If relatedResource is present, there MUST be an object in the array for each remote resource for each context used in the verifiable credential.

[iherman]

The issue was discussed in a meeting on 2023-09-14

• no resolutions were taken

View the transcript

2.2. Add relatedResource to VerifiablePresentation (issue vc-data-model#1265)

See github issue vc-data-model#1265.

Brent Zundel: Raised by Orie, who isn't able to attend today.
� Is it a good idea? Why?

Manu Sporny: we. have the concept of relatedResource.
� It allows us to refer to files outside a VC using a cryptographic hash.
� E.g. instead of embedding an image, you can refer to it with a cryptohash.
� We have that capability in VC, we don't have it for VPs.
� Unclear to me what the use case is for this. But sounds like a generally useful thing to have.
� I don't think it causes any harm having that feature. I'd be interested in hearing from the group on whether it's useful to have.

Joe Andrieu: Sounds like a new feature after the feature freeze. There are other ways of doing this by adding it to a presented VC.

Sebastian Crane: I would like to raise a potential issue that this means that a VP cannot be understood fully offline.

Joe Andrieu: just make a VC that says here's a related resource.

Manu Sporny: that's correct. This also happens if you haven't cached the context.

Joe Andrieu: holders can issue VCw.

Joe Andrieu: VCs.

Brent Zundel: +1 that handling this differently than the way additional data about the VP is handled would be inconsistent.

Manu Sporny: realted to what JoeAndrieu said, we don't have a way for the holder to do that.

Brent Zundel: we agreed on the mechanism in which the holder can make statements about the presentations.

Manu Sporny: yes, that's a good point. Had forgotten about that.
� that's a mark against this feature.

Ivan Herman: We have an open issue to look at all the properties that we have in the VC, to see which ones can be applied to VPs as well. This is related.
� I just translated what is in the spec to the vocab.

Brent Zundel: We'll get to it as some point today.

Joe Andrieu: If we had a good use case, it would be a different convo. Agree with seabass that we need a way to comm images. Will be tough with feature freeze.

Brent Zundel: Wrap up, thanks all. Back in 30 min.

Eric Siow: Thanks. I was about to ask.

Kristina Yasuda: I looked at the issue. Its a bit different than what we talked about before break.
� there's a broader application of a common feature, then that's viable.

Manu Sporny: looking at it again, I think Kristina is right. The intention is to do something different from what linkedResource does in DIDs.
� this is badly titled.
� This points to graphs by id. So that's problematic.
� still struggling to understand the use case.

Kristina Yasuda: +1 to ask Orie for clarification.

Dmitri Zagidulin: use case-wise I think I understand.
� not sure about the graph node. its the ability to include non VC resources in a VP.
� like here is PDF that is a part of something.
� and bind that to the same authentication.
� the same thing that linkedResources does.

Manu Sporny: each time I re-read the issue, my understanding changes.
� What you said Dimitri suggests it is related to relatedResources.

Dmitri Zagidulin: yes! attachments!

Brent Zundel: another interpretation? Gen has been discussing how to add attachments to credentials and presentations.
� the primary response is that we need more clarity from Orie.

Manu Sporny: plus one for the attachment use case.
� we can do that withthe VC.

Dmitri Zagidulin: the binding time is different, for a VC vs VP.

Joe Andrieu: I think the attachment use case is more problematic w/ feature freeze, we should table this for the next version.

Brent Zundel: any objection to adding this as future.

jose-gataca: jose-gataca has joined #vcwg.

Brent Zundel: chairs will have a conversation about feature freeze.

[jandrieu]

I think it's likely a mistake to add arbitrary resources to a presentation. If the verifier didn't request it, it's going to be weird.

If the verifier did request it, I think the likely path is as a VC, e.g., requesting a VC with a photo of the user and getting that VC is much more appropriate than arbitrarily shoving an image in the presentation. And how do request protocols handle requests for arbitrary data?

Doing it outside the VC flow raises questions. How does the verifier ask for the right asset? What happens if you don't have it? These augmentations are potentially interesting, but right now, we haven't explored how we support it.

I think this is too much of a new feature that isn't just a replication of what happens with VCs, it creates new questions and problems that need additional analysis and consideration.

[iherman]

As also agreed at TPAC, I will submit soonish a PR taking care of #1265 (comment). Reading through the comments, I do not think there is a consensus on adding VP as a possible domain for related resource, so I propose to keep it for VC only for now. (It is easy to change that later if we decide to do so.)