~ tighten up definition of LDI deliverable

[ericprud]

email discussion: http://www.w3.org/mid/20210510075552.GA3113626@w3.org

---

Preview | Diff

[iherman]

Closing (it was against a different, old branch...)

[iherman]

The diff is very outdated, it seems to refer to a diff to another branch:-(

[ericprud]

oh what the hell? it didn't look like that a minute ago! reworking...

[iherman]

@ericprud, sorry about that, but what would be cleaner to start from scratch: start with the latest main branch, and edit that one. This is way too confusing and error prone...

[ericprud]

Take a look now. diffs are confined to the appropriate area.

[iherman]

A commyon the proposal: I would not want to keep that reference to xml signature. The comparison with xml signature has already been used a lot against this work (see the separate note in the explainer). Firm -1 from me on this.

[iherman]

Take a look now. diffs are confined to the appropriate area.

Pfew...

[ericprud]

The xml sig ref was just to help people understand embedded sigs, which is what ld-proofs defines. I've commented it out in the interest of getting the more important clarifications through.

[mmccool]

One comment above mentioned that it should be possible to sign a subset of an RDF dataset. There is also the need for "chained" signatures. Both of these arise in WoT use cases:

• A TD might include components from multiple sources, each with a signature. The final TD will also have a signature.
• A Directory might add additional metadata to a TD (such as expiry date/time), and want to do that in a way that does not disturb existing signatures, and allows a consumer to confirm that the original was not modified.
• A Shadow (digital twin) may want to change URLs to point to the twin rather than the original device, and maybe augment the data models, but not otherwise update the interactions.
• A Thing Model may have a signature, but instantiating that TM (which describes a class of things) as a TD (which describes a particular instance) requires filling in templates. This case is peculiar since it may involve filling in template parameters in URLs... and we want to ensure that the rest of such URLs are not changed, only the template parameters. This particular case may be handled by a different kind of "proof", however (e.g. a proof that the TD is an instance of a particular TM, signed perhaps by a validator).

One of the technical problems that arises is how to identify the subset that is signed. We are particularly interested in the case of JSON-LD. We looked at using vocabulary prefixes (that has problems, though, including aliases; a better way to identify the subset of the vocabulary affected might work, though) and JSON pointers (which let you select particular structures). JSON pointers work on the serialization but I can't help but wonder if there is better way.

Some of use also wonder about the relationship with DIDs. In particular, embedding a signature in a DID or proving that a DID references a particular LDS dataset would be useful (this may already me mentioned, however).

[iherman]

@mmccool I wonder whether it would not be possible for you to contribute with a short use case concerning these features. The explainer document contains a set of use cases and having a WoT use case would be great. You can either create a PR or give me some more succinct text and I am happy to add it to the text.

The question is whether there is anything that should be reflected in the charter text, either in its incarnation in this PR or in the slightly different, alternative PR #80. (Knowing that the charter should not go into too much details.)

I believe the DID question is out of scope; it will have to be answered by the DID Working Group (now or next version). Same for the JSON-LD question: how to decide what URL to use to identify a dataset or a sub-set is not something this WG should specify...

[msporny]

@mmccool here's an unsolicited quick sanity check on the WoT use cases:

• A TD might include components from multiple sources, each with a signature. The final TD will also have a signature.

Yes, this is supported today, you can embed signed Datasets in other signed Datasets... and specifically, in JSON-LD it doesn't result in the same 33% base64 bloat that the JOSE stack does.

• A Directory might add additional metadata to a TD (such as expiry date/time), and want to do that in a way that does not disturb existing signatures, and allows a consumer to confirm that the original was not modified.

Yes, this is supported today.

• A Shadow (digital twin) may want to change URLs to point to the twin rather than the original device, and maybe augment the data models, but not otherwise update the interactions.

I'm less sure about this use case. It feels like the same use case as the one above.

• A Thing Model may have a signature, but instantiating that TM (which describes a class of things) as a TD (which describes a particular instance) requires filling in templates. This case is peculiar since it may involve filling in template parameters in URLs... and we want to ensure that the rest of such URLs are not changed, only the template parameters. This particular case may be handled by a different kind of "proof", however (e.g. a proof that the TD is an instance of a particular TM, signed perhaps by a validator).

Sounds like you want to sign a template signature, verify the template signature, and then ensure that only template values are changed. This can be done by layering logic on top of what the LDS WG is going to do, but I'd suggest the "validate that you used a signed template and modified only the template values" part is something that might be WoT specific.

One of the technical problems that arises is how to identify the subset that is signed.

The LDS approach is an "all or nothing" signing approach. You either sign the entire Dataset or none of it. We don't allow signing subsets of a dataset and then expressing the signature like JOSE does (that leads to all sorts of terrible "the developer then uses values that weren't digitally signed thinking that they were digitally signed" security failures). That said, all of this doesn't sound as dire as it may seem... you can always encapsulate signed objects inside unsigned objects and know what was signed and what wasn't signed. The LD Signature libraries drop unsigned properties on purpose so developers don't accidentally use unsigned properties after they've verified a signature.

... I'm sure we'll re-hash all of this in the LDS WG when it becomes active.

[danbri]

I don't have any other view on the current proposed changes in this PR (@iherman asked), except that the WG ought to be nudged away from spending W3C time on the planet-melting stuff.

eg. something like:

The WG acknowledge the TAG guidance to consider potential environmental impact of technologies, e.g. concerns around proof of work.

[iherman]

I don't have any other view on the current proposed changes in this PR (@iherman asked), except that the WG ought to be nudged away from spending W3C time on the planet-melting stuff.

eg. something like:

The WG acknowledge the TAG guidance to consider potential environmental impact of technologies, e.g. concerns around proof of work.

The charter does not refer to proof of work any more. Some use cases may refer to ledgers somewhere, but I do not see how this TAG reference would be relevant in the charter/explainer.

[iherman]

This proposal has been further improved by #80 and now merged, making this proposal moot...

Closing