Change on what exactly must be secured in a presentation

[iherman]

This is to answer to the issue raised in #1512

---

Preview | Diff

[dlongley]

I can't make a suggestion here, but I believe this should not be a statement about a "property" but about a securing mechanism, and it should be simplified to "The securing mechanism MUST secure all graphs in a [=verifiable credential=] not referred to by the property itself."

Similarly, the above "The property MUST define" seems more like it should say "The securing mechanism MUST define". This list should perhaps be about the requirements for the property and the new securing mechanism.

[TallTed]

I wonder whether —

Securing mechanism specifications that create new types of [=embedded proofs=] 
MUST specify a [=property=] for securing

— should become the following (which implies further changes to the bullet list, and possibly more) —

Securing mechanism specifications that create new types of [=embedded proofs=]
MUST specify an object for securing both [=verifiable credentials=] and
[=verifiable presentations=].

— (should object be [=object=]?) with appropriate bullet adjustments, such as —

The object MUST provide values for all [=properties] used by the [=proof graph=].

[iherman]

I not against making this change, but that is more complex change than what this PR proposes to do. I would prefer to finalize this PR first and, if needed, do that in a separate PR.

[iherman]

B.t.w., @TallTed, the (RDF) "object" term is not used in the core VCDM terminology, only "value".

[longpd]

With dlongley's amendments made by TallTed I support PR #1515

[iherman]

I have merged the proposal of @dlongley but I am not absolutely sure this is 100% correct. Let us take the hypothetical situation as follows.

• I use a securing mechanism using proof from DI with one of the cryptosuites.
• I also use, in the same VP (or VC) a securing mechanism that defined by the property signature.

Question: does proof have to also secure the proof graph defined by signature? In my original text, which explicitly lists what has to be secured, the answer is 'no'. In the text proposed by @dlongley the answer is, actually, 'yes'. I believe the intention is 'no', because the goal is to secure the core information in the VC/VP, but that requires an explicit listing of what is secured...

[iherman]

We should close this PR without merge, and concentrate on the more comprehensive #1519 instead.

[iherman]

The discussion has clearly moved to #1519, closing this PR without further action, to avoid misunderstandings.