search

w3c / wot-discovery

Repository for WoT discovery discussion
https://w3c.github.io/wot-discovery/
Other
19 stars 17 forks source link

What part of a TD can a TDD modify #257

Open egekorkan opened 2 years ago

egekorkan commented 2 years ago

Is the modification of a TD by the TDD left intentionally unspecified? Do I, as a TDD consumer, have any guarantees on what can change and what cannot? I know that registration object can be added but can the TDD add other fields, if it is doing so, is it violating any assertions? Due to some bugs in the TD spec (like unit having a %), it is already not exactly possible to guarantee round-tripping. These are small things but from the spec it seems as if TDD can even change affordance names, protocols etc.

My guess is that it is not intentionally left unspecified and anything but the following MUST be conserved:

It would be interesting to discuss whether TDD can add/remove default values for the cases where the Thing or TDD wants to reduce storage space.

mmccool commented 1 year ago

We should discuss and decide whether to add assertions to prevent a directory from modifying TDs. There are valid cases where we might want to do so (e.g. the directory is for endpoints exposed by a proxy...) but also (potential) security risks.

If we DO decide to add assertions we have to do it prior to CR, so I'm marking this as Resolve by CR.

farshidtz commented 1 year ago

We can't always enforce that because semantic databases can return TDs that are semantically equivalent but not equal JSONs. We faced a few issues in the testing tool because it was performing a deep comparison of input and output JSON objects; see https://github.com/farshidtz/wot-discovery-testing/pull/29

mmccool commented 1 year ago

I agree that insisting that input and outputs match exactly is hard, but to address Ege's point, is there any information we want to insist should be conserved? I can see various cases where rewriting may be necessary, but we could also say that a new TD (and id) should be created in these cases. But then we get into id-of-a-TD vs. id-of-a-Thing issues again.

We could also add a vague assertion that the information conveyed by the TD should not change.

egekorkan commented 1 year ago

I would avoid a vague assertion. It's better to not put one. We can say that affordance names, data schemas should not change? I'm guessing that form and security content can change in case of proxy or gateway.

mmccool commented 1 year ago

The original intention is that TDs would not be modified, except for the enriched data, and possibly adding @context (to support enriched data) and ids. Right now there are specific statements about what particular things can be changed, but no specific assertion that other things CANNOT be changed.

We could have a resolution (included in the CR transition resolution) to add an assertion: "Except where explicitly specified, the content of registered TDs SHOULD NOT be modified."

mmccool commented 1 year ago

At this point we can't add assertions, so the original issue was resolved by CR in favor of not adding new assertions. However, let's discuss this again however in the next charter, since if we want to support signing we will have to deal with this.

benfrancis commented 1 year ago

Note that if the client of the Directory Service API is a Consumer rather than a Producer of a Thing Description it is registering (i.e. it discovered the TD from elsewhere), no guarantees can be made about the integrity of the Thing Description since the Consumer may have modified any part of it before registering it in the Directory.

Signing could help here, but signing will be tricky if some parts of the TD (i.e. @context, id and registration) may be modified by the Directory client or server.

See also: https://github.com/w3c/wot-discovery/issues/464

lu-zero commented 10 months ago

I'd add to the list also base since something between directory and discovery may have to patch up base if it is omitted as we noticed with @benfrancis when we tested @sifis-home / @wot-rust demo-things

lu-zero commented 10 months ago

On why base should be patched:

In the case of signed TD, either we require that in order to sign the base must be populated or we'd provide the original TD through a link so the consumer may cross validate the two descriptions and decide what to trust.

danielpeintner commented 10 months ago

In the case of signed TD, either we require that in order to sign the base must be populated or we'd provide the original TD through a link so the consumer may cross validate the two descriptions and decide what to trust.

For signing a TD I think it is "safer" to require hrefs to be absolute and no base to be used.