What does "onboarding" involve?

[benfrancis]

The details document, and potentially the charter, talk about "onboarding" as a work item.

In this work item we will define mechanisms to perform secure minimum-effort onboarding of Things that conforms to the security and privacy requirements of specific deployment scenarios and use cases.

It's not clear to me, and others, what this would actually involve in practice. A more concrete example would be helpful.

[egekorkan]

btw, the details document currently has (see here):

Define lifecycle process to establish mutual trust and identification.

[mmccool]

Yeah, I should not define onboarding in terms of itself. I can see about coming up with an improved definition. But basically it's about provisioning keys (if devices do not already have them or don't have good enough sources of randomness to create them) and then recording the public keys/certs of trusted devices (e.g. "establishing trust") e.g. pairing.

[benfrancis]

@mmccool I'm familiar with this kind of process from protocols like Zigbee, Z-Wave, Bluetooth, HomeKit and WPS where devices are paired with a client or hub of some kind at the network layer. I am struggling to imagine how it applies to the Web of Things at the application layer though.

• Onboarding what to what? A web thing to a directory? Isn't that just registration? A web thing to a Consumer? Isn't that just consuming a TD?
• What are the "keys" used for in the context of WoT?
• What needs specifying in a WoT specification (as opposed to being an implementation detail)?

There is a mention of "Bootstrapping (or onboarding)" in the lifecycle section of the WoT Architecture specification, but the only example given in the context of WoT is registering a Thing in a Directory, for which there is already a specification.

The only example of something like this I can think of from my own implementation experience is the need for a Consumer to store credentials (e.g. a Bearer token) for accessing Things, so that a user doesn't have to be prompted for credentials every time an interaction occurs. That doesn't sound like what you're describing though.

I don't think that "onboarding" should be mentioned in the charter as something in scope for the WoT WG unless we have a shared understanding of what it means. Sorry if it's just me that doesn't understand it.

[mmccool]

Generally what we want to establish is a "set" of devices that trust each other and have access to information (such as public keys stored in certificates) that let them confirm the identity of each other and set up secure communications.

In the simplest case this could be done pairwise, e.g. providing two devices with mutual information about each other that let them validate the identity of each other and from that, establish secure communication with each other. As part of this pairing you also assert that the devices have a certain level of authorization to access affordances on each other (e.g. assert trust).

In a more complicated case you want to establish trust among a set of devices, which could be done via a "hub" (e.g. each devices registers with a central service, but the operation it provides is "introducing" devices to each other and automating paired trust), or having all devices in the set use a shared certificate (that would then be used to bootstrap paired trust when needed), which is all a "hub" service would really do.

The "onboarding" is really about including a new device into a circle of trust (set of devices that share trust with each other).

The problem we need to solve is essentially to support encryption on a LAN, which means finding a way to distribute public keys and confirming that they are valid without CA roots of trust or things like fixed URLs.

Practically, I think we need to define first how a Consumer and Thing can "pair" with each other, e.g. trade (possibly self-signed) certificates with each other and confirm the authority of the Consumer to access (some subset, probably defined by scopes) of the Things affordances. This "confirmation" process could have several alternatives, including pushing a button within a certain time, using the "device" OAuth2 flow, entering a pin code, etc.

Based on "pairwise" onboarding, I think we can define a special role for an "Onboarding" service that can pair with a new Thing and then transitively transfer trust to another set of devices that have already been paired, establishing the "set". It would be convenient, but not actually logically necessary, to also register the TDs with a TDD at this point, but technically discovery registration and onboarding are a different points in the lifecycle. First you establish trust. Then, once that is done, you can register metadata for discovery.

We need to sort out some details on this. I will work on a draft PR to try and capture some of this in the details document, then we will discuss in the Security call next week to refine it, then hopefully we can close this issue in the main call next week.

[benfrancis]

@mmccool Thank you for taking the time to write a detailed explanation.

On the surface it sounds like what you're trying to achieve is TLS on local networks, for which there is a dedicated W3C Community Group. I would suggest a liaison with that group so that any proposed solutions can be shared, since they could have applicability outside of IoT and there's potentially a lot of expertise in that group for reviewing solutions.

There seems to be more to this though because you talk about securing direct Web Thing to Web Thing interactions on a local network (which is not something I have seen done in practice or have experience of myself), and also a pairing/provisioning process which could go all the way down the hardware level and is usually something would happen outside the scope of WoT. My instinct is that these mechanisms should be outside the scope of the WoT Working Group and in general should be handled by lower level network protocols, but I don't think I understand the use cases well enough to say that authoritatively.

Ideally I think this is an area which could benefit from incubation in the WoT Community Group or Interest Group who could come up with a more concrete set of requirements and even a prototype solution, but since those groups are not really very active in those kinds of activities I don't object to this being done in the Working Group.

I would be interested in a solution which allows TLS to be used on a .local domain or local IP address by an IoT gateway or device. We did do some work in this area trying to find a way to use WebThings Gateway securely on a local network, and whilst we came up with several promising potential solutions nothing really worked (using existing web standards).

[relu91]

Interesting discussion, I don't have too much to add regarding the definition of the onboarding process @mmccool description is sufficient but I agree with @benfrancis that we are close to something that it could do outside the WG by other low-level web standards.

What I wanted to say is that I like the idea of using WoT as an explorative group for experimental features as it was originally conceived. Still, the relationship with WG is quite delicate right now... so maybe it could be something for the next CG charter.

[mmccool]

I agree this is a big task, but the community group you mentioned has not made much progress in many years - but I agree we should engage with them. IETF also has groups working on similar things, but focused on CoAP. DID and SSI are also related. In short, though, IoT is one of the main motivators for doing secure TLS on a LAN.

However, I also agree that doing some incubation here first would be a good idea, so it doesn't necessarily need to be a WG work item in this charter. But in my opinion the problem needs to be solved or WoT is incomplete.

I should also say the primary use case should be focused on Smart Home. Other domains (Factory, Smart Building, Smart City etc.) will either have their own key management systems or can use CAs on the public web. For Smart Home though a way to set up keys/certs easily for use on the LAN is needed.

[benfrancis]

@mmccool wrote:

For Smart Home though a way to set up keys easily is needed.

I agree that in the smart home there's a need for assigning local certificates and establishing a local chain of trust, but in our experience with WebThings we found it's a hard problem which probably can't be solved by WoT alone (I probably shouldn't get too much into details here, but see an overview below*).

@relu91 wrote:

I like the idea of using WoT [CG] as an explorative group for experimental features as it was originally conceived

This does seem like exactly the kind of topic which could be explored and prototyped in the WoT CG or IG in order to arrive at a concerete set of requirements and a prototype solution. I see no reason that couldn't be done regardless of what it says in the charter. It may be that the resulting solution actually needs to be proposed somewhere other than the WoT WG, like the IETF.

I'm not necessarily saying "onboarding" shouldn't be in the Working Group charter (either this one or a future one), just that it still seems quite loosely defined.

---

*We did some experiments merging a smart home hub with a router, so that the hub acts as the DHCP server on the local network which assigns IP addresses and tells clients to use a local DNS server which resolves a fully qualified domain name to a local IP address, using a regular TLS certificate. We also experimented with the hub acting as a local certificate authority which could sign certificates for .local domains which are only unique within that network. The problem in both cases was that client applications like web browsers often configure their own DNS settings and their own certificate chain of trust and ignore network provided settings.

I'm sure it could be possible to do something more exotic which is specific to WoT Consumers and doesn't work in general purpose HTTP clients, but then that limits where Consumers can be implemented. Ideally there would be a more generic solution for HTTP defined by the IETF.

There is a little-known HTTP header called Alt-Svc defined in RFC 7838 which can "allow an origin's resources to be authoritatively available at a separate network location", so that you can use a TLS certificate assigned to a FQDN on a .local host, but for some reason web browsers only implement it as part of HTTP/2 and it only works if the Thing also has a FQDN associated with it. An Mozilla security engineer proposed a solution for entirely local origins to the Community Group, but I think that would require a new standard to be defined by IETF.

[mmccool]

Agree there is a possibility that we do not want to commit to doing onboarding in the charter itself. I suggest we merge the work item for now (this PR), but I will create another PR to take the mention of onboarding out of the charter. Later when we do detailed planning we can decide if we want to tackle this in this charter or not.

[mmccool]

I think we also need to decide if we want to be limited by the fact that browsers are not currently implementing some of the relevant standards. I was thinking we could focus more on "backend" security, i.e. device-to-device and hub-to-device. Browser-to-device and browser-to-hub may need different solutions (for example, the hub could proxy the device to a public URL-with-cert that a web browser could connect to, but the hub-to-device communication could use a separate local cert set up and managed by the onboarding process).

[mmccool]

OK, this PR removes mention of onboarding from the charter: https://github.com/w3c/wot-charter-drafts/pull/81

I still think we should do it, and would like to merge the PR against "details", but in the interest of getting to consensus and getting the charter out the door I am willing to leave out the committment from the charter itself.