The following are details of some planned work items for the WoT WG charter starting in 2023, based on the current draft.
Details for each of these are given below.
Various updates are expected to be needed to align the Discovery spec with updates to other proposed deliverables in this charter, for example updates to the information model, including support for all versions of the Thing Description specification, and to improve security and validation.
Currently only Thing Descriptions can be stored in TD Directories, but it would be useful to also store Thing Models in them, in particular to allow links to Thing Models to be resolved by reference to a TD Directory.
Currently, TD Directory services only have an HTTP API defined. TD Directories are the only Discovery exploration mechanism supporting the return of multiple Thing Descriptions, and they may also be needed in the case of constrained devices hosting multiple Things. However, the cost of using HTTP in constrained environments can be prohibitive. Defining a CoAP API with equivalent functionality to the HTTP API would allow the API to be used and provided by constrained devices, including those that simply want to self-host multiple TDs.
Currently there is no mandatory query language support for TD Directories. This means that consumers will often need to download the contents of the entire directory if the id of a target TD is not known. An endpoint for SPARQL queries is defined but because of the difficulty of supporting RDF processing it is optional. JSON Path is still currently under discussion as an IETF RFC but was not mature enough to include during the last charter. JSON Path queries would complement the current SPARQL-based query support but would be lighter-weight to implement and use.
Some simple query filters would be added to the API for specific common use cases, such as filtering by type, time, or keyword. These filters would be chainable with each other and with query language results, so that, for example, the result of a JSON Path query might them be filtered by time without needing to complicate the JSON Path query with time computations. This mechanism would also be able to support filtering by geolocation.
Many WoT use cases have identified a need to limit discovery by geographic location or to identify the location of a Thing. To support this, a standard way to encode geolocation metadata is needed (or several ways, each identified using a profile) and (for discovery) query mechanisms that can filter by this metadata. Geolocation metadata should be aligned with existing standards, and should support both static and dynamic situations. Geolocation information may be included in either TDs or in data delivered directly from the Thing and ideally both situations would be supported. Since multiple standards and use cases exist for geolocation information, profiles to constrain how it should be encoded in particular situations (for example, in Building Information Management Systems) would be useful.
In order to establish secure communications in some contexts a process to establish mutual trust between Things and Consumers is needed. Having a prescriptive (but optional) process for this would be useful.
In particular, the goal of the onboarding process would be allow encrypted communications to be used on a LAN, including establishing and exchanging keying material among a set of devices without requiring fixed URLs or use of a CA. The keying material could, for example, take the form of certificates containing public keys that can be used to identify devices and also to establish mutual TLS or DTLS encrypted communication channels. A pairwise onboarding process would involve the exchange of this material between a Thing and a Consumer and a process or set of processes that can be used to verify the level of authorization to invoke affordances on the Thing. In order to onboard sets of devices, group keys or a special "onboarding" role can be used to establish transitive trust.
Onboarding is part of the larger WoT Thing lifecycle which is described in the Architecture document. In this work item we will define mechanisms to perform secure minimum-effort trust establishment and identity confirmation among sets of devices (both Things and Consumers) that conforms to the security and privacy requirements of specific deployment scenarios and use cases.
This work item complements the work that is done for device discovery, and is in particular useful when registering TDs with a TD Directory service, however is also applicable for other use cases. However, establishing identity and mutual trust would take place prior to registration with discovery services, and onboarding itself would not require registration with discovery services.
It must be possible for people with disabilities to navigate the onboarding process for Things independently. This means that any services, apps, or physical interactions that are necessary to the onboarding (or reconfiguration) process will need to be designed to be accessible, and function correctly with Assistive Technologies that Consumers may be using.
Currently security schemes are "baked into" the TD specification but it would be more manageable and consistent to break them out as separate ontologies so that all security schemes would be done via extensions. For protocol-specific security schemes in particular, these should be moved to the Protocol Bindings and ontologies supporting them. The TD 2.0 spec would be updated to only include general-purpose "structural" security schemes and "generic" schemes that apply to all protocols.
Mechanisms for signing TDs documents were under discussion in the last charter but were not mature enough to include. Adding support for TD canonicalization and signing would be helpful to ensure that TDs are not intercepted and modified by third parties. Verifying a signature requires identity management, i.e. the verifier needs to know or have trusted access to the public key of the signer. Directories need to be extended to verify signatures and generate new chained signatures as needed.
Some edge and cloud services can collect property value changes or event emissions for a certain time. This data, called timeseries, can be retrieved by Consumers to display the evolution of the affordance data over time, make predictions about the future values and more. There are different serialization formats and structures of such data in existing solutions. The generic mechanism for timeseries should be introduced in the Thing Description with bindings to existing solutions illustrated in the Binding Templates
Related Issues:
Some protocols are built on top of the application layer protocols. Some examples are:
The Thing Description should be updated with mechanisms that make it possible to describe such protocols while optimizing the TD instances to be human and machine readable. The Binding Templates should be updated with concrete cases where this mechanism is already used. The Profiles can use this mechanism to reduce the size of TDs while making them easier to understand. The working group will also document in which cases this method does not work due to making the TDs too complicated to understand, thus requiring a binding document.
Various use cases require the implementation of more complex actions that span multiple protocol transactions.
Such actions are not simply invoked but need to managed over time by the Thing and the Consumer. These are
covered in the WoT Thing Description 1.1 via the
initiation (invokeaction), monitoring (queryaction), and cancellation
(cancelaction) of ongoing actions. However, the following points are not supported:
Additionally, there have been proposals by the WG members that need to taken into account and evaluated:
Related Issues:
Currently, each form of an affordance has information on the endpoint, media type and other protocol related
information. It is possible to use the base term for simplifying the endpoint but it has limitations
such as:
Thus, a mechanism to describe connection and protocol information that can be used by other forms is needed. In protocols with initial connection, this can be also used to indicate what needs to be done by the Consumer before executing any operation.
Related Issues:
A streaming protocol establishes an ongoing connection supporting delivery of time-sensitive information such as audio or video. Note that this connection in general may be over either reliable (TCP) or unreliable (UDP) transports, or over a combination, and may also support encryption or content management. Streaming may also be used to support other kinds of ongoing time-sensitive data delivery.
While related to event notification mechanisms, streaming in practice is supported by a specific set of protcols such as RTSP, HLS, DASH, MSE, WebRTC, etc. This workitem would add any infrastructure needed to TDs in order to support streaming protocol bindings generally, for example, by adding additional subprotocols supporting stream publication and subscription management (if needed).
In order to clearly define what infrastructure is actually needed, if any, one or more concrete streaming protocol bindings should also be attempted, such as RTSP.
Thing Descriptions can contain the same information but serialized differently even in the same serialization format, due to structures such as maps which do not impose an order. This is problematic for comparing TDs or more importantly, for signing them where every byte difference results in a different signature. Thus, the WG will develop a canonicalization algorithm based on JSON-LD.
Related Issues:
Some work has been done in the previous charter but has been postponed due to lack of features in JSON-LD. Related PRs:
In order simplify how security mechanisms are described in simple cases, the WG will propose a way to use them with combining the definition and usage into a single term.
Related Issues:
Some work has been done in the previous charter but has been postponed due to backwards compatibility requirement. Related PRs:
TD allows themselves to be versioned. However, the semantics of such versioning is not defined, i.e. the meaning of version numbers. This makes it difficult to manage TDs and results in different behavior across versioned TD repositories. The WG will define the semantics of versions of a TD and recommendations on how to manage different versions of TDs.
Related Issues:
Currently the TD specification defines an abstract information model and a default JSON serialization for TDs.
However, parsing, consuming and validating TDs are not normatively defined. A validation process is defined but
is not normative, which leads to certain ambiguities for a Consumer parsing a TD. Additionally, no method is
proposed for validation the extensions that are used via the prefixes and the @context. The WG will
specify normative algorithms for parsing, consuming and validating TDs to ensure interoperability of
Consumers.
Linting rules exist for programming languages or for API specifications in order to establish custom rules within projects. How these rules can be defined for TDs is not specified in any way, making it difficult to constrain flexibility of TDs in a standardized manner. The WG will define the mechanism for linting TDs together with optional rules that can be used by different projects.
Related Issues:
The current mechanism for how a protocol or payload binding should happen is largely informative with some normative text in different deliverables. The WG will consolidate the explanation of the mechanism and explain it in further detail.
The WG will work on the current HTTP Protocol Binding that is split also into the TD specification in order to publish it as a standalone normative document. This will reference the HTTP in RDF ontology, introduce default values and describe the terms associated with the behavior of Things regarding the usage of the HTTP.
The WG will work on the current CoAP Protocol Binding in order to publish it as a standalone normative document. This will include a CoAP ontology, introduce default values and describe the terms associated with the behavior of Things regarding the usage of the CoAP.
The WG will work on the current MQTT Protocol Binding in order to publish it as a standalone normative document. This will include a MQTT ontology, introduce default values and describe the terms associated with the behavior of Things and Brokers regarding the usage of the MQTT.
The WG will work on the current Modbus Protocol Binding in order to publish it as a standalone normative document. This will include a Modbus ontology, introduce default values and describe the terms associated with the behavior of Things regarding the usage of the Modbus.
The WG will work on specifying a BACnet Protocol Binding for the Web of Things in order to publish it as a standalone normative document. This will include a BACnet ontology, introduce default values and describe the terms associated with the behavior of Things regarding the usage of the BACnet. Note: How should we mention ASHRAE here?
The WG will work on specifying a RTSP Protocol Binding for the Web of Things in order to publish it as a standalone normative document. This will include any necessary RTSP ontology (e.g. for RTSP methods), introduce default values, and describe the terms associated with the behavior of Things regarding the usage of RTSP.
RTSP is widely supported in IP cameras. The binding will permit multiple video and audio streams to be managed. Note that single cameras may have multiple videos streams supporting different resolutions or encodings, may likewise support multiple audio streams for different rates or encodings, and may support bidirectional audio streams (e.g. a speaker as well as a microphone). This is related to the Streaming workitem.
Note 1: There are many other streaming protocols. RTSP is older but is widely supported in IP cameras in particular. Unfortunately it is typically not directly supported in browsers, so we may want to consider additional streaming protocols such as HLS, DASH, MSE, WebRTC, RTMP, or others. Many of these are supported in browsers although often optimized for non-camera use cases, such as video conferencing (WebRTC) or content delivery (HLS, DASH).
Note 2: In addition IP cameras also often have associated pan-tilt-zoom (PTZ) controls so we may want to define some vocabulary terms to allow affordances for such controls to be described consistently in a TD.
The WG will work on specifying an OPC UA Protocol Binding for the Web of Things in order to publish it as a standalone normative document. This will include a OPC UA ontology, introduce default values and describe the terms associated with the behavior of Things regarding the usage of the OPC UA. Note: How should we mention OPC Foundation here?
The WG will work on specifying a gRPC Protocol Binding for the Web of Things in order to publish it as a standalone normative document. This will include a gRPC ontology, introduce default values and describe the terms associated with the behavior of Things regarding the usage of the gRPC.
The WG will work on specifying a JSON Payload Binding for the Web of Things in order to publish it as a
standalone normative document. This will include specification on the usage of Data Schema terms as well as
contentType term usage within forms.
The WG will work on specifying a CBOR Payload Binding for the Web of Things in order to publish it as a
standalone normative document. This will include specification on the usage of Data Schema terms as well as
contentType term usage within forms.
The WG will work on specifying an XML Payload Binding for the Web of Things in order to publish it as a
standalone normative document. This will include specification on the usage of Data Schema terms as well as
contentType term usage within forms.
The WG will work on specifying an CloudEvents Payload Binding for the Web of Things in order to publish it as
a standalone normative document. This will include specification on the usage of Data Schema terms as well as
contentType term usage within forms.
The WG will work on specifying an ECHONET Lite Web API Combination Binding for the Web of Things in order to publish it as a standalone normative document. This will include specification on the usage of Data Schema terms, together with how form elements should be structured with possible other assertions on the TD instances. Note: How should we mention ECHONET Consortium here?
The WG identifies multiple areas where a coordination of the standardization activity with the W3C WoT CG is beneficial to drive more interest to the Web of Things and increase its adoption. To this end, the WG will implement the following action items: