Security scenarios involving HTTP and WebSockets

[draggett]

Much of the added value for the IoT is in the services rather than the devices. This emphasises the importance of application platforms and the security scenarios around their use to support open markets of services.

Web of Things application platforms host applications that produce things for other applications that consume things, where things are objects that represent abstractions of sensors and actuators. Applications that consume things are decoupled from the IoT protocols and standards used by the sensors and actuators.

IoT devices may connect directly to cloud servers which offer things to applications on their behalf. Resource constrained devices using short range communications technologies, e.g. Bluetooth and Zigbee, require a local gateway. This can host applications that provide things for use by other applications either on the gateway, or in web pages on smart phones on the same wifi network, or they can supply the things to marketplaces on Internet cloud servers.

Whilst there are many IoT communication technologies, the vast majority of use cases for communication with application platforms can be addressed using HTTP and WebSockets in conjunction with transport layer security. One approach focuses on HTTP for discovery and transfer of thing descriptions, together with authentication and access control based upon evolving best practices for the Web.

An example is where a client requests a thing description, and is authenticated by the server and authorised to access the thing via WebSockets using a time limited security permit that is passed over the encrypted WebSocket connection when the client registers the consumed thing with the server. A fresh HTTP request can be made when a new security permit is needed.

Another example is where an app on a gateway is seeking to make a thing accessible on an Internet server. In this case, the HTTP request passes a thing description to the Internet server which then authenticates the app, and authorises it to supply the thing. The security permit is then passed to the Internet server via a registration message exchange over an encrypted WebSocket connection. The security permit is never exposed to the applications.

The HTTP request should identify what needs to be authorised and on behalf of whom, the thing, the application and the user/owner. The details need further scrutiny of specific use cases, and should consider what is needed to balance security and user experience.

For example, Joe finds a new application on a web site and installs it on his home gateway. This allows Joe to access his home security system from a web app or native app on his phone when he is out of the house. For this, Joe has to set up an account with the Internet cloud based app store. The process automatically transfers the associated security credentials to the gateway minimising the effort needed from Joe.

p.s. some further background is available in the scripting task force issue 64

See: w3c/wot-scripting-api#64

[ereshetova]

Should we have a case for this explained in the "Examples of WoT security configurations" section of the security doc? Seems like a good logical place to describe this case and also talk about the measures

[mmccool]

I agree with Elena's suggestion. Discussion from meeting follows:
Dave to look at making a draft PR for this section... discuss in the next meeting.
Elena - put a new subsection at end of section 5.
If add figures, try use the same style... look in wot-security/images
Michael - it would be good to align with existing practices in this space, eg. Evrythng

[mmccool]

Best practices will be constantly evolving... best we can do is take a snapshot of current best practices.

[mmccool]

We're going to have to defer this discussion until after the FP release.

[mmccool]

Generally this is still open, and we will need to deal with it after defining suitable "streaming data" abstractions to the spec(s).