Reformulation of the LDI deliverable description

[iherman]

Trying to move ahead on #73, this is a proposal largely taking over the proposal in #73, but also avoiding the pitfalls that were mentioned in the comments of that PR and elsewhere.

In particular, there is no explicit reference to proof of existence, etc; the only explicit concept is 'proof of (data) integrity'. On the other hand, the description is open ended and the intro part has now a reference to the explainer document where other examples (eg, BBS+) is also mentioned.

cc @danbri (github does not allow me to put you as a reviewer...)

---

Preview | Diff

[danbri]

This looks like an improvement

[dlongley]

@philarcher,

I think the point about signing individual graphs, and therefore possibly individual triples, is an issue the WG will want to consider.

I read this:

The group defines that framework to work with RDH, although the hashing algorithm, and other constituents of proofs of integrity, are identified as assertions, allowing the same framework to be used with other algorithms

As allowing different algorithms that may sign individual quads. Certainly BBS+ signatures (which depends on this work and is mentioned here) will use a form of group signatures to allow for selective disclosure of individual quads within a fully canonicalized RDF dataset.

[gkellogg]

Bikesheding here, but it might be worthwhile for the group to define a shape that can be applied to a dataset to derive a subset of the original dataset that can be signed/verified. Unfortunately, neither SHACL nor ShEx work on datasets, as that would be a natural way to describe such shapes. SPARQL CONSTRUCT or JSON-LD framing could be such a mechanism for defining a resulting dataset.

This would allow signing just the default graph of a dataset, for example, or can be used to refine the special case where the signature is removed when re-calculating the signature.

[dlongley]

@gkellogg, jfyi, BBS+ LD signatures uses JSON-LD framing to filter out parts of the dataset for selective disclosure. This WG won't be taking on standardizing that sort of thing, but I'm sure it could be mentioned informationally (and we certainly could refer to in-progress BBS+ specs somewhere). I don't think we need to change the charter to be able to do so.

[iherman]

Bikesheding here, but it might be worthwhile for the group to define a shape that can be applied to a dataset to derive a subset of the original dataset that can be signed/verified. Unfortunately, neither SHACL nor ShEx work on datasets, as that would be a natural way to describe such shapes. SPARQL CONSTRUCT or JSON-LD framing could be such a mechanism for defining a resulting dataset.

This would allow signing just the default graph of a dataset, for example, or can be used to refine the special case where the signature is removed when re-calculating the signature.

I am fully with you, @gkellogg, the WG should indeed do this. But, at this moment, I am selfishly and stubbornly considering the charter text only :-). And I do not believe that such details should be added to the charter...

[pchampin]

@gkellogg re. the use of shapes to restrict the graph/dataset to be signed, @danbri and I came to a very similiar idea. And also to the conclusion that the LDI deliverable would offers a generic enough framework to express that kind of thing. @iherman +1 to defer that to the WG.