Web of Things Working Group Charter
This charter has been replaced by a newer version.
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.
|Start date||31 January 2020|
|End date||31 July 2022|
|Charter extension||See Change History.|
|Chairs||Michael McCool (Intel) and Sebastian Kaebisch (Siemens)|
Kazuyuki Ashimura (0.2 FTE)
Dave Raggett (0.1 FTE)
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.
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 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.
The Working Group has the following work items in scope:
Scope SummaryAfter each work item, in parenthesis, we identify the deliverables it may be included in.
- Architectural Requirements, Use Cases, and Vocabulary: (Architecture)
- Understand and describe requirements of new use cases, architectural patterns, and concepts.
- Link Relation Types: (Architecture, Thing Description)
- Define link relation types for specific relationships.
- Interoperability Profiles: (Profile)
- Support plug-and-play interoperabilty via a profile mechanism that defines specific subsets of TDs.
- Thing Description Templates: (Architecture, Profile, Thing Description)
- Define a mechanism to describe classes of things and an inheritance mechanism and describe how Thing Descriptions can be defined in a modular way.
- Complex Interactions: (Architecture, Thing Description, Profile)
- Document how hypermedia controls can be used to describe complex interactions and thing behaviour.
- Discovery: (Discovery)
- Define a non-mandatory mechanisms to search for and retrieve Thing Descriptions in both local and global contexts.
- Lifecycle: (Architecture)
- Terminology for states and transitions for products, devices, and information.
- Onboarding: (Architecture, Discovery)
- Define how trust can be established between Things, gateways, and servers and how security configurations and provisioning can be established.
- Identifier Management: (Architecture, Discovery)
- Mitigate privacy risks by defining how identifiers are managed and updated.
- Security Schemes: (Thing Description)
- Vocabulary for new security schemes supporting targetted protocols, use cases and new requirements.
- Thing Description Vocabulary: (Thing Description)
- Extensions to Thing Description vocabulary definitions.
- Protocol Vocabulary and Bindings: (Thing Description)
- Extensions to protocol vocabulary definitions and protocol bindings.
- Observe Defaults: (Thing Description)
- For protocols such as HTTP where multiple ways to implement "observe" is possible, define a default.
Details for each of these are given below.
Architectural Requirements, Use Cases, and Vocabulary
The WoT Architecture specification includes the definitions of several terms and concepts used to define WoT specifications. These are often related closely to use cases and architectural patterns. As WoT implementations mature, it will be necessary to understand and describe the requirements for new use cases, architectural patterns, and associated concepts and vocabulary. In addition, descriptions of existing use cases and architectural patterns may need to be revisited to include these new concepts.
Link Relation Types
The WoT Thing Description (TD) includes a link mechanism to declare (potentially bidirectional) relationships between a TD and other entities identified by URIs, including but not limited to Thing Templates and other TDs. Each link includes a relation type which specifies the purpose of the link. To maximize interoperability, relation types for specific purposes should be identified. In collaboration with the WoT Interest Group and after use-case analysis, the Working Group will identify relation types of particular interest and specify their use for suitable use cases.
Candidates for link relation type specification may include type-of and part-of relationships to support Templates and Components, respectively. Other link types may be used to identify location or controller-controlled relationships, or implementation of specific network APIs.
The WoT Thing Description (TD) provides a general framework for describing the interface to a Thing independent of the network protocol, data encoding, or security mechanism used. TDs are defined to be extensible, since IoT protocols, data encodings, and security mechanisms are constantly evolving. However, this openness works against interoperability since it is not clear in advance what technologies must be supported by a given implementation of a TD Consumer, and a TD Consumer can only work with Things using the technologies it includes an implementation for.
In many contexts, "plug and play" interoperability is desirable. For example, in the Smart Home context, the consumer needs to know in advance of purchase whether a set of devices will work with each other. Such predictability is also essential in many other contexts, including industrial use cases. Unfortunately the set of technologies that must be supported depend on context: protocols, data types, and security mechanisms essential in an industrial context may be an unnecessary burden for a home gateway to have to implement.
To resolve this problem this work item will define "profiles" which define subsets of TDs supporting only specific technologies. This work item will include the following:
- Definition of a mechanism to identify the profile or profiles that a given TD is conformant to.
- Definition of specific profiles.
Thing Description Templates
Current WoT Thing Descriptions (TDs) apply to specific Things, for example, particular devices. However, there are often many devices manufactured with the same interface and capabilities. These devices differ from each other only in certain specific aspects, such as being installed in different locations and having different identifiers. In addition, devices may share common interactions for specific purposes (for example, management or power management) even if from different manufacturers and with different functions.
The current TD specification includes the definition of a "TD Template" which is a partial TD that omits information that is specific to an instance. However, the current definition of TD Templates does not define the inheritance mechanism and the applicable TD vocabulary. It only allows the definition of the interaction model without security schemes and/or protocol bindings. Thing templates have various application areas: They may be used for managing a class of devices, or to define digital twins and corresponding simulations. There are other use cases, where some knowledge of the protocol and security requirements may be required.
A closely related problem is that of components and standardized common APIs: we may wish to assemble a Thing Description from a set of reusable, modular capabilities, or declare that it supports some API, that is common to a class of Things. How is a TD Component to be defined and how are they to be combined into a complete Thing? How is a TD Consumer able to determine that a particular Thing supports a specific sub-interface common to a set of Things?
This work item will elaborate and refine the TD Template concept so it can satisfy these use cases.
Many use cases require the implementation of complex interactions that span multiple protocol transactions. An example would be the initiation, monitoring, and possible cancellation of ongoing actions. Another would be managing and accessing historical queues for events and actions.
In fact such complex interactions can be implemented with the more basic features already included in the WoT Thing Description and in particular can be supported in a self-describing way with hypermedia controls. Hypermedia controls can also be used to clarify what remediary actions can be taken when an error occurs.
However, there are many possible ways to implement and use such complex interactions. To better support the goals of interoperability, it would be useful to precisely define the most common complex interactions.
This work item will document the behavior of complex interactions, including:
- The ability to initiate, monitor, and cancel ongoing actions.
- Support for action and event queues.
- Error recovery via hypermedia responses.
During the previous charter a format for the storage of the metadata required to access a Thing was defined: the WoT Thing Description (TD). However, no mechanism was defined for the distribution of TDs. The exact properties of distribution mechanisms are important to preserve privacy, in particular TDs should only be distributed to parties with permission to access the data. However, we also wish to support flexible ad-hoc discovery of the services and devices described by WoT TDs. Discovery should be available at both local and global scales. It should also be possible for devices to self-describe themselves directly rather than depending on a centralized infrastructure.
This work item will require a coordinated effort with other standards bodies such as IETF also working on discovery and directory mechanisms so that a common architecture can be defined. Working closely with other WG within the W3C, such as the Privacy WG and the Distributed ID WG will also be important.
To summarize, the discovery mechanism proposed by this Working Group needs to support both peer-to-peer discovery and directory-based discovery, both local and global discovery, be privacy-preserving, and be coordinated with other standards bodies and W3C working groups.
Definition and description of states and transitions for products, devices and information. The product lifecycle definition will include the consideration that TDs can be used during planning, design, manufacturing, operational and maintenance. The device lifecycle will deal with the process by which trust is established and updated and the security configuration of a device is managed. The information lifecycle relates to the evolution of sensitive information such as IDs in TDs and is especially relevant to the protection of privacy.
In this work item we will define mechanisms to perform minimum-effort onboarding of Things in a secure way that conforms to the security and privacy requirements of specific deployment scenarios and use cases.
This work item complements the work that is done for device discovery, however is also applicable for other use cases.
A WoT Thing Description contains an identifier meant to be unique to every Thing. This identifier is useful for database management (for example, for device inventory) but can also pose a privacy risk. In particular, an immutable unique identifier might be used to track a device and from that infer the location or activities of the owner of that device. If identifiers persist across transfer of ownership of devices, they might also be used to trace commercial transactions or pose an even greater tracking risk.
In order to preserve privacy or confidentiality, such identifiers may need to be considered mutable so that such tracking can be disrupted. More generally, the lifecycle of such identifiers needs to be defined: when they are assigned, when and how they are updated, how notifications of such updates can be issued to authorized users, and how the identifiers must be deleted when an object is decommissioned or replaced when a device changes ownership.
This work item would define an identifier management lifecycle that would seek, as much as possible, to mitigate the privacy risks posed by explicit device identifiers while retaining their functionality, for example in database management and indexing. Implementation of functionality to support updates to identifiers could also be included in the definition of directory services supporting discovery.
In the context of a WoT Thing Description (TD), a security scheme defines vocabulary for describing public security metadata indicating the security mechanisms and requirements for accessing a Thing. Currently the TD specification includes standard vocabulary for several security schemes in common use by IoT devices. However, security mechanisms are constantly evolving and to stay relevant WoT TDs need to support new security schemes on an ongoing basis. The TD specification does include a vocabulary extension mechanism which can be used to support new security schemes. However, to maximize interoperability, these extension vocabularies should be standardized and where appropriate, included by default by the core TD context.
Based on a list of target security mechanisms identified by the WoT Interest Group, this work item will include the following tasks:
- For each target security mechanism, define a standard extension vocabulary for a security scheme supporting that mechanism that can be used with the current TD specification.
- For a core set of security schemes, propose extensions to the core TD vocabulary to include them by default.
Candidates for target security schemes include support for all flows in OAuth2, support for PoP Tokens, and support for ACE. This list is not inclusive and additional security schemes may be considered.
Thing Description Vocabulary
The WoT Thing Description (TD) context includes a core set of vocabulary. This vocabulary can be extended by including additional context files. However, to support new use cases and protocols in a consistent (interoperable) way, especially in cases where JSON-LD processing is not possible, extensions to this core vocabulary may be necessary.
Candidates for TD vocabulary extension include support for Data Schemas consistent with updated versions of JSON Schema, extensions to Data Schemas to support XML and CBOR (and possibly other structured payload data formats), support for additional standard metadata such as location or device manufacturer, and better support for default values.
Protocol Vocabulary and Bindings
The WoT Thing Description (TD) specification is augmented by a WoT Protocol Binding document which defines templates for how to use a TD to describe Things using specific concrete protocols. However, individual concrete protocols may require additional vocabulary to define protocol parameters, such as header options and other metadata. These are defined using vocabulary extensions specific to each protocol. Currently only a limited set of protocols are supported in a standard way. This work item will add support for an additional set of target protocols, where appropriate in collaboration with the defining standards body. This support will include new vocabulary and documentation of how to use that vocabulary in a protocol binding.
Candidates for extended protocol vocabulary include support for CoAP(S), CoAP(S)+WS(S), MQTT, and OPC UA.
The WoT interaction model includes abstractions for Properties, Events, and Actions. The Properties abstraction in particular includes an "observe" operation, which allows a Thing to asynchronously notify a Consumer of a change in a property. However, in some protocols of interest, most notably HTTP, there are several different ways to implement the observe operation. The WoT TD allows the specification of a subprotocol to indicate the mechanism used, but unfortunately no default is specified. Because of this Things using HTTP and observe must currently explicitly state the mechanism used, every time.
This work item would specify defaults for implementing observe, including methods and subprotocols, for all important protocols but most especially HTTP.
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.
The following includes projected completion dates for each deliverable. Milestones and updated publication schedules will be made available on the group publication status page.
Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.
In the following, "(Next)" and "(Update)" are used as placeholders in a title for a version number. The form of these version numbers will be decided by the Working Group before publication.
The Working Group will deliver the following W3C normative specifications:
- Web of Things (WoT) Architecture (Update)
This specification defines the Web of Things architecture, including its use cases and terminology. This deliverable extends the current Web of Things Architecture document to address new requirements and use cases, and to clarify existing definitions.Draft status: Proposed Recommendation (current version)
Expected completion: Q4 2020
Reference Draft: https://www.w3.org/TR/2019/CR-wot-architecture-20191106/,
associated Call for Exclusion on 6 November 2019 ending on 5 January 2020,
produced under Working Group Charter: https://www.w3.org/2016/12/wot-wg-2016.html
- Web of Things (WoT) Thing Description (Update)
This specification defines the Web of Things Thing Description information model and JSON-LD serialization. This deliverable addresses high-priority issues in the current Web of Things Thing Description document.Draft status: Proposed Recommendation (current version)
Expected completion: Q4 2020
Reference Draft: https://www.w3.org/TR/2019/CR-wot-thing-description-20191106/, associated Call for Exclusion on 6 November 2019 ending on 5 January 2020,
produced under Working Group Charter: https://www.w3.org/2016/12/wot-wg-2016.html
- Web of Things (WoT) Thing Description (Next)
This specification defines the Web of Things Thing Description information model and JSON-LD serialization. This deliverable extends the current Web of Things Thing Description document to address all the work items defined.
Expected completion: Q4 2021
- Web of Things (WoT) Interoperability Profiles
This specification defines profiles for subsets of TDs to enable plug-and-play interoperability.
Draft state: Editor's Draft
Expected completion: Q3 2020
Editor's Draft: https://w3c.github.io/wot-profile/
- Web of Things (WoT) Discovery
This specification defines how WoT Thing Descriptions are to be discovered and distributed using a privacy-preserving architecture.
Draft state: None
Expected completion: Q1 2021
Other non-normative documents may be created, such as the following. Some of these may form the basis for future normative work. This is not an exhaustive list.
- Use cases and requirements:
- For each deliverable, user-oriented motivations for the features will be defined.
- WoT Security and Privacy Guidelines (W3C Note):
- This document will analyse the threats, risks, vulnerabilities, and general mitigations for security and privacy considerations identified for the Web of Things.
- WoT Security and Privacy Best Practices (W3C Note):
- This document provides a set of best practices for security and privacy that will be updated whenever necessary.
- WoT Protocol Bindings (W3C Note):
- This document will provide guidance on how a Web of Things Thing Description can be configured to support interfacing with devices in different ecosystems and using different specific protocols.
- WoT Scripting (W3C Note):
- This document will present a design for a Scripting API that will support both exposing and consuming Thing Descriptions while providing a high-level interface to interactions that is independent of protocol.
- WoT Management (W3C Note):
- This document will describe additional design aspects that need to be considered to complete a WoT-based system design, including support for secure system management and provisioning, infrastructure and application services, and software installation and update.
- WoT Packaging (W3C Note):
- In order to support software installation and update, the scripts describing the behavior of a device need to be packaged in such a way that they and their dependencies can be easily installed on a device.
- WoT Developer's Guide (W3C Note):
- The Developer's Guide will support developers creating WoT Things and applications, and will act as a tutorial for developers creating both simple and complex implementations. It will describe best practices for developers.
- WoT Primer:
- The Primer will provide an explanation of basic WoT concepts, suitable for both users and developers. Material in the Primer will act as a foundation for the more detailed material in the Developer's Guide.
Timeline view of all deliverables.
This has been aligned with publication process requirements and deliverable targets, above.
NOTE: Dates will be adjusted once the starting date has been defined. The below dates were computed from a December 1 starting date.
- Q1 2020
- January 2020: Requirements and Use Cases for WoT Interoperability Profiles
- January 2020: Requirements and Use Cases for WoT Discovery
- January 2020: Requirements and Use Cases for WoT Architecture (Update)
- January 2020: Requirements and Use Cases for WoT Thing Description (Update)
- February 2020: FPWD for WoT Interoperability Profiles
- March 2020: FPWD for WoT Discovery
- Q2 2020
- Q3 2020
- Q4 2020
- Q1 2021
- Q2 2021
- June 2021: Face-to-face meeting and plugfest
- Q3 2021
- September 2021: CR for WoT Thing Description (Next)
- September 2021: Face-to-face meeting and plugfest (TPAC)
- Q4 2021
- November 2021: PR for WoT Thing Description (Next)
In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each of feature defined in the specification.
Each specification should contain a section detailing all known security and privacy implications for implementers, Web authors, and end users.
There should be testing plans for each specification, starting from the earliest drafts.
Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.
To promote interoperability, all changes made to specifications should have associated tests.In addition, all APIs and data formats should have formal definitions, such as data schemas, that allow for automatic validation.
For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, 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:
- Web of Things Interest Group
- For collaboration as outlined in Scope.
- JSON-LD Working Group
- For collaboration on JSON-LD features and WoT use cases.
- Efficient Extensible Interchange Community Group
- In relation to efficient interchange for Thing Descriptions.
- Web and Automotive Business & Working Groups
- For collaboration on technologies and requirements relating to connected cars and the Web of Things.
- Device and Sensors Working Group
- For coordination on APIs for sensors and actuators.
- Decentralized Identifier Working Group
- For coordination on identity management and information lifecycle.
- Web & Networks Interest Group
- For collaboration on networking technologies on the edge and in the cloud when exposing interactions between Things.
- Accessible Platform Architectures Working Group
- For coordination on impacts of Web of Things technologies on accessibility to users with disabilities.
- Privacy Interest Group
- In addition to horizontal review, during development of deliverables such as discovery and information lifecycle that require the development of a privacy-preserving architecture, close technical collaboration with the Privacy Interest Group will be needed.
- Schema Extensions for IoT Community Group
- For collaboration on extensions to Schema.org for IoT use cases.
To succeed in establishing inter-platform standards, W3C needs to coordinate with IoT alliances and standards development organizations. The following list provides examples of organizations with which the WoT Working Group has already had significant coordination during the period of the first charter. A longer list is available on the Interest Group wiki.
- IRTF Thing to Thing Research Group
- For coordination of matters of mutual interest in relation to the Web of Things, such as data modelling, discovery, directory services, and IoT semantics.
- Open Connectivity Foundation
- For collaboration on integrating OCF based platforms within the Web of Things, including platform metadata and approaches for enabling semantic interoperability, and end to end security across platforms.
- ECHONET Consortium
- For collaboration on integrating ECHONET Consortium based platforms within the Web of Things, including platform metadata and approaches for enabling semantic interoperability, and end to end security across platforms.
- Industrial Internet Consortium
- For collaboration on testbeds and on gathering user requirements for the Web of Things.
- OPC Foundation
- For collaboration on semantic interoperability in terms of information model, protocol binding, and security.
- Plattform Industrie 4.0
- For collaboration on use cases and requirements for smart manufacturing, including semantic interoperability and end to end security across platforms.
- For collaboration on integrating M2M based platforms within the Web of Things, including platform metadata and approaches for enabling semantic interoperability, and end to end security across platforms.
- For collaboration on IoT, M2M, security, and semantic interoperability.
- OMA SpecWorks
- For collaboration on integrating LWM2M based platforms with the Web of Things.
- Open Geospatial Consortium
- For coordination on the OGC SensorThings API and location metadata.
- For coordination in respect to the interests of Network Operators.
- For coordination on identifiers and discovery.
- For collaboration and coordination of the technical realization of the use of eCl@ss in the W3C Thing Description.
- AIOTI WG03
- For coordination with the Alliance for Internet of Things Innovation, Working Group 3 (standardisation), in respect to use cases, requirements, and semantic interoperability.
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. Ideally the Working Group would draw from different constituencies, with members from end-device manufacturers in various verticals, gateway/edge device manufacturers, and cloud providers. The Chairs, specification Editors, and Test Leads are expected to each contribute at least 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.
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 on a public repository 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 Working Group home page.
Most Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
This group primarily conducts its technical work on GitHub issues using both a master repo and repos specific to each deliverable. 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.
This group will seek to make decisions through consensus and due process, per the W3C Process Document (Section 3.3). 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 and/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 on the mailing list 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 3.4, Votes) and includes no voting procedures beyond what the Process Document requires.
This Working Group operates under the W3C Patent Policy (Version of 5 February 2004 updated 1 August 2017). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations 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 W3C Patent Policy Implementation.
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 5.2 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.
The following table lists details of all changes from the initial WoT WG charter, per the W3C Process Document (section 5.2.3):
|Charter Period||Start Date||End Date||Changes|
|Initial Charter||27 December 2016||31 December 2018|
|Charter Extension||1 January 2019||30 June 2019||Removed staff contact Yingyong Chen|
|Chair update||Matthias Kovatsch changed his affiliation and re-appointed as co-Chair on 13 February 2019.|
|Chair update||Kazuo Kajimoto stepped down as co-Chair on 4 April 2019.|
|Charter Extension||1 July 2019||31 December 2019||Charter period extended till 31 December 2019|
|Charter Extension||1 January 2020||31 January 2020||Charter period extended till 31 January 2020|
|Rechartered||31 January 2020||31 January 2022||
New charter. Deliverables include updates to existing documents (Thing Description (Update) and Architecture (Update)), extensions to existing documents (Thing Description (Next)) and new deliverables (Interoperability Profiles and Discovery)
|Charter Extension||1 February 2022||31 May 2022||Charter period extended till 31 May 2022|
|Charter Extension||1 June 2022||31 July 2022||Charter period extended till 31 July 2022|