Standardizing how to describe the location of the TD

[egekorkan]

The links vocabulary can be used to describe where the current TD has been obtained from. For example:

...
"links": [{
    "rel": "self",
    "href": "https://servient.example.com/things/lamp",
    "type": "application/td+json",
    "htv:methodName":"GET"
}]
...

Would this be definitely understood as the location of the current TD and thus would allow a Consumer to refetch the TD? If so, we can explicitly state this in the specification, i.e. if a Thing wants to describe the location of its TD, it should do it this way.

This would be also useful in plugfests. There, we put TDs in GitHub but sometimes they can be also gotten from another location (like the device itself, a directory etc.). Since GitHub uses HTTPS, a Consumer needs to either have an HTTPS client library or read the TD from local storage, which I find quite inconvenient. There is a related issue in node-wot as well: eclipse-thingweb/node-wot#160

[benfrancis]

The suggested syntax makes sense to me, in that it seems like a correct usage of a "self" link relation.

I am curious though whether there is an assumption here that a client may acquire a Thing Description from a source other than its canonical URL on the web? If this is the case, and a Thing Description for a Thing can be acquired from multiple sources, how does a client deal with updates to a Thing Description if sources differ? Which is the canonical version? How can a client know that a Thing Description which claims to represent the same Thing can be trusted?

Interestingly we've had a very similar discussion in the Web Applications Working Group regarding updating Web App Manifests, whose specification also doesn't yet define a solution to this problem.

My proposal for Thing Descriptions is the same as my proposal for Web App Manifests:

1. Clients should treat the URI of a Thing Description as the unique identifier of a Thing, instead of the current id member for which a Thing Description can not be trusted to be authoritative
2. Clients can request the latest version of a Thing Description by resolving this URI
3. Clients should treat web things with different Thing Description URIs as separate web things

If this was the case, than this self link relation wouldn't be necessary because clients could index things by their Thing Description URI and know that resolving that URI will always return the latest version of the Thing Description.

Any alternative solution needs to address:

1. How web things are uniquely identified
2. How a client knows whether to trust a given Thing Description is authoritative for the identifier it provides
3. How a client gets updated versions of a Thing Description from a trusted source

[takuki]

Clients should treat the URI of a Thing Description as the unique identifier of a Thing, instead of the current id member for which a Thing Description can not be trusted to be authoritative

Note Section 6.7.2 Indirect Communication in WoT Architecture, an intermediary Servient can generate a new TD for the same Thing with a different protocol binding, for example.

An intermediary is even allowed to assign new ID for the same thing.

[mmccool]

This is related to discovery, eg. we are defining ways to define URLs to retrieve TDs from directories. I will bring it up in that meeting... and will add a label. Note that in general these URLs might have query parameters. There may also be more than one place that the same TD can be retrieved from.

Also, this is definitely under the "define link relation types" activity of the charter.

[egekorkan]

There may also be more than one place that the same TD can be retrieved from.

I agree and this can be solved by having multiple link objects. However, we would then need to describe the difference between the two.

Note that in general these URLs might have query parameters.

I think that we also need URI variables in the root/Thing level. This would also solve the problem mention here, where a meta interaction such as readmultipleproperties would need URI variables.

[benfrancis]

@takuki wrote:

Note Section 6.7.2 Indirect Communication in WoT Architecture, an intermediary Servient can generate a new TD for the same Thing with a different protocol binding, for example.
An intermediary is even allowed to assign new ID for the same thing.

Yes, here is an example of such an intermediary.

What I'm saying is that from a WoT client's point of view, the ConsumedThing and ExposedThing (to use the terminology in that document) with different URLs should be treated as separate things, particularly if they come from different origins. This is the fundamental security model of the web.

[sebastiankb]

I support this initiative to have a web link based format (at the root level) to discover all TDs . I'm agree with @mmccool that this discussion should be addressed in the Discovery TF. Due to the issue of data privacy, we should also be careful about the unique identifier topic. So, this topic should be also addressed in the Security TF.

[sebastiankb]

since more related to discovery we should close this issue

[JKRhb]

Maybe this issue could also be moved to the discovery repo?