Ambiguous step in proof chain creation

[iherman]

Step (6) in §4.2 Add Proof Set/Chain says:

Set unsecuredDocument.proof to matchingProofs.

where matchingProofs is defined to be a list containing, in essence, the list of proofs. Quoting the definition from step (1)

If proof is a list, copy all the elements of proof to allProofs. If proof is an object add a copy of that object to allProofs.

The elements of allProofs are then copied to matchingProofs in steps (4) and (5).

The question that comes up is: what does matchingProofs contain exactly? The problem I have is that the answer may be different on whether I take a “JSON View” or an “RDF Dataset” view (the latter is generated from JSON-LD using the relevant @context.

In JSON(-LD), I have

{
   …
   "proof": [{
       … claims of the proof
   }]
}

So when I read the aforementioned statements with a strict JSON goggle on, the interpretation is that unsecuredDocument.proof includes all the claims of the proof.

The situation is a bit different in the RDF Dataset view, i.e., after the JSON-LD processor has generated the RDF quads. Indeed, the value, i.e., the object, of the RDF triples containing the proof property is a graph reference that contains a DataIntegrityProof object with the claims. See a playground example which includes:

<http://example.gov/credentials/3732> <https://w3id.org/security#proof> _:b0 .
…
<https://example.gov/myProof> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#DataIntegrityProof> _:b0 .

See also Figure 6 in the VCDM.

This means that, strictly speaking, the statement above means to add the graph names (_:b0 in the example above), without the claims themselves, to unsecuredDocument.

I presume the correct interpretation is the pure JSON view. But an implementer of DI in a pure RDF environment has to be sure about this, because the distinction, obviously, affects interoperability. The “translation” of the JSON view into RDF is that the implementation has to add a reference to the proof graph and the content of the Proof Object (i.e., all the claims) in the forms of quads (referring to _:b0 as a graph component).

I propose that this detail should be made at least in an editorial note, in the algorithm.

(I wonder whether a similar issue may be found elsewhere in the algorithmic description, which may require a more general note for the whole algorithm instead of only in this section.)

@msporny @dlongley @Wind4Greg

[msporny]

Yes, we expect the "JSON view" to happen (since it ends up making the right thing happen for JSON-LD). What would you like the editorial note to say, @iherman? Something like: "literally copy the claims to the proof object, don't just inject a reference to the graph names?"

[iherman]

Yes, we expect the "JSON view" to happen (since it ends up making the right thing happen for JSON-LD). What would you like the editorial note to say, @iherman? Something like: "literally copy the claims to the proof object, don't just inject a reference to the graph names?"

Almost... I think, to be more clear, we should refer to the proof graph rather than proof object (which is not the right term on the rdf level)

"literally copy the claims contained by the proof graphs, don't just inject a reference to the graph names."

[iherman]

296 has been raised. If and when that PR is merged, this issue may be closed.

[msporny]

PR #296 has been merged, closing.