New subsection on HTTP & WebSockets

[draggett]

Architecture for open markets of serviced across the Internet using Web protocols (HTTP and WebSockets) for synchronisation. This points out the need for further study of the many challenges involved

[mmccool]

One issue is that we want to avoid proposing "new" security standards, according to the charter. We just want to provide the metadata for existing standards. So... this content should be motivated by some references to some existing work in this area. It doesn't necessarily have to be a standard, but some evidence that this pattern is already in use and that we should support it. AWS IoT may use this pattern, I know they support shadowing (another word for "synchronization"). That would be worth investigating, and if they do use this pattern, that would be enough to include it, although more than one citation would be even better.

On the other hand, from my brief reading the AWS pattern is pretty simple, just a "cloud shadow" of an IoT device that can respond to deferred property set/get requests when the device is not available, not a mesh of services, and not something running on a gateway, etc.

[ereshetova]

Let's discuss this case in the next security call in more details (preferably not in last 5 minutes of the meeting, I think we need more time for a proper discussion). My thinking so far on this:

• I think this case conceptually is quite close to figures 5 in section 5.2 (look at my PR#38 from yesterday for the corrected figure) and figure 3 (section 5.1) with the main difference that WoT Client communicates directly with the Cloud and not with the gateway or device. I definitely will extend these sections to cover this case and this would be the place then to discuss the security mechanisms. This seems to be a very valid and even probable setup in practice for some use cases.

• When it comes to details, I guess the basic case can be just to use the Cloud as a service to proxy communication between WoT Client and actual device (via gateway if required). I guess this is what Michael meant with "shadowing"? As such this basic case I think is not very different from security mechanisms point of view. What is more interesting and needs discussing is the next case.

• The more complex case is really if this infrastructure becomes "open" in a sense that there is no single solution/service provider who setups the whole thing and provisions all the required credentials for successful authentication. I think this is the case Dave is interested about. Here I would need to understand a bit more on high-level model how this is thought to be deployed:

  • Who is expected to be hosting these public Clouds? Some 3rd party service? How much trust are we willing to put into this entity?
  • Does the host of a public cloud is the same entity that provides service to the WoT client devices? In case of simple browser it would mean that it gives users some credentials to access their cloud interface for some devices?
  • How information about the things (supplied by devices directly or via gateways) gets to the Clould? Who uploads it and in which stage of lifecycle? It has to be during some field deployment stage I guess, so that after devices are installed in their intended locations, they can announce to the cloud that they are ready to take requests.

I would also prefer to first forget about concrete mechanisms in this case, like HTTP or smth else and just discuss conceptually on what is happening or should happen in this scenario. We can always plug in concrete protocols later on and check how things look like.

[draggett]

I would like to note previous work on direct access to cloud servers by IoT devices in both the former EU Compose project on scalable cloud based IoT, and by EVRYTHNG.

One issue is that we want to avoid proposing "new" security standards, according to the charter. We just want to provide the metadata for existing standards.

We may have different understanding of the role of the W3C WG Note on security and privacy. I believe that the challenges are sufficiently complex that we need to encourage broader discussion and closer attention to the opportunities, requirements and potential solutions. We may be able to standardise metadata for some existing standards, but this is very much an evolving space, and we should encourage further work.

We can distinguish between backend IoT protocols such as Bluetooth and LPWAN, and protocols used for synchronisation over the Internet between web of things applications platforms. HTTP and WebSockets seem very well suited for the latter purpose. It is appropriate for us to discuss and incubate ideas for this in the Web of things IG. We can worry about charters when it is time to bring the work onto the W3C Recommendation track.

Who is expected to be hosting these public Clouds?

That question is analogous to who hosts HTTP servers on the Internet, and how these become more or less trusted. There are many entities to consider, and we can distinguish providers of cloud computing resources, operators of Web of Things servers that use those resources, the developers of web of things applications hosted by those servers, and the customers of those applications. In addition, there can be companies that attest to security, trust, rankings and reputation, etc. and others who support search across servers on different clouds. This is far from a comprehensive list.

How information about the things (supplied by devices directly or via gateways) gets to the Clould? Who uploads it and in which stage of lifecycle?

Here is one scenario - Joe purchases a smart home device. This comes with an application that he installed on his home gateway. To use the service, Joe has to create an account on a designated cloud server, and transfer the associated credentials to the app on his gateway. The app can then use these credentials to transfer the thing description to the cloud server and provision the thing on the cloud on Joe's behalf.

There are many ways that this could be realised. One possibility is with an HTTPS request that PUTs the model, and returns a security permit for use with the synchronisation protocol over WebSockets. The HTTPS request/response requires the use of Joe's credentials that were issued by the cloud server in a preceding step.

This includes a role for transport layer security certificates for the gateway and cloud server. This ensures that the thing description is only transferred to the designated server for the app. An attacker spoofing the server will be detected when the TLS connection is being established.

I am sure that there are many other possibilities, and my point is that we should be encouraging broader discussion on these. There is for instance, criticism about the failings of using OAUTH2. I therefore agree with @ereshetova that we should focus on framing the debate rather than on concrete proposals. We can then aim to provide some general guidelines, but I think it is premature to try to define metadata describing the range of possible security solutions.

[ereshetova]

Here is one scenario - Joe purchases a smart home device. This comes with an application that he >installed on his home gateway. To use the service, Joe has to create an account on a designated cloud >server, and transfer the associated credentials to the app on his gateway. The app can then use these >credentials to transfer the thing description to the cloud server and provision the thing on the cloud on >Joe's behalf.

This scenario is simple and I think just represents how initial provisioning between the device and Cloud can happen (in this case using Joe as out of band secure channel). The main question here is does the Joe uses this device beyond just solving his smart home scenarios. Is it now exposed via the Cloud to some 3rd party to use? Let's discuss it during the call today, I am still trying to grasp how complex this scenario can become conceptually.

[mmccool]

Dave, do you think you can make the next security call so we can discuss? Jan 15 would be good...

[mmccool]

No discussion on this in a LONG time, going to close. But can open again when there is a WS protocol defined...