Overview（概要）

本プロトコルはODS-RAMにおけるモニタリング機能を定義する。 モニタリング機能はデータトランザクションの稼働ステータスを継続的に把握し、異常や障害を早期に検知する機能を提供する。本機能はロギング機能を利用して収集及び集約したデータに基づき、リアルタイムの状態把握、システムの可視化、及び異常の早期検知を可能にする。

Abstract Normative Specification（抽象仕様）

• shall: ロギング機能で収集されたデータからメトリクスを算出する機能を提供しなければならない。

  • Rationale: 各種状況の適切な監視を可能にするため

• should: メトリクスの可視化を目的としたダッシュボードを提供することを原則とする。

  • Rationale: 状態の把握と利便性を向上させるため

• may: メトリクスがユーザ指定の条件を満たした際に、ユーザへの通知やシステムへの介入を行う機能を提供してもよい。

本プロトコルに必要な概念は以下である。

モニタリングの対象はOpen Dataspacesを構成する各モジュールである。 本モニタリング機能の主な対象は以下である。Open Dataspacesが機微なデータを扱う点から、一般的なデータの永続化機能に加えて証跡及びトレース情報を対象とする。

• 連携サービス・APIの通信状況: システムを通過する通信データおよびその通信履歴に基づき、トラフィック量、エラー率、レスポンス時間などを監視する。また各連携サービスやAPIのリクエスト数、成功率、失敗の種別、処理時間などを管理する。

• システムリソースの状況: CPU、メモリ、ディスク容量、ネットワーク帯域などのリソースを監視する。システムやサービスが設定した閾値を超えた場合には異常を検知しアラートを発報する。また収集したデータに基づき、定期的なレポートやトレンド予測を実施してシステム運用の改善活動に活用する。

• セキュリティの状況と監査: ネットワークやプロセスのようなシステムの構成要素、また各機能の挙動の監視を通じて、セキュリティの観点から通常とは異なる振る舞いを早期に検知する。またシステムの監査など証跡のための機能を提供する。

• should: 他の運用管理ツールやAIによる分析を前提に、サービスとの連携を念頭に、外部に提供するインタフェースはAPIを通じた連携とすることを原則とする。

• should: メトリクスを可視化するダッシュボードを提供することを原則とする。またユーザがダッシュボードをカスタマイズできるようにしてもよい。

• should: メトリクスを監視して異常を検知した場合にはシステム管理者に通知することを原則とする。異常検知の目的はサービスの稼働状況に加えて、システムのセキュリティ状況の監視を含む。異常を検知する手段として、各種メトリクスに閾値を設定してもよい。

Overview（概要）

本プロトコルはODS-RAMにおけるロギング機能を定義する。 ロギング機能は、通信ログ、サービスログ、処理ログの3つのカテゴリに基づき、システムの通信状況、各サービスの処理結果、全体の監視・運用状況を包括的に記録・分析可能とすることを目的とする。各ログは、それぞれ異なる保持要件、セキュリティ要件、および用途に基づき設計・運用される。

Abstract Normative Specification（抽象仕様）

• shall: ロギング機能はOpen Dataspacesの構成要素において発生する記録が求められる事象について、その事象の要件に基づく5W1Hの情報を付加して記録する機能を一貫して提供しなければならない。

• should: ログの記録においては、情報を適切に保護する仕組みを取り入れ、特に機密性の高い情報については改ざん防止等の処理を実施する仕組みを提供することを原則とする。

• should: ログへのアクセスは標準化されたインタフェースにより一貫したアクセス手段が提供されることを原則とする。

本プロトコルにおけるログ機能では、ロールをシステム管理者、セキュリティ管理者、開発者、監査担当者に分類して、ログを通信ログ、処理ログ、サービスログに分類する。各カテゴリごとに役割と対象情報を定義して多様なシステム運用や監視ニーズに対応する指針を示す。

本プロトコルに必要な概念は以下である。

ロギングではログを以下3つのカテゴリに分類する。

• 通信ログ: ODSを通過するメッセージ（例: リクエスト、レスポンス）やヘッダー情報を記録する。トラフィックや接続状況の監視、および異常検知を目的とする。

• 処理ログ: リアルタイムダッシュボードや運用監視ツールを通じて、システム全体の処理状況、エラー状況、リソース利用状況などの監視・運用改善を目的とする。

• サービスログ: 個別の連携サービスやAPIの処理結果の記録を目的とする。サービスログにはユーザの処理内容や機密情報が含まれる場合があり、特定の情報については適切な保護が求められる場合がある。

各ログの想定される用途は以下の通り。

• 通信ログ

  • トラフィックと接続状況の監視

  • 異常通信のチェック

  • トラブルシューティング

本ロギング機能は、それぞれのカテゴリごとに以下の情報を対象とする。 通信ログ・サービスログについては、ユーザーの個人情報や処理内容が含まれる可能性があるため、適切な保護が必要となる場合がある。

ODSシステムが処理する通信情報（通信ログ）:

• ODSを通過するメッセージのリクエストおよびレスポンスを対象とする。

• メッセージのボディに加えメタデータ（例: HTTPメソッド、HTTPヘッダー、ステータスコードなど）も対象とする。

ODSシステム内部の稼働情報（処理ログ）:

• システム全体の状態および各処理結果を対象とする。

• 対象とするシステムの要件や形態によって具体的な情報は様々であるため、システムごとの可用性や運用性を考慮して選別する。

• 各情報は集約して監視可能な形式で記録する。

ODSと連携する連携サービスの情報（サービスログ）:

• 連携サービスごとの各種機能や処理結果に関連する情報を記録対象とする。

• サービスによっては機密性の高い情報を含むため、適切な保護が求められる。

• shall: 各種ログは標準的なフォーマット（例: JSON, XML, CSV）で記録されなければならない。

• shall: 各種ログはその元となる事象に関する時系列情報を含まなければならない。

• should: 各種ログに含まれる機密性の高い情報については、記録時に匿名化などサービスの要件に応じた処理を実施することを原則とする。

• should: 各種ログのうち信頼性がサービス品質に直結するログについては改ざん防止のための処理を実施することを原則とする。改ざん防止のアプローチの例としては検知（ハッシュや署名など）や、永続化（イミュータブルストレージやWORM（Write Once Read Many）メディア）などが挙げられる。

• should: 通信ログの記録内容には、以下の主要メタデータを含むことを原則とする。

  • タイムスタンプ

  • クライアントのIPアドレス

  • リクエストアドレス

• should: 処理ログの記録内容には以下を含めることを原則とする。

  • リソース利用状況（CPU、メモリ、ディスク容量 など）

  • 発生したエラーの種別及び内容

• should: サービスログの記録内容には以下を含めることを原則とする。

  • 各サービスの処理結果（成功/失敗）

  • 各サービスのトレースのためのサービス識別子

本プロトコルは ODS-RAM の L1「Data Trust Assessment」に対応する Fundamental Protocol であり、「データの完全性／非改竄性の評価・算定を成立させるインターフェース（完全性／非改竄性の評価・算定そのものの機能は含まない）」を担う。

「データトラストアセスメント（Data Trust Assessment）」プロトコル仕様書は、2026年度に公開予定である。

Overview（概要）

Notifierは、データトランザクションに関する更新・受領状況を、データ提供者と利用者間で共有するための情報を通知する機能を提供する。

本レイヤは以下の領域を対象とする：

• 通知先リスト管理 データ提供者が提供データの登録・更新・削除をデータ利用者に通知する際に必要な通知先リストの管理機能を提供する。

• 通知管理 データ提供者からの通知管理および、データ利用者からの通知情報確認機能を提供する。

Abstract Normative Specification（抽象仕様）

Concepts and Roles（概念および役割）

本プロトコルに必要な概念は以下である。

• Open Dataspacesを介したデータ提供に関わる通知先リスト管理

• Open Dataspacesを介したデータ提供に関わる通知管理

• shall: 通知先リストは、データ提供者単位で管理されなければならず、異なるデータ提供者間で通知先リストが共有または混在してはならない。

  • Rationale: データ提供者ごとの通知設定の独立性およびセキュリティを確保するため。

• may: 通知先リストの管理は、複数の通知先を一括で登録・更新・削除する機能を必要に応じて提供してもよい。

• should: 通知の管理は、認証情報を用いたデータ提供者や利用者の情報を基に、認証・認可に基づいて行うことを原則とする。

  • Rationale: 前提とするL2やL3レイヤの要件に整合し、通知情報へのアクセス制御が必要であるため。

• may: 通知の管理は、複数通知の一括登録・一括更新・一括削除する機能を必要に応じて提供してもよい。

• Transaction（L2）を介して、本機能が利用されることを前提とする。

• Identity & Trust（L3）のトークンを用いて、本機能が利用されることを前提とする。

Notifierを利用する際の、メッセージ交換シーケンスを以下に示す。

本プロトコルで使用されるエラー処理について記す。

• CRYPTREC暗号リスト

実際の通信方式（HTTPS、ファイル転送、WebSocket等）に当てはめたときの定義を記述する。 以下に記述する内容は全てNon-normative（例示）である。

Concrete Specification（実装例）

Prerequisites（前提条件）

• 本プロトコルは HTTPS（TLS 1.2以上）を使用し、REST形式のHTTPリクエスト/レスポンスにより通信を行う。

• エンドポイント：指定されたURIに対してHTTPメソッド（GET, POST, PUT, DELETE）を使用

• データ形式：リクエストおよびレスポンスの本文はJSON形式

• 認証・認可：OAuth 2.0ベースのトークン認証を利用

• セキュリティ要件：TLS 1.2以上必須、暗号化通信を保証

本プロトコルで使用される各フィールドの定義を記す。

各フィールドについて、以下の情報を記す。

• フィールド名：binding内で使用される名称

• 型：データ型（例：整数、文字列）

• 必須性：フィールドの利用条件

Request・Responseのフィールドは、以下の通り。

Request・Responseのフィールドは本プロトコルの各機能で異なるため、の記載を参照してください。

Sent by・Resulting state(s)・Request・Response・Example・Error一覧・API固有のフィールド定義などの具体実装はの記載を参照してください。

実際の通信方式（HTTPS、ファイル転送、WebSocket等）に当てはめたときの定義を記述する。 以下に記述する内容は全てNon-normative（例示）である。

Concrete Specification（実装例）

Prerequisites（前提条件）

• HTTPS通信

• RDF

• JSON-LD

• UTF-8

• SAMM

• dcterms

本プロトコルで使用される各フィールドの定義を記す。

Discovery Finder/Discovery Serviceは「サービスインスタンス」データを返却する。 サービスインスタンスはJSON-LD形式で表現され、以下の主要な構成要素を持つ：

• フィールド名：binding内で使用される名称

• 型：データ型（例：整数、文字列）

• 必須性：フィールドの利用条件

• ビジネスドメインにおけるアプリケーション（データ/サービス）のリソース情報を元に、そのリソースに関するアプリケーションのエンドポイントを解決

• 利用者が、ドメインで使用する様々なデータを検索キーで検索し、データおよびそのデータ獲得に必要なドメインアプリケーションのメタデータを解決

  • 検索キー：緯度・経度、文字列、数値

なお、独自のビジネスドメイン用にDiscovery Serviceを構築する場合、メッセージ処理とデータベース部分は自動生成されるが、それらをつなぐ処理のみ開発を行う必要がある。

• Discovery Service利用者がDiscovery Serviceにアクセスするエンドポイントを解決するために使用

• Discovery Serviceのエンドポイントを登録

  • 既存のキーワードに登録するか新しいキーワードを作成して登録するか選択可能

Identity & Trust（L3）は、参加主体を識別し、正当な主体同士、かつ正当なリソースへの権限でのみデータ交換が成立する信頼の前提を提供する機能を提供する。

本プロトコルは以下の領域を対象とする：

• 認証（Authentication） 自然人（Human）およびシステム（Machine）を主体として識別・認証し、利用コンテキストに応じた認証を実現する。

• 認可（Authorization） リクエスト単位でポリシーベースの動的認可を行う。

Overview（概要）

本プロトコルは ODS-RAM の L1「Data Trustworthiness and Quality Assessment」に対応する Fundamental Protocol であり、「データ品質／信頼性の評価・算定を成立させるインターフェース（品質／信頼性の評価・算定そのものの機能は含まない）」を担う。

「データトラストワージネス・クオリティアセスメント（Data Trustworthiness and Quality Assessment）」プロトコル仕様書は、2026年度に公開予定である。

Overview（概要）

本プロトコルでは、エンドポイントとプロセス制御、データ転送を担い、各レイヤの結節点としてトランザクションを成立させる機能を提供する。 また、本プロトコルのコアコンポーネント群であるトランザクションコンポーネントはODPを構成する各プロトコルの結節点であり、各レイヤ/パースペクティブ（Fundamental Protocols, Complementary Protocols）との通信を行う。

本プロトコルは、以下のトランザクションマネジメントを定義する。

• データ転送

  データ利用者からの要求に応じて、データストアのエンドポイントからデータを転送する機能。 データ構造（構造化/非構造化）および処理方式（同期/非同期）のデータ転送を実現するために、下記の4つのデータプレーンモジュールに分類されている。

  • Web API転送モジュール 同期処理の構造化データ（Web API等）の転送に特化したデータプレーンモジュール。

  • ストリーム転送モジュール 非同期処理の構造化データ（ストリームデータ）の転送に特化したデータプレーンモジュール。

  • ファイル/バルク転送モジュール 同期処理の非構造化データ（大規模なファイルやバルクデータ）の転送に特化したデータプレーンモジュール。

  • メディアストリーム転送モジュール 非同期処理の非構造化データ（ビデオや音声などのリアルタイムストリーミングデータ）の転送に特化したデータプレーンモジュール。

• 認証認可連携 クレデンシャル発行サービスおよびアイデンティティコンポーネント(L3)と連携し、リクエスト単位で認証認可制御を行う機能。

• ロギング ロギング(Common Functionalities)と連携し、来歴情報およびクリアリング・ペイメント(DCS)で必要となる情報を記録する機能。

本プロトコルに必要な概念は以下である。

本仕様はWeb API転送モジュールを最小実装例として定義する。

• shall: Open Dataspacesにおけるデータ転送は、データプレーンモジュールを介して行わなければならない。

  • Rationale: Open Dataspacesにおける信頼性、相互運用性を確保するため。

• should: 複数のデータ構造および転送方式に対応可能な拡張性を持つことを原則とする。

• should: アイデンティティコンポーネント(L3)と連携し、リクエスト単位での認証および認可制御を行うことを原則とする。

  • Rationale: Open Dataspaces横断での一貫したアクセス制御を実現し、セキュリティと相互運用性を確保するため。

• should: データスペースコンプリメンタリサービス（DCS）が必要とする最低限のデータを記録できることを原則とする。

プロトコルが扱うメッセージの種類を以下に示します。

本プロトコルで送受信されるメッセージは、以下の要素で構成されている。

本プロトコルで扱う状態について記す。

本プロトコルで使用されるエラー処理について記す。

Concrete Specification

Prerequisites（前提条件）

• 本プロトコルは HTTPS（TLS 1.2以上） を使用し、 REST形式のHTTPリクエスト/レスポンス により通信を行う。

• エンドポイント：指定されたURIに対してHTTPメソッド（GET, POST, PUT, DELETE）を使用

• データ形式：リクエストおよびレスポンスの本文はJSON形式

• 認証・認可：認証・認可方式には OAuth 2.0 および OpenID Connect を使用する。

  自然人主体の認証には OpenID Connect（Authorization Code Flow）を、 システム主体のアクセス制御には OAuth 2.0（Client Credentials Flow）を用いる。

  また、ポリシーベースでの認可制御を提供する。

• セキュリティ要件：TLS 1.2以上必須、暗号化通信を保証

本プロトコルで使用される各フィールドの定義を記す。 なお、各APIの詳細な項目定義は別途公開している「」を参照すること。

各フィールドについて、以下の情報を記す。

• フィールド名：プロトコル内で使用される名称

• 型：データ型（例：整数、文字列）

• 必須性：フィールドの利用条件

Request・Response・Example・Error一覧・API固有のフィールド定義などの具体実装はの記載を参照すること。

本プロトコルの認証機能では以下の 2 種類の認証フローを提供する。

認証情報

本機能で用いる主な認証情報を以下に示す。

識別子

本プロトコルでは発行するアクセストークンに対し、業務上の識別に必要な以下2種類のカスタムクレームを付与する。

1. operator_id（事業者識別子）

ユーザまたはクライアントが所属する 事業者（operator） を識別するための情報である。 本クレームは以下のフローにおいてアクセストークンへ付与される。

　- Authorization Code Flow（認可コードフロー） → ユーザ払い出し時に指定された事業者を付与。

　- Client Credentials Flow（クライアントクレデンシャルフロー） → クライアント（client_id）払い出し時に指定された事業者を付与。

1. open_system_id（システム識別子）　　

クライアントが属するシステムを識別するための情報である。 本クレームは以下のフローにおいてのみアクセストークンへ付与される。

　- Client Credentials Flow（クライアントクレデンシャルフロー）

Authorization Code Flow（ユーザを伴うフロー）では付与されない。

を参照すること

Concrete Specification（実装例）

Prerequisites（前提条件）

• 本プロトコルは HTTPS（TLS 1.2以上） を使用し、 REST形式のHTTPリクエスト/レスポンス により通信を行う。

• エンドポイント：指定されたURIに対してHTTPメソッド（GET, POST, PUT, DELETE）を使用する。

• データ形式：リクエストおよびレスポンスの本文はJSON形式とする。

Field Definitions（フィールド定義）

本プロトコルで使用される各フィールドの定義を記す。

各フィールドについて、以下の情報を記す。

• フィールド名：プロトコル内で使用される名称

• 型：データ型（例：整数、文字列）

• 必須性：フィールドの利用条件

通信時にはクライアントから以下のヘッダー情報の付与が必要となる。以下に記載のないヘッダー情報については任意となり、Web API転送モジュールは関知しない。

Web API転送モジュールは透過的APIゲートウェイ方式を採用しており、ペイロード情報についてはデータ提供者が提供するAPIの仕様に依存するため、詳細な仕様については、該当するサーバー（データ提供者）のシステム仕様書を参照すること。

なお、エラー発生時の応答については以下のペイロード(JSON形式)が返却される。

• 出力例

Web API転送モジュールは、透過的APIゲートウェイ方式を採用し、ルーティング機能のみに限定しており、ペイロード情報の解析やモデル変換の機能は提供していない。また、Web API転送モジュールはデータ利用者のアプリケーションとデータ提供者が所有するシステム間通信に介在し、アイデンティコンポーネントと連携したトークン検証および認可制御のためのPEP（Policy Enforcement Point）機能を提供する。

トランザクションレイヤが提供する機能は以下の通りである。

実際の通信方式（HTTPS、ファイル転送、WebSocket等）に当てはめたときの定義を記述する。 以下に記述する内容は全てNon-normative（例示）である。

• 通信プロトコル: HTTPS (TLS1.2以上)

• メッセージ形式: JSON-LD

• エンコーディング: UTF-8

Overview（概要）

本プロトコルは ODS-RAM の L4「Metadata Exchange」に対応する Fundamental Protocol であり、データの所在や意味に関するメタデータを連携し、分散環境でのデータ発見性と意味判断を成立させるものである。 メタデータは、情報モデルとしてRDF(Resource Description Framework)を採用し、データモデルとしてJSON-LD 形式やTurtle形式を採用する。データやサービスの提供者がこのメタデータを公開することで、データやサービスの発見や解釈、利用が容易になる。また、この基盤的なプロトコルの上位プロトコルとして、Discovery and Search 等を用いることで、データやサービスがネットワーク上で分散的に存在しても、Open Dataspaces全体が透過的に一つのシステムとして機能することを可能にする。 このメタデータは、モビリティやサプライチェーンといった実社会におけるエンティティと、クラウド上のデータやサービスのアクセスを対応づけることを主に意図されているが、前者は必須ではない。

必須とする後者のメタデータにより、サービスの外部仕様がグローバルに意味解決可能となるように接地（意味定義を明確化）され、さらに、そこへのアクセスに必要な諸情報（宛先を含む）が明確になる。

これらのメタデータは、一般のWebアプリケーションサーバ/クライアントの側に構築される。すなわち、メタデータサーバは、アプリケーションサーバからメタデータを静的あるいは動的に取得する。 メタデータクライアントは、アプリケーションクライアントに対してメタデータを提供する。ここで、設計方針としては、通常のWebアプリケーションシステムがデータベース指向のシステム要件（トランザクション、リアルタイム性、高スループット）を満たすものであるのに対して、メタデータ関連のシステムは、広域環境で多種多様なデータの中から必要なデータを発見することを重視する代償として、データの一貫性等は一旦犠牲にし、必要に応じて追加するものとする。 そもそも実世界のデータや、既存のアプリケーションサーバ等のシステムの多様データを統一的なメタデータとして形式を変換し複製する以上、メタデータ管理を厳密に一貫性管理をする必要がる用途は限られていることを前提としている。

Abstract Normative Specification（抽象仕様）

Concepts and Roles（概念および役割）

• RDFメタデータ公開

• RDF Patch同期

• SPARQL取得

• shall: メタデータは、RDFで表現されなければならない。

  • Rationale: メタデータで表される意味（セマンティクス）の表現方法を統一し、相互運用性を確保するため。

• shall: メタデータには、データ授受あるいはサービス提供に関わるインターフェースの意味定義が、グローバルに意味解決可能な形で含まれなければならない（e.g. SAMM）。

• Identity & Trust（L3） と連携可能であること。

• メタデータ自体へのアクセスにも、適切なアクセス管理が必要な場合には、Identity & Trust（L3）と連携し、権限管理がされること。

• RDFモデルはODSセマンティクス方針に準拠する。

メタデータは、データやサービスを提供するシステムからメタデータサーバに提供され公開される。他のサービス提供者のメタデータを参照する、あるいはDiscovery Serviceに公開されるなどで、他のシステムから参照可能となる。

メタデータは、データやサービスの意味定義や宛先情報に関わるサービスメタデータと、実社会における実体と対応するリソースメタデータから構成される。サービスメタデータは、サービス仕様自体の記述、これを当該環境に展開した状態（インスタンス）などから構成されるが、サービス仕様自体の記述は、別のメタデータサーバに格納され、これを参照するなどで表現される。当該サービスに独自な仕様は当該メタデータサーバに格納されうる。サービスメタデータは、リソースメタデータから参照され得る。サービス仕様の記述は、SAMMなどを用いてAspect Modelとして記述される。

サービスメタデータは、二つのパートで構成される

@context は、メタデータで使用されるプレフィックスと名前空間との対応を定義する。

• 名前空間として以下を使用する。

  • @prefix http: .

  • @prefix dcterms: .

@graph は次の複数のオブジェクトから構成される。

• DomainApp ：ドメインアプリケーション全体を表す。

• DomainAppEndpoint ：SAMMによって定義されたエンドポイントのURI情報を表す。

• BaseEndpoint ：REST APIのエンドポイントの共通部分のURI情報を表す。

• SparqlEndpoint ：SPARQL用のエンドポイント情報を表す。

DomainAppはドメインアプリケーション全体を表す。

構造

DomainAppEndpointはSAMMによって定義されたエンドポイントのURI情報を表す。

共通構造

BaseEndpointはREST APIのエンドポイントの共通部分のURI情報を表す。

SparqlEndpointはSPARQL用のエンドポイント情報を表す。

リソースメタデータは、当該用途のアプリケーションが生成・管理する様々な形式のデータをRDFにより表現し、共通の語彙により意味を持たせた、ドメイン内データのメタデータである。ドメイン依存であるため、具体例は、binding.mdで挙げる。

(1) 基本構造

• 本データは JSON-LD により RDF を表現する

• 各ファイルは以下を基本単位とする

ID表現

• 各エンティティは @id により一意に識別される

• HTTP URI形式を採用

例:

データ型

• リテラル値は @value + @type で明示

• 主な型

  • xsd:string

本プロトコルで使用されるエラー処理について記す。

Michael Franklin, Alon Halevy, David Maier, "From Databases to Dataspaces: A New Abstraction for Information Management", SIGMOD Record, Vol. 34, No.4, Dec. 2005

Overview（概要）

本プロトコルは ODS-RAM の L4「Discovery and Search」に対応する Fundamental Protocol であり、メタデータをもとにした探索・検索の高度化を担うものであり、 Metadata Exchange 上に公開された情報を利用してリソース探索とエンドポイント解決を行う。

Abstract Normative Specification（抽象仕様）

Concepts and Roles

（補足） 「」で記述されている「Discovery Service」は、本プロトコル仕様における「Discovery Finder」（Discovery Serviceの探索）と「Discovery Service」（宛先（エンドポイント）の探索）を包含する概念である点に注意のこと。

• Discovery Service解決

• リソース検索

• エンドポイント取得

• shall: Discovery Service は、検索可能とするリソースを登録できるAPI（register）を持たなければならない。

  • Rationale: Discoveryは、サービスの提供者やデータの保持者が、保有するデータやサービスを検索対象となるために利用するのを原則としているため。Discovery Serviceは、Webサーチエンジンのように受動的（Passive）なインデックス化ではなく、サイト側が登録する能動型（Active）なインデックス化を行う。

• shall: クライアントが、データやサービスにアクセスするために必要なエンドポイントの解決をするために、属性をキーとして、エンドポイントを含むメタデータを返すAPI（find）を持たなければならない。

データ/サービス提供者に関する情報が、Discovery Serviceに登録されると、この情報のライフサイクル管理は次の状態遷移で管理される。

本プロトコルで使用されるエラー処理について記す。