Version: 29 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) Discovery document was published as a Candidate Recommendation Snapshot on 19 January 2023 and a Proposed Recommendation on 11 July 2023.
This document summarizes the results from the Web of Things (WoT) Discovery implementer reports received and describes the process that the Web of Things (WoT) Working Group followed in preparing this Implementation Report (IR).
Although results were generated with a combination of automated and manual tests, the automated tests were only meant to provide assistance to implementers in preparing their individual implementation test reports.
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) Discovery 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/Discovery.
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-discovery.
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, needed 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 Discovery specification from all organizations that submitted implementer reports. Each implementation represents a working system that either provides a WoT Discovery service or acts as a client for such a service.
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. We did permit the same implementer to report on multiple different implementations as long as the code bases were distinct.
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
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.
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 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
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
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
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
The Web of Things (WoT) Discovery specification includes 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) Discovery specification 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) Discovery specification. The results are broken into two parts: those for which automated testing has been implemented, and those for which it has not and manual testing and reporting was necessary.
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. Note that child assertions do not appear in the exact form shown in this report in the specification itself, so please refer to the parent assertion for context.
The following assertions have been validated by automated testing.
| ID | Category | Req | Context | Assertion | Parent | Results | |||
|---|---|---|---|---|---|---|---|---|---|
| P | F | N | T | ||||||
| 23: introduction-dns-sd-txt-record-udp | Y | For UDP-based services, the following information MUST be included in the TXT record that is pointed to by the Service Instance Name: td Absolute pathname of the Thing Description of the Thing or Thing Description of the Thing Description Directory. type Type of the Thing Description, i.e. Thing or Directory. If omitted, the type is assumed to be Thing. scheme Scheme part of URL. One of the following values can be specified, with the standard registered URI interpretations [RFC7595]: coap (CoAP over UDP) or coaps (CoAP over DTLS/UDP). If omitted, the scheme is assumed to be coap. | 2 | 0 | 0 | 2 | |||
| 29: introduction-did-service-context | Y | In order to define Service Endpoints for WoT Discovery, the DID Document obtained by resolving the DID of a Thing or Thing Description Directory MUST include the URL https://www.w3.org/2022/wot/discovery-did in its @context [did-spec-registries]. | 2 | 0 | 0 | 2 | |||
| 47: tdd-absolute-time | Y | Whenever an absolute time is expressed using dateTime it MUST be interpreted as date-time as specified in [RFC3339]. | 2 | 0 | 0 | 2 | |||
| 48: tdd-registrationinfo-vocab-created | TD Directory - Info | N | created: Provides the absolute time when the TD instance was created inside the directory. This MAY be set by the directory and returned to consumers. MAY be included. Type: optional. | 5 | 1 | 1 | 7 | ||
| 49: tdd-registrationinfo-vocab-modified | TD Directory - Info | N | modified: Provides the absolute time when the TD instance was last modified inside the directory. This MAY be set by the directory and returned to consumers. MAY be included. Type: optional. | 5 | 1 | 1 | 7 | ||
| 54: tdd-anonymous-td-identifier | TD Directory | Y | In situations where the server exposes an Anonymous TD (e.g. retrieval, listing, search), it MUST add the local identifier as id of the TD to allow local referencing. | 4 | 3 | 1 | 8 | ||
| 55: tdd-anonymous-td-local-uuid | TD Directory | N | The local identifier SHOULD be a UUID Version 4, presented as a URN [RFC4122]. | 5 | 2 | 1 | 8 | ||
| 56: tdd-http-error-response | TD Directory | Y | The HTTP API MUST use the Problem Details [RFC7807] format to carry error details in HTTP client error (4xx) and server error (5xx) responses. | 5 | 3 | 1 | 9 | ||
| 59: tdd-http-head | TD Directory | Y | For each HTTP endpoint that responds to the GET method, the server MUST accept HEAD requests and return only the headers. | 3 | 4 | 1 | 8 | ||
| 61: tdd-things-list-only | TD Directory - List | Y | The API MUST provide the interface to list TDs. | 6 | 1 | 1 | 8 | ||
| 62: tdd-things-crud | TD Directory | N | The API MAY provide the interfaces to create, read, update, and delete (CRUD) individual TDs. | 6 | 0 | 1 | 7 | ||
| 63: tdd-things-crudl | TD Directory | N | Full HTTP directories SHOULD implement all of CRUDL (create, read, update, delete, and list) interfaces. | 6 | 1 | 1 | 8 | ||
| 65: tdd-things-default-representation | TD Directory | Y | The default serialization format for all request and success response bodies MUST be JSON, with JSON-LD 1.1 [JSON-LD11] syntax to support extensions and semantic processing. | 5 | 2 | 1 | 8 | ||
| 68: tdd-things-create-known-vs-anonymous | TD Directory - Create | Y | A TD which is identified with an id attribute MUST be handled differently with one that has no identifier (Anonymous TD). | 6 | 2 | 1 | 9 | ||
| 69: tdd-things-create-known-td | TD Directory - Create | Y | A TD that has an id MUST be submitted to the directory in the body of an HTTP PUT request at /things/{id} endpoint, where id is the unique TD identifier, present inside the TD object. | 6 | 2 | 1 | 9 | ||
| 71: tdd-things-create-known-td-resp | TD Directory - Create | Y | Upon successful processing, the server MUST respond with 201 (Created) status. | 7 | 1 | 1 | 9 | ||
| 72: tdd-things-create-anonymous-td | TD Directory - Create | Y | An Anonymous TD MUST be submitted to the directory in the body of an HTTP POST request at /things endpoint. | 5 | 3 | 1 | 9 | ||
| 73: tdd-things-create-anonymous-contenttype | TD Directory - Create | N | The request SHOULD contain application/td+json Content-Type header for JSON serialization of TD. | 5 | 1 | 1 | 7 | ||
| 75: tdd-things-create-anonymous-td-resp | TD Directory - Create | Y | Upon successful processing, the server MUST respond with 201 (Created) status and a Location header containing the system-generated URI of created TD resource. | 5 | 2 | 1 | 8 | ||
| 76: tdd-things-retrieve | TD Directory - Retrieve | Y | The retrieval of an existing TD MUST be done using an HTTP GET request at /things/{id} endpoint, where id is the unique TD identifier. | 7 | 0 | 1 | 8 | ||
| 77: tdd-things-retrieve-resp | TD Directory - Retrieve | Y | A successful response MUST have 200 (OK) status and the requested TD in the body. | 7 | 0 | 1 | 8 | ||
| 79: tdd-things-update | TD Directory - Update | Y | A modified TD MUST replace an existing one when submitted using an HTTP PUT request at /things/{id} endpoint, where id is the identifier of the existing TD. | 5 | 2 | 1 | 8 | ||
| 81: tdd-things-update-resp | TD Directory - Update | Y | Upon success, the server MUST respond with 204 (No Content) status. | 5 | 2 | 1 | 8 | ||
| 82: tdd-things-update-partial | TD Directory - Update | Y | An existing TD MUST be partially modified when the modified parts are submitted using an HTTP PATCH request at /things/{id} endpoint, where id is the identifier of the existing TD. | 7 | 0 | 1 | 8 | ||
| 83: tdd-things-update-partial-mergepatch | TD Directory - Update | Y | The partial update MUST be processed using the JSON merge patch format described in [RFC7396]. | 6 | 1 | 1 | 8 | ||
| 84: tdd-things-update-partial-contenttype | TD Directory - Update | Y | The request MUST contain application/merge-patch+json Content-Type header for JSON serialization of the merge patch document. | 6 | 1 | 1 | 8 | ||
| 85: tdd-things-update-partial-partialtd | TD Directory - Update | Y | The input MUST be in Partial TD form and conform to the original TD structure. | 7 | 0 | 1 | 8 | ||
| 86: tdd-things-update-partial-resp | TD Directory - Update | Y | Upon success, the server MUST respond with a 204 (No Content) status. | 6 | 1 | 1 | 8 | ||
| 87: tdd-things-delete | TD Directory - Delete | Y | A delete operation MUST be done using an HTTP DELETE request at /things/{id}, where id is the identifier of the existing TD. | 7 | 0 | 1 | 8 | ||
| 88: tdd-things-delete-resp | TD Directory - Delete | Y | A successful response MUST have 204 (No Content) status. | 7 | 0 | 1 | 8 | ||
| 89: tdd-things-list-method | TD Directory - List | Y | The directory MUST allow retrieval of existing TDs using HTTP GET requests at the /things endpoint. | 7 | 1 | 1 | 9 | ||
| 90: tdd-things-list-resp | TD Directory - List | Y | A successful response MUST have 200 (OK) status and an array of TDs in the body. | 7 | 1 | 1 | 9 | ||
| 100: tdd-validation-syntactic | TD Directory - Validation | N | The syntactic validation of TD objects before storage is RECOMMENDED to prevent common erroneous submissions. | 7 | 1 | 1 | 9 | ||
| 102: tdd-validation-result | TD Directory - Validation | Y | If the server fails to validate the TD object, it MUST inform the client with necessary details to identify and resolve the errors. | 6 | 2 | 1 | 9 | ||
| 103: tdd-validation-response | TD Directory - Validation | Y | The validation error MUST be described as Problem Details [RFC7807] with an extension field called validationErrors, set to an array of objects with field and description fields. | 5 | 3 | 1 | 9 | ||
| 105: tdd-notification | TD Directory - Notification | N | Directories MAY implement the Notification API. | 2 | 1 | 2 | 5 | ||
| 106: tdd-notification-sse | TD Directory - Notification | Y | The Notification API MUST follow the Server-Sent Events (SSE) [HTML] specifications to serve events to clients at /events endpoint. | 2 | 1 | 2 | 5 | ||
| 107: tdd-notification-event-id | TD Directory - Notification | N | The server SHOULD provide an event ID as the id field in each event and respond to re-connecting clients by delivering all missed events. | 2 | 1 | 2 | 5 | ||
| 108: tdd-notification-event-types | TD Directory - Notification | Y | The server MUST produce events attributed to the lifecycle of the Thing Descriptions within the directory using thing_created, thing_updated, and thing_deleted event types. | 2 | 1 | 2 | 5 | ||
| 109: tdd-notification-filter-type | TD Directory - Notification | Y | The server MUST support event filtering based on the event type given by the client upon subscription. | 2 | 1 | 2 | 5 | ||
| 110: tdd-notification-data | TD Directory - Notification | Y | The event data MUST contain the JSON serialization of the event object. | 2 | 1 | 2 | 5 | ||
| 111: tdd-notification-data-td-id | TD Directory - Notification | Y | The event data object MUST at least include the identifier of the TD created, updated, or deleted at that event in Partial TD form. | 2 | 1 | 2 | 5 | ||
| 112: tdd-notification-data-create-full | TD Directory - Notification | N | When diff query parameter is set to true and the event has thing_created type, the server MAY return the whole TD object as event data. | 2 | 1 | 2 | 5 | ||
| 113: tdd-notification-data-update-diff | TD Directory - Notification | N | When diff query parameter is set to true and the event has thing_updated type, the server MAY inform the client about the updated parts following the JSON Merge Patch [RFC7396] format. | 2 | 1 | 2 | 5 | ||
| 114: tdd-notification-data-update-id | TD Directory - Notification | Y | A thing_updated event data that is based on JSON Merge Patch [RFC7396] MUST always include the identifier of the TD regardless of whether it is changed. | 2 | 1 | 2 | 5 | ||
| 115: tdd-notification-data-delete-diff | TD Directory - Notification | Y | The diff query parameter MUST be ignored for thing_deleted events. | 3 | 0 | 2 | 5 | ||
| 116: tdd-search-sparql | TD Directory - Search - SPARQL | N | The Directory MAY implement semantic search with SPARQL. | 2 | 3 | 1 | 6 | ||
| 119: tdd-search-sparql-method-get | TD Directory - Search - SPARQL | Y | The SPARQL API MUST accept queries using HTTP GET requests at /search/sparql?query={query} endpoint, where query is the SPARQL expression. | 2 | 3 | 1 | 6 | ||
| 120: tdd-search-sparql-method-post | TD Directory - Search - SPARQL | N | The support for SPARQL search using HTTP POST method at /search/sparql endpoint is OPTIONAL. | 2 | 3 | 1 | 6 | ||
| 121: tdd-search-sparql-resp-select-ask | TD Directory - Search - SPARQL | Y | A successful request with a query SELECT or ASK MUST return a response 200 (OK) status, and contain application/json by default in the Content-Type header. | 2 | 3 | 1 | 6 | ||
| 124: tdd-search-sparql-federation | TD Directory - Search - SPARQL | N | A WoT Thing Description Directory MAY implement federation in its SPARQL query API. | 2 | 3 | 1 | 6 | ||
The following assertions have been manually validated by the implementers.
| ID | Category | Req | Context | Assertion | Parent | Results | |||
|---|---|---|---|---|---|---|---|---|---|
| P | F | N | T | ||||||
| 1: discoverer-must-support-intros | Discoverer | Y | A Discoverer MUST support at least one Introduction mechanism. | 3 | 0 | 2 | 5 | ||
| 2: discoverer-must-support-fetching | Discoverer | Y | A Discoverer MUST support fetching a TD from at least one URL provided as part of the Introduction process. | 3 | 0 | 2 | 5 | ||
| 3: discoverer-may-multiple-intro | Discoverer | N | A Discoverer MAY support multiple invocations of the same Introduction mechanism. | 2 | 0 | 2 | 4 | ||
| 4: discoverer-merge-intros | Discoverer | Y | A Discoverer MUST be able to merge URLs resulting from multiple Introduction mechanisms, multiple results from a single Introduction mechanism, and multiple Introduction invocations into a single set. | 2 | 1 | 2 | 5 | ||
| 5: discoverer-td-identify | Discoverer | Y | A Discoverer MUST be able to identify whether a TD fetched from an Introduction URL has Thing Directory or Thing Link type. | 2 | 1 | 2 | 5 | ||
| 6: discoverer-fetch-tdd | Discoverer | N | A Discoverer MAY fetch additional TDs from any Exploration mechanism described in its initial set of TDs (including, in particular, Thing Description Directories) and add them into the set of TD results. | 2 | 0 | 3 | 5 | ||
| 7: discoverer-fetch-links | Discoverer | N | A Discoverer MAY fetch source TDs from the targets of the links in a Thing Link described in its initial set of TDs and add them into the set of TD results. | 2 | 0 | 3 | 5 | ||
| 8: discoverer-fetch-iteration | Discoverer | N | A Discoverer MAY fetch additional TDs iteratively from any Thing Link or Exploration mechanism described in its set of TDs and add them into the set of TD results. | 2 | 0 | 3 | 5 | ||
| 9: discoverer-termination | Discoverer | N | A Discoverer MAY terminate fetching additional TDs at any point or for any reason. | 2 | 0 | 2 | 4 | ||
| 10: discoverer-any-order | Discoverer | N | A Discoverer MAY fetch additional TDs by following links or fetching additional TDs from Exploration mechanisms (e.g. TDDs) in any order. | 3 | 0 | 2 | 5 | ||
| 11: discoverer-track | Discoverer | Y | A Discoverer MUST track which TDs describing links or Exploration mechanisms have already been fetched and avoid fetching duplicate results. | 2 | 2 | 2 | 6 | ||
| 12: introduction-direct-url | Introduction - Direct | N | To obtain an URL of an exploration service, any mechanism that results in a single URL MAY be used. | 6 | 0 | 2 | 8 | ||
| 13: introduction-direct-thing-description | Introduction - Direct | Y | A request on all such URLs MUST result in a TD as prescribed in 7. Exploration Mechanisms. | 6 | 0 | 2 | 8 | ||
| 14: introduction-direct-directory-description | Introduction - Direct | Y | If the URL references a Thing Description Directory, this MUST be the Thing Description of the Thing Description Directory. | 3 | 0 | 2 | 5 | ||
| 15: introduction-well-known-uri | Introduction - Well-Known URI | N | A Thing or Thing Description Directory MAY use the Well-Known Uniform Resource Identifier [RFC8615] to advertise its presence. | 8 | 0 | 1 | 9 | ||
| 16: introduction-well-known-path | Introduction - Well-Known URI | Y | If a Thing or Thing Description Directory use the Well-Known Uniform Resource Identifier [RFC8615] to advertise its presence, it MUST register its own Thing Description into the following path: /.well-known/wot. | 8 | 0 | 1 | 9 | ||
| 17: introduction-well-known-thing-description | Introduction - Well-Known URI | Y | When a request is made at the above Well-Known URI, the server MUST return a Thing Description as prescribed in 7. Exploration Mechanisms. | 8 | 0 | 1 | 9 | ||
| 18: introduction-dns-sd | Introduction - DNS-SD | N | A Thing or Thing Description Directory MAY use DNS-Based Service Discovery (DNS-SD)[RFC6763]. | 6 | 0 | 2 | 8 | ||
| 19: introduction-dns-sd-service-name | Introduction - DNS-SD | N | _wot._tcp: Thing MAY be included. Type: undefined. | 2 | 0 | 4 | 6 | ||
| 20: introduction-dns-sd-service-name-directory | Introduction - DNS-SD | N | _directory._sub._wot._tcp: TDD MAY be included. Type: undefined. | 4 | 0 | 4 | 8 | ||
| 21: introduction-dns-sd-service-name-udp | N | _wot._udp: Thing MAY be included. Type: undefined. | 2 | 0 | 1 | 3 | |||
| 22: introduction-dns-sd-txt-record | Introduction - DND-SD | Y | For TCP-based services, the following information MUST be included in the TXT record that is pointed to by the Service Instance Name: td Absolute pathname of the Thing Description of the Thing or Thing Description of the Thing Description Directory. type Type of the Thing Description, i.e. Thing or Directory. If omitted, the type is assumed to be Thing. scheme Scheme part of URL. One of the following values can be specified, with the standard registered URI interpretations [RFC7595]: http (HTTP over TCP), https (HTTP over TLS/TCP), coap+tcp (CoAP over TCP), or coaps+tcp (CoAP over TLS/TCP). If omitted, the scheme is assumed to be http. | 3 | 0 | 4 | 7 | ||
| 24: introduction-core-rd | Introduction - CoRE RD | N | A Thing or Thing Description Directory MAY advertise its presence using the Constrained RESTful Environment (CoRE) Link Format [RFC6690]. | 2 | 0 | 5 | 7 | ||
| 25: introduction-core-rd-directory | Introduction - CoRE RD, "introduction-core-rd-resource-type-directory | N | A Thing or Thing Description Directory MAY use the CoRE Resource Directory [RFC9176] to register a link to its corresponding Thing Description. | 4 | 0 | 4 | 8 | ||
| 26: introduction-core-rd-resource-type-thing | Introduction - CoRE RD | Y | The resource type (rt) of the Link that targets the Thing Description of the Thing MUST be wot.thing. | 2 | 0 | 5 | 7 | ||
| 27: introduction-core-rd-resource-type-directory | Y | The resource type of the Link that targets the Thing Description of the Thing Description Directory MUST be wot.directory. | 2 | 0 | 4 | 6 | |||
| 28: introduction-did | Introduction - DID | N | A Thing or Thing Description Directory using a Decentralized Identifier (DID) [DID-CORE] MAY advertise the location of its TD by including a DID Service Endpoint of type WotThing or WotDirectory, respectively, in the DID Document that the TD's identifier resolves to. | 2 | 0 | 3 | 5 | ||
| 30: introduction-did-service-endpoint | Introduction - DID | Y | If the DID Document obtained by resolving the DID of a Thing or Thing Description Directory contains a Service Endpoint of type WotThing or WotDirectory, respectively, then this Service Endpoint MUST refer to the TD describing that Thing (when using the WotThing service name) or the TD describing that Thing Description Directory (when using the WotDirectory service name), respectively [did-spec-registries]. | 2 | 0 | 3 | 5 | ||
| 31: exploration-directory-description-type | TD Directory | Y | A TD which describes a Thing Description Directory instance MUST use type ThingDirectory from the discovery context or URI https://www.w3.org/2022/wot/discovery#ThingDirectory. | 4 | 0 | 1 | 5 | ||
| 32: exploration-link-description-type | Link | Y | A TD which describes a reference to another TD MUST use type ThingLink from the discovery context or URI https://www.w3.org/2022/wot/discovery#ThingLink. | 2 | 0 | 2 | 4 | ||
| 33: exploration-link-description-link | Link | Y | A Thing Link MUST define the referenced TD as a Link with describedby link relation type, application/td+json media type and href set to the target URL. | 2 | 0 | 2 | 4 | ||
| 34: security-bootstrapping-endpoints | Security Bootstrapping | N | Security bootstrapping MAY be provided on any HTTP endpoint that serves a TD. | 3 | 0 | 2 | 5 | ||
| 35: exploration-secboot-401 | Security Bootstrapping | Y | If security bootstrapping is enabled on an exploration service, after initial contact using the URL provided by an introduction mechanism, the exploration service MUST reply with an HTTP response code appropriate for one of the Basic, Bearer, Digest, or OAuth2 security schemes if authentication information has not been provided but access can be granted when it is. | 4 | 0 | 2 | 6 | ||
| 36: exploration-server-http-method | TD Server - HTTP | Y | An HTTP-based TD Server providing a TD MUST serve that resource with a GET method. | 6 | 0 | 0 | 6 | ||
| 37: exploration-server-http-resp | Y | A successful response from an HTTP-based TD Server providing a TD MUST have 200 (OK) status and the TD in the body. | 6 | 0 | 0 | 6 | |||
| 38: exploration-server-http-resp-content-type | Y | A successful response with JSON serialization MUST contain either application/json or application/td+json in the Content-Type header. | 6 | 0 | 0 | 6 | |||
| 39: exploration-server-http-resp-json | Y | The default serialization format for successful response bodies MUST be JSON, with JSON-LD 1.1 [JSON-LD11] syntax. | 5 | 1 | 0 | 6 | |||
| 40: exploration-server-http-alternate-content | N | An HTTP-based TD Server providing a TD MAY provide alternative representations through server-driven content negotiation, that is by honoring the request's Accept and Accept-Encoding headers and responding with the supported TD serialization and equivalent Content-Type and Content-Encoding headers. | 4 | 0 | 1 | 5 | |||
| 41: exploration-server-http-head | TD Server - HTTP | Y | An HTTP-based TD Server providing a TD MUST respond to HEAD requests by returning only the headers equivalent to those returned by a GET request to the same endpoint. | 4 | 1 | 0 | 5 | ||
| 42: exploration-server-coap-method | Y | A CoAP-based TD Server providing a TD MUST serve that resource with a GET method. | 3 | 0 | 2 | 5 | |||
| 43: exploration-server-coap-resp | Y | A successful response from a CoAP-based TD Server providing a TD MUST have a 2.05 (Content) status, contain a Content-Format option with value 50 (application/json) or 432 (application/td+json), and the TD in the payload. | 3 | 0 | 2 | 5 | |||
| 44: exploration-server-coap-alternate-content | N | A CoAP-based TD Server providing a TD MAY provide alternative representations through server-driven content negotiation, that is by honouring the request's Accept option and responding with the supported TD serialization and equivalent Content-Format option. | 2 | 0 | 3 | 5 | |||
| 45: exploration-server-coap-size2 | N | A CoAP-based TD Server providing a TD SHOULD respond to requests containing a Size2 option by including the size estimate of the TD in its next response. | 2 | 0 | 3 | 5 | |||
| 46: tdd-context-injection | TD Directory | Y | An Enriched TD MUST contain in its @context the URI https://www.w3.org/2022/wot/discovery. | 4 | 0 | 0 | 4 | ||
| 50: tdd-registrationinfo-vocab-expires | TD Directory - Info | Y | expires: Provides the absolute time when the TD instance registration expires. The producer MAY set this to indicate the absolute expiry time during the registration. For servers that support expirable TDs: If ttl (relative expiry) is present, the server MUST ignore client assignments to expires and instead compute and set it internally. MAY be included. Type: optional. | 2 | 0 | 2 | 4 | ||
| 51: tdd-registrationinfo-vocab-ttl | TD Directory - Info | Y | ttl: Time-to-live: relative amount of time in seconds from the registration time until when the TD instance registration expires. The producer MAY set this to indicate the relative expiry time during the registration. For servers that support expirable TDs: The server MUST use ttl to calculate the expires (absolute expiry) value. MAY be included. Type: read-only. | 2 | 0 | 2 | 4 | ||
| 52: tdd-registrationinfo-vocab-retrieved | TD Directory - Info | N | retrieved: The absolute time at which the TD was retrieved from the server. This is useful for clients that intend to process other absolute timestamps but do not have an internal clock or other means of acquiring the current time. MAY be included. Type: optional. | 2 | 0 | 2 | 4 | ||
| 53: tdd-registrationinfo-expiry-purge | TD Directory - Info | N | Servers SHOULD periodically purge TDs that are past their expiry times. | 2 | 2 | 2 | 6 | ||
| 57: tdd-http-error-response-utf-8 | TD Directory | Y | All HTTP API error responses described using Problem Details MUST be encoded using UTF-8. | 6 | 0 | 0 | 6 | ||
| 58: tdd-http-error-response-lang | TD Directory | N | HTTP API error responses MAY report details in different languages using proactive negotiation, if the Accept-Language header field has been set in the HTTP request [RFC7231]. | 2 | 0 | 1 | 3 | ||
| 60: tdd-http-unsupported-feature | N | When a directory is unable to answer a request because of unsupported recommended or optional features, it SHOULD inform the client about the absence of those features by returning appropriate HTTP errors. | 6 | 0 | 0 | 6 | |||
| 64: tdd-things-read-only-auth | TD Directory | Y | To expose read-only access, the directory MUST enforce access control on create, update, and delete interfaces. | 2 | 0 | 3 | 5 | ||
| 66: tdd-things-representation-alternate-input | TD Directory | N | Directories MAY accept alternative representations based on request's indicated Content-Type or Content-Encoding headers. | 2 | 0 | 1 | 3 | ||
| 67: tdd-http-representation-alternate-output | TD Directory | N | Directories MAY provide alternative representations through server-driven content negotiation, that is by honouring the request's Accept and Accept-Encoding headers and responding with the supported TD representation and equivalent Content-Type and Content-Encoding headers. | 3 | 0 | 1 | 4 | ||
| 70: tdd-things-create-known-contenttype | TD Directory - Create | N | The request SHOULD contain application/td+json Content-Type header for JSON serialization of TD. | 5 | 1 | 1 | 7 | ||
| 74: tdd-things-create-anonymous-id | Y | The directory MUST assign a local identifier to any Anonymous TD to enable local management and retrieval from the directory. | 4 | 1 | 0 | 5 | |||
| 78: tdd-things-retrieve-resp-content-type | Y | A successful response with JSON serialization MUST contain either application/json or application/td+json in the Content-Type header. | 6 | 0 | 0 | 6 | |||
| 80: tdd-things-update-contenttype | TD Directory - Update | N | The request SHOULD contain application/td+json Content-Type header for JSON serialization of TD. | 4 | 2 | 1 | 7 | ||
| 91: tdd-things-list-resp-content-type | Y | A successful response with JSON serialization MUST contain either application/json or application/ld+json in the Content-Type header. | 6 | 0 | 0 | 6 | |||
| 92: tdd-things-list-pagination | TD Directory - List | N | The server MAY support pagination to return the collection in small subsets. | 3 | 0 | 1 | 4 | ||
| 93: tdd-things-list-pagination-limit | TD Directory - List | N | When the limit query parameter is set to a positive integer, the server MAY respond with a subset of TDs totalling to less than or equal to the requested number. | 4 | 0 | 1 | 5 | ||
| 94: tdd-things-list-pagination-header-nextlink | TD Directory - List | Y | When there are more TDs after a returned subset of the collection, the response MUST contain a next Link header [RFC8288] with the URL of the next subset. | 3 | 0 | 1 | 4 | ||
| 95: tdd-things-list-pagination-header-nextlink-attr | TD Directory - List | Y | The next link MUST include all arguments needed to produce the same set of data and its ordering, in particular the same limit argument given on the initial request as well as a zero-based offset argument anchored at the beginning of the next subset. | 3 | 0 | 1 | 4 | ||
| 96: tdd-things-list-pagination-header-nextlink-base | TD Directory - List | Y | The link MUST be absolute or relative to directory API's base URL. | 3 | 0 | 1 | 4 | ||
| 97: tdd-things-list-pagination-header-canonicallink | TD Directory - List | Y | All paged responses MUST contain a canonical Link header [RFC8288] pointing to the collection and include an etag parameter to represent the current state of the collection. | 3 | 0 | 1 | 4 | ||
| 98: tdd-things-list-pagination-order-default | TD Directory - List | Y | The collection MUST be sorted in ascending order using Unicode code point order by the unique identifier of TDs. | 3 | 0 | 2 | 5 | ||
| 99: tdd-things-list-pagination-collection | TD Directory - List | N | As an alternative to an array of TDs as the body of the response, the server MAY send a more verbose payload allowing server-side information, such as pagination information, to be included in addition to the actual data. | 2 | 0 | 2 | 4 | ||
| 101: tdd-validation-jsonschema | TD Directory - Validation | N | The server SHOULD use at least Minimal Validation as defined in [wot-thing-description11] to validate TDs, including use of the WoT Thing Description (1.0) JSON Schema or WoT Thing Description 1.1 JSON Schema, and the JSON schema defined in A. JSON Schema for WoT Discovery TD-extensions for Enriched TDs, as appropriate based on the value of the @context. | 4 | 2 | 1 | 7 | ||
| 104: tdd-validation-response-utf-8 | TD Directory - Validation | Y | All validation error responses described using Problem Details MUST be encoded using UTF-8. | 5 | 0 | 0 | 5 | ||
| 117: tdd-search-large-tdds | TD Directory - Search | N | It is RECOMMENDED that directories implement a search API to efficiently serve TDs based on client-specific queries. | 4 | 2 | 1 | 7 | ||
| 118: tdd-search-sparql-version | TD Directory - Search - SPARQL | Y | If implemented, the SPARQL search API MUST allow searching TDs using the SPARQL 1.1 protocol [sparql11-overview]. | 2 | 0 | 1 | 3 | ||
| 122: tdd-search-sparql-resp-describe-construct | TD Directory - Search - SPARQL | Y | A successful request with a query CONSTRUCT and DESCRIBE MUST return a response 200 (OK) status, and contain application/ld+json by default in the Content-Type header. | 2 | 0 | 1 | 3 | ||
| 123: tdd-search-sparql-error | TD Directory - Search - SPARQL | Y | A request with any query different from SELECT, ASK, CONSTRUCT or DESCRIBE MUST return a response 400 (Bad Request). | 2 | 0 | 1 | 3 | ||
| 125: tdd-search-sparql-federation-version | TD Directory - Search - SPARQL | Y | If implemented, the SPARQL API MUST implement the SPARQL 1.1 Federated Query standard [sparql11-overview]. | 2 | 0 | 1 | 3 | ||
| 126: sec-tdd-intro-no-observe | Security | N | Open implementations of Introduction mechanisms SHOULD NOT support observe or similar extended result subprotocols. | 2 | 0 | 2 | 4 | ||
| 127: sec-tdd-intro-no-ext | Security | N | Introduction mechanisms on a segmented network behind a firewall (e.g. a LAN) SHOULD NOT respond to requests that are (apparently) from outside that LAN. | 2 | 0 | 2 | 4 | ||
| 128: sec-self-psk | Security | N | PSK (pre-shared keys) SHOULD be used if possible on LANs, meaning one of the ciphersuites in [RFC4279]. | 2 | 1 | 2 | 5 | ||
| 129: sec-self-segment | Security | N | If Things cannot be individually secured with transport security and authentication and authorization, a separate network SHOULD be set up, i.e. with an alternative SSID, and used only for IoT devices. | 3 | 1 | 2 | 6 | ||
| 130: priv-loc-priv-dir-access | N | To reduce the risk of negative location inferencing, access to private directories SHOULD be limited by using access controls. | 2 | 0 | 1 | 3 | |||
| 131: priv-loc-explicit-care | Privacy | N | When explicit location information is available, whether stored in a TD or available in a property, additional care SHOULD be taken to only share the TD and/or access to the device with trusted partners, including directories. | 2 | 0 | 1 | 3 | ||
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: