The text become too long for an effective abstract. Text is partly copied from introduction. Needs realignment between the two sections.

The W3C Web of Things (WoT) is intended to enable interoperability across IoT Platforms and application domains. Primarily, it provides mechanisms to formally describe IoT interfaces to allow IoT devices and services to communicate with each other, independent of their underlying implementation, and across multiple networking protocols. Secondarily, it provides a standardized way to define and program IoT behavior.

This document describes the abstract architecture for the W3C Web of Things. It is derived from a set of use cases and can be mapped onto a variety of concrete deployment scenarios, several examples of which are given. This document is focused on the standardization scope of W3C WoT, which consists of three initial building blocks that are briefly introduced and their interplay explained.

An abstract architecture for the Web of Things and a functional architecture for Servients has been introduced. It is based on WoT building blocks, which are described by additional WoT specifications:

Of these, the WoT Thing Description is the primary building block, as it describes the network-facing interface of a Thing ( WoT Interface ), whether or not it uses WoT Binding Templates or the WoT Scripting API internally. The implementation of WoT Binding Templates results in multiple possible Protocol Bindings, so that a Thing can communicate with different IoT Platforms (i.e., IoT ecosystems or standards). When a Thing uses the WoT Scripting API internally, its application logic can be programmed against a standardized contract using JavaScript. This way, it simplifies IoT application development and enables portability across vendors and WoT network components.

The architecture described here applies well to a wide variety of different use cases. Based on these, we have described serveral scenarios where one or more Servients were used together to overcome, for instance, limitations on the reach of specific communication protocols. These examples are not exhaustive and are only meant to illustrate the applicability and flexibility of the WoT approach.

Other non-normative architectural blocks and conditions underlying the Web of Things are also described in the context of deployment scenarios. In particular, recommendations for security and privacy are included, while the goal is to preserve and support existing device mechanisms and properties. In general, W3C WoT is designed to describe what exists rather than to prescribe what to implement.

Please contribute to this draft using the GitHub Issue feature of the WoT Architecture repository. For feedback on security and privacy considerations, please use the WoT Security and Privacy Issues, as they are cross-cutting over all our documents.


The "Web of Things" (WoT) started as an academic initiative in the form of publications and, starting in 2010, a yearly International Workshop on the Web of Things . Its goal is to improve interoperability as well as usability in the Internet of Things (IoT). With the increasing role of IoT services using other web standards in commercial and industrial applications, the W3C chartered an Interest Group in 2015 to identify technological building blocks for Recommendation Track standardization. With the WoT Working Group chartered end of 2016, the first set of WoT building blocks is now being standardized:

This document serves as an umbrella for the W3C WoT draft specifications and defines the basics such as terminology and the underlying abstract architecture of the W3C Web of Things. In particular, the purpose of this document is to provide


This document uses the following terms as defined here. The WoT prefix is used to avoid ambiguity for terms that are defined specifically for Web of Things concepts.

An Interaction Pattern to invoke procedure on a Thing, potentially a long running physical process (e.g., lowering of window blinds).
A running or periodically running process that consumes one or more Things (read and processes there data, control their state) and/or exposes one or more Things (provide access to locally gathered data or computed from consumed Things, provide remote control and management interfaces). The application can be implemented using the Scripting API or native platform APIs. The application may also be distributed over multiple Things and other hosts.
Binding Templates
A re-usable collection of blueprints for the communication with different IoT platforms. The blueprints includes the required vocabulary for the Thing Description to map Interactions to platform-specific messages as well as implementation notes for the required protocol stacks or dedicated communication drivers.
Client API
Programming interface that allows scripts to access remote Things over the network, local Things in a different execution environment, or directly attached hardware (which is abstracted as Things).
to consume a Thing
To read in a Thing Description and create a Consumed Thing software object for the application in the local runtime environment.
Consumed Thing
A software object instance created through the WoT object of the Scripting API that represents a remote Thing used by the local application. It is defined by the ConsumedThing interface of the WoT Scripting API.
Discovery API
Programming interface that allows scripts to discover other Things (local, nearby, or remote).
Domain-specific vocabulary
Linked Data vocabulary that can be used in the WoT Thing Description, but is not defined by W3C WoT.
An Interaction Pattern to subscribe to data pushed by a WoT Server. These can be stand-alone events such as an alarm, change-of-value notifications, or time series of data.
Execution Environment
A sandbox within the Runtime that isolates scripts running on the same Servient.
to expose a Thing
To create an Exposed Thing software object in the local runtime environment that enables the application to provide local state and calls as Interactions over the network.
Exposed Thing
A software object instance created through the Server API that is implemented locally and can be accessed over the network by remote WoT Clients. It is defined by the ExposedThing interface of the WoT Scripting API.
A functionality exposed by Thing that is defined by the TD Interaction Model.
Interaction Model
A formal model that syntactically and semantically maps different network-facing interfaces (i.e., WoT Interfaces) to application-facing interfaces (e.g., the Scripting API -- note that these can also be proprietary APIs when not implementing the WoT Runtime). The Thing Description is built around this model and connects it to Link Data vocabularies.
Interaction Pattern
A default solution to describe common Interactions: Property, Action, and Event.
IoT platform
A specific IoT ecosystem such as OCF, oneM2M, or Mozilla Project Things with its own specifications for application-facing APIs, data model, and protocols or protocol configurations.
Local Discovery
A discovery method that can discover Things directly connected to a Servient (e.g., sensor or actuator that is abstracted as Thing).
Manual Discovery
A discovery method where the URI of the used consumed Thing Descriptions is provided manually (e.g., through user configuration or hard-coding in a script).
Nearby Discovery
A discovery method where the physical location is considered (e.g., BLE, Audio Watermarking, ...).
Network Discovery
A discovery method that can discover Things in local networks (e.g. SSDP, mDNS/DNS-SD, ...).
An Interaction Pattern to read a specific value of a Thing and optionally to write it.
Protocol Binding
An implementation of the mapping between Interaction in the TD Interaction Model (e.g., Property read) and specific operations of a protocol (e.g., HTTP GET).
Remote Discovery
A discovery method which supports lookup of remote Things also beyond network boundaries, for instance by using a directory service. The endpoint of the directory must be supported.
Scripting API
The application-facing programming interface provided by a Servient; comparable to the Web browser APIs.
Server API
Programming interface that allows scripts to expose local functionality as Things to WoT Clients.
A software stack that implements the WoT building blocks. A Servient can host and expose Things (server role) and/or consume Things (client role). Servients usually have multiple Protocol Bindings to enable interaction with different platforms.
Short for Thing Description.
TD Vocabulary
A controlled Linked Data vocabulary by W3C WoT to tag the metadata of Things in the WoT Thing Description including communication metadata of WoT Binding Templates.
An abstraction of a physical or virtual entity whose metadata and interfaces are described by a WoT Thing Description. This entity can be an existing device augmented with a Thing Description, a logical component of a device that has a software stack that natively provides Thing Descriptions (see Servient), a local hardware component of a Servient, or a logical entity (e.g., location) that does not directly provide any software stack such as a room or building.
Thing Description (TD)
Structured data describing a Thing. A TD includes metadata, domain-specific metadata, a list of offered interactions, the supported protocol bindings for each interaction, and links to related Things. The Thing Description is built around a formal Interaction Model.
Thing Directory
A directory service for TDs that provides a Web interface to register TDs (see draft-ietf-core-resource-directory ) and look them up (e.g., using SPARQL queries or CoRE Link Format).
WoT Client
An entity that can connect with a network interface described by a WoT Thing Description (i.e., consume a Thing). WoT Clients usually implement multiple Protocol Bindings. WoT Client is also used to refer to a Servient in client role only.
WoT Interface
The network-facing interface of a Thing as defined by its Thing Description.
WoT Object
The WoT object is the Scripting API entry point within a WoT Runtime. It provides methods to discover, consume, and expose Things.
WoT Runtime
A runtime system for application scripts with the WoT Scripting API. Implementing a WoT Runtime is optional for Servients.
WoT Server
An entity that exposes a network interface consistent with a WoT Thing Description. WoT Server is also used to refer to a Servient in server role only.
Acronym for Constrained Application Protocol [RFC7252]
CBOR Web Token
A JSON document that is augmented with support for Linked Data by providing an @context property with a defining URI JSON-LD .
JSON Web Token [RFC7519]
The Resource Description Framework (RDF) of the Semantic Web rdf11-concept

TODO: add missing terms, such as WoT, WoT Containers, MQTT, TD manager

The definitions CWT, JWT, RDF are not used in this document.

Use Cases

This section presents the application domains and use cases targeted by the W3C WoT and which are used to derive the abstract architecture discussed in TODO: add link . While Smart Home use cases might appear predominant in this section, they should be seen as simply a vehicle to identify fundamental requirements inherent to most application domains. The Smart Home domain is suitable for identifying such general requirements, as most stake holders can relate to it.

Application Domains


TODO: add language describing scenarios of the consumer domain


The industrial use cases in this section are applicable to different industry verticals.
Due to the nature of overlaps in the application scenarios, different verticals have similar use cases.

shows an example of a Smart Factory. In this case, cell controllers automate factory equipment with specialized communication such as RS-485 or EtherCAT. Line controllers orchestrate multiple cell controllers over IP-based networks. A factory controller integrates different line controllers. A cloud service collects data from the factory controller and analyzes them for predictive maintenance. Users can monitor the factory through a dashboard. Note that factories usually do not reveal the internal topology of their lines and cells.

Smart Factory


Predictive Maintenance Monitoring and predicting machine failures and anomalies.
Maintenance automation Automating the process of creating a maintenance/service ticket based on reactive or predictive detection of problems.
Quality Improvements Improving quality through monitoring the condition of manufacturing equipment.
Industrial safety Reducing industrial safety incidents/accidents.
Environment monitoring Monitoring environment in the manufacturing plant for presence of poisonous gases, excessive noise/heat, etc.
Real-time monitoring Real-time monitoring and KPI calculations of production equipment.

Transportation & Logistics>

Shipment tracking Tracking of shipment en-route - condition, quality and location monitoring.
Fleet tracking Monitoring fleet vehicles, fuel costs, maintenance needs, assignments.
Cold chain monitoring Ensuring integrity of the cold chain - from warehouses to refrigerated trucks to delivery.
Warehouse monitoring Monitoring equipment and stock in warehouses, yards.


Advanced Metering Infrastructure Automated reading of residential and C&I (Commercial and Industrial) meters, and billing.
Distributed Energy Resource management Monitoring the condition and output of distributed renewable energy generation equipment.
Distribution Automation Monitoring and remote-controlling Distribution equipment.
Crew safety Improving safety of utilities crew in the field.

Oil and Gas

Pipeline monitoring Offshore platform monitoring Industrial safety on offshore platforms.
Leakage detection Detecting/Predicting leakage through the pipelines.
Tank/Reservoir level monitoring Monitoring and Controlling the levels in tanks and reservoirs.
Automated Stock Taking Automated calculation of a distributed stock through various storage tanks and delivery pipes/trucks.


Proactive Asset Monitoring Monitoring of high value assets such as connected structures, fleet vehicles, etc.
Usage based insurance Usage tracking and customized insurance policies.
Safety monitoring Employee/Occupant safety monitoring.
Loss reduction - leakage detection Detecting leakages to limit the losses.
Loss prevention - garaging fleet vehicles Predictive weather monitoring and re-routing fleet vehicles to covered garages to limit loss due to hail damage, tree damage.

Engineering and Construction

Worker Safety Worker monitoring for industrial safety.
Construction Asset Monitoring Monitoring assets at construction site.

Smart Buildings

Energy management Monitoring energy usage throughout the building.
Equipment monitoring, Occupant satisfaction Monitoring equipment in the buildings such as HVAC, Elevators, etc. Monitoring satisfaction of occupants.

Connected Car

shows an example of a Connected Car. In this case, a gateway connects to car components through CAN and to the car navigation system through a proprietary interface. Services running in the cloud collect data pushed from car components and analyze the data from multiple cars to determine traffic patterns. The gateway can also consume cloud services, in this case, to get traffic data and show it to the driver through the car navigation system.

Connected Car
Operation monitoring Monitoring of operation status, prediction of service needs, optimisation of maintenance.
Driver Safety Enhance driver safety with notifications of an early warning system for critical road and traffic conditions.


Soil condition monitoring Monitoring soil conditions and creating optimal plans for watering, fertilizing.
Produce monitoring Monitoring produce conditions.


Clinical Trials Data collection and analytics of clinical trial data.
Pharmaceutical monitoring Monitoring of medicines and totes throughout the supply chain.
Remote Patient Monitoring Monitoring of patients after hospitalization.

Smart Cities

Infrastructure monitoring Monitoring of Bridges, Dams, Levees, Canals - material condition, deterioration, vibrations monitoring.
Smart Parking Tracking usage, availability of parking spaces and automating billing/reservations.
Smart Lighting Smart control of street lights based on presence detection, weather predictions, etc.
Waste Management Monitoring of garbage containers to optimize the trash collection route.
Highway Monitoring Monitoring of highways and providing appropriate signage.

Environment Monitoring

Environment monitoring typically relies on a lot of distributed sensors that send their measurement data to common gateways, edge devices and cloud services. The following table just lists a few scenarios - these could be deployed to a small community, a city, a country, a continent or even worldwide.

Air and water pollution Monitoring of air pollution, water pollution and other environmental risk factors such as fine dust, ozone, volatile organic compound, radioactivity, temperature, humidity to detect critical environment conditions.
Disaster prediction and prevention Analysis of sensor data from distributed sensors to detect anomalies and predict critical environment conditions.

Common Architecture Patterns

This section introduces common architecture patterns that illustrate how devices/things interact with controllers, other devices, agents and servers.

Device Controllers

The first use case is a local device controlled by user-operated remote controller as depicted in TODO . For example, an electronic appliance such as an air conditioner with Web server functionality might be connected directly to a local home network. A remote controller can access the air conditioner through the local home network directly. In this case, the remote controller can be realized by a browser or native application.

Device Control


shows an example of direct Thing-to-Thing interaction. The scenario is as follows: when a sensor detects the room temperature is surpassing a set threshold (e.g., 25°C), a control agent issues a "power-on" command to an air conditioner.

Control Agent

Remote Access

Must rewrite for remote access/control use case. Include changing uplink connectivity.

The third use case is a mobile remote controller (e.g., on a smartphone) as shown in . When at home, the smartphone can use Wi-Fi or Bluetooth/BLE to control an electronic appliance locally, while outside, it can use the cellular network.

Multiple Network Interfaces

Multiple Subsystems

Pattern from consumer (ZigBee, Bluetooth, and WiFi in home), industrial (multiple fieldbusses), connected car, and more.


Must rewrite for local box/compute node use case.

shows a use case based on a Smart Home gateway. It is placed between a home network and the Internet. The gateway manages electronic appliances inside the house and can receive commands from a remote controller over the Internet, e.g., from a smartphone as in the previous use case.

Smart Home Gateway

Cloud Proxies

A cloud proxy is a virtual representation of a device, that resides on a cloud server or edge device. Proxies can model a single device, or they can aggregate multiple devices in a virtual representation of the combined devices. This is often called a digital twin.

Cloud proxies can be realized in different ways:

The complexity of the use cases here increases too quickly. They will be split up to progressively add and explain each new feature.

Cloud-ready Devices

shows an example where electronic appliances are connected directly to the cloud. The cloud mirrors the appliances and, acting as a proxy, can receive commands from remote controllers (e.g., a smartphone). Authorized controllers can be located anywhere, as the proxy is globally reachable.

Proxies with Cloud-ready Devices

Legacy Devices

Check terminology, here agent.

shows an example where legacy electronic appliances cannot directly connect to the cloud. Here, a gateway is needed to relay the connection. The gateway works as:

  • integrator of a variety of legacy communication protocols both in the physical and logical view
  • firewall toward the Internet
  • privacy filter which substitutes real image and/or speech, and logs data locally
  • local agent in case the Internet connection is interrupted
  • emergency services running locally when fire alarms and similar events occur

The cloud mirrors the gateway with all connected appliances and acts as an agent that manages them in the cloud in conjunction with the gateway. Furthermore, the cloud can receive commands from remote controllers (e.g., a smartphone), which can be located anywhere.

Proxies with Legacy Devices

Cross-domain Collaboration

show an example of a Cross-domain collaboration. In this case, each system involves other systems in other domains, such as Smart Factrory with Smart City, Smart City with Smart Home. This type of system is called "Symbiotic" ecosystem . There are two collaboration models: direct collaboration and indirect collaboration. In the direct collaboration model, systems exchange their own information directly with each other in peer-to-peer manner. In the indirect collaboration, systems exchange their own information via some collaboration platform. In order to maintain and continue this collaboration, each system provide the metadata of their ability and interfaces and adopt itself to others.

Cross-domain collaboration


The following figure has to be simplified to only show the abstract patterns without the implementation and WoT details (inside the gray boxes). Instead, common patterns can be listed at the corresponding places.

Use Case Overview


The requirements have to be reviewed, partly merged, and sorted into the proper category (functional vs technical).

Functional Requirements

This section defines the properties required in an abstract Web of Things (WoT) architecture.

Common Principles

  • WoT architecture should enable mutual interworking of different eco-systems using web technology.
  • WoT architecture should be based on the web architecture using RESTful APIs.
  • WoT architecture should allow to use multiple payload formats which are commonly used in the web.
  • Flexibility

    There are a wide variety of physical device configurations for WoT implementations. The WoT abstract architecture should be able to be mapped to and cover all of the variations.

  • Compatibility

    We already have many existing IoT solutions and ongoing IoT standardization activities in many business fields. The WoT should provide a bridge between these existing and developing IoT solutions and Web technology based on WoT concepts. The WoT should be upwards compatible with existing IoT solutions and current standards.

Thing functionalities

  • WoT architecture should allow thing's to have functionalities such as
    • reading thing's status information
    • updating thing's status information which might cause actuation
    • subscribing to, receiving and unsubscribing to the notification of the change of thing's status information.
    • invoking functions with input and output parameters which would cause certain actuation or calculation.
    • subscribing to, receiving and unsubscribing to the notification which does not directly relate to thing's status information.

Search and discovery

  • WoT architecture should allow clients to know thing's attributes, functionalities and their access points, prior to access to the thing itself.
  • WoT architecture should allow clients to search things by its attributes and functionalities.
  • WoT architecture should allow semantic search of its functionalities based on unified vocabulary, regardless of naming of its functionalities.

Description mechanism

  • WoT architecture should support common description mechanism which enables describing things and their functions.
  • Such description should be not only human-readable, but also machine-readable.
  • Such description should allow semantic annotation of its structure and described contents.
  • Such description should be able to be exchanged using multiple formats which are commonly used in the web.

Description of attributes

  • WoT architecture should allow describing thing's attributes such as
    • name
    • explanation
    • version of spec, format and description itself
    • links to other related things and information
  • Such description should support internationalization.

Description of functionalities

  • WoT architecture should allow describing thing's functionalities which is shown in ## Thing functionalities


  • WoT architecture should support multiple web protocols which are commonly used.
  • Such protocols include 1)protocols commonly used in the internet and 2)protocols commonly used in the local area network
  • WoT architecture should allow using multiple web protocols to access to the same functionality.
  • WoT architecture should allow using mixture of multiple protocols to the functionalities of the same thing (e.g. HTTP and WebSocket).


  • WoT architecture should support wide variety of thing capability such as edge devices with resource restrictions and virtual things on the cloud, based on the same model.
  • WoT architecture should support multiple levels of thing hierarchy with intermediate entities such as gateways and proxies.
  • WoT architecture should support accessing things in the local network from the outside of the local network (the internet or other local network), considering network address translation.


  • WoT architecture should allow describing applications on the wide variety of things such as edge device, gateway, cloud and UI/UX device, using web standard technology based on the same model.

Legacy adaption

  • WoT architecture should allow mapping of legacy IP and non-IP protocols to web protocols, supporting wide variety of hierarchy, where such legacy protocols are terminated and translated.
  • WoT architecture should allow transparent use of existing IP protocols without translation, which follow RESTful architecture.

Technical Requirements

The previous section delineated the Web of Things abstract architecture by showing various use cases and enumerating patterns for combining architectural components. This section describes technical requirements derived from the abstract architecture.

Components consisting Web of Things and the Web of Things architecture

Observation of the use cases shows that basic components such as devices, applications that access and control those devices, proxies (e.g. gateways and platforms) that sit between devices and applications to link them together, directories that provides device search functionality are required.

Those components are connected to the internet or field networks in offices, factories or other facilities. Note that all components involved may be connected to a single network in some cases, however, components can be deployed across multiple networks in general.


Access to devices are made based on descriptions of their functions and interfaces (i.e. Thing Description). Those include general description about devices, information models representing functions, transport protocol description for operating on information models, and security information, and so on.

General descriptions are about device identifiers (URI) and other human readable information. Information models defines device attributes, and represent device’s internal settings, control functionality and notification functionality. Devices that have the same functionality have the same information model regardless of the transport protocols used.

Because many systems based on Web of Things architecture are crossing system Domains, vocabularies and meta data (e.g. ontologies) used in information models should be commonly understood by involved parties. In addition to REST transports, PubSub transports are also supported.

Security information includes descriptions about authentication, authorization and secure communications. Devices are required to put TDs either inside them or at locations external to the devices, and to make TDs accessible so that other components can find and access them.


Applications need to generate and utilize program interfaces internally based on device descriptions (i.e. TD).

Applications have to be able to obtain device descriptions (i.e. TD) through the network, therefore, need to be able to conduct search operation and acquire the necessary TD over the network.


Proxies need to generate program interfaces internally based on device descriptions (i.e. TD), and to represent virtual devices by using those program interfaces. A proxy then has to produce a TD for the virtual device and make it externally available.

Identifiers of virtual devices need to be newly assigned, therefore, are different from the original devices. This makes sure that virtual devices and the original devices are clearly recognized as separate entities. Transport and security mechanisms and settings of the virtual devices can be different from original devices if necessary. Virtual devices are required to have TDs put either inside the proxies or at locations external to the proxies, and to make the TDs accessible so that other components can find and access them.


For TDs of devices and virtual devices to be accessible from devices, applications and proxies, there needs to be a common way to share TDs. Directories can serve this requirement by providing functionalities to allow devices and proxies themselves automatically or the users to manually register the descriptions.

Descriptions of the devices and virtual devices need to be searchable by external entities. Directories have to be able to process search operations with search keys such as keywords from the general description in the device description or information models.


Security information related to devices and virtual devices needs to be described in device descriptions. This includes information for authentication/authorization and payload encryptions.

WoT architecture should support multiple security mechanism commonly used in the web, such as Basic, Digest, Bearer and OAuth2.0.

WoT Architecture


Abstract Architecture of W3C WoT

Architectural Constraints

URIs, media types, protocols with fixed set of methods (uniform interface)

Uniform Interface


Identify protocols and resources

Media Types and Schemas

Identify data formats, potentially augmented by schemas

Known Set of Methods

Binding only for protocols with fixed set of methods

Hypermedia Controls

Links and Forms

Interaction Model




Building Blocks

This section presents the initial WoT building blocks that build up the abstract architecture for the Web of Things. This architecture is derived from the use cases in Section and the requirements in Section . summarizes the high-level goals and requirements and shows the three levels where the WoT building blocks can be applied:

shows a conceptual view of how a component in the WoT Architecture makes use of the WoT building blocks. Each block is described in more detail in the following sections.

Conceptional Architecture of the WoT Building Blocks

Web Thing

A Thing is the abstraction of a physical or virtual entity that needs to be represented in IoT applications. This entity can be a device, a logical component of a device, a local hardware component, or even a logical entity such as a location (e.g., room or building).

Things provide a network-facing API for interaction ( WoT Interface ) based on a formal model. These WoT Interfaces are a superset of Web APIs, as Things can also be available over non-Web protocols such as MQTT or ZigBee. The outward-facing WoT Interface is not to be confused with the Scripting API , which is optional and interfaces with application scripts inside the software stack of a Thing .

There can be Things , however, that do not provide a WoT Interface and only consist of metadata that is relevant to the application (e.g., the room in which devices are located). In W3C WoT however, a Thing must have a Thing Description ; therefore, everything that has a Thing Description is a Thing .

WoT Thing Description

The WoT Thing Description (TD) is structured data that adheres to a formal model and closes the gap between Linked Data vocabularies and functional APIs of IoT systems. It can be seen as the "HTML for Things". A TD provides general metadata of a Thing as well as metadata about the Interactions , data model, communication, and security mechanisms of a Thing . Usually, TDs make use of domain-specific metadata for which WoT provides explicit extension points. However, any domain-specific vocabulary is out-of-scope of the W3C standardization activity.

The WoT Thing Description is built around a formal Interaction Model that can support multiple messaging paradigms (i.e, request-response, publish-subscribe, and message passing). The default Interaction Patterns are Property , Action , and Event . These were found to be able to cover the network-facing APIs provided by most IoT Platforms. Properties abstract data points that can be read and often written. Actions abstract invokable processes that may run for a certain time; yet they can also abstract RPC-like interactions in general. Events abstract interactions where the remote endpoint pushes data asynchronously.

Thing Descriptions are serialized to JSON-LD [[!JSON-LD]] by default. More serialization formats are planned in the future, in particular more concise formats for resource-constrained Things . For now, JSON-LD offers a good trade-off between machine-understandable semantics and usability for developers.

Thing Descriptions can be managed in Thing Directories , which are aligned with the CoRE Resource Directory [[CoRE-RD]]. They provide a Web interface for registration, registration updates, and removal, and automatic removal after a given lifetime expired without registration update. Thing Directories also provide a Web interface for lookups, usually including a SPARQL endpoint for semantic queries in addition to simple CoRE Resource Directory [[CoRE-RD]] lookups.

The WoT Thing Description fosters interoperability in two ways: First, and foremost, TDs enable machine-to-machine communication in the Web of Things. Second, TDs can serve as a common, uniform format for developers to document and retrieve all details necessary to access IoT devices and make use of their data.

WoT Binding Templates

A great challenge for the WoT is to enable interactions with a myriad of different IoT Platforms (e.g., OCF, oneM2M, RESTful devices not following any particular standard but providing an HTTP or CoAP interface, etc.). The IoT uses a variety of protocols for accessing devices, since no one protocol is appropriate in all contexts. W3C WoT is tackling this variety by including communication metadata in the Thing Description . This metadata can be used to configure the communication stack to produce compliant messages for a wide variety of target IoT Platforms and protocols.

The WoT Binding Templates are an informal collection of communication metadata blueprints that explain how to interact with different IoT Platforms . When creating a Thing Description for a particular device, the Binding Template for the corresponding IoT Platform can be used and instantiated in the Thing Description for that device.

From Binding Templates to Protocol Bindings

shows how Binding Templates are applied. A WoT Binding Template is created only once for each IoT Platform and then instantiated, and hence reused in all TDs for its devices. The WoT Client consuming that TD must implement the corresponding Protocol Binding to be able to interact with the Thing described. The communication metadata of a Binding spans four dimensions:

  • IoT Platform: IoT Platforms often introduce proprietary tweaks to protocols such as platform-specific HTTP header fields or CoAP options. This spans another dimension within the transfer protocol used. Usually, these tweaks can be described with standard TD Vocabulary . If not, platform-specific vocabulary along with a corresponding Protocol Binding implementation is required.
  • Transfer Protocol: The WoT Thing Description comes with vocabulary to identify standard protocols (e.g., HTTP, CoAP, WebSockets, or MQTT). Their configuration (e.g., port or variations such as HTTP long-polling [[!RFC6202]] to support event notification) is also done through TD Vocabulary . If a transfer protocol is not covered by the TD Vocabulary , domain-specific vocabulary can be used. This, of course, needs to be backed by a corresponding Protocol Binding implementation in the WoT Client .
  • Media Type: IoT Platforms often differ in the representation formats (or serializations) used for exchanging data. The Internet Meda Type [[!RFC6838]] identifies these formats.
  • Security: Security can be applied at different places of the communication, and hence opens another dimension of variability. Examples are (D)TLS [[!RFC5246]]/[[!RFC6347]], IPSec [[!RFC6071]], OAuth [[!RFC6749]], and ACE [[!RFC7744]].

WoT Scripting API

The Scripting API is programming interface that allows scripts to discover and consume (retrieve) Thing Descriptions, instantiate local objects that act as a proxy for remote Things and their interactions (properties, actions and events). Also, it allows scripts to expose WoT Things and specify their interactions.

The Scripting API is an optional "convenience" building block in WoT and it is typically used in network nodes that are able to run a WoT Runtime, for instance gateways or more complex leaf nodes.

The Scripting API specification describes a low level ECMAScript API that follows the Thing Description specification closely. Other, simpler APIs may be implemented on top of it. Other runtimes (e.g. Python, Lua, etc.) may also mimic this API, but in principle any WoT scripting API can be defined and used, as long as the WoT interactions are presented on the network interface.

The current reference implementation of the Scripting API is the Eclipse ThingWeb (node-wot) project. This API is the only one at the moment that ensures "de facto" portability of WoT scripts. Other, proprietary implementations of the Scripting API exist as well and have been tested against <node-wot during Working Group test fests.

WoT Security and Privacy Guidelines

Explain how to use and apply guidelines.

Servient Implementation

A Servient is a software stack that implements the WoT building blocks presented in the previous section. Servients can host and expose Things and/or consume Things. Thus, Servients can perform in both the server and client roles; the name (a portmanteau of server and client) is based on this dual role.

The previous shows how the WoT building blocks conceptionally relate to each other. When implementing these concepts, a more detailed view is necessary that takes certain technical aspects into account. The detailed architecture of a Servient is shown in .

Implementation View of a Servient

The role and functionality of each module shown in is as follows:


Applications running on a Servient are usually implemented through scripts (i.e., JavaScript). The application scripts must be provided along with security metadata that defines their Execution Environment and consequently how scripts must be isolated. The security metadata also needs to include keying material or certificates to authenticate the Things the script exposes.

Note that the WoT Scripting API building block is optional. There can be minimal Servient implementations where applications are implemented natively for the software stack. These do not have the Scripting API and WoT Runtime modules.


Explain native implementation against custom API in programming language of choice.

WoT Scripting API

The standardized WoT Scripting API is the contract between applications and the runtime system of a Servient, the so-called WoT Runtime. The WoT Scripting API is equivalent to any platform API, and hence there must be mechanisms to prevent malicious access to the system. As mentioned above, this building block, including the underlying WoT Runtime implementation, is optional.

The WoT Scripting API is an optional building block that eases IoT application development. Traditionally, device logic is implemented in firmware, which underlies the productivity constraints of embedded development. The WoT Scripting API enables having a runtime system for IoT applications similar to a Web browser, and aims to improve productivity and reduce integration costs. Furthermore, standardized APIs enable portability for application modules, for instance, to move compute-intense logic from a device up to a local gateway, or to move time-critical logic from the cloud down to a gateway or edge node.

The Scripting API is built on top of the Thing abstraction and the TD Interaction Model. There are three sub APIs:

  • WoT object as API entry point to discover, consume, and expose Things
  • ConsumedThing interface as Client API to consume Things over the network or locally (e.g., physically attached hardware)
  • ExposedThing interface as Server API to configure and expose Things over the network

See WoT Scripting API for details.

WoT Runtime

The Thing abstraction and Interaction Model is implemented in a runtime system that offers the application-facing WoT Scripting API. This WoT Runtime interfaces with the Protocol Bindings to access remote Things and with the system API to access local hardware and proprietary means for communication. Note that both local hardware and devices behind proprietary communications protocols are also represented as Things in the runtime environment, that is, they are also accessed through the Client API. The WoT Runtime is also tasked with generating the Thing Description based on the Servient metadata (e.g., location), application metadata (e.g., provided Interactions), and available Protocol Bindings (e.g., implemented WoT Binding Templates).

Protocol Bindings

Protocol Bindings are implementations of the Binding Templates. They produce the messages to interact with Things over the network based on the information given in the Thing Description of the Consumed Thing. Servients usually have multiple Protocol Bindings to enable interaction with different IoT Platforms.

In many cases, where standard protocols are used, generic protocol stacks can be used to produce the platform-specific messages (e.g., one for HTTP(S) dialects, one for CoAP(S) dialects, and one for MQTT solutions, etc.). In this case, the communication metadata from the Thing Description is used to select and configure the right stack (e.g., HTTP with the right header fields or CoAP with the right options). Parsers and serializers for the expected representation format identified by the Internet Media Type can also be shared across these generic protocol stacks.

In some cases, where no aspects can be shared, the Protocol Binding is more comparable to a platform-specific driver that is selected and configured through the communication metadata in similar way as above.

See WoT Binding Templates for details.

System API

The implementation of a Thing may access local hardware or system services (e.g. storage) through proprietary APIs or other means. This block is out of scope of WoT standardization.

A WoT Runtime may provide local hardware or system services to application scripts through the Thing abstraction, as if they were accessible over a network protocol. In this case the implementation should be optimized to avoid the overhead that would be involved in a literal implementation of a network protocol while maintaining a consistent WoT Interface. The details of such "System Things" are out of the scope of standardization at present, although W3C WoT will document several informational examples.

A device may be physically external to a Servient, but connected via proprietary protocols. In this case, the implemented runtime environment may access legacy devices with such protocols (e.g., Echonet Lite, X10, I2C, SPI) through proprietary APIs, but again exposes them to applications as Things through the Scripting API. A script can then act as gateway to the legacy devices. This should only be done if the legacy device cannot be described using the WoT Thing Description.

? WoT Servient Implementation ?

This section already talks about cross-Servient interactions. Text most likely needs to be moved to WoT Deployments section.

This section defines components that make a Web of Things entity, clarifies each component’s functions, and then shows how a web of Things as a whole works. The architecture described here is derived from the Web of Things use cases as well as technical requirements extracted from them.

High-level architecture

Overview of WoT component’s behavior is explained using a couple of system configuration diagrams. First, shown below is a configuration that consists of a device and an application shown below.

High level architecture of appliation and device

Functions of a device is described by a Thing Description (TD). A TD describes, among other things, a device’s identifier, functions and attributes of a device implemented internally, communication protocols (i.e. transport layer) information. Details of TD format are defined the Thing Description specification.

Each Web of Things device MUST have a corresponding TD. Applications can recognize a device by obtaining a TD of the device. Conceptually, a device can be thought to have an ExposedThing that provides an interface that conforms to the TD. On the other hand, an application can be conceptually considered to have a ConsumedThing that provides an interface functionality for an application to utilize. An application can generate a ConsumedThing upon a receipt of a TD. Communication between an application and a device are realized by ConsumedThing and ExposedThing connect to each other and exchange messages.

Next, in the below configuration, an application and a device connect to each other via a proxy.

High level architecture with proxy

A proxy contains both ExposedThing and ConsumedThing functionality, and relay messages that are exchanged between an application and a device. In a proxy, a ConsumedThing creates a shadow of the device, and an application can access the shadow device through the proxy’s ExposedThing.

Proxy’s ExposedThing and ConsumedThing can communicate in different protocols. For example, a device and an application can use separate protocols, CoAP and HTTP, respectively. Even when there are multiple devices and they use different protocols, an application can communicate with those devices using a single protocol through the proxy. The same is true for device authentication. An application only need to handle a single authentication method even when multiple devices connected to a proxy use different authentication methods.

A proxy creates a ConsumedThing based on a TD and generates another TD for a shadow device. The TD for a shadow device uses a new identifier different from the original device TD’s, and changes communication protocols if necessary. A proxy then creates an ExposedThing that serves as the Thing for the TD. An application communicates with a device via a proxy through a ConsumedThing that works according to the TD for the shadow device.

Simple configuration of WoT servient

The remainder of this section discusses and clarifies the inner structure of a servient.

First, inner structure of a servient is explained based on the structure of an application servient and a device servient. WoT runtime defines an abstract interface that contains methods such as READ, WRITE, INVOKE, SUBSCRIBE, NOTIFY through which to access devices. When a servient communicates over a network, those methods are bound to concrete protocols. For example, in the case of HTTP, HTTP methods such as PUT and GET are assigned to implement the abstract methods. WoT clients can retrieve and change device settings or device attributes defined in TDs through those abstract methods. In a device servient, TD manager creates an ExposedThing based on TD. TD manager also advertises a TD to other servients, or provides other servients with a TD upon request. A device servient’s functions are usually implemented as hardware, and those functions are accessible through its firmware. An ExposedThing’s abstract interface is translated into hardware commands by a device interface adapter. A device interface adapter is a custom software developed for each specific type of hardware. In an application servient, on the other hand, a TD manager obtains TDs by getting one from location advertised by other servients or requesting other servients of TDs, and creates a ConsumedThing based on the obtained TD. Functions of an application servient are usually implemented as an application. The abstract interface of a ConsumedThing is provided as a programming language (such as JavaScript) interface, and the application achieves its functions by using this interface.

Simple configuration of application and device

Next, inner structure of a servient is explained based on the structure of a proxy servient that connects a device servient and application servient together.

A runtime in a proxy servient has both ExposedThing and ConsumedThing functionality. A TD manager, similar to that of an application servient, obtains a TD of a device servient, and creates a ConsumedThing. At the same time, a TD manager creates a shadow of the device as well as a TD for the shadow device where the identifier is a new one and protocol bindings are appropriately described to serve for the application. An ExposedThing is created based on this TD, and a TD manager notifies other servients of the TD.

Simple configuration with proxy

Below is a WoT architecture diagram that summarizes the inner structure of a WoT servient. A runtime creates ExposedThing or ConsumedThing based on TDs, provides an abstract interface that through protocol binding can interact with other servients. Note that the diagram also contains a legacy device that does not by itself support WoT abstract interface. A device interface adapter converts legacy interface into an abstract interface to allow them to interact with the runtime.

Simple configuration of WoT servient

WoT Deployments

In the previous sections, how WoT servients connect to each other and their roles and basic behaviors were described based on two simple structures; one with an application and a device, and the other with a proxy connecting an application and a device together. These simple structures can be used as is for use cases involving relatively small numbesr of devices. However, they are too simple per se to describe those more complex uses cases where the number of connected devices are not small, or devices are physically located in multiple remote sites. This section illustrates more advanced structures that can be applied to those non-simple use cases.

Device Servients

Move content from sections further down here and potentially other places here.

Application Servients

Move content from sections further down here and potentially other places here.

Proxy Servients

Move content from sections further down here and potentially other places here.

Thing Directories

Try to explain this component in open way, as specification is not available yet.

Devices in a Local Network Controlled from a Cloud

In smart home cloud service use cases, sensors and home appliances connected to a home network are monitored as well as in some cases operated by cloud applications. There is a firewall between the home network to which the devices are connected and the cloud. The WoT servients in this case can communicate each other only if the communication successfully goes through the firewall.

The figure below shows a typical structure that is adopted in ITU-T Recommendation Y.2070. As described in previous sections, a proxy can aggregate multiple device servients into common ExposedThing(s), and provide the applications with a simple access interface. For example, even when the connected devices each uses a different protocol such as REST, WebSocket and CoAP, the ExposedThing can converge them into a single protocol so that applications do not need to be aware of the various protocols the devices use. In the figure, there are two applications connected to a proxy. Those applications use a single protocol (e.g. REST) to communicate with the proxy, which makes the development of an application much simpler.

There is a firewall between applications and devices. There is a proxy on each side of the firewall; one in the home network and the other in the internet. These two proxies work together to tunnel all communications to go through the firewall. The local proxy which is on the home network side aggregates all connected devices, and the remote proxy on the internet side aggregates the applications. Applications and devices need to know nothing about the firewall.

Note: An example structure adopted in ITU-T Recommendation Y.2070

Service-to-Service connections across multiple Domains

Once devices can be monitored or operated by cloud applications, a variety of services can be built on top of that. For example, a cloud application can change a device’s operating condition based on analysis of collected data. When the remote proxy is a part of a cloud platform servicing applications, an application needs to be able to find device information by, for example, accessing a directory of connected devices. In the figure below, information of all devices connected to the remote proxy via a local proxy is registered in a directory. An application needs to obtain the information of the device(s) that it needs to communicate with to achieve its application functionality. It can do so by querying the directory of device information.

Cloud service with directory

Multiple cloud eco-systems each based on a different platform can work together to make a larger, systems-of-systems eco-system. Built on the previously discussed structure of a cloud application eco-system, the figure below shows two eco-systems connected each other to make a system-of-systems. Consider a case in which an application servient in one eco-system (i.e. Application Servient A in below) uses a device servient in another eco-system (i.e. Device Servient B in below). There are more than one mechanisms to achieve this cross eco-systems application-device integration. Below, two mechanisms of doing this are explained each using a figure to help understand how it can be achieved.

In the first figure below, two directories synchronize device information, which makes it possible for Application Servient A to obtain the information of Device Servient B through TD directory A. As described in previous sections, Remote Proxy Servient B holds a shadow device of Device servient B. By obtaining the TD of this shadow device, Application servient A is able to use Device Servient B through the shadow device on Remote Proxy Servient B.

Multiple cloud connect through directory synchronization

In the second figure below, two remote proxy servients synchronize device information. When a shadow of Device Servient B is created in Remote proxy servient B, the shadow’s TD is simultaneously synchronized into Remote proxy servient A. Remote proxy servient A in turn creates its own shadow of Device servient B, and registers the TD to TD directory A. With this mechanism, synchronization between TD directories is not necessary.

Multiple cloud connect through proxy synchronization

SNIPPETS: (was WoT Deployment Scenarios and Guidelines)

There are many possibilities for deploying the abstract WoT Architecture and mapping the functions to physical devices and network structures. This section, which is informative but not normative, lists a number of design patterns that may be used when implementing the Web of Things.

WoT Client

Servient Consuming Thing

shows the basic scenario, where a Servient in client role, a WoT Client , is consuming an existing device that is augmented with a Thing Description (TD). The latter could be generated from digital descriptions already available for the device within the corresponding IoT Platform . It could also be written by a developer using tools or even manually.

The Application Script is loaded and executed by the WoT Runtime . Scripts can be manually configured with the URI of the device TD located on a reachable Web server. Using the WoT object , the Application Script retrieves the TD and instantiates a corresponding Consumed Thing . The Application Script can use the metadata of the Thing and inspect what Interactions it provides. The communication metadata within the TD is used by the Servient to select the matching Protocol Binding and to configure its protocol stack. These communication details are hidden from the Application Script. However, the script can only interact with the Thing , if the Servient implements a Protocol Binding that matches the communication metadata given in the TD .

Using the Client API (i.e., ConsumedThing interface), the Application Script can read or write a Property , invoke an Action , or subscribe for Events offered by the Thing . The selected Protocol Binding maps these Interactions to the low-level protocol operations and serializations understood by the remote Thing . When a message is returned by the Thing , the Protocol Binding parses the response and maps it back to the Interaction abstraction. The Interaction output is delivered back to the Application Script by resolving a (JavaScript) Promise.

Each sub-section shall describe the technical details to realize the scenario. They shall describe how to discover the involved WoT components, how to realize connectivity, and what security mechanisms can be used. For now, the draft only contains strawman proposals and placeholders that will be replaced as the draft progresses.

  • Manual (Application Script is configured with TD URI)
  • Local over (W)LAN or LPWANs (ZigBee, Z-Wave, etc.)
  • Remote over globally reachable IP address of the Thing
  • Security metadata to sandbox the Application Script
  • Access control implemented on the Thing
  • Integrity protection when retrieving the TD
  • Potentially confidentiality and integrity protection when interacting with the Thing

Servient on Device

Servient on Device Itself

In this case, a Servient is running on the device itself. The right most Servient in shows an LED Light, whose controller has a powerful CPU and a large memory and is able to provide web server functionality connected directly to the Internet. Then the leftmost browser and/or another application on the internet can access the LED light through the Internet directly.

Resource-constrained Device as Thing

Devices that are not powerful enough to host a Servient can still act as Things . In this case, a classic firmware is providing a Thing Description that describes the functionality and protocols implemented. The right most Servient in shows a legacy device that has a constrained CPU and a small memory and is able to provide web server functionality connected directly to the internet. Then the leftmost browser and/or another application on the internet can access the device through the Internet directly like .

  • WoT Client discovers Servient on the same network [network discovery].
  • (W)LAN
  • LPWANs (ZigBee, Z-Wave, etc.)
  • t.b.d.

Servient on Smartphone

This example uses a Servient running on a Smartphone. Smartphones are not only popular but have enough performance to provide gateway functionality. This functionality can be used to bridge between the internet and a legacy device without any intermediate hardware.

Servient on Smartphone

shows an example of a Servient on a smartphone, which can act as a gateway to existing devices (e.g., via Bluetooth or local Wi-Fi). The Web browser with the user interface can either run on the smartphone directly or remotely on a separate device (such as a laptop).

  • WoT Client discovers an electronic appliance when the remote controller is nearby [nearby discovery].
  • WoT Client discovers Servient remotely when the remote controller is outside [remote discovery].
  • t.b.d.
  • t.b.d.

Servient on Gateway

Servient on Gateway

shows an example of a Servient on a gateway. Gateway are often introduced as a home automation and/or home energy management solution. In the case of consumer electronics, there are very wide variety of physical communication formats such as WiFi, 802.15.4g, Bluetooth Low Energy, HDPLC and so on. In order to normalize those variations, almost all home automation systems introduce a gateway. In , a Servient wraps various mechanisms for communicating with legacy devices and provides to other clients a universal device accessing method. Inside the home, HTTP/TCP/IP/WiFi can then be used as the sole unfied communication method between the Servient on the gateway and a user interface device such as a Web broswer.

  • Servient discovers electronic appliances nearby [nearby discovery].
  • WoT Client discovers Servient remotely [remote discovery].
  • t.b.d.
  • t.b.d.

Servient on Cloud and Gateway

Client Apps can control devices at home through a Servient on a gateway. But in this case the location of client apps is restricted to the home, because physical communication path "WiFi" and/or wired Ethernet between gateway and client apps such as a Web browser is limited to the physical domain provided by the WiFi signal. To provide for controlling devices at home from outside the house, a HTTP/TCP/IP interface to a Servient running in the cloud with a globally reachable address could be used. However, in this case the Servient in the cloud cannot generally access devices running in the home through only local interfaces such as Bluetooth.

Servient on Cloud Server and Gateway

shows an example of Servient running on a cloud server paired with another Servient running on a gateway. In the case of , a browser accesses the Servient on the cloud Server named "Cloud". This Servient provides its interface through the Internet globally. So, wherever a browser user is, they can access this Servient . The Servient on "Cloud" can accept the request of the browser and/or other application through HTTP, CoAP, and so on. Then the Servient on the cloud server finds out the route to access another Servient on the gateway. After finding out the route, the Servient on the cloud server transfers the request from the browser to the Servient on the gateway. After that, the gateway processes the request according the use case. The Thing Description of the Servient on the cloud server can be just a mirror of that on the gateway, since it will generally just pass interactions directly through. More generally, though, one or both Servients can provide services such as privacy filtering or sub-setting. When the user is home, they can also access the Servient in the gateway directly.

  • Servient discovers WoT Server remotely [remote discovery].
  • WoT Client discovers Servient remotely [remote discovery].
  • t.b.d.
  • t.b.d.

Servient on Cloud Server

Servient on Cloud Server Only

shows a second example of Servients in the cloud. In this case, a browser accesses a Servient on a cloud server, similar to . This Servient provides access through the global Internet. So, wherever the browser user is, they can access this Servient . The cloud Servient accepts the requests of the browser and/or other applications through HTTP, CoAP, etc. Then it finds out the route to access a proprietry discovery service running on a gateway. In , the Servient running in the cloud could talk to another Servient running on the gateway. However, many service providers have already provided IoT services using proprietary IoT interfaces or some other IoT standard. In this case, the gateway can still support the same functionalities, as in the previous case, but using methods outside of the WoT definitions.

  • Servient1 discovers Servient2 remotely [remote discovery].
  • Servient2 discovers electronic appliances nearby [nearby discovery].
  • WoT Client discovers Servient1 remotely [remote discovery].
  • t.b.d.
  • t.b.d.

Security and Privacy Considerations

This section will likely undergo significant revision and reorganization. Please see the WoT Security and Privacy repository for work in progress. In particular, the WoT Threat Model defines the main WoT security stakeholders, assets, attack surfaces, and threats.

The functional WoT architecture should enable the use of best practices in security and privacy. Generally, the WoT security architecture must support the goals and mechanisms of the IoT protocols and systems it connects to. These systems vary in their security requirements and risk tolerance, so security mechanisms will also vary based on these factors. However, the WoT architecture needs to do no harm: it should support security and privacy at least as well as the systems it connects to.

Security means the system should preserve its integrity and functionality even when subject to attack. Privacy means that the system should maintain the confidentiality of personally identifiable information. In general, security and privacy cannot be guaranteed but the WoT architecture should support best practices.

Security and privacy are especially important in the IoT domain since IoT devices need to operate autonomously and in many cases have access to both personal data and/or can be in control of safety-critical systems. Compared to personal systems, IoT devices are subject to different and in some cases higher risks than IT systems. It is also important to protect IoT systems so that they can not be used to launch attacks on other computer systems.

Security and privacy considerations are still under discussion and development; the content below should be considered preliminary. Due to the complexity of the subject we are considering producing a separate document containing a detailed security and privacy considerations discussion including a risk analysis, threat model, recommended mitigations, and appropriate references to best practices. A summary will be included here. Work in progress is located in the WoT Security and Privacy repository. Please file any security or privacy considerations and/or concerns using the GitHub Issue feature.

Security is a cross-cutting issue that needs to be taken into account in all WoT building blocks . The W3C WoT does not define any new security mechanisms, but provides guidelines to apply the best practices from Web security, IoT security, and information security for general software and hardware considerations.

The WoT Thing Description must be used together with integrity protection mechanisms and access control policies. Users must ensure that no sensitive information is included in the TDs themselves.

The WoT Binding Templates must correctly cover the security mechanisms employed by the underlying IoT Platform . Due to the automation of network interactions necessary in the IoT, operators need to ensure that Things are exposed and consumed in a way that is compliant with their security policies.

WoT Runtime Security and Privacy Risks

The WoT Runtime implementation for the WoT Scripting API must at least have mechanisms to prevent malicious access to the system and isolate scripts in multi-tenant Servients . More specifically the WoT Runtime implementation for the WoT Scripting API should take into account the below security and privacy risks and implement the recommended mitigations.

Cross-Script Security and Privacy Risk

In basic WoT setups, all scripts running inside the WoT Runtime are considered trusted, and therefore there is no strong need to perform strict isolation between each running script instance. However, depending on device capabilities and deployment use case scenario risk level it might be desirable to do so. For example, if one script handles sensitive privacy-related data and well-audited, it might be desirable to separate it from the rest of the script instances to minimize the risk of data exposure in case some other script inside WoT gets compromised during runtime. Another example is mutual co-existence of different tenants on a single WoT device. In this case each WoT runtime instance will be hosting a different tenant, and isolation between them is required.

The WoT runtime should perform isolation of script instances and their data in cases when scripts handle privacy-related or other critical security data. Similarly, the WoT Runtime implementation should perform isolation of WoT Runtime instances and their data if a WoT device has more than one tenant. Such isolation can be performed within the WoT Runtime using platform security mechanisms available on the device. For more information see Sections "WoT Servient Single-Tenant" and "WoT Servient Multi-Tenant" of [[!WOT-SECURITY-CONSIDERATIONS#]].
Physical Device Direct Access Security and Privacy Risk

In case a script is compromised or misbehaving, the underlying physical device (and potentially surrounded environment) can be damaged if a script can use directly exposed native device interfaces. If such interfaces lack safety checks on their inputs, they might bring the underlying physical device (or environment) to an unsafe state (i.e. device overheats and explodes).

The WoT Runtime should avoid directly exposing the native device interfaces to the script developers. Instead a WoT Runtime implementation should provide a hardware abstraction layer for accessing the native device interfaces. Such hardware abstraction layer should refuse to execute commands that might put the device (or environment) to an unsafe state. Additionally, in order to reduce the damage to a physical WoT device in cases a script gets compromised, it is important to minimize the number of interfaces that are exposed or accessible to a particular script based on its functionality.
Provisioning and Update Security Risk

If the WoT Runtime implementation supports post-manufacturing provisioning or updates of itself, WoT scripts, or any related data (including security credentials), it can be a major attack vector. An attacker can try to modify any above described element during the update or provisioning process or simply provision attacker's code and data directly.

Post-manufacturing provisioning or update of scripts, the WoT Runtime itself or any related data should be done in a secure fashion. A set of recommendations for secure update and post-manufacturing provisioning can be found in [[!WOT-SECURITY-CONSIDERATIONS]].
Security Credentials Storage Security and Privacy Risk

Typically the WoT Runtime needs to store the security credentials that are provisioned to a WoT device to operate in WoT network. If an attacker can compromise the confidentiality or integrity of these credentials, then it can obtain access to the WoT assets, impersonate WoT things or devices or create Denial-Of-Service (DoS) attacks.

The WoT Runtime should securely store the provisioned security credentials, guaranteeing their integrity and confidentiality. In case there are more than one tenant on a single WoT-enabled device, a WoT Runtime implementation should guarantee isolation of each tenant provisioned security credentials. Additionally, in order to minimize a risk that provisioned security credentials get compromised, the WoT Runtime implementation should not expose any API for scripts to query the provisioned security credentials.

Example Sequences of interaction patterns (Informative)

This section is non-normative.

This section illustrates example sequences of interaction patterns such as read propery, invoke action and event, among WoT client and WoT server.

For the sake of simplicity, remote and local proxies between client and server are omitted from following sequences.


Read property (binding = HTTP)

Following sequence illustrates example sequence of read property operation with HTTP binding.

Read property               (binding = HTTP)

Write property (binding = HTTP)

Following sequence illustrates example sequence of write property operation with HTTP binding.

Write               property (binding = HTTP)

Observe property (binding = HTTP Long Polling)

Following sequence illustrates example sequence of observe property operation with HTTP Long Polling binding.

Observe property (binding = HTTP Long Polling)

Observe property (binding = HTTP Server Sent Event)

Following sequence illustrates example sequence of observe property operation with HTTP Server Sent Event binding.

Observe property (binding = HTTP Server Sent Event)

Observe property (binding = Simple WebSocket)

Following sequence illustrates example sequence of observe property operation with simple WebSocket binding.

Observe property (binding = simple WebSocket)


Invoke action (binding = HTTP)

Following sequence illustrates example sequence of invoke action operation with HTTP binding, where operation is synchronous and the request to server is blocked until action completes.

Invoke action               (binding = HTTP)

Note: Action with asynchronous operation is subject to further study.


Subscribe, notify and unsubscribe event (binding = HTTP Long Polling)

Following sequence illustrates example sequence of subscribe, notify and unsubscribe event operation with HTTP Long Polling binding.

Subscribe,               notify and unsubscribe event (binding = HTTP Long               Polling)

Subscribe, notify and unsubscribe event (binding = HTTP Server Sent Event)

Following sequence illustrates example sequence of subscribe, notify and unsubscribe event operation with HTTP Server Sent Event.

Subscribe,               notify and unsubscribe event (binding = HTTP Server Sent               Event)

Subscribe, notify and unsubscribe event (binding = Simple WebSocket)

Following sequence illustrates example sequence of subscribe, notify and unsubscribe event operation with simple WebSocket binding.

Subscribe,               notify and unsubscribe event (binding = simple WebSocket)


Special thanks to all active Participants of the W3C Web of Things Interest Group and Working Group for their technical input and suggestions that led to improvements to this document.