Imprecise definition of what should be secured in a VP

[iherman]

In the section "Securing Mechanisms Specifications" the text says (defining what exactly is secured in the case of a VP):

In a verifiable presentation, the property MUST secure the default graph of the presentation as well as every proof graph related to each verifiable credential in the presentation.

But this is not entirely precise. In my view, it should say:

In a verifiable presentation, the property MUST secure the default graph of the presentation as well as each verifiable credential with the related proof graph in the presentation.

Why? In the case of a VP, each credential is a separate named graph, which is then secured by a proof graph (see Figure 9). The original text may be read as if only the proof graphs should be secured, forgetting about the credentials themselves.

(I am happy to make a PR of course, if there is agreement.)

cc @msporny @dlongley

[msporny]

@iherman I'm fine with your language, though we might ALSO want to point to @dlongley's new text in DI on the matter, which is more generalized:

https://w3c.github.io/vc-data-integrity/#proof-graphs

We can fine tune the language once you've been able to raise a PR; please raise a PR.

[iherman]

@iherman I'm fine with your language, though we might ALSO want to point to @dlongley's new text in DI on the matter, which is more generalized:

https://w3c.github.io/vc-data-integrity/#proof-graphs

I do not think it is appropriate; this would become a dependency on DI.

Actually... I wonder whether it is not the other way round. The text in the DI spec is a bit general (and that is perfectly fine), and the definition of what has to be secured in the case of VCs and VPs is in the VCDM spec, ie, this is where the generality of DI becomes more specific.

We can fine tune the language once you've been able to raise a PR; please raise a PR.

Raised #1515.

[iherman]

The (accepted) comment from @dlongley reuses his terminology, and does not point to the DI text. That indeed sounds fine!

[msporny]

PR #1519 has been merged to address this issue, closing.