What part of a TD can a TDD modify

[egekorkan]

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:

• id
• registration (although with TTL this is also not super clear)
• maybe version (see Influence of UPDATE or PATCH operation on version #255)

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]

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]

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 farshidtz/wot-discovery-testing#29

[mmccool]

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]

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]

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]

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]

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: #464

[lu-zero]

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]

On why base should be patched:

• It is possible to have a TD with a relative Form and empty base because of rfc3986 5.1.3
• Once it is stored in the Directory either we rewrite the forms or we write the base otherwise the implied base is surely wrong.

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]

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.