Web of Things Working Group Charter

Scope

The Working Group has the following work items in scope:

Details for each of these are given below.

Architectural Requirements, Use Cases, and Vocabulary

The WoT Architecture specification includes the definitions of several terms and concepts used to define WoT specifications. These are often related closely to use cases and architectural patterns. As WoT implementations mature, it will be necessary to understand and describe the requirements for new use cases, architectural patterns, and associated concepts and vocabulary. In addition, descriptions of existing use cases and architectural patterns may need to be revisited to include these new concepts.

Link Relation Types

The WoT Thing Description (TD) includes a link mechanism to declare (potentially bidirectional) relationships between a TD and other entities identified by URIs, including but not limited to Thing Templates and other TDs. Each link includes a relation type which specifies the purpose of the link. To maximize interoperability, relation types for specific purposes should be identified. In collaboration with the WoT Interest Group and after use-case analysis, the Working Group will identify relation types of particular interest and specify their use for suitable use cases.

Candidates for link relation type specification may include type-of and part-of relationships to support Templates and Components, respectively. Other link types may be used to identify location or controller-controlled relationships, or implementation of specific network APIs.

Interoperability Profiles

The WoT Thing Description (TD) provides a general framework for describing the interface to a Thing independent of the network protocol, data encoding, or security mechanism used. TDs are defined to be extensible, since IoT protocols, data encodings, and security mechanisms are constantly evolving. However, this openness works against interoperability since it is not clear in advance what technologies must be supported by a given implementation of a TD Consumer, and a TD Consumer can only work with Things using the technologies it includes an implementation for.

In many contexts, "plug and play" interoperability is desirable. For example, in the Smart Home context, the consumer needs to know in advance of purchase whether a set of devices will work with each other. Such predictability is also essential in many other contexts, including industrial use cases. Unfortunately the set of technologies that must be supported depend on context: protocols, data types, and security mechanisms essential in an industrial context may be an unnecessary burden for a home gateway to have to implement.

To resolve this problem this work item will define "profiles" which define subsets of TDs supporting only specific technologies. This work item will include the following:

1. Definition of a mechanism to identify the profile or profiles that a given TD is conformant to.
2. Definition of specific profiles.

Thing Description Templates

Current WoT Thing Descriptions (TDs) apply to specific Things, for example, particular devices. However, there are often many devices manufactured with the same interface and capabilities. These devices differ from each other only in certain specific aspects, such as being installed in different locations and having different identifiers. In addition, devices may share common interactions for specific purposes (for example, management or power management) even if from different manufacturers and with different functions.

The current TD specification includes the definition of a "TD Template" which is a partial TD that omits information that is specific to an instance. However, the current definition of TD Templates does not define the inheritance mechanism and the applicable TD vocabulary. It only allows the definition of the interaction model without security schemes and/or protocol bindings. Thing templates have various application areas: They may be used for managing a class of devices, or to define digital twins and corresponding simulations. There are other use cases, where some knowledge of the protocol and security requirements may be required.

A closely related problem is that of components and standardized common APIs: we may wish to assemble a Thing Description from a set of reusable, modular capabilities, or declare that it supports some API, that is common to a class of Things. How is a TD Component to be defined and how are they to be combined into a complete Thing? How is a TD Consumer able to determine that a particular Thing supports a specific sub-interface common to a set of Things?

This work item will elaborate and refine the TD Template concept so it can satisfy these use cases.

Complex Interactions

Many use cases require the implementation of complex interactions that span multiple protocol transactions. An example would be the initiation, monitoring, and possible cancellation of ongoing actions. Another would be managing and accessing historical queues for events and actions.

In fact such complex interactions can be implemented with the more basic features already included in the WoT Thing Description and in particular can be supported in a self-describing way with hypermedia controls. Hypermedia controls can also be used to clarify what remediary actions can be taken when an error occurs.

However, there are many possible ways to implement and use such complex interactions. To better support the goals of interoperability, it would be useful to precisely define the most common complex interactions.

This work item will document the behavior of complex interactions, including:

1. The ability to initiate, monitor, and cancel ongoing actions.
2. Support for action and event queues.
3. Error recovery via hypermedia responses.

Discovery

During the previous charter a format for the storage of the metadata required to access a Thing was defined: the WoT Thing Description (TD). However, no mechanism was defined for the distribution of TDs. The exact properties of distribution mechanisms are important to preserve privacy, in particular TDs should only be distributed to parties with permission to access the data. However, we also wish to support flexible ad-hoc discovery of the services and devices described by WoT TDs. Discovery should be available at both local and global scales. It should also be possible for devices to self-describe themselves directly rather than depending on a centralized infrastructure.

This work item will require a coordinated effort with other standards bodies such as IETF also working on discovery and directory mechanisms so that a common architecture can be defined. Working closely with other WG within the W3C, such as the Privacy WG and the Distributed ID WG will also be important.

To summarize, the discovery mechanism proposed by this Working Group needs to support both peer-to-peer discovery and directory-based discovery, both local and global discovery, be privacy-preserving, and be coordinated with other standards bodies and W3C working groups.

Lifecycle

Definition and description of states and transitions for products, devices and information. The product lifecycle definition will include the consideration that TDs can be used during planning, design, manufacturing, operational and maintenance. The device lifecycle will deal with the process by which trust is established and updated and the security configuration of a device is managed. The information lifecycle relates to the evolution of sensitive information such as IDs in TDs and is especially relevant to the protection of privacy.

Onboarding

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

This work item complements the work that is done for device discovery, however is also applicable for other use cases.

Identifier Management

A WoT Thing Description contains an identifier meant to be unique to every Thing. This identifier is useful for database management (for example, for device inventory) but can also pose a privacy risk. In particular, an immutable unique identifier might be used to track a device and from that infer the location or activities of the owner of that device. If identifiers persist across transfer of ownership of devices, they might also be used to trace commercial transactions or pose an even greater tracking risk.

In order to preserve privacy or confidentiality, such identifiers may need to be considered mutable so that such tracking can be disrupted. More generally, the lifecycle of such identifiers needs to be defined: when they are assigned, when and how they are updated, how notifications of such updates can be issued to authorized users, and how the identifiers must be deleted when an object is decommissioned or replaced when a device changes ownership.

This work item would define an identifier management lifecycle that would seek, as much as possible, to mitigate the privacy risks posed by explicit device identifiers while retaining their functionality, for example in database management and indexing. Implementation of functionality to support updates to identifiers could also be included in the definition of directory services supporting discovery.

Security Schemes

In the context of a WoT Thing Description (TD), a security scheme defines vocabulary for describing public security metadata indicating the security mechanisms and requirements for accessing a Thing. Currently the TD specification includes standard vocabulary for several security schemes in common use by IoT devices. However, security mechanisms are constantly evolving and to stay relevant WoT TDs need to support new security schemes on an ongoing basis. The TD specification does include a vocabulary extension mechanism which can be used to support new security schemes. However, to maximize interoperability, these extension vocabularies should be standardized and where appropriate, included by default by the core TD context.

Based on a list of target security mechanisms identified by the WoT Interest Group, this work item will include the following tasks:

1. For each target security mechanism, define a standard extension vocabulary for a security scheme supporting that mechanism that can be used with the current TD specification.
2. For a core set of security schemes, propose extensions to the core TD vocabulary to include them by default.

Candidates for target security schemes include support for all flows in OAuth2, support for PoP Tokens, and support for ACE. This list is not inclusive and additional security schemes may be considered.

Thing Description Vocabulary

The WoT Thing Description (TD) context includes a core set of vocabulary. This vocabulary can be extended by including additional context files. However, to support new use cases and protocols in a consistent (interoperable) way, especially in cases where JSON-LD processing is not possible, extensions to this core vocabulary may be necessary.

Candidates for TD vocabulary extension include support for Data Schemas consistent with updated versions of JSON Schema, extensions to Data Schemas to support XML and CBOR (and possibly other structured payload data formats), support for additional standard metadata such as location or device manufacturer, and better support for default values.

Protocol Vocabulary and Bindings

The WoT Thing Description (TD) specification is augmented by a WoT Protocol Binding document which defines templates for how to use a TD to describe Things using specific concrete protocols. However, individual concrete protocols may require additional vocabulary to define protocol parameters, such as header options and other metadata. These are defined using vocabulary extensions specific to each protocol. Currently only a limited set of protocols are supported in a standard way. This work item will add support for an additional set of target protocols, where appropriate in collaboration with the defining standards body. This support will include new vocabulary and documentation of how to use that vocabulary in a protocol binding.

Candidates for extended protocol vocabulary include support for CoAP(S), CoAP(S)+WS(S), MQTT, and OPC UA.

Observe Defaults

The WoT interaction model includes abstractions for Properties, Events, and Actions. The Properties abstraction in particular includes an "observe" operation, which allows a Thing to asynchronously notify a Consumer of a change in a property. However, in some protocols of interest, most notably HTTP, there are several different ways to implement the observe operation. The WoT TD allows the specification of a subprotocol to indicate the mechanism used, but unfortunately no default is specified. Because of this Things using HTTP and observe must currently explicitly state the mechanism used, every time.

This work item would specify defaults for implementing observe, including methods and subprotocols, for all important protocols but most especially HTTP.