Version: 23 Nov 2023
Editors:
Michael McCool (Intel)
Copyright © 2017-2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
The Web of Things (WoT) Architecture 1.1 document was published as a Candidate Recommendation Snapshot on 19 January 2023 and as a Proposed Recommendation on 11 July 2023.
This document summarizes the results from the Web of Things (WoT) Architecture 1.1 implementer reports received and describes the process that the Web of Things (WoT) Working Group followed in preparing this Implementation Report (IR).
Results were based on data files submitted by implementers stating whether or not their implementations conformed to the specification.
During the CR period, the Working Group performed the following activities:
Implementers were invited to contribute to the assessment of the Web of Things (WoT) Architecture 1.1 Candidate Recommendation by submitting implementer reports describing the coverage of their implementations with respect to the test assertions outlined in the table below.
Implementer reports were collected through the W3C WoT Interest Group's
PlugFest activity and collected
in the GitHub repository
https://github.com/w3c/wot-testing
under data/input_2022/Architecture.
Comments on this document, or requests made for further information were posted to the Working Group's public mailing list wot-wg@w3.org (archive) and as issues on the GitHub repository https://github.com/w3c/wot-architecture.
The Web of Things (WoT) Working Group established the following entrance criteria for the Proposed Recommendation phase:
In order to be included in the PR all features, whether optional or required, need to have received at least two implementations. At the time of publication of this report all assertions have met this requirement.
Feature status is in practice indicated by RFC 2119 assertions associated with the feature. Features defined using any assertions containing the words MUST are considered required. Features defined using MAY and SHOULD assertions are considered optional.
Feature utility is indicated indirectly by the number of implementations supporting each feature. In general, features with fewer implementations will have a narrower scope, but may still be important for specific use cases.
pass, fail, or not-impl (not implemented).
This implementation Report will not cover:
Although we did not formally test interoperability, we required two or more independent implementations for all features in the specification and tested general interoperability at plugfest events.
This section contains descriptions of each of the implementations of the WoT Architecture specification from all organizations that submitted implementer reports to at least one of the WoT specifications. Each implementation represents a working system that is based on the WoT Architecture. However, only the following submitted implementation reports for the WoT Architecture specification itself, and not all of these reported on all features:
For the purpose of establishing the implementability of the WoT Architecture specification, we only count systems with mostly independent code bases as distinct implementations. There are however some cases (documented in the following) where implementations shared components but were still considered substantially independent implementations. In cases where a substantial component was shared across implementations the features supported by that component were only counted once.
The library dart_wot is a WoT Scripting API implementation written in the Dart programming language, aimed at bringing Web of Things support to the Dart/Flutter ecosystem.
It supports consuming and discovering TDs, providing protocol bindings for HTTP, CoAP, and MQTT.
Its supported security mechanisms include DTLS (CoAP), TLS (HTTP, MQTT), Basic and Bearer authentication (HTTP), PSK (CoAP), and username/password authentication (MQTT).
Furthermore, dart_wot's CoAP binding offers experimental support for ACE-OAuth (RFC 9200), an authorization and authentication framework for constrained environments.
Usage: dart_wot can be included in Dart and Flutter projects as a dependency. In Flutter apps, all platforms are supported, with macOS and iOS (where CoAPS support is limited) and Web browsers (where CoAP is not supported at all) as partial exceptions.
Public Repository: https://github.com/namib-project/dart_wot
pub.dev Entry: https://pub.dev/packages/dart_wot
Contributing Member Organizations: Invited Experts
Eclipse Ditto offers a Java Module to use TDs and TMs inside Java environments with concepts native to Java, e.g. providing a builder API for creating new TM/TD instances and rendering those to JSON strings and vice versa.
Usage: Library
Public Repository: https://github.com/eclipse/ditto/tree/master/wot/model
Contributing Member Organizations: Bosch.IO
A service that provides APIs for managing digital twins and interacting with the abstracted devices. Fetches linked Thing Models of digital twins and provides instance specific Thing Descriptions for them.
Usage: Service
Public Repository: https://github.com/eclipse/ditto
Website: https://www.eclipse.org/ditto/basic-wot-integration.html
Contributing Member Organizations: Bosch.IO
This is an intermediary that connects ECHONET Lite devices into the W3C WoT and allows WoT clients to interact with them via provided TDs.
This intermediary extends the node-wot library.
The Eclipse EdiTDor implementation is a web application for simply designing W3C Thing Descriptions and Thing Models.
Usage: Web Application
Public Repository: https://github.com/eclipse/editdor Website: https://eclipse.github.io/editdor/
Contributing Member Organizations: Siemens AG, Bosch.IO
This TM focused implementation is built upon the Fischertechnik Factory Simulator. The TMs are written by hand, together with the relationships. The TMs are then consumed by Eclipse Thingweb node-wot and is the reason why only TMs are submitted instead of TMs and the corresponding TDs.
Usage: To be consumed by tools like Eclipse Thingweb node-wot
Contributing Member Organizations:Siemens AG and TU Munich (not member)
The Fujitsu ledbulb is a Wi-Fi controllable LED bulb that can be changed brightness and color. In addition, the light can be gradually turned off or turned on at a specified time.
Fujitsu's proxy creates a shadow of the device in the proxy, allowing consumers to control the actual device by accessing the shadow. Even if the actual device does not have an authentication mechanism, the proxy provides an authentication mechanism instead to enable secure access. Another advantage is that even if multiple devices have different protocol bindings, they can be accessed using one protocol. It also has a directory for discovering networked devices, creating their shadows, and registering them.
The proxy is implemented in Java.
This proxy is provided as a product in Japan. The product page is below (Japanese only). https://www.fujitsu.com/jp/products/network/carrier-router/wideareanetwork/virtuora-mx/
The Fujitsu sensor is a sensor with temperature, humidity, and air pressure, and can be communicated through Wi-Fi to get data. This sensor was used to collect environmental data in agriculture and factories.
This is an example of a Thing implemented on a microcontroller. It can exporting the Thing's sensor reading via HTTP REST API, and advertise its own Thing Description using DNS-SD/mDNS.
Node generator is command line tool to generate Node-RED node modules from several various sources including Thing Description of Web of Things. Using this tool, node developers can dramatically reduce their time to implement Node-RED node modules.
This is an example of a Thing implemented in Node-RED. It can turn on and off a LED connected to Raspberry Pi's GPIOs and notify changes in LED status. It can also advertise its own Thing Description using DNS-SD/mDNS.
This plugin uses wot-discovery functionality and make it easy to import Things into Node-RED flow editor. The plugin discovers Things connected on the local area network or registered in the Thing Description Directory, and converts them into functional blocks that can be used in Node-RED.
Two services based on a shared NodeJS codebase (not using node-wot):
Usage: Exposer
Contributing Member Organizations: Intel
This is a reverse proxy service that provides authentication (via various mechanisms indicated by the schemes indicated in the Thing Description) and encrypted transport (TLS) termination. The reverse proxy service was made accessible over a secure tunnel, and depending on the circumstances, can be run in the cloud, on a gateway computer, or locally on a device.
The secure endpoints provided by this service are not given in TDs for the service itself, but added to the TDs for the Things it services.
Usage: Intermediary
Contributing Member Organizations: Intel
A simple integration of WoT into Home Assistant. A service interrogates the metadata made available from Home Assistant on its external RESTful API. It then generates TDs for Home Assistant entities that can be accessed via this API and makes then available via a TD Directory service that follows the WoT Discovery specification. WoT Consumers can then access the TD Directory to find TDs for entities supported by Home Assistant and access these services using WoT affordance abstractions.
Usage: Directory and Exposer
Contributing Member Organizations: Intel
The MQTT Experimental is an MQTT-based Thing implementation that aims to test different WoT operations together with the Data Schema variations that can exist in a TD. It is implemented in Python and can act as a way to verify interoperability between different MQTT Binding implementations.
Usage: Command line
Public Repository: https://github.com/egekorkan/wot-implementations/tree/master/mqtt-online
Contributing Member Organizations:Siemens AG
WoT device emulator (Android App) Hybrid TV Emulator AndroidTV App
The Eclipse node-wot implementation is a Node.js-based framework for WoT Servients. It features an implementation of the WoT Scripting API to both consume TDs to instantiate Consumed Things and produce Exposed Things that provide a TD. The Eclipse node-wot implementation supports several Protocol Bindings including HTTP, CoAP, WebSockets, MQTT, Firestore, OPC-UA, Modbus, M-Bus and NETCONF with corresponding security mechanisms such as DTLS (CoAP); TLS (HTTP, MQTT), Basic, Digest, and Bearer Token authentication (HTTP), PSK (CoAP), and username/password authentication (MQTT).
Usage: It can be included in bigger projects as a dependency, used as a Command Line Interface or as a browser library.
Public Repository: https://github.com/eclipse/thingweb.node-wot
Contributing Member Organizations: Siemens AG, Invited Experts
This implementation leverages the already developed Philips Hue devices. The TDs for them are written by hand and show the use of WoT for brownfield devices. Philips Hue uses API Key in the URI, which is one of the features of the TD 1.1.
Usage: The TDs of the devices can be consumed and interacted with.
Public Repository: https://github.com/tum-esi/wot-sys/tree/master/Devices/PhilipsHUE
Contributing Member Organizations:Siemens AG and TU Munich (non-member)
The Thing Description Playground implementation is a set of tools that allows one to validate TDs, as well to transform them into different representations such as OpenAPI and AsyncAPI or to manipulate TDs to add or remove default terms and values. It also allows to detect implemented assertions of the TD spec by looking at a TD, which is how the implementation report for the TD is generated.
Usage: It can be included in bigger projects as a dependency, used as a Command Line Interface or as a web application library.
Public Repository: https://github.com/thingweb/thingweb-playground Website: http://plugfest.thingweb.io/playground/
Contributing Member Organizations:Siemens AG
Custom implementation pattern using the Flask library for creating an HTTP server that exposes a TD. This pattern is used in many devices that have been developed. It is not a framework like Eclipse Thingweb node-wot, more like a copy-paste driven implementation pattern.
Usage: Command line
Public Repository: All that start with "flask" at https://github.com/tum-esi/wot-sys/tree/master/Devices
Contributing Member Organizations:Siemens AG and TU Munich (non-member)
WoT modules for RIOT, a real-time operating system for the Internet of Things.
The implementation provides data structures and serialization capabilities for generating and retrieving a RIOT device's TD using CoAP and DTLS (in PSK and RPK mode).
The TD can be both discovered using /.well-known/wot and the CoRE Link Format (exposing the TD resource via /.well-known/core).
Furthermore, the implementation includes a code generator that allows for translating an input Thing Model or Thing Description into C structures which will be used for serializing the device's TD.
At the time of writing, the implementation is not yet part of the RIOT upstream repository and only lives in a RIOT fork. However, the authors are working on integrating it into the RIOT upstream project.
Usage: RIOT-based applications can include the WoT modules via RIOT's Make-based build system.
Example applications (usable with ESP32s) can be found here: https://github.com/namib-project/wot-nodes
Contributing Member Organizations: Invited Experts
sayWoT! is an industrial-grade implementation that allows integration of devices into Siemens software products like Asset Performance Suite, Desigo CC in a semantically-described and standardized way. sayWoT! is implemented in golang for optimal scalability and cross-architecture compatability.
Usage: Service in the cloud or on premise, Command Line Interface
Website: https://www.evosoft.com/en/digitalization-offering/saywot/
Contributing Member Organizations: Siemens AG
The SDF-WoT-Converter is a Python-based conversion tool between WoT data models (TDs and TMs) and the Semantic Definition Format (SDF), an IETF specification that strives to be a common data format for IoT device descriptions.
The implementation provides a library API for using it in Python projects as well as a command-line interface after installing it via the Python package manager pip.
Besides converting between WoT data models and SDF, the implementation also supports the conversion between TDs and TMs.
Usage: Library or Command Line
Public Repository: https://github.com/JKRhb/sdf-wot-converter-py
Python Package Index Entry: https://pypi.org/project/sdf-wot-converter/
Contributing Member Organizations: Invited Experts
SparTDD is an implementation of the W3C Web of Things Thing Description Directory. There are two main components. The API of the TDD is written in Python using Flask. The data is stored in RDF in a Apache Jena Fuseki SPARQL endpoint. A demo can be found here.
Usage:Directory
Contributing Member Organizations:Siemens
This is an implementation of the W3C Web of Things (WoT) Thing Description Directory (TDD). This directory is designed to be lightweight and portable, enabling deployment on the edge. It uses a layered architecture to allows the addition of different storage backends to server high scalability needs.
The directory advertises itself in local networks using DNS-SD. It comes with the Things and Notification APIs, as well as JSONPath search support (non-normative). The directory performs fine-grained access control with the help of locally defined rules and an OpenID Connect server.
Usage: Directory
Public Repository: https://github.com/TinyIoT/thing-directory
Website: https://github.com/TinyIoT
Contributing Member Organizations: The parent fork has been developed as part of LinkSmart by Fraunhofer-Gesellschaft
Basic Rust-based CoAP server, providing a TD resource that can be discovered using DNS-SD and multicast DNS.
Usage: The application can be started from the command line using Rust's package manager cargo.
Public Repository: https://github.com/JKRhb/wot-coap-dns-sd
Contributing Member Organizations: Invited Experts
The WoT Experimental is a collection of Thing implementations that aims to test different features of the TD specification such as WoT operations, Data Schema variations and API Key usage in Body.
Usage: Command line
Public Repository: https://github.com/egekorkan/wot-implementations
Contributing Member Organizations:Siemens AG
WoT Hive is an implementation of a W3C Web of Things directory. This implementation is compliant with the standard specification but aims at providing enriched features thanks to the usage of other W3C standards related to Semantic Web technologies.
Usage: Directory
Public Repository: https://github.com/oeg-upm/wot-hive
Website: https://github.com/oeg-upm/wot-hive
Contributing Member Organizations: Universidad Politécnica de Madrid
Zion implements the standard TDD APIs with a set of extentions to cover the use cases of VAIMEE
Zion employes the best open source technologies to provide a scalable TDD service. Zion wants to be fast, ease to use and flexible. Our goal is to build a service tailored for entrepise use and scalable to different deployments from small set of TDs in the Edge to high loads of the Cloud. Currently, Zion is written in Typescript and supports the following features:
/.well-known/coreUsage: Directory
Public Repository: https://github.com/vaimee/zion
Website: https://zion.vaimee.com/
Contributing Member Organizations: Invited Experts
The Web of Things (WoT) Architecture specification describes systems that include features to support security. Functional aspects of assertions associated with security features are validated in the same fashion as other functional features.
The aim of this section is to summarize the assertions from the Web of Things (WoT) Architecture document and summarize the results from the implementation reports received in the CR period. The tables in each section below lists all assertions derived from the Web of Things (WoT) Architecture document.
The headers for these tables are described as follows:
pass (P),
fail (F), and
not-impl (N)
status results in the individual implementer reports.
In the case of assertions with multiple mutually exclusive options (for example, enumerated values) each of these options may be tested separately and the results combined. In this case the 'pass' and 'total' values reported are the minimum value of any of the more detailed tests, while the 'fail' and 'not implemented' values report the maximum value of any of these tests. Since minimum and maximum value may be drawn from different detailed tests, the sum of the 'pass', 'fail', and 'not implemented' cases may not equal the 'total'. Instead the total represents the number of implementations for which all options were tested. For such cases the "child" assertions have underscores in their names prior to each value tested and the table row is also rendered in a different color.
The following assertions have been validated by the implementers.
| ID | Category | Req | Context | Assertion | Parent | Results | |||
|---|---|---|---|---|---|---|---|---|---|
| P | F | N | T | ||||||
| 1: arch-td-metadata | Metadata | Y | In W3C WoT, the description metadata for a Thing instance MUST be available as a WoT Thing Description (TD) [WOT-THING-DESCRIPTION]. | 9 | 0 | 1 | 10 | ||
| 2: arch-other-thing-representations | Metadata | N | There MAY be other representations of a Thing such as an HTML-based user interface, simply an image of the physical entity, or even non-Web representations in closed systems. | 6 | 0 | 3 | 9 | ||
| 3: arch-td-mandatory | Metadata | Y | To be considered a Thing, however, at least one TD representation MUST be available. | 9 | 0 | 1 | 10 | ||
| 4: arch-td-linking | Metadata | N | WoT Thing Descriptions and WoT Thing Models MAY link to other Things, WoT Thing Models, and other resources on the Web to form a Web of Things. | 7 | 0 | 3 | 10 | ||
| 5: arch-networked | Links | Y | Things MUST be hosted on networked system components with a software stack to realize interaction through a network-facing interface, the WoT Interface of a Thing. | 9 | 0 | 1 | 10 | ||
| 6: arch-affordances | Affordance | N | In addition to navigation affordances (i.e., Web links), Things MAY offer three other types of Interaction Affordances defined by this specification: Properties, Actions, and Events. | 9 | 0 | 1 | 10 | ||
| 7: arch-property-dataschema | Affordances | N | If the data format is not fully specified by the Protocol Binding used (e.g., through a media type), Properties MAY contain one data schema for the exposed state. | 7 | 0 | 1 | 8 | ||
| 8: arch-action-functions | Affordance | N | An Action MAY manipulate state that is not directly exposed (cf. Properties), manipulate multiple Properties at a time, or manipulate Properties based on internal logic (e.g., toggle). | 6 | 0 | 4 | 10 | ||
| 9: arch-action-process | Affordance | N | Invoking an Action MAY also trigger a process on the Thing that manipulates state (including physical state through actuators) over time. | 6 | 0 | 4 | 10 | ||
| 10: arch-action-dataschema | Affordance | N | If the data format is not fully specified by the Protocol Binding used (e.g., through a media type), Actions MAY contain data schemas for input parameters and output results. | 6 | 0 | 3 | 9 | ||
| 11: arch-event-trigger | Affordance | N | Events MAY be triggered through conditions that are not exposed as Properties. | 5 | 0 | 5 | 10 | ||
| 12: arch-event-dataschema | Affordance | N | If the data is not fully specified by the Protocol Binding used (e.g., through a media type), Events MAY contain data schemas for the event data and subscription control messages (e.g., a callback URI to subscribe with a Webhook). | 5 | 0 | 4 | 9 | ||
| 13: arch-rel-types | Links | Y | Extension relation types MUST be compared as strings using ASCII case-insensitive comparison, (c.f. ASCII case insensitive). (If they are serialized in a different format they are to be converted to URIs). | 2 | 0 | 6 | 8 | ||
| 14: arch-rel-type-lowercase | Links | N | Nevertheless, all-lowercase URIs SHOULD be used for extension relation types [RFC8288]. | 3 | 0 | 5 | 8 | ||
| 15: arch-form-iris | Links | Y | Form contexts and submission targets MUST both be Internationalized Resource Identifiers (IRIs) [RFC3987]. | 9 | 0 | 1 | 10 | ||
| 16: arch-form-iris2 | Links | N | Form context and submission target MAY point to the same resource or different resources, where the submission target resource implements the operation for the context. | 9 | 0 | 1 | 10 | ||
| 17: arch-op-request-method | Operations | Y | The request method MUST identify one method of the standard set of the protocol identified by the submission target URI scheme. | 9 | 0 | 1 | 10 | ||
| 18: arch-op-expected-request | Operations | N | Form fields are optional and MAY further specify the expected request message for the given operation. | 7 | 0 | 3 | 10 | ||
| 19: arch-op-form-fields-protocol | Operations | N | Form fields MAY depend on the protocol used for the submission target as specified in the URI scheme. | 7 | 0 | 3 | 10 | ||
| 20: arch-hypermedia | Links | Y | Interaction Affordances MUST include one or more Protocol Bindings. | 8 | 0 | 2 | 10 | ||
| 21: arch-hypermedia-protocol-binding | Links | Y | Protocol Bindings MUST be serialized as hypermedia controls to be self-descriptive on how to activate the Interaction Affordance. | 6 | 0 | 4 | 10 | ||
| 22: arch-hypermedia-caching | Links | N | The hypermedia controls MAY be cached outside the Thing and used for offline processing if caching metadata is available to determine the freshness. | 2 | 0 | 7 | 9 | ||
| 23: arch-media-type | Links | Y | All data (a.k.a. content) exchanged when activating Interaction Affordances MUST be identified by a media type [RFC2046] in the Protocol Binding. | 9 | 0 | 1 | 10 | ||
| 24: arch-media-type-extra | Links | N | Protocol Bindings MAY have additional information that specifies representation formats in more detail than the media type alone. | 3 | 0 | 7 | 10 | ||
| 25: arch-schema | Metadata | N | Thus, the Interaction Affordance for structured data types SHOULD be associated with a data schema to provide more detailed syntactic metadata for the data exchanged. | 8 | 0 | 1 | 9 | ||
| 26: arch-intermediary-td-extra-protocols | Links | N | If necessary, a TD generated by an Intermediary MAY contain interfaces for other communication protocols. | 3 | 0 | 4 | 7 | ||
| 27: arch-security-consideration-separate-security-data | Security | N | There SHOULD be a strict separation of Public Security Metadata and Private Security Data. | 5 | 0 | 4 | 9 | ||
| 28: arch-security-consideration-auth-private-data | Security | N | Authentication and authorization SHOULD be established based on separately managed Private Security Data. | 5 | 0 | 4 | 9 | ||
| 29: arch-security-consideration-no-private-security-data | Security | Y | Producers of TDs MUST ensure that no Private Security Data is included in TDs. | 4 | 0 | 5 | 9 | ||
| 30: arch-security-consideration-communication-binding | Security | N | Whenever possible, TD creators SHOULD use the vetted communication metadata provided in the WoT Binding Templates. | 3 | 0 | 4 | 7 | ||
| 31: arch-security-consideration-communication-platform | Security | N | When generating TDs for an IoT Platform not covered by the WoT Binding Templates, TD creators SHOULD ensure that all the security requirements of the IoT Platform are satisfied. | 2 | 0 | 6 | 8 | ||
| 32: arch-security-consideration-isolation-sensitive | Security | N | The WoT Runtime SHOULD perform isolation of script instances and their data from each other in cases when scripts handle sensitive data. | 3 | 0 | 6 | 9 | ||
| 33: arch-security-consideration-isolation-tenants | Security | N | Similarly, the WoT Runtime implementation SHOULD perform isolation of WoT Runtime instances and their data from each other if a WoT device has more than one tenant. | 3 | 0 | 6 | 9 | ||
| 34: arch-security-consideration-avoid-direct | Security | N | The WoT Runtime SHOULD NOT directly expose low-level device hardware interfaces to the script developers. | 4 | 0 | 6 | 10 | ||
| 35: arch-security-consideration-use-hal | Security | N | A WoT Runtime implementation SHOULD provide a hardware abstraction layer for accessing the low-level device hardware interfaces. | 2 | 0 | 7 | 9 | ||
| 36: arch-security-consideration-secure-update | Security | N | Post-manufacturing provisioning or update of scripts, the WoT Runtime itself or any related data SHOULD be done in a secure fashion. | 2 | 0 | 6 | 8 | ||
| 37: arch-security-consideration-secure-cred-storage | Security | N | The WoT Runtime SHOULD securely store any provisioned security credentials, guaranteeing their integrity and confidentiality. | 4 | 0 | 5 | 9 | ||
| 38: arch-security-consideration-secure-cred-isolation | Security | N | In case there are more than one tenant on a single WoT-enabled device, a WoT Runtime implementation SHOULD isolate each tenant's provisioned security credentials from other tenants. | 3 | 0 | 7 | 10 | ||
| 39: arch-security-consideration-no-expose-cred | Security | N | In order to minimize a risk that provisioned security credentials get compromised, the WoT Runtime implementation SHOULD NOT expose any API for scripts to query provisioned security credentials. | 2 | 0 | 7 | 9 | ||
| 40: arch-security-consideration-limit-cred-access | Security | N | Such credentials (or even better, abstract operations that use them but do not expose them) SHOULD only be accessible to the underlying protocol implementation that uses them. | 4 | 0 | 5 | 9 | ||
| 41: arch-security-consideration-limit-trust | Security | N | Trust relationships SHOULD be as restricted as possible, ideally pairwise and limited to precisely the access required. | 6 | 0 | 4 | 10 | ||
| 42: arch-security-consideration-segmented-network | Security | N | In the case of implicit access control via access to a common network a segmented network SHOULD be used. | 3 | 0 | 4 | 7 | ||
| 43: arch-security-consideration-tls-mandatory-pub | Security | Y | When a Thing is made available on the public internet so it can be accessed by anyone, from anywhere, then it MUST be protected by secure transport such as TLS or DTLS. | 4 | 0 | 4 | 8 | ||
| 44: arch-security-consideration-tls-recommended-priv | Security | N | When a Thing is made available on a private network then it SHOULD be protected by secure transport such as TLS or DTLS. | 2 | 0 | 6 | 8 | ||
| 45: arch-security-consideration-tls-optional-on-lan | Security | N | Private networks such as a LAN, protected by a firewall, MAY use the Trusted Environment approach of depending on network security only. | 7 | 0 | 1 | 8 | ||
| 46: arch-security-consideration-tls-1-3 | Security | N | When secure transport over TCP is appropriate, then at least TLS 1.3 [RFC8446] SHOULD be used. | 5 | 0 | 5 | 10 | ||
| 47: arch-security-consideration-tls-1-2 | Security | N | If TLS 1.3 cannot be used for compatibility reasons but secure transport over TCP is appropriate, TLS 1.2 [RFC5246] MAY be used. | 7 | 0 | 3 | 10 | ||
| 48: arch-security-consideration-dtls-1-2 | Security | N | If DTLS 1.3 cannot be used for compatibility reasons but secure transport over UDP is appropriate, then DTLS 1.2 [RFC6347] MAY be used. | 2 | 0 | 8 | 10 | ||
| 49: arch-security-consideration-no-earlier-tls-or-dtls | Security | Y | Versions of DTLS or TLS earlier than 1.2 MUST NOT be used for new development. | 5 | 0 | 5 | 10 | ||
| 50: arch-privacy-consideration-min-explicit-pii | Privacy | N | Storage of explicit PII in TDs SHOULD be minimized as much as possible. | 3 | 0 | 7 | 10 | ||
| 51: arch-privacy-consideration-explicit-pii | Privacy | N | TDs that can be associated with a person SHOULD generally be treated as if they contained PII and subject to the same management policies as other PII, even if they do not explicitly contain it. | 2 | 0 | 7 | 9 | ||
| 52: arch-privacy-consideration-dist-td-auth | Privacy | N | Distribution mechanisms for TDs SHOULD ensure they are only provided to authorized Consumers. | 4 | 0 | 5 | 9 | ||
| 53: arch-privacy-consideration-access-control-mandatory-person | Privacy | N | Things returning data or metadata (such as TDs) associated with a person SHOULD use some form of access control. | 3 | 0 | 7 | 10 | ||
| 54: arch-privacy-consideration-id-access-control-mandatory-immutable | Privacy | N | Services returning Thing Descriptions with immutable IDs SHOULD use some form of access control. | 2 | 0 | 7 | 9 | ||
The Web of Things Working Group would like to acknowledge the contributions to the making of this document from the following individuals in various capacities, including contributions to past testing inputs which were used for compatibility testing: