unique id

[mlagally]

Without a canonical representation of a TD a consumer needs a different way to identify if two TDs describe the same thing.
unique ids are optional in the TD specification, but should be mandatory for profiles.

[benfrancis]

There is an ongoing discussion on this topic in w3c/wot-discovery#190

My view is that two different Thing Descriptions retrieved from two separate URLs should be treated by a Consumer as two separate Web Things, regardless of what they provide as an id member.

I don't agree that id should be mandatory in the Core Profile and that may not pass spec review for the same reasons it didn't pass review for the TD spec.

As a compromise, if we make Direct discovery mandatory by saying that a compliant TD has to be retrieved from an HTTP URL, then I propose that the URL from which the Thing Description was retrieved could be used as the default id, if none is provided. This would ensure that there's always an id, but not require that one be specified in the TD in order to address the issues raised on the TD specification.

[egekorkan]

unique ids are optional in the TD specification, but should be mandatory for profiles.

You can trigger a bad feedback from the wide review. Strongly discouraging id to be mandatory even though I would like to see it as well.

[mlagally]

Arch call on May 4th:
We should use "probablistically unique", we could use uuids, recommend uuid-v4
https://datatracker.ietf.org/doc/html/rfc4122

[mlagally]

Resolution: use uuidv4 for ids: https://datatracker.ietf.org/doc/html/rfc4122 and make ids mandatory

[mmccool]

I looked into UUIDs and it seems that v4 is appropriate. Versions v1-v3 are obsolete. Version v5 might be an option but v4 uses pure random numbers and v5 uses SHA-1 hashing. Version v3 also used hashing, but MD5, which is now considered obsolete (broken from a security point of view). I think v4 is the safe choice; if SHA-1 is broken in the future like MD5 was it will cause a problem.

[mmccool]

The only issue with v4 is it NEEDS a "good" source of random numbers which might be a problem for constrained devices. Therefore also allowing v5 would be ok if we are concerned about this (perhaps with some guidance on what should be used as input to the hashing algorithm; ideally it would be information that does not have PII issues; in particular it is better to hash the MAC instead of the TD; there is probably guidance in the uuid spec so I would just say "id MUST be in the format of a uuidv4 or uuidv5 URI" and leave it at that).

[benfrancis]

Making it mandatory that IDs have to be UUIDs is going to be a problem to implement in WebThings Gateway.

Firstly, I don't really agree that IDs should be mandatory, I think that the URL of the Thing Description should be used as the default identifier. But putting that aside for a moment (since requiring that the description of a web thing has a URL on the web is apparently controversial)...

In WebThings Gateway, the value of the id member in Thing Descriptions is set to a URI, the end part of which is generated by a protocol-specific add-on adapter. This usually consists of an adapter-specific prefix and then a identifying string which is unique within that adapter and may relate to an id scheme of the underlying protocol. Some examples below:

• https://example.webthings.io/things/zb-0b0257f2f3d9de21
• https://example.webthings.io/things/zwave-fd6d1b3c-8
• https://example.webthings.io/things/onvif-00526D935C7E
• https://example.webthings.io/things/Chromecast-Audio-13ccecebc2a9fc43d1f5343513d2f346._googlecast._tcp.local.

Requiring that all IDs must now be UUIDs would require deep architectural changes in WebThings Gateway, but also the cooperation of the authors of around 100 add-ons.

What is the rationale for requiring that IDs be UUIDs? I understand there is a privacy concern about immutable identifiers, but I don't really understand the rationale behind that either (see w3c/wot-thing-description#1497).

Ideally I don't think the id member should be mandatory, but failing that why can it not just be "any URI" like in the Thing Description specification, potentially with a recommendation to use a mutable UUID (in the form of a URN) in certain use cases where privacy is a factor.

[mlagally]

@benfrancis

My view is that two different Thing Descriptions retrieved from two separate URLs should be treated by a Consumer as two separate Web Things, regardless of what they provide as an id member.

I'm a bit confused about this statement, to me it is counterintuitive. If you buy a book at Amazon or in a local bookstore, it is still the same book with the same ISBN.
If you want to manage and control a physical device, it should not make a difference how you obtained the description - it is still the same device. Unique id's are required to perform this mapping. They don't have to be globally unique, which was the concern in the TD review, but unique within the same use case / application domain.

[mlagally]

@benfrancis Thanks for the concrete proposal:

why can it not just be "any URI" like in the Thing Description specification, potentially with a recommendation to use a mutable UUID (in the form of a URN) in certain use cases where privacy is a factor.

I believe that is a solution where we can get consensus.
We should also add the best practices that were proposed by @mmccool in
w3c/wot-thing-description#1497

Explicitly mentioning and citing UUIDv4 when "random UUIDs" are mentioned (note: some of the examples do not follow this advice and I would personally like to see them updated to use UUIDs rather than IDs with embedded metadata as many of them do that at present)

Adding an assertion that IDs MUST be changed when a device is offboarded and onboarded on a new system (e.g. for change of ownership). This is best practice, and WebThings in fact does it, but we don't have an assertion for it.

Add an assertion that "If possible and allowed by law, required immutable IDs SHOULD be made available through a property rather than used as the id for the TD itself". This allowed by the current text but an explicit assertion would be better.

[benfrancis]

@mlagally wrote:

I'm a bit confused about this statement, to me it is counterintuitive. If you buy a book at Amazon or in a local bookstore, it is still the same book with the same ISBN.

I think this boils down to the usual difference in assumptions about whether WoT is just metadata which describes physical IoT devices, or a software abstraction on top of IoT upon which web services can be built.

My perspective on this is that a web thing is an abstraction of a physical device as a web service, and therefore the identifier identifies the web thing, not the physical device which may be underlying it.

A web thing is an abstraction which may represent zero, one or many physical devices and a physical device may be represented by one or many web things.

Web resources are identified by URIs and those URIs should ideally not change. Therefore the URI of the Thing Description could be sufficient as an identifier of a web thing.

why can it not just be "any URI" like in the Thing Description specification, potentially with a recommendation to use a mutable UUID (in the form of a URN) in certain use cases where privacy is a factor.

I believe that is a solution where we can get consensus.

That would be fine.

[benfrancis]

That would be fine.

Unless TD 1.1 requires ID rotation, in which case requiring an ID may suddenly become a lot more complicated to implement.

[mlagally]

There's an ID Proposal in #271