Discuss All the layers profiles can cover

[lu-zero]

This is part of the discussion about layers and profile ecosystems

[benfrancis]

I'm not completely sure what this diagram is meant to represent, but if it's helpful my strawman proposal for a Profiles 2.0 profile includes a very concrete list of extension points which a profile can constrain, with examples:

1. Protocol bindings
2. Payload bindings
3. Security mechanisms
4. Discovery mechanisms
5. Link relations
6. Semantic contexts

This list is also now included in the Motivation section of the specification.

These are not just abstract concepts, they are the extension points defined in the WoT Thing Description specification (plus discovery mechanisms which are used to discover a Thing Description and are defined in the WoT Discovery specification).

As an aside, I'm still not clear on what "onboarding" means as distinct from discovery and security so it would be good to see examples of that.

[lu-zero]

It is made out of notes from the past week brainstorming, I think we can leverage your terminology since it is already laid out.

Tomorrow I hope we can have more discussion, with onboarding I mean any pairing, certificate exchange and so on.

[egekorkan]

Also we have created this list by thinking what different ecosystems can specify to use. So link relations and TD discovery are always out of question in there. Those can be added on top as WoT features.

[benfrancis]

@lu-zero wrote:

with onboarding I mean any pairing, certificate exchange and so on

Do you have specific examples of these from particular protocols?

My only experience of pairing in IoT is from Zigbee, Z-Wave, Bluetooth and WPS which are not directly described at the WoT layer, but are abstracted away by an Internet protocol which just assumes that pairing has already taken place at a lower layer of the protocol stack. Are there instances where a WoT Consumer needs to be aware of and directly participate in the pairing process?

Similarly for certificate exchange, in web-based protocols this tends to happen quite transparently by the underlying network stack and is not something that needs to be explicitly described at the WoT layer. I can imagine there might be exceptions to this such as exotic encryption schemes (HomeKit Accessory Protocol over HTTP comes to mind), or something like self-signed certificates which may require user intervention. Do you have examples of protocols where certificate exchange can follow an open ended range of different schemes which need to be explicitly described to a WoT Consumer and might therefore need to be constrained in a WoT profile?

@egekorkan wrote:

Also we have created this list by thinking what different ecosystems can specify to use. So link relations and TD discovery are always out of question in there. Those can be added on top as WoT features.

Makes sense. But when it comes to defining a list of "layers profiles can cover", my assumption is that a profile only needs to constrain extension points at the WoT layer. Anything which a WoT Consumer doesn't need to care about is probably an implementation detail lower down in the protocol stack and therefore out of scope for a profile.

With the exception of my queries above, most of what I see in the diagram seems reasonable.

Data structure and behaviour are things which are currently constrained in the HTTP Basic Profile (specifically for asynchronous actions), but I think we may have learnt that (at least for Profiles 2.0) these should probably be defined as defaults in a protocol binding document (referenced from a profile) rather than defined as constraints in a profile.

[lu-zero]

@benfrancis wrote:

@lu-zero wrote:

with onboarding I mean any pairing, certificate exchange and so on

Do you have specific examples of these from particular protocols?

My only experience of pairing in IoT is from Zigbee, Z-Wave, Bluetooth and WPS which are not directly described at the WoT layer, but are abstracted away by an Internet protocol which just assumes that pairing has already taken place at a lower layer of the protocol stack. Are there instances where a WoT Consumer needs to be aware of and directly participate in the pairing process?

A very simple onboarding flow is the one that tell the thing which is the network to join for its standard operation. It can be even exposed as a no-security thing that advertises itself as unconfigured over its own wifi in AP mode. This is common with wifi actuators/sensors.

Assuming we have a onboarding-bluetooth profile dictating that the onboarding information (e.g. wifi network, mTLS certificates) have to be exchanged through a bluetooth channel, the Thing and Consumer will have to have bluetooth and advertise accordingly. This is common with stuff like Vacuum cleaners and such devices having dual communication channels. (also nfc + bluetooth)

Similarly for certificate exchange, in web-based protocols this tends to happen quite transparently by the underlying network stack and is not something that needs to be explicitly described at the WoT layer. I can imagine there might be exceptions to this such as exotic encryption schemes (HomeKit Accessory Protocol over HTTP comes to mind), or something like self-signed certificates which may require user intervention. Do you have examples of protocols where certificate exchange can follow an open ended range of different schemes which need to be explicitly described to a WoT Consumer and might therefore need to be constrained in a WoT profile?

If you have mutual TLS the two endpoints have to agree on which CA to trust or even build one as part of the onboarding process and have a shared policy on certs renovation/distribution. I assume some ecosystems do have all this so a ecosystem profile has to document (and constrain) it as well. Group OSCORE should be another example.