The Web of Things is applicable to multiple IoT domains, including Smart Home, Industrial, Smart City, Retail, and Health applications, where usage of the W3C WoT standards can simplify the development of IoT systems that combine devices from multiple vendors and ecosystems. During the last charter period of the WoT Working Group several specifications were developed to address requirements for these domains.
This Use Case and Requirements Document is created to collect new IoT use cases from various domains that have been contributed by various stakeholders. These serve as a baseline for identifying requirements for the standardisation work in the W3C WoT groups.
The World Wide Web Consortium (W3C) has published the Web of Things (WoT) Architecture and Web of Things (WoT) Thing Description (TD) as official W3C Recommendations in May 2020. These specifications enable easy integration across Internet of Things platforms and applications.
The W3C Web of Thing Architecture [[wot-architecture]] defines an abstract architecture, the WoT Thing Description [[wot-thing-description]] defines a format to describes a broad spectrum of very different devices, which may be connected over various protocols.
During the inception phase of the WoT 1.0 specifications in 2017-2018 the WoT IG collected use cases and requirements to enable interoperability of Internet of Things (IoT) services on a worldwide basis. Thes released specifications have been created to address the use cases and requirements for the first version of the WoT specifications, which are documented in https://w3c.github.io/wot/ucr-doc/
The present document gathers and describes new use cases and requirements for future standardisation work in the WoT standard.
This document is an early work in progress and is currently under significant editorial and content rework. It is currently an aggregation of use case descriptions that were contributed in a different file format (Markdown)
Before it can be published as a IG note, it will undergo major restructuring and cleanup in due course.
There are MANY TV standards and this would be a long list. Rather leave blank unless a very specific standard provides more insight.
Sample flow:A service, or a user, sends a (SPARQL) query to the discovery endpoint of a known Middle-Node (which can be wrapped by a GUI). The Middle-Node will try to answer the query first checking the Thing Descriptions of the IoT devices registered in such Middle-Node. Then, if the query requires further discovery, or it was not successfully answered the Middle-Node will forward the query to its *known* Middle-Nodes. Recursively, the Middle-Nodes will try to answer the query and/or forward the query to their known Middle-Nodes. When one Middle-Node is able to answer the query it will forward back to the former Middle-Node the partial query answer. Finally, when the discovery task finishes, the former Middle-Node will join all the partial query answers producing an unified view (which could be synchronous or asynchronous).
F2761-09 (2013)Medical Devices and Medical Systems - Essential safety requirements for equipment comprising the patient-centric integrated clinical environment (ICE) - Part 1: General requirements and conceptual model. The idea behind ICE is to allow medical devices that conform to the ICE standard, either natively or using an adapter, to interoperate with other ICE-compliant devices regardless of manufacturer.
OpenICEOpenICE is an initiative to create a community implementation of F2761-09 (ICE - Integrated Clinical Environment) based on DDS.
MDIRA Specification Document Version 1.0.MDIRA Version 1.0 provides requirements and implementation guidance for MDIRA-compliant systems focused on trauma and critical care in austere environments. Johns Hopkins University Applied Physics Laboratory (JHU-APL) lead a research project in collaboration with US military to develop a framework of autonomous / closed loop prototypes for military health care which are dual use for the civilian healthcare system.
Virtual TwinThe virtual twin is a representation of a physical device or an asset. A virtual twin uses a model that contains observed and desired attribute values and also uses a semantic model of the behavior of the device. Intermittent connectivity: An application may not be able to connect to the physical asset. In such a scenario, the application must be able to retrieve the last known status and to control the operation states of other assets. Protocol abstraction: Typically, devices use a variety of protocols and methods to connect to the IoT network. From a users perspective this complexity should not affect other business applications such as an enterprise resource planning (ERP) application. Business rules: The user can specify the normal operating range of a property in a semantic model. Business rules can be declaratively defined and actions can be automatically invoked in the edge or on the device. Example: In a fleet of connected vehicles, the user monitors a collection of operating parameters, such as fuel level, location, speed and others. The semantics-based virtual twin model enables the user to decide whether the operating parameters are in normal range. In out of range conditions the user can take appropriate actions.
Predictive TwinIn a predictive twin, the digital twin implementation builds an analytical or statistical model for prediction by using a machine-learning technique. It need not involve the original designers of the machine. It is different from the physics-based models that are static, complex, do not adapt to a constantly changing environment, and can be created only by the original designers of the machine. A data analyst can easily create a model based on external observation of a machine and can develop multiple models based on the user’s needs. The model considers the entire business scenario and generates contextual data for analysis and prediction. When the model detects a future problem or a future state of a machine, the user can prevent or prepare for them. The user can use the predictive twin model to determine trends and patterns from the contextual machine data. The model helps to address business problems.
Twin ProjectionsIn twin projections, the predictions and the insights integrate with back-end business applications, making IoT an integral part of business processes. When projections are integrated with a business process, they can trigger a remedial business workflow. Prediction data offers insights into the operations of machines. Projecting these insights into the back-end applications infrastructure enables business applications to interact with the IoT system and transform into intelligent systems.
Decentralized Power GenerationWhile electricity grids with centralized power generation have dominated up to now, the trend is moving towards decentralized generation plants, both for generation from fossil primary energy through small CHP plants and for generation from renewable sources such as photovoltaic systems, solar thermal power plants, wind turbines and biogas plants. This leads to a much more complex structure, primarily in the area of load control, voltage maintenance in the distribution grid and maintenance of grid stability. In contrast to medium to large power plants, smaller, decentralised generation plants also feed directly into the lower voltage levels such as the low-voltage grid or the medium-voltage grid. This use case variants also includes operation and control of energy storages like batteries.
Virtual Power PlantsA Virtual Power Plant (VPP) is an aggregation of Distributed Energy Resources (DERs) that can act as an entity on energy markets or as an ancillary service to grid operation. The individual DERs often have a primary use on their own, with electric generation/consumption being a side-effect resp. secondary use. This results in negotiations/collaborations between many different parties e.g. such as the DER owner, the VPP operator, the grid operator and others.
Smart MeteringFor consumers, a major change is the installation of smart meters. Their core tasks are remote reading and the possibility to realize fluctuating prices within a day at short notice. All electricity meters must therefore be replaced by those with remote data transmission.
Other variantsEmergency response, grid synchronization, grid black start
+--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+Steps A and B defines what is known as authorization grant type or flow. What is important to realize here is that not all of these interactions are meant to take place over a network protocol. In some cases, interaction with with a human through a user interface may be intended. OAuth2.0 defines 4 basic flows plus an extension mechanism. The most common of which are:
+-----------+ +----------+ | | | Resource | | Remote | | Owner | | Device +<-------+ | | | | | +----+-----+ +-----------+ | ^ | | | (B) | +------------+ Client Identifier +---------------+ | | ------(A)-- & Redirection URI ---->+ | | | User- | | Authorization | | | Agent ------(B)-- User authenticates --->+ Server | | | | | | | | ------(C)-- Authorization Code ---<+ | | +---+----+---+ +---+------+----+ | | | ^ v | (A) (C) | | | | | | | | ^ v | | | +---+----+---+ | | | | |>-+(D)-- Authorization Code ---------' | | | WoT | & Redirection URI | | | Consumer | | | | |<-+(E)----- Access Token -------------------' | +-----+------+ (w/ Optional Refresh Token) | v | | | +-----------(F)----- Access WoT --------------------------------+ AffordanceNotice that steps (A), (B) and (C) are broken in two parts as they pass through the User-Agent.
deviceThe device flow (IETF RFC 8628) is a variant of the code flow for browserless and input-constrained devices. Similarly, to its parent flow, it requires a close interaction between the resource owner and the WoT consumer. Therefore, the use cases for this flow are the same as the code authorization grant but restricted to all devices that do not have a rich means to interact with the resource owner. However, differently from `code`, RFC 8628 states explicitly that one of the actors of the protocol is an end-user interacting with a browser (even if section-6.2 briefly describes an authentication using a companion app and BLE), as shown in the following (slightly adapted) diagram:
+----------+ | | | Remote | | Device | | | +----^-----+ | | (G) Access WoT Affordance | +----+-----+ +----------------+ | +>---(A)-- Client Identifier ---v+ | | | | | | +<---(B)-- Device Code, ---<+ | | | User Code, | | | WoT | & Verification URI | | | Consumer | | | | | [polling] | | | +>---(E)-- Device Code --->+ | | | & Client Identifier | | | | | Authorization | | +<---(F)-- Access Token ---<+ Server | +-----+----+ (& Optional Refresh Token) | | v | | : | | (C) User Code & Verification URI | | : | | ^ | | +-----+----+ | | | End User | | | | at +<---(D)-- End user reviews --->+ | | Browser | authorization request | | +----------+ +----------------+Notable mentions:
client credentialThe Client Credentials grant type is used by clients to obtain an access token outside of the context of an end-user. From RFC6749:
+----------+ | | | Remote | | Device | | | +----^-----+ | | (C) Access WoT Affordance ^ +----+-----+ +---------------+ | | | | | +>--(A)- Client Authentication --->+ Authorization | | WoT | | Server | | Consumer +<--(B)---- Access Token ---------<+ | | | | | | | +---------------+ +----------+Comment: Usually client credentials are distributed using an external service which is used by humans to register a particular application. For example, the `npm` cli has a companion dashboard where a developer requests the generation of a token that is then passed to the cli. The token is used to verify the publishing process of `npm` packages in the registry. Further examples are Docker cli and OpenId Connect Client Credentials.
implicitDeprecated From OAuth 2.0 Security Best Current Practice:
+----------+ | Resource | | Owner | | | +----+-----+ ^ | (B) +----------+ Client Identifier +---------------+ | ------(A)-- & Redirection URI --->+ | | User- | | Authorization | | Agent ------(B)-- User authenticates -->+ Server | | | | | | +<---(C)--- Redirection URI ----<+ | | | with Access Token +---------------+ | | in Fragment | | +---------------+ | +----(D)--- Redirection URI ---->+ Web-Hosted | | | without Fragment | Client | | | | Resource | | (F) +<---(E)------- Script ---------<+ | | | +---------------+ +-+----+---+ | | (A) (G) Access Token | | ^ v +-+----+---+ +----------+ | | | Remote | | WoT +>---------(H)--Access WoT--------->+ Device | | Consumer | Affordance | | | | +----------+ +----------+
resource owner passwordDeprecated From OAuth 2.0 Security Best Current Practice:
+----------+ | Resource | | Owner | | | +----+-----+ v | Resource Owner (A) Password Credentials | v +-----+----+ +---------------+ | +>--(B)---- Resource Owner ------->+ | | | Password Credentials | Authorization | | WoT | | Server | | Consumer +<--(C)---- Access Token ---------<+ | | | (w/ Optional Refresh Token) | | +-----+----+ +---------------+ | | (D) Access WoT Affordance | +----v-----+ | Remote | | Device | | | +----------+
Actors (represent a physical person or group of persons (company))Manufacturer Service Provider Network Provider (potentially transparent for WoT use cases) Device Owner (User) Others?
Roles:Depending on the use case, an actor can have multiple roles, e.g. security maintainer. Roles can be delegated.
This section defines the properties required in an abstract Web of Things (WoT) architecture.
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.
There are already 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.
WoT must be able to scale for IoT solutions that incorporate thousands to millions of devices. These devices may offer the same capabilities even though they are created by different manufacturers.
WoT must provide interoperability across device and cloud manufacturers. It must be possible to take a WoT enabled device and connect it with a cloud service from different manufacturers out of the box.
The W3C WoT Thing Architecture [[wot-architecture]] defines the abstract architecture of Web of Things and illustrates it with various system topologies. This section describes technical requirements derived from the abstract architecture.
The use cases help to identify basic components such as devices and applications, that access and control those devices, proxies (i.e., gateways and edge devices) that are located between devices. An additional component useful in some use cases is the directory, which assists with discovery.
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, in general components can be deployed across multiple networks.
Access to devices is made using a description of their functions and interfaces. This description is called Thing Description (TD). A Thing Description includes a general metadata about the device, information models representing functions, transport protocol description for operating on information models, and security information.
General metadata contains device identifiers (URI), device information such as serial number, production date, location 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 be able to generate and use network and program interfaces based on metadata (descriptions).
Applications have to be able to obtain these descriptions through the network, therefore, need to be able to conduct search operations and acquire the necessary descriptions over the network.
Digital Twins need to generate program interfaces internally based on metadata (descriptions), and to represent virtual devices by using those program interfaces. A twin has to produce a description 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 descriptions provided either directly by the twin or to have them available at external locations. In either case it is required to make the descriptions available so that other components can find and use the devices associated with them.
For TDs of devices and virtual devices to be accessible from devices, applications and twins, there needs to be a common way to share TDs. Directories can serve this requirement by providing functionalities to allow devices and twins 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 encryption.
WoT architecture should support multiple security mechanism commonly used in the web, such as Basic, Digest, Bearer and OAuth2.0.
The Web of Things primarily targets machine-to-machine communication. The humans involved are usually developers that integrate Things into applications. End-users will be faced with the front-ends of the applications or the physical user interfaces provided by devices themselves. Both are out of scope of the W3C WoT specifications. Given the focus on IoT instead of users, accessibility is not a direct requirement, and hence is not addressed within this specification.
There is, however, an interesting aspect on accessibility: Fulfilling the requirements above enables machines to understand the network-facing API of devices. This can be utilized by accessibility tools to provide user interfaces of different modality, thereby removing barriers to using physical devices and IoT-related applications.
Special thanks to all authors of use case descriptions for their contributions to this document.
Many thanks to the W3C staff and all other active Participants of the W3C Web of Things Interest Group (WoT IG) and Working Group (WoT WG) for their support, technical input and suggestions that led to improvements to this document.