Web of Things Working Group Charter

Scope

The Working Group has four items in scope to enable interoperability across IoT platforms:

Of these, the first deliverable, the normative Thing Description standard, is central, with the other items playing supporting roles. The Scripting API is also normative but simply serves to provide a standardized and convenient way to access the functionality of the Thing Description from a programming language in order to build concrete applications. Binding Templates are informational and provide mappings to concrete protocols. This deliverable also provides templates for describing further protocol mappings through the Thing Description. The Security and Privacy deliverable is normative, but while considered separately, its implementation is integrated into the other deliverables.

Details for each of these are given below.

Thing Description

The Working Group will develop solutions to describe Things through metadata and declarations of their capabilities (e.g., possible interactions). This work includes the definition of different machine-understandable vocabulary sets as well as serialization formats of such a Thing Description. The Thing Description will be aimed at enabling scalable and automated tooling, including but not limited to search, automated bridging, service composition, validation, and development abstractions. While enabling the use of powerful tooling, the Thing Description will be designed in such a way that even constrained devices can use it. In particular, for basic usages there will not be an explicit dependence on RDF and it will not be necessary for constrained systems to perform explicit semantic processing. However, to enable more complex usages, the Thing Description will include extension points to allow the use of semantic vocabularies and tools (e.g., Linked Open Data, Schema.org, Resource Description Framework (RDF), semantic reasoners, etc.).

The Thing Description will include the following components:

• A common vocabulary for describing Things in terms of the data and interaction models they expose to and/or consume from applications (e.g., interaction patterns such as Properties, Actions, and Events as described in the WoT Interest Group current practices document). This vocabulary will cover Thing lifecycles, datatypes (including streams and integrity constraints), and provision for early and late binding. This cross-domain vocabulary will be designed for use in combination with vocabularies for domain-specific semantics and metadata.
• A common vocabulary for security and privacy metadata as a basis for platforms to determine how to securely interoperate. This will build upon emerging standards and best practices for securing exchanges, including metadata relating to authentication, authorization, secure communication, and privacy policies. It will support, but not mandate, the utilization of online trusted third party services such as authorization servers. It will support a variety of security token form factors of established serialization formats, domain-specific security token contents (e.g., building automation), and various security models. It will support a variety of protocols for their acquisition and for transportation. Support for secure communications will consider transport as well as application-level security.
• A common vocabulary for communications metadata. This will enable platforms to determine how to interoperate given a choice of protocols, data formats, and encodings, as well as different communication patterns, e.g., push, pull, pub-sub, and peer-to-peer. Communications metadata may be needed to describe the multiplexing of data from different sensors, different approaches to buffering data, and the interoperability requirements for communicating with battery-powered or ambient-powered devices that spend a lot of their time asleep to conserve power.

Serialization formats for the Thing Description suitable for use by resource-constrained platforms will be provided and designed to appeal to application developers. The encoding shall allow for resource-efficient instantiation of the software objects that reflect the data and interaction models of Things. Where practical, this will be based upon existing formats and encodings (e.g., EXI- or CBOR-compressed JSON-LD).

Scripting API

The Working Group will seek to specify an API exposed to applications covering the following:

• Interactions with Things and reactions/handlers to provide the functionality of a Thing. This includes APIs both for applications acting in the client role interacting with a Thing as well as APIs for applications in the server role, exposing a Thing.
• Discovery for local and remote cases, abstracting away from the details of the discovery mechanisms. This will cover a range of approaches: Things on the same host, Things nearby, Things on the same network, Things listed in a repository, and discovery based upon formal or crowd-sourced semantics and social relationships. The API will support a Thing lifecycle including registering and creating Things, either from a Thing Description or using scripting. The API will make applications aware of lifecycle transitions.
• Cross-platform security frameworks including authentication, authorization, and secure communication, as well as the means for their establishment through provisioning of metadata and keying associations. This will enable the use of security frameworks, such as IETF OAuth and ACE, according to the specific tasks for the client (e.g., security credentials acquisition and supply), and for the server (e.g., security token enforcement and validation), as well as common tasks (e.g., registration). A goal is to decouple applications from the implementations of the security frameworks. This introduces online trusted-third party components to which constrained WoT components delegate specific processing tasks (such as authentication and authorization). It requires trusted assertions that report about such processing events as well as protocols to trigger such processing.

Where practical, APIs will be defined in ways that are independent of the choice of programming languages. The scope includes APIs for User Agents/browsers as well as APIs for faceless applications in a runtime environment such as Node.js. The underlying assumptions and contracts between the runtime environment and the application (e.g., security policies and callback signatures) will be well-defined.

It should be emphasized that this is a secondary deliverable and in case of conflicts, the Thing Description deliverable will have priority.

Binding Templates

While the Thing Description will provide general mechanisms to describe arbitrary protocols, to enable interoperability, the Working Group will define standard binding templates for common protocols. These standard binding templates will be created in close collaboration with the industry alliances and standards development organizations responsible for these. This includes definition of mappings from the interactions at the Thing Layer to:

• Transfer layer communication patterns such as push, pull, pub-sub, bi-directional messaging, etc.
• Specific protocols at the transfer layer, e.g., REST-based protocols such as HTTP and CoAP, pub-sub protocols such as MQTT, and raw channel-based protocols such as WebSockets

The Web of Things has a multi-protocol architecture and bindings to both IP and non-IP transports (e.g., Bluetooth Low Energy) may be defined.

Support for secure communications will be included, as defined by the Security and Privacy deliverable.

The Binding Templates deliverable is informative by nature since the intended capabilities of the Thing Description could be used to describe any protocol, even common ones, from first principles. However, interoperability will be enhanced by providing and encouraging the use of standard binding templates for common protocols when possible.

Security and Privacy

The mechanisms for security and privacy must be cross-cutting over the descriptions, scripting APIs, and bindings. The Thing Description and the Scripting API will support both transport and object security using best practices, and the Binding Templates will support the use of appropriate security for the protocols they map to.

In order to enhance the security of WoT systems, we will also generate and implement a security testing plan which will include both functional and adversarial testing of the proposed standards and their implementations. We will only recommend an implementation of the proposed standards for use in production once it has passed such testing.