Web of Things (WoT) Discovery

W3C 勧告

この文書の詳細
このバージョン:
https://www.w3.org/TR/2023/REC-wot-discovery-20231205/
最新公開バージョン:
https://www.w3.org/TR/wot-discovery/
最新エディター草案:
https://w3c.github.io/wot-discovery/
履歴:
https://www.w3.org/standards/history/wot-discovery/
コミット 履歴
実装報告:
https://w3c.github.io/wot-discovery/testing/report.html
編集者:
Andrea Cimmino (Universidad Politécnica de Madrid)
Michael McCool (Intel Corp.)
Farshid Tavakolizadeh (招聘 専門家)
Kunihiko Toumura (Hitachi, Ltd.)
旧編集者:
Farshid Tavakolizadeh (Fraunhofer-Gesellschaft) - まで
フィードバック:
GitHub w3c/wot-discovery (プル リクエスト, 新規 issue, 未解決 issue)
public-wot-wg@w3.org 宛てに、件名行を [wot-discovery] … メッセージのトピック … として送信してください (アーカイブ)
正誤表:
正誤表が あります。
コントリビューター
GitHub リポジトリ内
リポジトリ
GitHub 上に あります
バグを 報告

翻訳も参照してください。

Copyright © 2017-2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

概要

W3C Web of Things (WoT) は、IoT プラットフォームおよびアプリケーション領域を 横断した相互運用性を可能にすることを意図している。この目標を 達成するための重要な仕組みの 1 つは、IoT デバイスまたはサービスが ネットワーク越しに利用可能にするインタラクションを、適切な 抽象化レベルで記述するメタデータを定義し使用することである。 WoT Thing Description 仕様はこの目的を 満たす。

しかし、Thing を使用するには、その Thing Description をまず 取得しなければならない。この文書で記述する WoT Discovery プロセスは、この問題に対処するものである。WoT Discovery は、多様なユースケースにおける WoT Thing Description の配布をサポートする必要がある。これには、アドホックな システムと設計されたシステム、開発時と実行時、ならびに ローカルネットワークとグローバルネットワークの両方が含まれる。 このプロセスはまた、既存の発見メカニズムと連携し、安全であり、 私的な情報を保護し、WoT Thing Description の更新や IoT エコシステムの動的で多様な性質を効率的に扱える必要がある。

WoT Discovery プロセスは、Introduction と Exploration という 2 つのフェーズに分けられる。Introduction フェーズは 既存の発見メカニズムを活用するが、メタデータを直接公開しない。 それらは、セキュアな認証および認可の後にのみメタデータを提供する Exploration サービスを発見するために単に使用される。この文書は、 2 つの Exploration サービスを規範的に定義する。1 つは、通常の Web サービスから単一の WoT Thing Description を配布するものであり、 特殊な場合として自己記述を含む。もう 1 つは、Thing Description の集合のための検索可能な WoT Thing Description Directory サービスである。多様な Introduction サービスも 記述されており、それらをサポートするために必要な場合には 規範的な定義が与えられている。

この文書のステータス

このセクションは、この文書の公開時点における ステータスを説明する。現在の W3C 出版物の一覧および この技術報告の最新版は、 W3C 技術報告 索引（https://www.w3.org/TR/）で確認できる。

この仕様の将来の更新には、 新機能が組み込まれる可能性がある。

この文書は、Web of Things Working Group により、Recommendation track を用いた Recommendation として公開された。

W3C は、この仕様を Web の標準として広く展開することを推奨する。

W3C Recommendation は、広範な合意形成を経た後に W3C およびその会員によって承認され、 実装に対する ロイヤリティフリーのライセンスについて、Working Group メンバーからの確約を 有する仕様である。

この文書は、 W3C Patent Policy の下で活動するグループによって作成された。 W3C は、このグループの 成果物に関連して行われた 特許開示の公開一覧を管理している。 そのページには、特許を開示するための手順も含まれている。 個人が、自身の知るところとして、その個人が Essential Claim(s) を含むと信じる特許を実際に認識している場合、 その情報を W3C Patent Policy のセクション 6 に従って開示しなければならない。

この文書は、2023年11月03日版 W3C Process Document によって管理される。

1. 序論

Web of Things (WoT) は、Web 技術を IoT デバイスと統合し利用することをサポートするアーキテクチャを定義する。 WoT Architecture [wot-architecture11] 文書は、サポートされる基本概念および利用パターンを定義している。 しかし、WoT Thing Description [wot-thing-description11] は、WoT Discovery の目的が WoT Thing Descriptions を 利用可能にすることであるため、WoT Discovery にとって重要な仕様である。 具体的には、WoT Discovery は、認証および認可されたエンティティ （かつそれらのエンティティのみ）が、特定のセマンティクスを持つことや、 特定のインタラクションを含むことなど、一連の基準を満たす WoT Thing Descriptions を見つけられるようにしなければならない。 逆に、セキュリティおよびプライバシーの目的をサポートするため、 WoT Discovery プロセスは、認可されていないエンティティに 情報を漏えいしてはならない。これには、Thing Descriptions 自体で配布される情報だけでなく、あるエンティティが特定の 情報を要求しているという情報の漏えいも含まれる。

すでに多数の発見メカニズムが定義されている [Discovery-Categorization-IoT] ため、新しいものを提案する理由を明確にする必要がある。第一に、 既存の多くの発見メカニズムは、セキュリティおよびプライバシー保護が 比較的弱い。私たちの目的の 1 つは、メタデータを保護するために ベストプラクティスを使用するだけでなく、必要に応じて将来の ベストプラクティスをサポートするようアップグレード可能な メカニズムを確立することである。第二に、ここでは発見を広い意味で 用い、ローカルおよび非ローカルの両方のメカニズムを含めている。 ローカルなメカニズムではブロードキャストプロトコルを使用できる 一方、非ローカルなメカニズムでは、ブロードキャストがスケーラブルでない 現在のネットワークセグメントを越える場合があり、そのため 検索サービスのような別のアプローチが必要になる。私たちのアプローチは、 必要に応じて既存のメカニズムを使用し、より一般的でセキュアな メタデータ配布システムへブートストラップすることである。第三に、 配布するメタデータである WoT Thing Description は高度に構造化されており、 データスキーマやセマンティック注釈などの豊富なデータを含んでいる。 単純なキー値ペアの一覧に基づく既存の発見メカニズムは適切ではない。 同時に、SPARQL [SPARQL11-OVERVIEW] のようなセマンティックデータクエリの既存標準の使用は、 一部の高度なユースケースには適している可能性があるものの、 想定される多くの IoT アプリケーションにとっては労力が大きすぎる 可能性がある。したがって、より基本的なアプリケーションに対処するため、 より単純ないくつかのクエリメカニズムも定義する。

いくつかの基本用語を定義した後、WoT Discovery の 基本的なユースケースと要件を要約する。これらは、WoT Use Cases [wot-usecases] および WoT Architecture [wot-architecture11] 文書で提示されている、より詳細で網羅的なユースケースおよび要件の サブセットである。次に、2 フェーズの Introduction/Exploration アプローチを使用する WoT Discovery プロセスの基本アーキテクチャを説明する。このアーキテクチャの基本的な 目標は、既存の発見標準を使用して、保護された発見サービスへの アクセスをブートストラップできるようにする一方で、詳細なメタデータは 認可されたユーザーにのみ配布し、クエリを行う者についても盗聴者から 可能な限り保護することである。その後、特定の Introduction および Exploration メカニズムの詳細を説明する。特に、Things または それらに代わって動作するエンティティによって動的に登録可能な WoT Thing Descriptions の集合に対する検索メカニズムを提供する、 WoT Thing Description Directory (WoT TDD) サービスの規範的 API を 詳細に定義する。ただし、WoT Discovery メカニズムは、通常の Web サービスから単一の TD を配布することもサポートしており、 その特殊な場合が自己記述である。最後に、潜在的なリスクと 緩和策のセットを含む、セキュリティおよびプライバシーに関する 考慮事項について議論する。

2. 適合性

非規範的としてマークされたセクションに加え、この仕様内のすべての オーサリングガイドライン、図、例、および注記は非規範的である。 この仕様内のそれ以外のすべては規範的である。

この文書におけるキーワード MAY、MUST、OPTIONAL、 RECOMMENDED、SHOULD、および SHOULD NOT は、ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] で説明されているとおりに解釈される。

3. 用語

このセクションは非規範的である。

Thing、Thing Description (TD)、Thing Model (TM)、Property、Action、 Event、Anonymous TD、Discoverer、Discovery、Exploration、Introduction、Thing Description Server (TD Server)、Thing Description Directory (TDD)、Partial TD、Enriched TD などの基本的な WoT 用語は、WoT Architecture 1.1 仕様 [wot-architecture11] の セクション 3 で定義されている。

4. アーキテクチャ

このセクションは非規範的である。

図 1 は、WoT Discovery プロセスの概要を示している。Discovery は、 オープンであることと、メタデータへのアクセスを認可された エンティティに制限することという競合する要件を解決するため、 2 フェーズのアーキテクチャを使用する。第 1 フェーズでは、 比較的オープンな「Introduction」メカニズムの集合のうち 1 つ以上を使用して、候補 URL の集合を生成できる。これらの URL 自体にはメタデータは含まれず、第 2 段階で、認証後に Thing Descriptions の形で 実際にメタデータを提供できる「Exploration」サービスを参照するために 使用される。

Discovery プロセスの概要
図 1 発見アーキテクチャの概要。オープンな Introduction メカニズムの集合が URL の集合を提供し、それらは、 適切な認証の後にのみメタデータ（TD）を提供する Exploration サービスを指す。Thing Links および Thing Description Directories は追加の柔軟性を提供するが、 これらからさらに結果を取得するかどうかはアプリケーションの 裁量に委ねられる。

Introduction メカニズムは、Discovery プロセスの残りの部分に 開始点を提供する、比較的オープンな「最初の接触」メカニズムであることを 意図している。この文書では、ローカルおよび非ローカルの シナリオの両方を含む、さまざまなユースケースに適したいくつかの Introduction メカニズムの詳細を規定するが、実際には URL を 返すことができる任意のメカニズムによって Introduction を提供できる。 ただし、Introduction にはセキュリティまたはプライバシー制御が含まれない ため、メタデータを直接提供すべきではない。代わりに、 Introduction メカニズムによって提供される URL は 「Exploration」サービスを参照する。Exploration サービスは実際に メタデータを提供するが、それは適切な認証およびアクセス制御が 適用された後に限られる。

Discovery プロセスは、Introduction メカニズムが 1 つだけ 使用される場合でも、その Introduction フェーズからの出力として URL の集合を生成できる（一部の Introduction メカニズムは それ自体で複数の URL を返すことができる）。Exploration フェーズ後の 最終出力も、Thing Descriptions の集合になり得る。

Introduction フェーズによって提供される各 URL は常に、 単一の Thing Description を返す Exploration サービスエンドポイントを 指す。最も単純な場合、この URL は、IoT エンドポイントデバイスを 記述する Thing の Thing Description を提供する Web サーバー上の 通常のリソースを参照する。この特殊な場合として、自己記述する Things では、Introduction URL が、Thing 自身の Thing Description を 提供する Thing によって提供されるエンドポイントを直接指すことがある。

一般に、Thing Descriptions はさまざまな方法で提供される可能性があり、 特に自己記述ではない場合がある。たとえば、

そのような Things の Thing Description は、別個のサービスによって 提供されるべきである。

この文書は、より高い柔軟性を可能にする 2 つの特殊な場合を規定する。

一般に巨大な結果集合になる可能性があるため、Discovery プロセスが Thing Description Directories の内容を取得し、それらを結果の一部として 返すことは必須ではない。代わりに、アプリケーションは結果を走査して Thing Description Directory TD を探し、そこから TD を取得するかどうかを、 場合によっては選択的に判断すべきである。同様に、Thing Links を 自動的にたどる必要はない。代わりに、アプリケーションはそれらを 選択的にたどることを選んでもよい。

5. Discoverer プロセス

このセクションでは、クライアントの観点から WoT Discovery プロセスを 説明し、クライアントが WoT Discovery をサポートすると言うことの 意味を説明する。WoT Discovery プロセスのクライアントである エンティティを表すために、 Discoverer という用語を使用する。 Discoverer は完全な Consumer である場合もあれば、そうでない場合もある。 ただし Discoverer は、Directories および Thing Links 用の特別な TD から 情報を読み取り抽出し、それらで提供される特定のアフォーダンスおよび リンクを使用する必要がある。逆に、Consumer は Discovery をサポートしない 場合もあるが、これは推奨される [wot-architecture11]。

WoT Discovery プロセスは、単一の URI が与えられたときに単一の TD を取得できるほぼ任意のクライアントが、WoT Discovery を サポートすると言えるように設計されている。当然、Discoverers は より強力な Discovery メカニズムをサポートできるが、それらの一部には 追加要件がある。一部の Introduction メカニズムは複数の URL を 返すことができ、それぞれを使用して少なくとも 1 つの TD を取得できる。 したがって、TDD がなくても、複数の TD を発見することが可能である。

以下の表明は、Discoverer の具体的な責任を説明する。

上記のプロセスは、Directories が自身の TD を重複させることなく 他の Directories を参照できる方法をサポートする。他の Directories を 参照したい Directory は、他の Directory サービスの TD への "describedby" 関係を持つ Thing Link を含めるべきである。その後、上記のプロセスは Thing Link を展開して Directory の実際の TD を取得し、その後（任意で）適切な Directory アフォーダンスを使用してリンク先 Directory の内容にアクセスすることになる。 このような Thing Link は Directory 自体ではなく、Directory の TD を指すことに 注意する。これらは同じ場所にホストされている場合もあれば、そうでない場合もある。

このようなリンクされたディレクトリの内容を再帰的にフェッチすると、 特に具体的なクエリやフィルターなしでは、大量のデータをダウンロードする結果に 容易になり得る。このような再帰的展開は、インベントリ、監査、索引付けなど、 それを必要とするユースケースに制限されるべきである。

Directory サービスの URL は、後述する SPARQL クエリのフェデレーション機能と ともに使用することもできる。これはほとんどの場合、分散した ディレクトリサービスの集合から特定の情報を収集するより効率的な方法である。 ただし、SPARQL ではそのようなフェデレーションのために SPARQL エンドポイントの URL が必要であり、それは SPARQL クエリをサポートする Directories の TD 内で 見つけられる。これは Directory の TD を指す URL と同じではない。

6. Introduction メカニズム

この章では、Things または Thing Description Directories との初期接触のためのメカニズムを説明する。 以下のいずれのメカニズムも、Thing または Thing Description Directory によって Consumers に提供され得る。 introduction メカニズムの結果は常に、適切な認証後に詳細な メタデータ（TD）を取得するために使用できる exploration サービスの URL （アドレス）である。複数の introduction メカニズムを使用し、 結果をマージすることも可能である。少なくとも 1 つの exploration サービスの URL が何らかの方法で取得される限り、特定の introduction メカニズムは必須ではない。

6.1 Direct

exploration サービスの URL を取得するために、単一の URL を結果として返す任意の メカニズムを使用 MAY。 これには、Bluetooth ビーコン、QR コード、 およびユーザーが入力する書面上の URL が含まれる。そのような すべての URL へのリクエストは、7. Exploration メカニズムで規定される TD を結果として返さ MUST。 自己記述する Things では、これは Thing 自体の TD であり得る。URL が Thing Description Directory を参照する場合、これは Thing Description Directory の Thing Description で MUST。

6.2 Well-Known URI

Thing または Thing Description Directory は、その存在を通知するために Well-Known Uniform Resource Identifier [RFC8615] を使用 MAY。 Thing または Thing Description Directory がその存在を通知するために Well-Known Uniform Resource Identifier [RFC8615] を使用する場合、次のパスに自身の Thing Description を登録し MUST: /.well-known/wot。

上記の Well-Known URI に リクエストが行われた場合、サーバーは 7. Exploration メカニズムで規定される Thing Description を返さ MUST。

6.3 DNS ベースのサービス発見

Thing または Thing Description Directory は DNS-Based Service Discovery (DNS-SD)[RFC6763] を使用 MAY。 これは、同じローカルネットワーク上で Multicast DNS (mDNS)[RFC6762] と組み合わせて使用することもできる。

次の表は、その存在を広告するためのサービス名およびプロトコルを 一覧にしている。各項目は既存の exploration メカニズムで有効な 用途を持つため、これらは規範的である。

サービス名 Thing または TDD プロトコル
_wot._tcp Thing HTTP over TCP、HTTP over TLS/TCP、CoAP over TCP、または CoAP over TLS/TCP
_directory._sub._wot._tcp TDD HTTP over TCP、HTTP over TLS/TCP、CoAP over TCP、または CoAP over TLS/TCP
_wot._udp Thing CoAP over UDP または CoAP over DTLS/UDP

以下の追加サービス名は将来利用のために定義されている。ただし、 現在 CoAP over UDP を使用する定義済みの directory サービスは存在しないため、 この定義は参考情報である。

サービス名 Thing または TDD プロトコル
_directory._sub._wot._udp TDD CoAP over UDP または CoAP over DTLS/UDP

TCP ベースのサービスでは、Service Instance Name によって指し示される TXT レコードに、 次の情報を含め MUST。

td
Thing の Thing Description または Thing Description Directory の Thing Description の 絶対パス名。
type
Thing Description の型。すなわち Thing または Directory。省略された場合、 型は Thing とみなされる。
scheme
URL のスキーム部分。標準登録された URI の解釈 [RFC7595] に従い、次の値のいずれかを指定できる。 http (HTTP over TCP)、https (HTTP over TLS/TCP)、coap+tcp (CoAP over TCP)、または coaps+tcp (CoAP over TLS/TCP)。 省略された場合、スキームは http とみなされる。

UDP ベースのサービスでは、Service Instance Name によって指し示される TXT レコードに、 次の情報を含め MUST。

td
Thing の Thing Description または Thing Description Directory の Thing Description の 絶対パス名。
type
Thing Description の型。すなわち Thing または Directory。省略された場合、 型は Thing とみなされる。
scheme
URL のスキーム部分。標準登録された URI の解釈 [RFC7595] に従い、次の値のいずれかを指定できる。 coap (CoAP over UDP) または coaps (CoAP over DTLS/UDP)。省略された場合、スキームは coap とみなされる。

図 2 および 図 3 は、DNS-SD および mDNS を使用して Thing または Thing Description Directory の発見をサポートする例示的なシーケンスを示している。

DNS-SD および mDNS を使用した Thing の発見の例示的なシーケンス
図 2 mDNS を使用した Thing の Thing Description の発見
DNS-SD および mDNS を使用した directory サービスの発見の例示的なシーケンス
図 3 mDNS を使用した Thing Description Directory (TDD) の Thing Description の発見

Thing または Thing Description Directory は、Constrained RESTful Environment (CoRE) Link Format [RFC6690] を使用して その存在を広告 MAY。 Thing または Thing Description Directory は、対応する Thing Description へのリンクを登録するために、CoRE Resource Directory [RFC9176] を使用 MAY。

Thing の Thing Description をターゲットとする Link のリソースタイプ (rt) は wot.thing で MUST。 Thing Description Directory の Thing Description をターゲットとする Link のリソースタイプは wot.directory で MUST。

6.5 DID 文書

Decentralized Identifier (DID) [DID-CORE] を使用する Thing または Thing Description Directory は、TD の識別子が解決される DID Document 内に、 それぞれ WotThing または WotDirectory 型の DID Service Endpoint を含めることによって、 その TD の 場所を広告 MAY。

WoT Discovery 用の Service Endpoints を定義するために、 Thing または Thing Description Directory の DID を解決して取得される DID Document は、 その @context [did-spec-registries] に URL https://www.w3.org/2022/wot/discovery-did を含め MUST。

Thing または Thing Description Directory の DID を解決して取得される DID Document が、 それぞれ WotThing または WotDirectory 型の Service Endpoint を含む場合、この Service Endpoint は WotThing サービス名を使用する場合はその Thing を記述する TD を参照し、 WotDirectory サービス名を使用する場合はその Thing Description Directory を記述する TD をそれぞれ参照し MUST [did-spec-registries]。

7. Exploration メカニズム

このセクションでは、いくつかの共通の背景情報を示した後に、 サポートされる exploration メカニズムを定義する。

7.1 概要

Exploration メカニズムの高レベルクラス図
図 4 exploration メカニズムの 高レベルクラス図。Thing Description Servers および Thing Description Directories がどのように TD を提供するかを示している。 Self-describing Thing は、Thing でもある Thing Description Server の特殊な場合である。Thing Description Directory は、 それが含む各 Thing Description について Thing Description Server として動作する。

図 4 は、TD Servers（自己記述用のものを 含む単一の TD を提供する）および Thing Description Directory サービスの高レベル情報モデルを示している。 Thing Description Directory は TD を含むことができ、同時にそれ自体も Thing であり、これはそれ自身の TD を持つことを意味する。directory は、 他の Things の個別の TD を取得するための Web サービスエンドポイントもホストし、それぞれを TD Server として 使用できる。一般に Thing は自身の TD をホストすることができ、 その場合、それは Self-Describing Thing である。自己記述は directories に必須ではないが、Thing Description Directories であると同時に Self-Describing Things でもある Self-Describing Thing Description Directories は可能である。

2 つの基本的な exploration メカニズムは、 7.2 Thing Description Server および 7.3 Thing Description Directory で説明される。

7.1.1 オントロジー

discovery コンテキストにおける TD のオントロジー
図 5 Discovery コンテキストにおける Thing Descriptions の オントロジー。

図 5 は、Thing オントロジーの拡張として Discovery オントロジーを示している。

このオントロジーには、directory に保存された TD に 関連付けられるメタデータのためのクラスが含まれる。このクラスは RegistrationInformation と呼ばれ、 7.3.1.1 登録 情報における directory 仕様の一部として説明される。

Discovery オントロジーはまた、以下のセクションで説明する 2 つの新しい Thing Description クラスを定義しており、 特別な exploratory metadata をモデル化するために使用できる。 ThingDirectory および ThingLink である。

7.1.1.1 ThingDirectory
Thing Description Directory インスタンスを記述する TD は、 discovery コンテキストまたは URI https://www.w3.org/2022/wot/discovery#ThingDirectory から 型 ThingDirectory を使用 MUST。

このクラスの TD は、Directory の Thing Model から導出できる。 7.3.2.4 API 仕様 (Thing Model) を参照。

7.1.2 セキュリティブートストラップ

exploration サービスの目的は TD を提供することだが、 それは適切な認証の後、かつ認可された当事者に対してのみである。 しかし、特にアドホックなシナリオでは、Discoverer が exploration サービス経由で TD にアクセスするために必要な セキュリティ資格情報を知らない場合がある。exploration サービスへの 初回アクセス時に、適切な認証資格情報が提供されていなければ Discoverer はまだ TD にアクセスできないため、Discoverer は どの種類の認証および認可情報が必要かを知るために、TD に保持される セキュリティメタデータに依存できない。Discoverer が事前知識を 持たない場合、少なくとも TD 自体へのアクセスをブートストラップするために、 既存のセキュリティ交渉サポートに依存しなければならない。

ここでは、セキュリティ交渉プロセスがすでに存在する HTTP プロトコルについて、以下を定義する。ただし、HTTP 交渉プロセスの多くは 人間のユーザーが関与することを前提としているが、これは WoT Discovery にも適している。なぜなら、この問題は通常、ユーザーが 公開 WoT サービスにアクセスしようとする場合、または新しいデバイスの 統合を行おうとする場合に発生するためである。この場合、交渉の目的は、 システムにアクセスするために必要な資格情報についての案内を提供することである。

exploration サービスがシステム管理の自動化に使用されている場合、 関連する exploration サービスにアクセスするために必要な資格情報 （および認証メカニズム）を事前に確立しておくのが最善であり、 セキュリティブートストラップは不要である。このため、 セキュリティブートストラップは必須機能ではなく、事前に確立された セキュリティメカニズムで使用されるデバイスでは、省略または無効化できる。

セキュリティブートストラップは、TD への最初のアクセス時にのみ 必要となる場合もある。Discoverer が特定の exploration サービスに アクセスするために必要な資格情報および認証メカニズムを判断した後は、 その情報を保持し、将来のアクセスでそれを使用しようとすることができる。 ただし、使用されるセキュリティスキームによっては、資格情報自体が期限切れに なり、定期的に再確立する必要がある場合があることに注意する。

セキュリティブートストラップは、 TD を提供する任意の HTTP エンドポイントで提供 MAY。 上述のとおり、 セキュリティメカニズムが以前に確立されている場合、 セキュリティブートストラップを無効化または省略することは許容される。 たとえば、あるインストールが OAuth2 client フローを使用し、潜在的なクライアントに 使用すべき認証サーバーのアドレスを事前に提供したい場合、 代替手段として他の（場合によってはより弱い）認証形式を含めることになるため、 セキュリティブートストラップを無効化できる。

HTTP プロトコルでは、使用される認証および認可メカニズムは一般に、 HTTP サーバーが、必要な情報を指定する WWW-Authenticate ヘッダーとともに "401 (Unauthorized)" レスポンスコードを返すことによって交渉できる。 アクセスを得るには、クライアントはその後、必要な情報を伴う別の リクエストを行う必要がある。 IANA に登録されている認証スキームはいくつかある。 しかし、 これらのすべてが広く使用されているわけではなく、一部は実験的であり、 TD がサポートするスキームとは部分的にしか重ならない。また、 IANA 登録における oauth スキームは非推奨の OAuth1 を指しているため、使用すべきではないことに注意する。 関連する OAuth2 フローである code フローは、 401 レスポンスではなく、認証サーバーへのリダイレクトから始まり、 最終的にアクセスに使用できる資格情報（WoT の場合は bearer token）を 得ることになる。

これらの考慮事項を踏まえ、ブラウザーだけでなく多様なデバイス上で セキュリティブートストラップを可能にするため、次の制約に従うべきである。

  • exploration サービスで セキュリティブートストラップが有効になっている場合、 introduction メカニズムによって提供された URL を使用した 初回接触の後、認証情報が提供されていないが、提供されれば アクセスを許可できるとき、exploration サービスは Basic、Bearer、 Digest、または OAuth2 セキュリティスキームのいずれかに適した HTTP レスポンスコードで応答 MUST。 exploration サービスが何らかの理由で アクセスを提供したくない場合、またはセキュリティブートストラップが 無効になっている場合、リクエストを無視するか、404 または 403 などの 別のコードで応答できることに注意する。また、認証が不要な場合、 システムは認証情報が提供されたかのように、要求された TD を直ちに 返すことができる。ただし、認証を迂回することが適切なのは、 応答として提供される TD が Personally Identifiable Information を含まず、 かつ推測にも使用できない場合に限られる。 9. プライバシーに関する 考慮事項を参照。
  • Basic、Bearer、または Digest のいずれかの IANA 登録済み HTTP Authentication Schemes を使用する exploration サービスでセキュリティブートストラップが有効になっている場合、 （これらの認証スキームの標準に従い）TD を提供することを意図した API エンドポイントにおける 401 HTTP レスポンスは、 WWW-Authenticate ヘッダーおよび必要な認可を記述する その他のヘッダーを含まなければならない。要件の詳細については、 上記の各認証スキームについて IANA レジストリを参照すべきである。 同様に、OAuth2 仕様に従い、セキュリティブートストラップ中に OAuth2 code フローが使用される場合、認証サーバーへの リダイレクトには "302 (Found)" または "303 (See Other)" レスポンスコードを使用しなければならず、最終的にアクセス資格情報は bearer token として表される。WoT Thing Description 1.1 でサポートされる もう 1 つの OAuth2 フローである client は、 初回アクセスが最終エンドポイントではなく認証サーバーに対して 行われることを想定しているため、セキュリティブートストラップ経由では 使用できないことに注意する。これらの要件はまた、セキュリティ ブートストラップをサポートする必要がある可能性のある exploration サービスのエンドポイント、すなわち TD を提供するエンドポイントにのみ 適用され、同じ exploration サービスによって提供される可能性のある 他のエンドポイントには適用されない。特に、これらの要件は introduction メカニズムによって参照され得る URL にのみ適用され、 （たとえば）イベント購読エンドポイントには適用されない。

TD へのアクセスに認証が必要となる場合、およびセキュアなトランスポートの 使用に関して、[wot-architecture11] および [wot-thing-description11] には関連する Security and Privacy Considerations がある。 9. プライバシーに関する考慮事項も参照。要約すると、 セキュアなトランスポート（例: TLS）は公開サービスに必須であり、 プライベートネットワーク上でも（認証要件がない場合であっても、 クエリの機密性を保護するために）強く推奨される。また、 認証および認可なしにリクエストを提供することは、Personally Identifiable Information が存在しない、または推測できない限定的な状況においてのみ 検討されるべきである。

7.2 Thing Description Server

URL によって参照でき、適切な認証およびアクセス制御を伴って TD を返すことができる任意の Web サービスは、exploration メカニズムとして 使用できる。これを Thing Description Server または TD Server と呼ぶ。 TD Server は Thing である必要はない。特に、TD は通常の Web サーバー上でホストされ、その URL によって参照できる。

TD Server は自己記述をサポートするために使用できる。 自己記述では、Thing が 自身の TD をホストし、 URL で識別される Web リソースを介して利用可能にする。 ただし、このような Web リソースは TD 自体の affordance には含まれない。 この Web リソースは、 6.2 Well-Known URI で定義される Introduction メカニズムとして使用される well-known URL と同じである場合もあれば、そうでない場合もある。

セキュアなトランスポートの使用は、 [wot-architecture11] および [wot-thing-description11] 仕様の Security Considerations および Privacy Considerations セクションに示される表明に従う。これらは、セキュアなトランスポートが 推奨または必須となるシナリオ、および相互認証が推奨されるシナリオを 定義している。

次のプロトコルを使用して TD を配布する TD Server は、 以下の制約に従う。

HTTP

HTTP ベースの TD Server が TD を提供する場合、 そのリソースを GET メソッドで提供 MUST。 HTTP ベースの TD Server が TD を提供する場合、その成功レスポンスは 200 (OK) ステータスを持ち、body に TD を含め MUST。 JSON シリアライズを持つ 成功レスポンスは、Content-Type ヘッダーに application/json または application/td+json のいずれかを含め MUST。 ここでは application/td+json がより具体的であり、 application/json を含意するため望ましい。 成功レスポンス body の デフォルトのシリアライズ形式は、JSON-LD 1.1 [JSON-LD11] 構文による JSON で MUST。 JSON-LD 構文は、 セマンティック拡張および処理を可能にする。 HTTP ベースの TD Server が TD を提供する場合、 サーバー主導のコンテンツネゴシエーション、すなわちリクエストの Accept および Accept-Encoding ヘッダーを尊重し、 サポートされる TD シリアライズと同等の Content-Type および Content-Encoding ヘッダーで応答することにより、 代替表現を提供 MAY。 さらに、 WoT Thing Description 1.1 仕様 [wot-thing-description11] で規範的に定義されるプロセスに従い、 HTTP ベースの TD Server が TD を提供する場合、リクエストの Accept-Language ヘッダーを尊重することによるサーバー主導の コンテンツネゴシエーションの後、異なるデフォルト言語を使用して 変更された TD またはエラーレスポンスを提供してもよい。

HTTP ベースの TD Server が TD を提供する場合、 同じエンドポイントへの GET リクエストによって返されるものと 同等のヘッダーのみを返すことにより、HEAD リクエストに応答 MUST。 これにより、クライアントは Content-Length などの HTTP ヘッダーを事前に取得して、 TD のサイズ（バイト単位）を把握し、 効率的なクエリ戦略を決定できる。

制約のある環境では、単一の TD がサーバーまたはクライアントにとって 処理するには大きすぎる場合がある。要求された payload の インクリメンタル転送に関するプロトコル固有の推奨事項については、 10.1 インクリメンタル 転送を参照。

エラーレスポンス:

  • 401 (Unauthorized): 認証なし。
  • 403 (Forbidden): リソースに対する権限不足。
CoAP

CoAP ベースの TD Server が TD を提供する場合、 そのリソースを GET メソッドで提供 MUST。 CoAP ベースの TD Server が TD を提供する場合、その成功レスポンスは 2.05 (Content) ステータスを持ち、値 50 (application/json) または 432 (application/td+json) の Content-Format option を含み、 payload に TD を含め MUST。 Content-Format 432 は、より具体的であり Content-Format 50 を含意するため望ましい。payload は block-wise transfer [RFC7959] を使用して複数のメッセージ交換に分割される可能性があることに注意する。 CoAP ベースの TD Server が TD を提供する場合、 サーバー主導のコンテンツネゴシエーション、すなわちリクエストの Accept option を尊重し、サポートされる TD シリアライズと同等の Content-Format option で応答することにより、 代替表現を提供 MAY。

CoAP ベースの TD Server が TD を提供する場合、Size2 option を含むリクエストに対し、 次のレスポンスに TD の サイズ見積もりを含めて応答 SHOULD。 これは、 block-wise transfer を使用して TD を 取得する場合に関連し、合計 payload サイズが大きすぎて 処理できない可能性があるときに、クライアントが取得を中止できるようにする。

制約のある環境では、単一の TD がサーバーまたはクライアントにとって 処理するには大きすぎる場合がある。要求された payload の インクリメンタル転送に関するプロトコル固有の推奨事項については、 10.1 インクリメンタル 転送を参照。

エラーレスポンス:

  • 4.01 (Unauthorized): 認証なし。
  • 4.03 (Forbidden): リソースに対する権限不足。

7.3 Thing Description Directory

Thing Description Directory（略して TDD または Directory）は、 他の Things を記述する TD の集合を管理するサービスを 提供する Thing である。

7.3.1 情報モデル

図 4 に示すように、Thing Description Directory は 0 個以上の TD を含むことができる。 directory は、各 TD について、記録管理および検索の目的で 追加のメタデータを維持する。これらは 7.3.1.1 登録 情報 および 7.3.1.3 匿名 TD 識別子で説明される。directory とのインタラクションの一部として そのような追加メタデータを埋め込む TD は、 Enriched TD と呼ばれる。

7.3.1.1 登録 情報

Discovery コンテキストにおける TD のオントロジーは、 図 5 で導入された。 RegistrationInformation クラスは、 directory に保存される TD と関連付けられる。 次の表は、Discovery コンテキストを埋め込む、または参照する TD 内で使用する登録情報属性を一覧にしている。 登録情報を埋め込むのは Enriched TD のみであることに注意する。 Enriched TD は、その @context に URI https://www.w3.org/2022/wot/discovery を含め MUST。 この表では、client は TD の producer または consumer を指し、 server は Thing Description Directory を指す。

絶対時刻が dateTime を使用して表現される場合は常に、[RFC3339] で指定される date-time として解釈され MUST。 具体的には、タイムゾーンオフセットは任意ではない。

編集者メモ: dateTime と date-time

dateTime と date-time のこの奇妙な組み合わせではなく、 date-time および RFC3339 のみを使用するように オントロジーを更新すべきであるが、これは TD 仕様でも 解決されるべきである。ただし、この追加の制約を伴う 新しい SHACL shape が必要になる。

語彙用語 説明 Client 割り当て Server 割り当て 型
created TD インスタンスが directory 内で作成された絶対時刻を提供する。

これは directory によって設定され、consumers に返され MAY。

読み取り専用 任意 dateTime
modified TD インスタンスが directory 内で最後に変更された絶対時刻を提供する。

これは directory によって設定され、consumers に返され MAY。

読み取り専用 任意 dateTime
expires TD インスタンスの登録が失効する絶対時刻を提供する。

producer は、登録中に絶対失効時刻を示すために これを設定 MAY。

失効可能な TD をサポートする servers の場合: ttl（相対失効）が存在する場合、 server は client による expires への割り当てを 無視し、代わりに内部で計算して設定し MUST。

任意 任意 dateTime
ttl Time-to-live: 登録時刻から TD インスタンスの登録が 失効するまでの相対的な時間量（秒単位）。

producer は、登録中に相対失効時刻を示すために これを設定 MAY。

失効可能な TD をサポートする servers の場合: server は ttl を使用して expires（絶対失効）値を計算し MUST。

任意 読み取り専用 number
retrieved TD が server から取得された絶対時刻。

これは、他の絶対タイムスタンプを処理しようとするが、 内部時計または現在時刻を取得する他の手段を持たない clients に有用である。

 読み取り専用 任意 dateTime
7.3.1.2 登録の失効
セクション 7.3.1.1 登録 情報 は、登録された TD の失効時刻を指定および 発見するためのいくつかの属性を導入する。

Producers は、TD 登録の有効性について directory および 他の consumers に知らせるために失効時刻を設定できる。 失効は、動的な TD の失効について consumers に知らせるための有用な指標でもある。たとえば、 地理位置情報や properties などのメタデータへの変更が、 限られた期間だけ有効であると期待される場合である。 Consumers は、取得した TD がどのくらいの期間 有効であるか、またいつより新しいものを要求する必要があるかを 知るために、失効時刻に依存してもよい。失効した TD を取得した consumers は、それを非アクティブな client のメタデータとみなしてもよい。

servers にとって、失効時刻は、古くなった登録や偶発的な登録の 自動削除を実装するのに有用である。Servers は、 失効時刻を過ぎた TD を定期的に削除 SHOULD。 失効時刻について グローバルな義務または上限を規定することは アプリケーション固有であり、この仕様の範囲外である。 Servers は、失効時刻に対する構成可能な上限を義務付ける、 または設定し、準拠しないリクエストを拒否してもよい。 servers による削除は、自身の TD を明示的に登録解除できない clients（例: IoT デバイス）とやり取りする場合に特に有益である。 これは、プロトコル固有の制限、故障、破壊、または 正常でない廃止による可能性がある。そのような clients は、 妥当に短い失効時刻を設定し、通常動作中にそれを定期的に 延長すべきである。失効は、TD に変更を加えない更新を含め、 登録を完全または部分的に更新することで延長できる。 7.3.2.1.3 更新を参照。 client が動作を停止した場合、削除機能を持つ directory は その登録を自動的に削除する。

7.3.1.3 匿名 TD 識別子
directory は、Anonymous TD にローカル識別子を割り当て、directory からの そのような TD の管理および取得を可能にする。server が Anonymous TD を公開する状況 （例: 取得、一覧表示、検索）では、ローカル参照を可能にするため、 TD の id としてローカル識別子を追加し MUST。 ローカル識別子は、 URN [RFC4122] として提示される UUID Version 4 である SHOULD。 UUID Version 4 は、ホストまたはリソースに関する意図しない情報を 持たないランダムまたは擬似ランダムな数値である。

7.3.2 Directory Service API

Directory サービスは、System User Data へのアクセスを提供するため、適切なセキュリティおよび プライバシー保護を提供する必要がある。WoT Directory Service API の 実装における真正性および機密性のためのセキュアなトランスポートプロトコル およびアクセス制御の使用は、[wot-architecture11] に示される Security Considerations および Privacy Considerations によって規定される。

HTTP API レスポンスは、成功レスポンスおよびエラーレスポンスに対して、 このセクションで説明される適切なステータスコードを使用しなければならない。 HTTP API は、HTTP クライアントエラー (4xx) およびサーバーエラー (5xx) レスポンスでエラー詳細を運ぶために、 Problem Details [RFC7807] 形式を使用し MUST。 これにより、機械と人間の双方が、 高レベルのエラークラスおよび細かな詳細を知ることができる。 Problem Details を使用して 記述されるすべての HTTP API エラーレスポンスは、UTF-8 でエンコードされ MUST。 HTTP API エラーレスポンスは、 HTTP リクエストで Accept-Language ヘッダーフィールドが 設定されている場合、プロアクティブネゴシエーションを使用して異なる言語で 詳細を報告しても MAY [RFC7231]。

API は、[RFC7231] のセクション 6 で定義される HTTP ステータスコードを設定する。 使用されるエラーコードの一覧には、以下が含まれる（ただしこれらに限定されない）。

  • 400 (Bad Request): body、query、または headers における 無効な client 入力。これには適切なレスポンスメッセージが伴う。
  • 401 (Unauthorized): リクエストに有効な認証資格情報がない。 7.1.2 セキュリティ ブートストラップで述べたように、これは認証交渉の 最初のステップであり、TD へのセキュアなアクセスをブートストラップするために 必要である。必要な資格情報に関する情報は、 WWW-Authenticate ヘッダーに含まれる。
  • 403 (Forbidden): リソースにアクセスするための権限が不足している。
  • 404 (Not Found): TD または endpoint が存在しない。 これには適切なレスポンスメッセージが伴う。

GET メソッドに応答する各 HTTP endpoint について、server は HEAD リクエストを受け入れ、headers のみを返さ MUST。 これにより、clients は body を受信することなく Content-Length などの headers を取得し、 情報を問い合わせるための適切な戦略を決定できる。たとえば、 制約のある client は、オブジェクトの必要な部分のみを （適切な検索クエリを使用して）要求したり、項目一覧を小さなサブセットで 取得したりできる。

制約のある環境では、単一の TD が server または clients にとって 処理するには大きすぎる場合がある。これは、読み取り （すなわち、1 つ以上の TD または TD フラグメントの取得）と 書き込み（すなわち、TD または Partial TD の送信）の両方の操作に 影響する。payloads のインクリメンタル転送に関するプロトコル固有の 推奨事項については、10.1 インクリメンタル 転送を参照。

URL 上でデータを安全に送信するために、client と server の双方が、 URL の残りの部分にある区切り文字と競合する文字を percent encode/decode することが期待される。これらの文字は [RFC1738] のセクション 2.2 で unsafe と定義されている。Unsafe 文字は、 たとえば path に含まれる resource ID がそれ自体 URL である場合や、 search query string 内に現れる場合、URL 内で予期しない動作を 引き起こす可能性がある。

directory API には、必須、推奨、および任意の機能が含まれる。 directory が、サポートされていない 推奨機能または任意機能のためにリクエストに応答できない場合、 適切な HTTP エラーを返すことにより、それらの機能が存在しないことを client に通知 SHOULD。 以下の例は、実装の指針として使用できる。

  • 欠けている機能が既存 API の機能をカスタマイズするものである場合は、 400 (Bad Request) または 501 (Not Implemented) を使用する。
  • API endpoint が提供されていない場合（例: /search/sparql endpoint）、404 (Not Found) を使用する。
  • 既存の API endpoint でメソッドがサポートされていない場合 （例: /things endpoint に対する PATCH）、405 (Method Not Allowed) を使用する。

TD 内ですでに提供されている翻訳を使用して TD のデフォルト言語を 変更するプロセスは、WoT Thing Description 1.1 仕様 [wot-thing-description11] で規範的に記述されている。このプロセスを使用して、Directory server は サーバー主導のコンテンツネゴシエーションの後、すなわちリクエストの Accept-Language header を尊重することによって、異なるデフォルト言語を使用した 変更済み TD、または自身の TD を提供してもよい。

7.3.2.1 Things API

Things API は、/things endpoint で提供される RESTful HTTP API であり、 TD を 作成、取得、更新、削除、および一覧表示（CRUDL）するための インターフェイスを提供する。この API の設計は [RFC7231] および [REST-IOT] に従っている。

HTTP API は以下の一般規則に従う。

  • API は TD を一覧表示する インターフェイスを提供し MUST。 Search API は、この一覧からの フィルタリングおよび選択を可能にする。 7.3.2.3 Search APIを参照。
  • API は、個々の TD を 作成、読み取り、更新、および削除（CRUD）するインターフェイスを 提供しても MAY。
  • HTTP 上で読み取りと書き込みの両方を提供する directory は、 full HTTP directory と見なされる。 Full HTTP directories は、 CRUDL（create、read、update、delete、および list）インターフェイスを すべて実装 SHOULD。 directory が静的な TD の集合を提供する場合は、 読み取りおよび一覧表示のインターフェイスのみを実装することが実用的である。 これは、HTTP 上では取得操作のみを公開し、他の操作は out-of-band メカニズムで行うことを意図する directories にも有用である。 読み取り専用アクセスを 公開するために、directory は create、update、および delete インターフェイスに対してアクセス制御を強制し MUST。
  • すべてのリクエストおよび 成功レスポンス body のデフォルトのシリアライズ形式は、 拡張およびセマンティック処理をサポートするために、JSON-LD 1.1 [JSON-LD11] 構文による JSON で MUST。
  • Directories は、 リクエストで示された Content-Type または Content-Encoding headers に基づく 代替表現を受け入れても MAY。 これは、raw JSON 以外の表現を directory への入力として提供する必要があるアプリケーションに有用である。
  • Directories は、 サーバー主導のコンテンツネゴシエーション、すなわちリクエストの Accept および Accept-Encoding headers を尊重し、サポートされる TD 表現と 同等の Content-Type および Content-Encoding headers で応答することによって、 代替表現を提供しても MAY。 これは、Gzip 圧縮 JSON など、 raw JSON 以外の表現を directory から取得する必要がある アプリケーションに有用である。

CRUDL 操作は以下のセクションで説明される。

7.3.2.1.1 作成

作成とは、新しい TD を directory 内に登録することを指す。

TD object は、 7.3.2.1.6 検証に従って検証される。TD は、それが記述する Thing によって生成される場合もあれば、 そうでない場合もあることに注意する。特に brownfield devices では、 Thing に代わって TD を生成し登録する、 別個の Discoverer プロセス またはサービスが必要となる場合がある。

id 属性で識別される TD は、識別子を持たないもの （Anonymous TD）とは異なる方法で扱われ MUST。 作成操作は以下で詳述される。

  • id を持つ TD は、HTTP PUT リクエストの body に入れて /things/{id} endpoint に送信され MUST。ここで id は、 TD object 内に存在する一意の TD 識別子である。 Anonymous TD は異なる方法で扱われる。以下を参照。 リクエストは、 TD の JSON シリアライズのために application/td+json Content-Type header を含む SHOULD。 TD object は 7.3.2.1.6 検証に従って検証される。 処理が成功した場合、server は 201 (Created) status で応答し MUST。

    注記: ターゲット位置が既存の TD に対応する場合、 リクエストは代わりに Update 操作として進行し、 適切なステータスコードで応答しなければならない （Update セクションを参照）。

    識別子を持つ TD の作成操作は、 7.3.2.4 API 仕様 (Thing Model) の createThing action として規定されている。

  • Anonymous TD は、HTTP POST リクエストの body に入れて /things endpoint に送信され MUST。 リクエストは、TD の JSON シリアライズのために application/td+json Content-Type header を含む SHOULD。 TD object は 7.3.2.1.6 検証に従って検証される。 directory は、directory からの ローカル管理および取得を可能にするため、任意の Anonymous TD にローカル識別子を割り当て MUST。 システム生成 ID のスキームは、 7.3.1.3 匿名 TD 識別子で説明されている。 処理が成功した場合、server は 201 (Created) status と、作成された TD リソースの システム生成 URI を含む Location header で応答し MUST。 システム生成 URI には、TD のシステム生成識別子が含まれ、 後で directory から TD を問い合わせるために使用できる。

    Anonymous TDs の作成操作は、 7.3.2.4 API 仕様 (Thing Model) の createAnonymousThing action として規定されている。

失効可能な TD をサポートする server は、 7.3.1.2 登録の失効で説明されるように、その機能を実現する。 特に、作成中に ttl（相対失効）が与えられた場合、 そのような servers は expires 値を計算して保存する。

7.3.2.1.2 取得

既存 TD の取得は、 HTTP GET リクエストを /things/{id} endpoint に対して使用して行われ MUST。ここで id は一意の TD 識別子である。 成功レスポンスは 200 (OK) status を持ち、body に要求された TD を含め MUST。 JSON シリアライズを持つ成功レスポンスは、 Content-Type header に application/json または application/td+json のいずれかを含め MUST。 ここでは application/td+json がより具体的であり、 application/json を含意するため望ましい。 デフォルトのシリアライズは JSON-LD 構文による JSON であり、 代替シリアライズはネゴシエート可能であることに注意する。 7.3.2.1 Things APIを参照。

retrieve 操作は、 7.3.2.4 API 仕様 (Thing Model) の retrieveThing action として規定されている。

以下は、取得された TD の例である。

これは Enriched TD であり、directory 内での TD の作成時刻や変更時刻などの 登録情報を含む。

以下の例は、Anonymous TD が取得され、 Enriched TD 形式であり、ローカル識別子 urn:uuid:48951ff3-4019-4e67-b217-dbbf011873dc を 持つことを示している。

以下は、3600 秒（1 時間）の相対失効時刻で登録された TD が取得された例である。server は、変更時刻の 1 時間後として 絶対失効時刻を計算している。

読みやすさのため、この例の時刻値は正確な数値に設定されている。 現実的な設定では、時刻値に小数部が含まれる場合がある。

7.3.2.1.3 更新

update 操作は、既存の TD を置き換える、または部分的に変更するためのものである。

update 操作は以下で説明される。

  • 変更された TD は、 HTTP PUT リクエストを /things/{id} endpoint に対して使用して送信されるとき、 既存のものを置き換え MUST。ここで id は既存 TD の識別子である。 リクエストは、 TD の JSON シリアライズのために application/td+json Content-Type header を含む SHOULD。 TD object は 7.3.2.1.6 検証に従って検証される。 成功した場合、server は 204 (No Content) status で応答し MUST。

    この操作は、 7.3.2.4 API 仕様 (Thing Model) の updateThing property として規定されている。

    失効可能な TD をサポートする server は、 7.3.1.2 登録の失効で説明されるように、その機能を実現する。 update 操作中に ttl （相対失効）が設定された場合、server は expires（絶対失効）値を計算して設定する。

    注記: ターゲット位置が既存の TD に対応しない場合、 リクエストは代わりに Create 操作として進行し、 適切なステータスコードで応答しなければならない （Create セクションを参照）。言い換えれば、HTTP PUT リクエストは create または update 操作として動作する。

  • 既存の TD は、 変更部分が HTTP PATCH リクエストを使用して /things/{id} endpoint に送信されるとき、 部分的に変更され MUST。ここで id は既存 TD の識別子である。 partial update は、[RFC7396] で説明される JSON merge patch 形式を使用して処理され MUST。 リクエストは、 merge patch document の JSON シリアライズのために application/merge-patch+json Content-Type header を含め MUST。 入力は Partial TD 形式であり、元の TD 構造に適合し MUST。 入力が元の TD に現れる members を含む場合、それらの値は置き換えられる。 member が元の TD に現れない場合、その member は追加される。 member が null に設定されているが元の TD に現れる場合、 その member は削除される。object 値を持つ members は再帰的に 処理される。変更を適用した後、TD object は 7.3.2.1.6 検証に従って検証される。 成功した場合、server は 204 (No Content) status で応答し MUST。

    この操作は、 7.3.2.4 API 仕様 (Thing Model) の partiallyUpdateThing property として規定されている。

    失効可能な TD をサポートする server は、 7.3.1.2 登録の失効で説明されるように、その機能を実現する。 partial update 操作中に、結果として得られる TD が ttl （相対失効）を持つ場合、server は新しい expires（絶対失効）値を計算して設定する。

    patch 操作は、ttl（相対失効）値を使用する登録の 失効を効率的に延長するために特に有用である。これは通常、 空の merge patch document、すなわち空の JSON object を送信することで行われる。 これは実質的に、何も更新しない partial update 操作を実行することに 変換されるが、expires（絶対失効）値の再計算を トリガーする。この失効機能は、server が 7.3.1.2 登録の失効で定義されるようにそれをサポートする場合にのみ機能する。

    以下の例は、TD の base および registration expires fields のみを更新するための merge patch document である。

7.3.2.1.4 削除

delete 操作は、 HTTP DELETE リクエストを /things/{id} に対して使用して行われ MUST。ここで id は 既存 TD の識別子である。 成功レスポンスは 204 (No Content) status を持ち MUST。 retrieve 操作は 7.3.2.4 API 仕様 (Thing Model) の deleteThing property として規定されている。

7.3.2.1.5 一覧表示

listing endpoint は、directory から full TD objects の集合を 問い合わせるためのさまざまな方法を提供する。

多くのシナリオでは、full TD objects ではなく一部を取得することが望ましい。 必要なのは要素のサブセットのみである場合（例: すべての TD について property の id と href）があり、 ネットワークリソースを節約できるためである。Search API は TD objects の一部を問い合わせることを可能にする。 7.3.2.3 Search APIを参照。

directory は、 /things endpoint における HTTP GET リクエストを使用して既存 TD を取得できるようにし MUST。 成功レスポンスは 200 (OK) status を持ち、 body に TD の配列を含め MUST。 JSON シリアライズを持つ 成功レスポンスは、Content-Type header に application/json または application/ld+json のいずれかを含め MUST。 ここでは application/ld+json がより具体的であり、 application/json を含意するため望ましい。 デフォルトのシリアライズは JSON-LD 構文による JSON であり、 代替シリアライズはネゴシエート可能であることに注意する。 7.3.2.1 Things APIを参照。

clients が TD の小さなサブセットで集合を取得する必要がある シナリオがある。Search API（7.3.2.3 Search API）は特定の範囲を問い合わせる能力を提供するが、 それは最適でない場合や、開発者にとって使いやすくない場合がある。 server は、 集合を小さなサブセットで返すために pagination をサポートしても MAY。 pagination は以下の規則に 基づかなければならない。

  • limit query parameter が正の整数に設定されている場合、server は、 要求された数以下の TD からなるサブセットで応答しても MAY。
  • 返された集合の サブセットの後にさらに TD がある場合、response は 次のサブセットの URL を持つ next Link header [RFC8288] を含め MUST。 next link は、 同じデータ集合およびその順序を生成するために必要なすべての引数、 特に初回リクエストで与えられた同じ limit 引数、および次のサブセットの先頭に基づく zero-based の offset 引数を含め MUST。 link は、絶対 URL または directory API の base URL に相対的な URL で MUST。 さらに、ordering または session management に必要な追加引数を含めてもよい。
  • すべての paged responses は、集合を指す canonical Link header [RFC8288] を含み、 collection の現在状態を表す etag parameter を含め MUST。 link は絶対 URL または directory API の base URL に相対的な URL であってもよい。 etag 値は、TD collection が TD の ordering に影響する形で 変更されるたびに設定される、revision number、timestamp、または UUID Version 4 であり得る。clients は、collection の paginated retrieval 全体で collection が一貫しているかどうかを知るために etag 値に依存してもよい。たとえば、TD の作成または削除、 あるいは ordering に使用される TD fields の更新は、計算された paging window をずらす可能性がある。
  • collection は、 TD の一意識別子を用いて、Unicode code point order による 昇順でソートされ MUST。

上記の仕様は、JSON-LD array の任意 pagination を可能にするため、 Linked Data Paging [LDP-Paging] のサブセットに従っている。Linked Data Paging の追加部分は、 たとえば client の query preference を尊重するため、 または semantic annotation および alternative navigation links のために 他の link relations を追加するために実装されてもよい。

以下の例は、TD の paginated retrieval の手順を示している。

response の body として TD の配列を送信する代替として、server は、 pagination 情報などの server-side 情報を実データに加えて 含められる、より詳細な payload を送信しても MAY。

代替 pagination 形式は Hydra Advanced Concepts、より具体的には Partial Collection View に着想を得ている。ここでの目的に合わせ、 TD の配列を収めるために members field を使用すると、 listing endpoint では以下のようになる。

どの形式を送信するかを server に伝えるために、 追加の query parameter ?format=array|collection をリクエストに追加できる。 ?format=array はデフォルト parameter であり、明示的に 指定する必要はなく、TD の純粋な配列として server response を返す。 ?format=collection は、 例 9 で説明される形式の server response を返すべきである。

listing 操作は、 7.3.2.4 API 仕様 (Thing Model) の things property として規定されている。

7.3.2.1.6 検証

保存前に TD objects の構文検証を 行うことは、一般的な誤った送信を防ぐために RECOMMENDED。 server は、 TD を検証するために、[wot-thing-description11] で定義される少なくとも Minimal Validation を使用 SHOULD。これには、 WoT Thing Description (1.0) JSON Schema または WoT Thing Description 1.1 JSON Schema の使用、および @context の値に基づいて適切な場合には、 Enriched TDs に対して A. WoT Discovery TD 拡張のための JSON Schema で定義される JSON schema の使用が含まれる。

さまざまなユースケースをサポートするために、追加の検証形式を 追加できる。たとえば、あるユースケースでは、version 値が事前定義された規則に従って初期化および更新されることを保証するために、 入力 TD の stateful validation が必要になる場合がある。

server が TD object の 検証に失敗した場合、エラーを識別し解決するために必要な詳細を client に通知し MUST。 validation error は、 validationErrors と呼ばれる拡張 field を持つ Problem Details [RFC7807] として記述され、その値は field および description fields を持つ objects の配列に設定され MUST。 これは、 機械可読な方法でエラーを表現するために必要である。 Problem Details を使用して 記述されるすべての validation error responses は、UTF-8 でエンコードされ MUST。 エラー報告について一般に すでに述べたように、HTTP リクエストで Accept-Language header field が設定されている場合、 validation error responses はプロアクティブネゴシエーションを使用して 異なる言語で詳細を報告してもよい [RFC7231]。

例 10 は、2 つの validation errors を含む error response の例である。

7.3.2.2 Events API

Notification API は、directory 内で維持される TD の変更について clients に通知するためのものである。 Directories は Notification API を実装しても MAY。

Notification API は、 /events endpoint で clients に events を提供するために、 Server-Sent Events (SSE) [HTML] 仕様に従い MUST。 特に、server は成功したリクエストに対して 200 (OK) status および text/event-stream Content Type で応答する。再接続する clients は、最後の event ID を Last-Event-ID header value として提供することにより、 最後の event から継続してもよい。 server は、 各 event の id field として event ID を提供し、 再接続する clients に対して欠落したすべての events を配信して応答 SHOULD。

このセクションの残りでは、SSE プロトコル上の実装詳細を説明する。 MQTT などの他のプロトコルを使用して notification 機能を実現することは可能であり、 この仕様の将来バージョンで形式化される可能性がある。

Event Types
server は、 directory 内の Thing Descriptions のライフサイクルに帰属する events を、 thing_created、 thing_updated、および thing_deleted event types を使用して生成し MUST。
Event Filtering
API は、clients が必要とする events のみを配信することで リソース消費を減らすために、events の server-side filtering を可能にする。 Client libraries は、client-side で追加の filtering capabilities を 提供してもよい。

server は、 subscription 時に client が指定する event type に基づく event filtering をサポートし MUST。

たとえば、URI Template /events{/type} が与えられた場合:

  • /events/thing_created は、 thing_created 型の events のみを配信するよう server に指示する。
  • /events は、すべての events を配信するよう server に指示する。

clients は、server から events のサブセット（例: thing_created と thing_deleted のみ）を受信するために、 個別に subscribe する必要がある。HTTP/2 を使用する場合、 同じ domain 上の複数の subscriptions（HTTP streams）は、 1 つの connection 上で多重化される。

Event Data

event data は、 event object の JSON シリアライズを含み MUST。 event data object は、 リクエストに応じて Partial TD または完全な TD object である。

  • event data object は、少なくともその event で作成、更新、または削除された TD の識別子を、Partial TD 形式で含め MUST。
  • diff query parameter が true に設定され、event が thing_created 型である場合、server は 完全な TD object を event data として返しても MAY。
  • diff query parameter が true に設定され、event が thing_updated 型である場合、server は JSON Merge Patch [RFC7396] 形式に従って、更新された部分について client に通知しても MAY。 JSON Merge Patch [RFC7396] に 基づく thing_updated event data は、 それが変更されたかどうかにかかわらず、常に TD の識別子を 含め MUST。

    以下の例は、例 12 の TD の更新時にトリガーされる event を示す。

  • diff query parameter は thing_deleted events については無視され MUST。 言い換えれば、 diff が true に設定されている場合でも、 server は thing_deleted events の payload に 追加 properties を含めてはならない。
  • diff query parameter をサポートしていない server が そのような query parameter 付きで要求された場合、 リクエストを拒否すべきである。これは、connection 時にその機能が 存在しないことを clients に通知し、event data attributes の欠落によって 実行時例外が発生することを避けるためである。

Notification API は、 7.3.2.4 API 仕様 (Thing Model) において、以下の 3 つの event affordances として 規定されている。 thingCreated、thingUpdated、および thingDeleted。

注記: SSE Authorization Header

一部の初期 SSE 実装（HTML5 EventSource を含む）は、 初期 HTTP リクエストで custom headers を設定することを許可しない。 Authorization header はいくつかの OAuth2 flows で必要であり、 それを query parameter として渡すことは 推奨されない。Authorization header の設定を可能にするブラウザー用 polyfills および modern libraries が存在する。

7.3.2.4 API 仕様 (Thing Model)

Thing Description Directories の API のテンプレートを、ここでは Thing Model として示す。 Thing Model は（注記されている箇所を除き）規範的であるが、 Thing Description Directory を実装または利用するための唯一の参照と 見なすべきではない。7.3.2 Directory Service API に示される仕様も参照されたい。

この Thing Model に示される searchJSONPath および searchXPath affordances は規範的ではなく、参考情報としてのみ 提供されている。

contentType は、WoT TD 1.1 仕様 [wot-thing-description11] により、ExpectedResponse class の instances （すなわち、form 内の key response に対応する JSON object） に対して、HTTP response の body が空であると想定される場合であっても 必須であることに注意する。この場合、以下の TM から生成される TD が 有効であることを保証するために、application/x-empty を 使用できる。 

{
    "@context": [
        "https://www.w3.org/2022/wot/td/v1.1",
        "https://www.w3.org/2022/wot/discovery"
    ],
    "@type": [
        "tm:ThingModel",
        "ThingDirectory"
    ],
    "title": "Thing Description Directory (TDD) Thing Model",
    "version": {
        "model": "1.0.0"
    },
    "base": "{{DIRECTORY_BASE_URL}}",
    "tm:optional": [
        "/actions/createThing",
        "/actions/createAnonymousThing",
        "/actions/retrieveThing",
        "/actions/updateThing",
        "/actions/partiallyUpdateThing",
        "/actions/deleteThing",
        "/actions/searchJSONPath",
        "/actions/searchXPath",
        "/actions/searchSPARQL",
        "/events/thingCreated",
        "/events/thingUpdated",
        "/events/thingDeleted"
    ],
    "properties": {
        "things": {
            "description": "Retrieve all Thing Descriptions",
            "uriVariables": {
                "offset": {
                    "title": "Number of TDs to skip before the page",
                    "type": "number",
                    "default": 0
                },
                "limit": {
                    "title": "Number of TDs in a page",
                    "type": "number"
                },
                "format": {
                    "title": "Payload format",
                    "type": "string",
                    "enum": [
                        "array",
                        "collection"
                    ],
                    "default": "array"
                }
            },
            "forms": [
                {
                    "href": "/things{?offset,limit,format}",
                    "htv:methodName": "GET",
                    "response": {
                        "description": "Success response",
                        "htv:statusCodeValue": 200,
                        "contentType": "application/ld+json",
                        "htv:headers": [
                            {
                                "htv:fieldName": "Link"
                            }
                        ]
                    },
                    "additionalResponses": [
                        {
                            "description": "Invalid query arguments",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 400
                        }
                    ]
                }
            ]
        }
    },
    "actions": {
        "createThing": {
            "description": "Create a Thing Description",
            "uriVariables": {
                "id": {
                    "@type": "ThingID",
                    "title": "Thing Description ID",
                    "type": "string",
                    "format": "iri-reference"
                }
            },
            "input": {
                "description": "The schema is implied by the content type",
                "type": "object"
            },
            "forms": [
                {
                    "href": "/things/{id}",
                    "htv:methodName": "PUT",
                    "contentType": "application/td+json",
                    "response": {
                        "description": "Success response",
                        "htv:statusCodeValue": 201
                    },
                    "additionalResponses": [
                        {
                            "description": "Invalid serialization or TD",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 400
                        }
                    ]
                }
            ]
        },
        "createAnonymousThing": {
            "description": "Create an anonymous Thing Description",
            "input": {
                "description": "The schema is implied by the content type",
                "type": "object"
            },
            "forms": [
                {
                    "href": "/things",
                    "htv:methodName": "POST",
                    "contentType": "application/td+json",
                    "response": {
                        "description": "Success response including the system-generated URI",
                        "htv:headers": [
                            {
                                "description": "System-generated URI",
                                "htv:fieldName": "Location"
                            }
                        ],
                        "htv:statusCodeValue": 201
                    },
                    "additionalResponses": [
                        {
                            "description": "Invalid serialization or TD",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 400
                        }
                    ]
                }
            ]
        },
        "retrieveThing": {
            "description": "Retrieve a Thing Description",
            "uriVariables": {
                "id": {
                    "@type": "ThingID",
                    "title": "Thing Description ID",
                    "type": "string",
                    "format": "iri-reference"
                }
            },
            "output": {
                "description": "The schema is implied by the content type",
                "type": "object"
            },
            "safe": true,
            "idempotent": true,
            "forms": [
                {
                    "href": "/things/{id}",
                    "htv:methodName": "GET",
                    "response": {
                        "description": "Success response",
                        "htv:statusCodeValue": 200,
                        "contentType": "application/td+json"
                    },
                    "additionalResponses": [
                        {
                            "description": "TD with the given id not found",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 404
                        }
                    ]
                }
            ]
        },
        "updateThing": {
            "description": "Update a Thing Description",
            "uriVariables": {
                "id": {
                    "@type": "ThingID",
                    "title": "Thing Description ID",
                    "type": "string",
                    "format": "iri-reference"
                }
            },
            "input": {
                "description": "The schema is implied by the content type",
                "type": "object"
            },
            "forms": [
                {
                    "href": "/things/{id}",
                    "htv:methodName": "PUT",
                    "contentType": "application/td+json",
                    "response": {
                        "description": "Success response",
                        "htv:statusCodeValue": 204
                    },
                    "additionalResponses": [
                        {
                            "description": "Invalid serialization or TD",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 400
                        }
                    ]
                }
            ]
        },
        "partiallyUpdateThing": {
            "description": "Partially update a Thing Description",
            "uriVariables": {
                "id": {
                    "@type": "ThingID",
                    "title": "Thing Description ID",
                    "type": "string",
                    "format": "iri-reference"
                }
            },
            "input": {
                "description": "The schema is implied by the content type",
                "type": "object"
            },
            "forms": [
                {
                    "href": "/things/{id}",
                    "htv:methodName": "PATCH",
                    "contentType": "application/merge-patch+json",
                    "response": {
                        "description": "Success response",
                        "htv:statusCodeValue": 204
                    },
                    "additionalResponses": [
                        {
                            "description": "Invalid serialization or TD",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 400
                        },
                        {
                            "description": "TD with the given id not found",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 404
                        }
                    ]
                }
            ]
        },
        "deleteThing": {
            "description": "Delete a Thing Description",
            "uriVariables": {
                "id": {
                    "@type": "ThingID",
                    "title": "Thing Description ID",
                    "type": "string",
                    "format": "iri-reference"
                }
            },
            "forms": [
                {
                    "href": "/things/{id}",
                    "htv:methodName": "DELETE",
                    "response": {
                        "description": "Success response",
                        "htv:statusCodeValue": 204
                    },
                    "additionalResponses": [
                        {
                            "description": "TD with the given id not found",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 404
                        }
                    ]
                }
            ]
        },
        "searchJSONPath": {
            "description": "JSONPath syntactic search.  This affordance is not normative and is provided for information only.",
            "uriVariables": {
                "query": {
                    "title": "A valid JSONPath expression",
                    "type": "string"
                }
            },
            "output": {
                "description": "The schema depends on the given query",
                "type": "object"
            },
            "safe": true,
            "idempotent": true,
            "forms": [
                {
                    "href": "/search/jsonpath?query={query}",
                    "htv:methodName": "GET",
                    "response": {
                        "description": "Success response",
                        "contentType": "application/json",
                        "htv:statusCodeValue": 200
                    },
                    "additionalResponses": [
                        {
                            "description": "JSONPath expression not provided or contains syntax errors",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 400
                        }
                    ]
                }
            ]
        },
        "searchXPath": {
            "description": "XPath syntactic search.  This affordance is not normative and is provided for information only.",
            "uriVariables": {
                "query": {
                    "title": "A valid XPath expression",
                    "type": "string"
                }
            },
            "output": {
                "description": "The schema depends on the given query",
                "type": "object"
            },
            "safe": true,
            "idempotent": true,
            "forms": [
                {
                    "href": "/search/xpath?query={query}",
                    "htv:methodName": "GET",
                    "response": {
                        "description": "Success response",
                        "contentType": "application/json",
                        "htv:statusCodeValue": 200
                    },
                    "additionalResponses": [
                        {
                            "description": "XPath expression not provided or contains syntax errors",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 400
                        }
                    ]
                }
            ]
        },
        "searchSPARQL": {
            "description": "SPARQL semantic search",
            "uriVariables": {
                "query": {
                    "title": "A valid SPARQL 1.1. query",
                    "type": "string"
                }
            },
            "output": {
                "description": "The schema depends on the given query",
                "type": "object"
            },
            "safe": true,
            "idempotent": true,
            "forms": [
                {
                    "href": "/search/sparql?query={query}",
                    "htv:methodName": "GET",
                    "response": {
                        "description": "Success response",
                        "contentType": "application/json",
                        "htv:statusCodeValue": 200
                    },
                    "additionalResponses": [
                        {
                            "description": "SPARQL query not provided or contains syntax errors",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 400
                        }
                    ]
                },
                {
                    "href": "/search/sparql",
                    "htv:methodName": "POST",
                    "response": {
                        "description": "Success response",
                        "contentType": "application/json",
                        "htv:statusCodeValue": 200
                    },
                    "additionalResponses": [
                        {
                            "description": "SPARQL query not provided or contains syntax errors",
                            "contentType": "application/problem+json",
                            "htv:statusCodeValue": 400
                        }
                    ]
                }
            ]
        }
    },
    "events": {
        "thingCreated": {
            "description": "Registration of Thing Descriptions inside the directory",
            "uriVariables": {
                "diff": {
                    "description": "Receive the full created TD as event data",
                    "type": "boolean"
                }
            },
            "data": {
                "title": "Partial/Full TD",
                "type": "object"
            },
            "forms": [
                {
                    "op": "subscribeevent",
                    "href": "/events/thing_created{?diff}",
                    "subprotocol": "sse",
                    "htv:headers": [
                        {
                            "description": "ID of the last event for reconnection",
                            "htv:fieldName": "Last-Event-ID"
                        }
                    ],
                    "response": {
                        "contentType": "text/event-stream"
                    }
                }
            ]
        },
        "thingUpdated": {
            "description": "Updates to Thing Descriptions within the directory",
            "uriVariables": {
                "diff": {
                    "description": "Include TD changes inside event data",
                    "type": "boolean"
                }
            },
            "data": {
                "title": "Partial TD",
                "type": "object",
                "contentMediaType": "application/merge-patch+json"
            },
            "forms": [
                {
                    "op": "subscribeevent",
                    "href": "/events/thing_updated{?diff}",
                    "subprotocol": "sse",
                    "htv:headers": [
                        {
                            "description": "ID of the last event for reconnection",
                            "htv:fieldName": "Last-Event-ID"
                        }
                    ],
                    "response": {
                        "contentType": "text/event-stream"
                    }
                }
            ]
        },
        "thingDeleted": {
            "description": "Deletion of Thing Descriptions from the directory",
            "data": {
                "title": "Partial TD",
                "type": "object"
            },
            "forms": [
                {
                    "op": "subscribeevent",
                    "href": "/events/thing_deleted",
                    "subprotocol": "sse",
                    "htv:headers": [
                        {
                            "description": "ID of the last event for reconnection",
                            "htv:fieldName": "Last-Event-ID"
                        }
                    ],
                    "response": {
                        "contentType": "text/event-stream"
                    }
                }
            ]
        }
    }
}

8. セキュリティに関する考慮事項

セキュリティは、すべての WoT building blocks および WoT 実装において 考慮する必要がある横断的な課題である。この章では、具体的な WoT discovery 実装のセキュリティを維持するために役立つ、いくつかの一般的な課題と ガイドラインを要約する。セキュリティおよびプライバシーの課題の、より詳細で 完全な分析については、WoT Security and Privacy Guidelines 仕様 [WOT-SECURITY] を参照。WoT Thing および WoT TDDs も Web サービスであり、 Web サービスのベストプラクティスを用いて実装されるべきである。 以下の具体的なセキュリティ考慮事項に加えて、OWASP Top 10 [OWASP-Top-10] などのガイドで 議論されているセキュリティリスクおよび緩和策を評価し、該当する場合には 対処すべきである。

8.1 サービス拒否

directory サービスの特定の機能、特に検索クエリは、実行に多大な リソースを必要とする場合があり、この事実は WoT Thing Description Directory サービスに対するサービス拒否 (DoS) 攻撃を開始するために 利用される可能性がある。そのような攻撃では、WoT Directory が攻撃者からの リクエストによって過負荷になり、他のリクエストを処理できなくなる。

緩和策:
  • WoT Thing Description Directory 実装は、 同一 requestor からの単位時間あたりのクエリ数を制限すべきである。
  • WoT Thing Description Directory 実装は、 クエリの複雑さ（たとえば、クエリ式の総長またはその深さ）を 制限すべきである。
  • WoT Thing Description Directory 実装は、 一定の最大（実装で構成可能な）時間を超えて実行されるクエリを 中止するために watchdog timer を使用すべきである。

8.2 増幅および分散型 サービス拒否

WoT Discovery メカニズムの要素を使用して、他のターゲットに対する 分散型サービス拒否 (DDoS) 攻撃を開始できる可能性もある。 そのような攻撃では、WoT Discovery サービス自体はターゲットではない。 代わりに、WoT Discovery サービスのある側面が悪用され、 実際のターゲットである第三者を過負荷にする増幅されたネットワークトラフィックが 生成される。そのような攻撃には 2 つの要件がある。第一に、トラフィックを 第三者へリダイレクトできること、第二に、攻撃者からのネットワークトラフィックを 増幅するために悪用できる intermediary service である。 ネットワークトラフィックのリダイレクトは、保護されていない CoAP などの 一部のプロトコルにおいて、headers 内の source 情報を変更することで可能である。 増幅は、3 つの乗法的要因を利用することで可能になる。 request と response payload sizes の比率、CoAP のようなプロトコルにおける "observe" の使用（1 つの request に対して複数の結果を与え得る）、 および multicast の使用（1 つの request に対して複数の servers が応答できる）。 認証をサポートしないサービスは、このような間接攻撃の理想的な intermediaries である。残念ながら、WoT Discovery の Introduction メカニズムは、discovery を開始するためのオープンアクセスメカニズムを 提供することを目的としており、この目的で悪用される可能性がある。

緩和策:
  • Introduction メカニズムの オープンな実装は、observe または類似の拡張結果 subprotocols をサポート SHOULD NOT。
  • Introduction メカニズムのオープンな実装は、 それがプロトコルによって絶対に必要とされる場合を除き、 multicast requests に応答すべきではない。multicast のサポートが 必要な場合、CoAP の場合には [AMPLIFICATION-ATTACKS] でなされた観察が関連する。なぜなら、discovery 中に multicast request に応答する可能性がある servers の数は、一般に事前には 分からないためである。
  • responses のサイズを最小限に制限する。public internet 上 （保護されたローカルネットワークの外側）での Introduction に対する responses の総サイズは、request の総サイズの 3 倍未満であるべきであり、 これには error responses も含めるべきである。これは [RFC9000] (QUIC) および HTTP/3 における DDOS 緩和策と一致する。 ここで "total size" には、プロトコル自体が必要とする headers、 およびより大きな response を許容するための request 内の padding が 含まれる。
  • Introductions は、特定の request source に対する responses を rate-limit すべきである。
  • ファイアウォール背後の segmented network（例: LAN）上の Introduction メカニズムは、 その LAN の外部からのものと見られる requests に応答 SHOULD NOT。
特に懸念されるのは、CoRE-RD や DID など、複数の結果を返すことができる Introduction メカニズムである。 上記の他の緩和策が十分でない場合、そのような Introduction メカニズムにも authentication/authorization を使用する必要があるかもしれない。 推奨される代替手段は、そのような Introductions からの複数の結果を WoT TDD に移し、その後、適切な authentication および authorization 措置によって保護できるようにすることである。その場合、オープンな Introduction メカニズムは 1 つの結果、すなわち TDD の URL だけを 返せばよい。open internet から見える Introduction メカニズムは、 上記の緩和策の実装に特に注意すべきであり、複数の URL を返すことができる Introduction メカニズムを完全に避けることも検討すべきである。

8.3 LAN における自己発見

LAN 上では、certificates および browsers が HTTPS のために TLS を 適切に設定できない場合がある。これは、browsers が公開可視 URL を 指す certificates を期待するためである。LAN 内で HTTP を使用することは 一般的な慣行だが、自己記述と組み合わせると、WoT Things が実質的に private LAN へアクセスできる全員に TDs を可視化することを意味する。 HTTP passwords などのセキュリティメカニズムが使用されたとしても、 transport security なしでは、それらは有効ではない （traffic analyser によって容易に発見され得る）。

緩和策:

LAN 上では、可能であれば PSK（pre-shared keys）を使用 SHOULD。これは [RFC4279] の ciphersuites のいずれかを意味する。 これには、Things が共通の security domain において PSK を 割り当てられていることが必要であり、通常は onboarding process に 従うことで行われる。残念ながら、具体的な onboarding processes は 現時点では WoT 仕様の範囲外である。

代替手段として、local network security （すなわち WEP）に依存することがある。これはセキュリティまたは プライバシーの観点から最善の解決策ではないが、文脈によっては許容され得る。 ただし、network にアクセスできるすべての users は、自己記述を介して すべての TDs にアクセスできることに注意する。Things を transport security と authentication および authorization によって 個別に保護できない場合、別個の network、すなわち代替 SSID を持つものを設定し、IoT devices 専用に使用 SHOULD。 segmented network を使用すると、 その network に接続された IoT devices の集合へアクセスする必要がある人に この network の password を配布する必要性が減る。

もう 1 つの代替手段は、cloud 上の reverse proxy service を 使用することである。IoT device が cloud にアクセスできる場合、 proxy server は public URL を持つことができ、初期接続は HTTPS を使用し、 その後 websocket 上で secure tunnel を開くことができるため、 セキュアな設定を実現できる。proxy はさらに secure endpoint を再公開し、 場合によっては authentication を追加できる。このアプローチの欠点には、 外部 cloud service への依存、および外部 access point を公開する必要性 （それ自体がセキュリティリスクである）が含まれる。最初の欠点は、 proxy service をローカルにホストし、local server が ISP を通じて 接続されている場合には dynamic DNS などを使用して public URL を 公開することで対処できる。Things を transport security と authentication および authorization によって個別に保護できない場合、 適切な access controls を提供できる proxy を介して一般アクセスに 利用可能にしてもよい。

9. プライバシーに関する考慮事項

プライバシーは、すべての WoT building blocks および WoT 実装において 考慮する必要がある横断的な課題である。この章では、具体的な WoT discovery 実装のプライバシーを維持するために役立つ、いくつかの一般的な課題と ガイドラインを要約する。セキュリティおよびプライバシーの課題の、より詳細で 完全な分析については、WoT Security and Privacy Guidelines 仕様 [WOT-SECURITY] を参照。

WoT discovery アーキテクチャは、2 フェーズアプローチを使用し、 metadata release の前に authorization を強制できるようにすることで、 既存の discovery schemes のプライバシーに依存することを避けるように 設計されている。しかし、いくつかのプライバシーリスクはなお存在する。 これらを可能な緩和策とともに以下に列挙する。特にプライバシーへのリスクの レベルは、ユースケース、および個人に関連する情報がその個人のプライバシー上の 希望と一致しない方法で配布されるリスクがあるかどうかに依存する。 プライバシーについて、次の広いユースケースシナリオの分類を区別する。

Institutional
metadata を生成する Things と、その metadata の Consumers の両方が、 institution または institution の代表者によって所有および管理されている。 例: control system が品質を評価するために assembly line の状態へアクセスする factory automation。
Service
metadata を生成する Things は institution または institution の代表者によって 所有および管理されている一方、consumers は個人である。 例: electric vehicle の運転者が充電状態を確認するために charge station の TD へアクセスする。
Personal
metadata を生成する Things と、その metadata の Consumers の両方が、 同じ個人によって所有および管理されている。例: 自宅設置の solar panels から electric car を充電する smart home control system であり、 home と car はどちらも同じ人物が所有している。
Personal Peer-to-Peer
metadata を生成する Things と、その metadata の Consumers が 異なる個人によって所有および管理されている。例: guest の electric car を 自宅設置の solar panels から充電する smart home control system。
Institutional Peer-to-Peer
metadata を生成する Things と、その metadata の Consumers が 異なる institutions によって所有および管理されている。 例: utility が factory に供給される電力を提供および管理し、factory が on-demand power usage reductions を交渉するためのインターフェイスを utility に提供する。
Client
metadata を生成する Things は個人によって所有および管理されている一方、 consumers は institution または institution の代表者である。 例: personal electric vehicle が、public charging station が vehicle の charge status を評価できるようにインターフェイスを公開する。

これらすべては実際にはプライバシーリスクを伴う。factory automation の場合でさえ、 従業員の performance に関するデータが取得される可能性があり、 それを適切に管理しなければならない可能性がある。

以下では、"tracking" に頻繁に言及する。この用語は、location tracking および behavioral profiling を含む複数のプライバシーリスクを 含む。一般に、GDPR [GDPR-Defs] 第 4 条で示される "profiling" の定義は、この文書で使用する "tracking" と同等であると見なす。

これらの定義および分類を確立したうえで、ここからは具体的な プライバシーリスクと潜在的な緩和策について議論する。

9.1 位置追跡および プロファイリング

discovery service は、本人の同意なしに、その人のおおよその位置を 判断できるようにする可能性がある。このリスクは、回避または緩和可能な いくつかの特定の状況で発生する。これは DHCP や DNS などの他の network services がもたらすリスクにも類似している。

このリスクが発生するには、まず、必要な medical device や vehicle など、 人の位置と確実に関連付けられる IoT device が存在しなければならない。 このリスクは personal use cases にのみ適用され、institutional ones には 適用されないことに注意する。第二に、その device は最も近い directory service に自動登録するよう構成されていなければならない。この場合、 device の位置は directory service の network range から推測でき、 その人の位置は device の位置から推測できる。

これにはいくつかの変種がある。

Location tracking だけが profiling risk ではない。 一般に "profiling" には、economic status、health、preferences、 interests、reliability、および behavior など、人に関する情報を評価するために 使用されるあらゆるメカニズムが含まれる。TD 内の metadata の一部は、 記述される Thing を人と関連付けられる場合、この種の情報を推測するために 使用され得る。以下の緩和策の一部は、このより一般的な profiling の定義にも 適用できる。

これらのリスクの一部は類似サービスと共有される。たとえば、 DCHP は local network 上で IP addresses のリクエストに自動応答し、 devices は通常、このプロセスの一部として identifier（MAC address）を 提供し、DHCP server は registry を維持する。理論上、たとえば cafe の DHCP server にアクセスできる者は、この情報を使用して誰かの phone を追跡し、 その位置を推測できる。

緩和策:
これらのリスクを緩和するための選択肢はいくつかある。
  • location tracking および他の forms of profiling を避けるため、人に関連付けられた WoT Thing は public directories への登録を無効化してもよい。 登録は personal directories、たとえば home gateway では依然として可能だが、 user は他の場所での登録を無効化できる。これには機能が失われるという 欠点がある。すなわち、personal devices は public locations で発見できない。 これは、internet-accessible private discovery services を持つことで 対処できる。たとえば、user の home gateway は internet-accessible service を提供できるが、access control により authorized users への 使用を制限する。
  • location tracking および他の forms of profiling を避けるため、人に関連付けられた WoT Thing は public directories に登録する際に anonymous TDs を使用すべきである。 場合によっては、anonymous TDs を使用し、TDD に送信する TDs から 明示的な IDs を省略することが可能である。この場合、TDD はその TDD 内でのみ 有効な local ID を生成する。ただし、これは update を複雑にする。 client は TDD によって割り当てられた local ID を記憶する必要があるためである。 Anonymous TDs は、fingerprinting など他の手段による tracking を 防ぐものでもない。
  • location tracking および他の forms of profiling を避けるため、人に関連付けられた WoT Thing は 定期的に新しい IDs を生成してもよい。固定 IDs を使用すると、 devices の追跡が非常に容易になる。この問題は DHCP における MAC address でも 発生し、類似の部分的緩和策がある。すなわち、定期的に新しい random IDs を 生成することである。ただし、いくつかの課題がある。第一に、TD 内の他の identification information を隠す必要がある。たとえば、API security のために CSPs によって発行された client IDs は、容易に変更できない場合には TDs から省略すべきである。第二に、device が新しい ID を生成する場合でも、 user は discovery によって device を見つけるために現在の ID を知る必要が あるかもしれない。ただし、これは現在時刻の関数である deterministic cryptographic generator を使用して新しい IDs を生成することで実現できる。 ただし、IDs の再生成だけでは tracking を不可能にするわけではない。 TD が fingerprinted される可能性があるためである。また、ID の更新は directory service の owner に観察される可能性があり、その owner は 更新された ID を追跡および記録できる。TD が削除され再挿入された場合でさえ、 その関連付けを推測できる可能性がある。ただし、これは DHCP と MAC addresses の rotation の状況と正確に並行している。一般に、それでも TD が提供される service または person ごとに少なくとも新しい identifiers を生成することは、 異なる場所および時刻での registration events を関連付けにくくする。 また、local network または hub から unregister し、新しいものに登録する など、構成に大きな変更があった場合（通常、所有権の変更を示す）に 新しい identifiers を生成することも賢明である。追跡を緩和するために 定期的に更新が必要になる可能性がある long-lived IP addresses にも 関連する課題がある。ipv6 [RFC8981] の文脈ではこれが議論されている。最後に、immutable identifiers を必要とする devices、たとえばそのような jurisdictions における medical devices には 問題がある。これは [wot-thing-description11] で議論されているが、要約すると、そのような immutable identifiers が TD 内ではなく、authentication を必要とする affordances などを介した protected properties としてのみ利用可能にされ、TD identifier 自体 （使用される場合）は immutable identifier から独立していて、 mutable にできるならば、この問題を避けられる。
  • negative location inferencing のリスクを減らすため、private directories へのアクセスは access controls を使用して制限 SHOULD。 attacker が service にアクセスできない場合、location を推測するための情報を 取得できない。guests に提供される access rights（例: Peer-to-Peer Personal scenarios）は、適切に時間制限されるべきである。 他の場合には長い time-to-live 値の使用が適切なこともある。 さらに、TDs は変更があった場合にのみ directory で更新されるべきである。 たとえば、car の TD は、新しい services を提供する新しい car firmware が 利用可能になった場合にのみ更新され、time-to-live は 1 か月 （ほとんどの不在期間をカバーする）に設定されるかもしれない。
  • 明示的な location information が利用可能である場合、それが TD に保存されているか property として利用可能であるかにかかわらず、TD および/または device へのアクセスを、directories を含む trusted partners とのみ 共有するよう追加の注意を払う SHOULD。 TD を public directory と 共有しなければならない場合、location information は削除されてもよい。

9.2 クエリ追跡

directory service は、個人による queries を記録および追跡し、 提供された authenticated identity によってその個人を識別する可能性がある。 その場合、個人に関連付けられた queries の集合は、その個人を profile するために使用され得る。また、特定の queries は個人に関する personal information を明らかにする場合もある。

緩和策:

public directory にアクセスする場合、他の public web service と同様に、 users および implementations は anonymous identity provider を使用すべきである。 特に OAuth2 は、特定の個人を識別せず、別の場所で証明された access rights を 主張するだけの tokens を提供できる。

10. パフォーマンスに関する考慮事項

このセクションは非規範的である。

10.1 インクリメンタル転送

TD objects は サイズに制約されていない。それらは個別または集合的に処理および転送するには 高価になる可能性がある。単一の TD または TDs の一覧は、制約のある device が、 自身の TD を consumers に提供したり、directory に送信したり、他の TDs を 消費したりするには大きすぎる場合がある。そのような要件を満たすため、 servers は protocol-specific mechanisms を使用した payloads の インクリメンタル転送をサポートすべきである。

ほとんどの HTTP servers および clients は、chunks で転送されるデータを 自動的に処理する。memory-constrained clients は、 de-serialization のために object 全体を memory に読み込もうとするのではなく、 受信データをインクリメンタルに消費することを検討すべきである。

11. IANA に関する考慮事項

11.1 Well-Known URI 登録

IANA は、[RFC8615] で 定義される Well-Known URI に、以下の値を割り当てるよう求められる。

11.2 サービス名登録

IANA は、[RFC6335] で定義される Service Name and Transport Protocol Port Number Registry に、 以下の値を割り当てるよう求められる。

11.3 CoRE リソースタイプ 登録

IANA は、[RFC6690] で定義される Constrained Restful Environments (CoRE) Parameters registry の Resource Type (rt=) Link Target Attribute Values sub-registry に、以下の値を割り当てるよう求められる。

値 説明 参照
wot.thing Thing の Thing Description 6.4 CoRE Link Format および CoRE Resource Directory
wot.directory Thing Description Directory の Thing Description 6.4 CoRE Link Format および CoRE Resource Directory

12. その他の名前登録に関する 考慮事項

12.1 DID サービス名 登録

DID Documents で使用される Service Type について、以下の値が割り当てられる。

値 説明 参照
WotThing Thing の Thing Description 6.5 DID 文書
WotDirectory Thing Description Directory の Thing Description 6.5 DID 文書

A. WoT Discovery TD 拡張のための JSON Schema

以下の JSON Schema は、 Enriched TDs で使用される拡張を規定する。これは、 7.3.2.1.6 検証で規定されるとおり、 TDD によって TDs を検証するために使用できる。 
{
  "title": "WoT Discovery TD-extensions Schema - 21 May 2021",
  "description": "JSON Schema for validating TD instances with WoT Discovery extensions",
  "$schema ": "https://json-schema.org/draft/2019-09/schema#",
  "type": "object",
  "properties": {
    "registration": {
      "type": "object",
      "properties": {
        "created": {
          "type": "string",
          "format": "date-time"
        },
        "expires": {
          "type": "string",
          "format": "date-time"
        },
        "retrieved": {
          "type": "string",
          "format": "date-time"
        },
        "modified": {
          "type": "string",
          "format": "date-time"
        },
        "ttl": {
          "type": "number"
        }
      }
    }
  }
}

B. 最近の仕様変更

B.1 2023年7月11日 Proposed Recommendation からの変更

B.2 2023年1月19日 Candidate Recommendation からの変更

B.3 2022年8月10日 Working Draft からの変更

B.4 2021年6月2日 Working Draft からの変更

B.5 2020年11月24日 First Public Working Draft からの変更

C. 謝辞

IoT における既存の discovery mechannisms に関する調査作業について、Arne Broering、Soumya Kanti Datta、 および Christian Bonnet に特別な謝意を表する。この文書への貢献について、 Philipp Blum、Victor Charpeney、Ben Francis、Christian Glomb、Daniel Peintner、 Christine Perey、Jan Romann、および Elodie Thieblin に 特別な謝意を表する。

W3C staff、特に Kazuyuki Ashimura および Dominique Hazael-Massieux、ならびに この文書の改善につながる支援、技術的な input および suggestions を 提供した W3C Web of Things Interest Group (WoT IG) および Working Group (WoT WG) のすべての active Participants に深く感謝する。

D. 参考文献

D.1 規範的参考文献

[AMPLIFICATION-ATTACKS]
Amplification Attacks Using the Constrained Application Protocol (CoAP). John Preuß Mattsson; Göran Selander; Christian Amsüss. IETF. DRAFT. URL: https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-amplification-attacks
[DID-CORE]
Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 19 July 2022. W3C Recommendation. URL: https://www.w3.org/TR/did-core/
[did-spec-registries]
DID Specification Registries. Orie Steele; Manu Sporny. W3C. 11 September 2023. W3C Working Group Note. URL: https://www.w3.org/TR/did-spec-registries/
[Discovery-Categorization-IoT]
A Categorization of Discovery Technologies for the Internet of Things. Arne Broering; Soumya Kanti Datta; Christian Bonnet. Association of Computing Machinery (ACM): IoT'16 Proceedings. 7-9 November 2016. URL: https://dl.acm.org/doi/10.1145/2991561.2991570
[GDPR-Defs]
General Data Protection Regulation (GDPR) Article 4 - Definitions. European Union (EU) and the European Economic Area (EEA). URL: https://gdpr-info.eu/art-4-gdpr/
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[JSON-LD11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/
[OWASP-Top-10]
OWASP Top Ten. OWASP. URL: https://owasp.org/www-project-top-ten/
[RFC1738]
Uniform Resource Locators (URL). T. Berners-Lee; L. Masinter; M. McCahill. IETF. December 1994. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc1738
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3339]
Date and Time on the Internet: Timestamps. G. Klyne; C. Newman. IETF. July 2002. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3339
[RFC4122]
A Universally Unique IDentifier (UUID) URN Namespace. P. Leach; M. Mealling; R. Salz. IETF. July 2005. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc4122
[RFC4279]
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). P. Eronen, Ed.; H. Tschofenig, Ed.. IETF. December 2005. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc4279
[RFC6335]
Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry. M. Cotton; L. Eggert; J. Touch; M. Westerlund; S. Cheshire. IETF. August 2011. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc6335
[RFC6690]
Constrained RESTful Environments (CoRE) Link Format. Z. Shelby. IETF. August 2012. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6690
[RFC6762]
Multicast DNS. S. Cheshire; M. Krochmal. IETF. February 2013. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6762
[RFC6763]
DNS-Based Service Discovery. S. Cheshire; M. Krochmal. IETF. February 2013. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6763
[RFC7231]
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[RFC7396]
JSON Merge Patch. P. Hoffman; J. Snell. IETF. October 2014. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7396
[RFC7595]
Guidelines and Registration Procedures for URI Schemes. D. Thaler, Ed.; T. Hansen; T. Hardie. IETF. June 2015. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc7595
[RFC7807]
Problem Details for HTTP APIs. M. Nottingham; E. Wilde. IETF. March 2016. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7807
[RFC7959]
Block-Wise Transfers in the Constrained Application Protocol (CoAP). C. Bormann; Z. Shelby, Ed.. IETF. August 2016. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7959
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8288]
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
[RFC8615]
Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. IETF. May 2019. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8615
[RFC8981]
Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6. F. Gont; S. Krishnan; T. Narten; R. Draves. IETF. February 2021. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8981
[RFC9000]
QUIC: A UDP-Based Multiplexed and Secure Transport. J. Iyengar, Ed.; M. Thomson, Ed.. IETF. May 2021. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9000
[RFC9176]
Constrained RESTful Environments (CoRE) Resource Directory. C. Amsüss, Ed.; Z. Shelby; M. Koster; C. Bormann; P. van der Stok. IETF. April 2022. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9176
[SPARQL11-OVERVIEW]
SPARQL 1.1 Overview. The W3C SPARQL Working Group. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-overview/
[wot-architecture11]
Web of Things (WoT) Architecture 1.1. Michael Lagally; Ryuichi Matsukura; Kunihiko Toumura; Michael McCool. W3C. 5 December 2023. W3C Recommendation. URL: https://www.w3.org/TR/wot-architecture11/
[wot-thing-description11]
Web of Things (WoT) Thing Description 1.1. Sebastian Käbisch; Michael McCool; Ege Korkan. W3C. 5 December 2023. W3C Recommendation. URL: https://www.w3.org/TR/wot-thing-description11/
[wot-usecases]
Web of Things (WoT): Use Cases. Michael Lagally; Michael McCool; Ryuichi Matsukura; Tomoaki Mizushima. W3C. 15 October 2020. Editor's Draft. URL: https://w3c.github.io/wot-usecases/
[xpath-31]
XML Path Language (XPath) 3.1. Jonathan Robie; Michael Dyck; Josh Spiegel. W3C. 21 March 2017. W3C Recommendation. URL: https://www.w3.org/TR/xpath-31/

D.2 参考情報文献

[JSONPATH]
JSONPath: Query expressions for JSON. Stefan Gössner; Glyn Normington; Carsten Bormann. IETF. DRAFT. URL: https://datatracker.ietf.org/doc/html/draft-ietf-jsonpath-base
[LDP-Paging]
Linked Data Platform Paging 1.0. Steve Speicher; John Arwe; Ashok Malhotra. W3C. 30 June 2015. W3C Working Group Note. URL: https://www.w3.org/TR/ldp-paging/
[REST-IOT]
RESTful Design for Internet of Things Systems. Ari Keranen; Matthias Kovatsch; Klaus Hartke. IETF. 11 May 2020. URL: https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-rest-iot-06
[RFC7230]
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
[RFC7540]
Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. May 2015. Proposed Standard. URL: https://httpwg.org/specs/rfc7540.html
[RFC8323]
CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. C. Bormann; S. Lemay; H. Tschofenig; K. Hartke; B. Silverajan; B. Raymor, Ed.. IETF. February 2018. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8323
[WOT-SECURITY]
Web of Things (WoT) Security and Privacy Guidelines. Elena Reshetova; Michael McCool. W3C. 6 November 2019. W3C Working Group Note. URL: https://www.w3.org/TR/wot-security/