[Proposed] Web of Things Working Group Charter

Scope

The Working Group has four items in scope to enable interoperability across IoT platforms: the standardization of three individual building blocks and the integration of one cross-cutting as detailed in the sub-sections.

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 vocabularies based on triples and linkable graphs as well as serialization formats of such a Thing Description. The aim is to be compatible with existing vocabularies and tools (e.g., Linked Open Data, Schema.org, Resource Description Framework (RDF), semantic reasoners, etc.).

• A common vocabulary for describing Things in terms of the data and interaction models they expose to applications (e.g., interaction patterns such as Properties, Actions, and Events as described in the WoT Interest Group current practices document). This 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. Consideration will be given to the means for describing the stability of data models and metadata, and how they evolve over time. This is needed to manage interdependencies and is analogous to the role of metadata for package management in the Linux operating system.
• 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, and includes metadata relating to authentication, authorization, secure communication, and privacy policies. The use of such metadata will be optional (to support deployments that prefer to inform the requester via error responses rather than upfront). 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- or ambient-powered devices that spend a lot of their time asleep to conserve power.
• Serialization formats for the Thing Description suitable for processing on resource-constrained platforms 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 APIs

The Working Group will seek to specify a suite of APIs 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.
• 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.
• Thing lifecycles, e.g., registering and creating Things, either from a Thing description or using scripting and enabling applications to be aware of lifecycle transitions.
• Error handling that unifies the different error reports provided by different platforms and protocols.
• Cross-cutting concerns, e.g., internationalization, accessibility, and privacy.

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.

Bindings to Common Platforms and Protocols

To enable interoperability, the Working Group will seek to define standard bindings to common platforms and protocols 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 initially focus on transport-level security (e.g., TLS and DTLS), but also object security is considered where relevant. This task will utilize 3rd party defined security frameworks and protocols including their extension points. The profiling of their usage is in scope of this task. The specification of own (new from scratch) frameworks is out-of-scope.

Cross-cutting Security and Privacy

The mechanisms for security and privacy must be cross-cutting over the descriptions, scripting APIs, and bindings. Thus, they are detailed within the corresponding building blocks above.