Protocol
Overview（概要）
クリアリング・ペイメントは、サードパーティの電子決済アプリケーションを通じてデータ取引の実績を記録・照合して精算・課金／決済するインターフェース（清算・課金／決済そのものの機能は含まない）を提供する。本プロトコルはComplementary Protocolsの1つとして、Open Dataspacesを実現するための補完的な機能である。
本レイヤは以下の領域を対象とする：
精算（Clearing） データ交換における、提供者と利用者間の取引を記録し、利用量と料金モデルに基づく精算処理を行う。なお、記録した取引は、ロギング機能を利用して収集したデータ交換の取引実績と比較することにより、精算対象を確認する。
課金／決済（Payment） 決済処理に必要な情報を提供する。なお、実際に決済を処理する機能については対象外である。
Abstract Normative Specification（抽象仕様）
Concepts and Roles（概念および役割）
本プロトコルに必要な概念は以下である。
Data Provider（データ提供者）
データ利用者に対してデータストアに格納されたデータを送信する主体。
Data Consumer（データ利用者）
データ提供者からデータを受信する主体。
Payment Service（決済サービス）
データ提供者が本プロトコル外で選択する決済処理を行う主体。
Scope（適用範囲）
Open Dataspacesを介した処理における精算（Clearing）
Open Dataspacesを介した処理における課金／決済（Payment）
Normative Requirements（規定要件）
精算（Clearing）
shall: 精算機能は、複数の証跡情報を突合して精算対象の取引実績を決定しなければならない。証跡情報は少なくとも (a) Dataspace Fundamental Services(DFS)の証跡、(b) 提供者申告、(c) 利用者申告を含まなければならない。
Rationale: データスペースの構成（連邦型・分散型）により、単一情報のみでは精算対象の正当性が担保できないため。
should: 証跡情報の (a) DFSの証跡、(b) 提供者申告、(c) 利用者申告、全て一致する場合に精算対象とすることを原則とする。
Rationale: 証跡間に矛盾が存在する場合、精算機能が自動で精算対象を確定してはならないため。
may: Industry Service(IS)の情報は、必要に応じて使用してもよい。
Rationale: 業務要件に応じた柔軟実装を許容するため。
may: 精算結果の状態は、必要に応じて定義し、管理してもよい。
Rationale: 複数の証跡情報を突合して精算対象の取引実績を決定するにあたり、状態管理の実装を許容するため。
may: 保持するデータを暗号化する場合、CRYPTRECが推奨する暗号方式等の標準的な暗号技術を、必要に応じて参照・採用してもよい。
Rationale: 運用要件に合わせた暗号化技術の採用を、検討可能とするため。
課金／決済（Payment）
should: 決済の方式は、提供者が提示する決済方式から利用者が選択し、事前に取り決めることを原則とする。
Rationale: 一般的な商習慣に従うため。
should: 決済処理に必要な情報は、精算処理の結果を基にすることを原則とする。
Rationale: 一般的な商習慣に従うため。
may: 決済処理機能は、外部の決済サービスを活用してもよい。ただし、外部の決済サービスを選定した際には、当該サービスとの連携方法や必要な制御については、精算決済機能側でカスタマイズを行うことを原則とする。
Rationale: 業務要件に応じた柔軟実装を許容するため。また、決済サービスごとの差異を吸収し、精算決済機能としての一貫した提供を可能とするため。
may: 保持するデータを暗号化する場合、CRYPTRECが推奨する暗号方式等の標準的な暗号技術を、必要に応じて参照・採用してもよい。
Rationale: 運用要件に合わせた暗号化技術の採用を、検討可能とするため。
Non-functional / Cross-layer Requirements（非機能要件 / クロスレイヤ要件）
Transaction（L2）を介して、本機能が利用されることを前提とする。
Identity & Trust（L3）のトークンを用いて、本機能が利用されることを前提とする。
データ交換における、提供者と利用者間の各取引は、X-TrackingIDにて一意に特定できることを前提とする。
Message Types（メッセージ種類）
Request
クライアント（Transaction（L2）） ⇒ サーバー（Clearing and Payment）
クライアントが精算決済の各機能を実行するために送信するメッセージ。認証情報や要求パラメータを含む。
Response
サーバー（Clearing and Payment） ⇒ クライアント（Transaction（L2））
サーバー（Clearing and Payment）がリクエストに対する結果を送信するメッセージ。処理結果、エラー情報などを含む。
Protocol Flow（プロトコルフロー）
Clearing and Paymentを利用する際の、メッセージ交換シーケンスを以下に示す。
Error Handling（エラー処理）
本プロトコルで使用されるエラー処理について記す。
リクエスト不正
パラメータ不正、必須項目欠落等において返却される。
入力内容を再確認し、正しい入力内容を設定し、再送信を行う。
トークン設定に関するエラー
アクセストークン未設定、無効等において返却される。
アクセストークンを再取得および再設定（必要に応じて再ログインまたはトークン更新）し、再送信を行う。
権限不足エラー
必要な権限不足等において返却される。
該当操作が許可されていない旨を通知する。なお、再送しても成功しないため再送信は行わない。
リソース存在エラー
該当リソースが存在しない等において返却される。
リソースが存在しない旨を通知する。なお、再送しても成功しないため再送信は行わない。
データ不整合エラー
重複データ、排他制御等において返却される。
最新のデータを再取得し、競合を解消させたうえで、再送信を行う。
リクエスト形式エラー
サポートされないリクエスト形式指定時において返却される。
正しいContent-Typeを設定し、再送信を行う。
システムエラー
サーバ内部において何らかの異常発生時に返却される。
継続的に発生する場合はシステム管理者へ通知を行う。なお、再送信については行った操作によって実行要否を行う。
References（参考文献）
CRYPTREC暗号リスト 参照元
最終更新