PROPOSED Web of Things Working Group Charter

The mission of the Web of Things Working Group is to counter the fragmentation of the IoT through the specification of building blocks that enable easy integration of IoT devices and services across IoT platforms and application domains. These building blocks should complement and enhance existing standards. This Working Group Charter covers those aspects that the Web of Things Interest Group (charter here) believes are mature enough to progress to W3C Recommendations.

Join the Web of Things Working Group.

This proposed charter is available on GitHub. Feel free to raise issues.

Charter Status See the group status page and detailed change history.
Start date 1 June 2023 (ESTIMATED) (date of the "Call for Participation", when the charter is approved)
End date 1 June 2025 (ESTIMATED; Start date + 2 years)
Chairs [chair name] (affiliation)
Team Contacts Kazuyuki Ashimura (0.2 FTE)
Meeting Schedule Teleconferences: Weekly with additional topic specific calls as appropriate.

Face-to-face: We will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, with no more than four (4) face-to-face meetings in total per year.

Note: The W3C Process Document requires “The level of confidentiality of the group's proceedings and deliverables”; however, it does not mandate where this appears. Since all W3C Working Groups should be chartered as public, this notice has been moved from the essentials table to the communication section.

This working group is tasked with the standardization or extension of several technological building blocks identified by the Web of Things Interest Group (IG) as being important to advancing the Web of Things. The WoT building blocks are intended to complement existing and emerging IoT standards by focusing on enabling cross-platform and cross-domain interoperability. The proposed work items are summarized in the Scope section, and include (REVISE) interoperability profiles for particular usage contexts; vocabulary support for new protocols, security schemes, and links; standardized discovery mechanisms; and improvements to Thing Description Templates. These work items will be prototyped and tested by multiple implementors in WoT IG PlugFests during development. Open-source implementations will be prioritized.

Scope

The Working Group has the following work items in scope:

Scope Summary

After each work item, in parenthesis, we identify the deliverables it may be included in.
Discovery Updates (Discovery):
Backward-compatible updates to the Discovery specification to support additional introduction mechanisms, align with scripting APIs, support all Thing Description versions (1.0, 1.1, and 2.0), and improve security and validation.
Discovery of Thing Models (Discovery):
Extend discovery support to include storing and returning Thing Models from exploration mechanisms.
Discovery CoAP Directory (Discovery):
Add support for a CoAP API to TD Directory services supporting discovery.
Discovery JSON Path Query Language (Discovery):
Add support for JSONPath queries to TD Directory services.
Discovery Query Filters (Discovery):
Add support for query filters for common use cases to TD Directory services.
Geolocation (Discovery, Thing Description, Profiles):
Define mechanisms for embedding of static geolocation information in TDs, annotation of data models for dynamic geolocation, and spatial filters in TD Directory queries for geospatially-limited discovery.
Onboarding (Architecture, Discovery, Security):
Define lifecycle process to establish mutual trust and identification.
Security Scheme Ontology (Thing Description, Security):
Refactor TD security schemes using TD extension ontologies.
Signing (Discovery, Thing Description, Security):
Add support for TD signing and support signed TDs in the discovery process. Requires definition of TD canonicalization.
Timeseries (Thing Description, Binding Templates):
Add support for describing historical values or value changes of affordances to the TD specification in an interoperable way with existing solutions.
Payload Driven Protocols (Thing Description, Binding Templates, Profiles):
Add support for describing protocols that depend on specific payload structures on top of the protocol bindings.
Manageable Actions (Thing Description, Profiles):
Add support for describing actions that can be managed after their invocation.
Initial / Common Connection Description (Thing Description, Binding Templates):
Add support for a connection description to be shared among affordance operations
Canonicalization (Thing Description, Discovery):
Add a canonicalization algorithm.
Inline Security (Thing Description):
Add a way to describe security definitions in a simplified fashion for simple cases.
TD Versioning (Thing Description, Discovery):
Explain the semantics on how to version Thing Descriptions.
Normative TD Parsing, Consuming and Validation (Thing Description, Scripting API, Profiles):
Define normative algorithms for parsing, consuming and validating Thing Descriptions.
Linting mechanism for TDs (Thing Description, Profiles):
Define a linting mechanism for Thing Descriptions that allows adding additional rules.
Binding Mechanism (Binding Templates, Thing Description, Security, Profiles):
Add normative binding mechanism
HTTP Protocol Binding (Binding Templates)
Add normative HTTP binding
CoAP Protocol Binding (Binding Templates)
Add normative CoAP binding
MQTT Protocol Binding (Binding Templates)
Add normative MQTT binding
Modbus Protocol Binding (Binding Templates)
Add normative Modbus binding
BACnet Protocol Binding (Binding Templates)
Add normative BACnet binding
OPC UA Protocol Binding (Binding Templates)
Add normative OPC UA binding
gRPC Protocol Binding (Binding Templates)
Add normative gRPC binding
JSON Payload Binding (Binding Templates)
Add normative JSON binding
CBOR Payload Binding (Binding Templates)
Add normative CBOR binding
XML Payload Binding (Binding Templates)
Add normative XML binding
CloudEvents Payload Binding (Binding Templates)
Add normative CloudEvents binding
ECHONET Lite Web API Combination Binding (Binding Templates)
Add normative ECHONET Lite Web API binding

Details for each of these are given below.

Discovery Updates

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.

Discovery of Thing Models

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.

Discovery CoAP 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.

Discovery JSON Path Query Language

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.

Discovery Query Filters

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.

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.

Onboarding

In order to establish secure communications in some contexts, for example on a LAN, some form of onboarding process to establish mutual trust between Things and Consumers is needed. Having a prescriptive (but optional) process for this would be useful. Onboarding may be part of a larger "lifecycle" which would be described in the Architecture document. In this work item we will define mechanisms to perform secure minimum-effort onboarding of Things 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.

Security Scheme Ontology

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. Then the TD 2.0 spec would only have to include general-purpose "structural" security schemes like nosec and combo. The security ontologies and URLs for them would be published in a new Registry Track Note.

Signing

A mechanism for signing JSON-LD documents was under discussion in the last charter but was not mature enough to include. Adding support for RDF canonicalization and signing in alignment with those standards would be helpful to ensure that TDs are not intercepted and modified by third parties. This may also require a definition of TD canonicalization. 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 should be extended to verify signatures and generate new chained signatures as needed.

Timeseries

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:

Payload Driven Protocols

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.

Manageable Actions

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:

These limitations are also influencing the Profiles.

Additionally, there have been proposals by the WG members that need to taken into account and evaluated:

Related Issues:

Initial / Common Connection Description

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:

Canonicalization

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:

Inline Security Definitions

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 Versioning

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:

TD Parsing, Consumption and Validation

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.

TD Linting

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:

Binding Mechanism

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.

HTTP Protocol Binding

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.

CoAP Protocol Binding

The WG will work on the current Modbus 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.

MQTT Protocol Binding

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.

Modbus Protocol Binding

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.

BACnet Protocol Binding

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?

OPC UA Protocol Binding

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?

gRPC Protocol Binding

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.

JSON Payload Binding

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.

CBOR Payload Binding

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.

XML Payload Binding

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.

CloudEvents Payload Binding

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.

ECHONET Lite Web API Combination Binding

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?

Out of Scope

The following features are out of scope, and will not be addressed by this Working group.

Application- and domain-specific metadata vocabularies:
The Working Group is restricted to work on cross-domain vocabularies.
APIs and security frameworks specific to particular platforms external to the W3C:
The scope of the Working Group is restricted to APIs and security frameworks that are applicable across platforms. We will not define new security mechanisms but will use existing mechanisms and best practices.
Modification of protocols:
If during work on protocol bindings, it becomes apparent that changes are needed to protocols, the Web of Things Working Group will rely on the organization responsible for the protocol to make the changes. It is out of scope for the Working Group to standardize such changes itself.

Deliverables

Updated document status is available on the group publication status page. [or link to a page this group prefers to use]

Draft state indicates the state of the deliverable at the time of the charter approval. Choose one: Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state The Working Group intends to publish the latest state of their work as Candidate Recommendation (with Snapshots) and does not intend to advance their documents to Recommendation.

Normative Specifications

The Working Group will deliver the following W3C normative specifications:

Web of Things (WoT) Thing Description 2.0

This specification defines the version 2.0 of the Thing Description specification. This version will include features that have been postponed due to being not backwards compatible and other features that have been identified via use cases.

Draft state:No draft

Expected completion: TBD

Adopted Draft: This will be a revision of the current Web of Things (WoT) Thing Description 1.1 specification published at https://www.w3.org/TR/wot-thing-description/, as a Candidate Recommendation on 19 January 2023.

Web of Things (WoT) Discovery 1.1

This specification defines a Discovery process for WoT, and would be a backward-compatible update to the existing WoT Discovery Specification.

Draft state:No draft

Expected completion: Q3 2024

Adopted Draft: This will be a revision of the current Web of Things (WoT) Discovery specification published at https://www.w3.org/TR/wot-discovery/, as a Candidate Recommendation on 19 January 2023.

Web of Things (WoT) Binding Templates

This specification defines the mechanism to bind protocols, payload and media formats, or combination of the two to the Web of Things. The binding mechanism will be a normative document with the following set of registry sections:

  • 3 registry sections dedicated to stable bindings that reach at least a working draft status
  • 3 registry sections dedicated to experimental bindings that are at least publicly available

Draft state:No draft

Expected completion: TBD

Adopted Draft:TBD

Other Deliverables

Other non-normative documents may be created such as:

  • Use case and requirement documents;
  • Test suite and implementation report for the specification;
  • Primer or Best Practice documents to support web developers when designing applications.

Timeline

Put here a timeline view of all deliverables.

  • June 2023: First teleconference
  • July 2023: First face-to-face meeting
  • September 2023: Requirements and Use Cases for WoT Discovery 1.1
  • January 2024: FPWD for WoT Discovery 1.1
  • August 2024: CR Transition for WoT Discovery 1.1
  • December 2024: PR Transition for WoT Discovery 1.1
  • March 2025: REC Transition for WoT Discovery 1.1

Success Criteria

In order to advance to Proposed Recommendation, each normative specification is expected to have at least two independent interoperable implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites, and two or more implementations interoperating with each other. In order to advance to Proposed Recommendation, each normative specification must have an open test suite of every feature defined in the specification.

A testing plan will be developed for each specification, starting from the earliest drafts.

To promote interoperability, all changes made to specifications in Candidate Recommendation or to features that have deployed implementations should have tests.

Each specification should contain sections detailing all known security and privacy implications for implementers, Web authors, and end users.

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

In addition to the above catch-all reference to horizontal review which includes accessibility review, please check with chairs and staff contacts of the Accessible Platform Architectures Working Group to determine if an additional liaison statement with more specific information about concrete review issues is needed in the list below.

W3C Groups

[other name] Working Group
[specific nature of liaison]

Note: Do not list horizontal groups here, only specific WGs relevant to your work.

Note: Do not bury normative text inside the liaison section. Instead, put it in the scope section.

External Organizations

[other name] Working Group
[specific nature of liaison]

Participation

To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct.

Communication

Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.

Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Web of Things (WoT) Working Group home page.

Most Web of Things (WoT) Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis. However, one teleconference will be held weekly to coordinate activities among the task forces responsible for each specification.

This group primarily conducts its technical work on GitHub issues, using a main repository for general topics and more specific repositories for individual specifications. The public is invited to review, discuss and contribute to this work.

The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

Decision Policy

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the licensing information.

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Charter History

Note:Display this table and update it when appropriate. Requirements for charter extension history are documented in the Charter Guidebook (section 4).

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):

Charter Period Start Date End Date Changes
Initial Charter [dd monthname yyyy] [dd monthname yyyy] none
Charter Extension [dd monthname yyyy] [dd monthname yyyy] none
Rechartered [dd monthname yyyy] [dd monthname yyyy]

[description of change to charter, with link to new deliverable item in charter] Note: use the class new for all new deliverables, for ease of recognition.

Change log

Changes to this document are documented in this section.