BLUEPRINT

4 外部統合ポイント

第4章：外部統合ポイント

本章では CAP プロトコルと外部システムとの統合ポイントを記述し、各統合ポイントの責務境界、相互作用の方向、通信プロトコル要件を明確にする。CAP プロトコルは孤立して動作するシステムではなく、iFay_Runtime、端末オペレーティングシステム、ハードウェアドライバ、Registration_Authority などの外部システムと協調して端末制御権限の管理を共同で完了する必要がある。これらの統合ポイントのインターフェース境界と相互作用方式を理解することは、システムインテグレーターが CAP プロトコルを正しく実装するための前提条件である。

4.1 iFay_Runtime との統合

iFay_Runtime は Fay（iFay または coFay）のランタイム環境であり、Fay インスタンスのライフサイクル管理とスケジューリングを担当する。CAP プロトコルの観点では、iFay_Runtime は制御権リクエストの発行元である——Fay が端末リソースにアクセスする必要がある場合、iFay_Runtime が代わりに CAP プロトコル層に認可検証リクエストを発行する。

統合責務：

制御権リクエストの発行：iFay_Runtime は Fay を代表して Protocol_Engine に認可検証リクエストを提出する。リクエストには Fay のアイデンティティ識別子、ターゲット Terminal_Resource、認可資格情報（Authorization_Descriptor または Trusted_Ticket）が含まれる
Fay のライフサイクル管理：iFay_Runtime は Fay インスタンスの起動、一時停止、再開、終了を担当する。Fay インスタンスが終了した際、iFay_Runtime は Protocol_Engine に当該 Fay が保持するすべてのアクティブ Session の解放を通知する
生存検知チャネルの維持：iFay_Runtime は Fay と端末間の長時間接続を維持し、設定された間隔でアプリケーション層ハートビートメッセージを送信して Liveness_Detection メカニズムの正常な動作を支える
セッション状態通知の受信：Protocol_Engine は Session の状態変更（作成成功、ハンドオーバーリクエスト、強制終了など）を iFay_Runtime に通知し、iFay_Runtime が対応する Fay インスタンスに伝達する

相互作用の方向： 双方向（Bidirectional）

iFay_Runtime は CAP プロトコル層にリクエストを発行し（認可検証、セッション解放、ハートビート送信）、CAP プロトコル層は iFay_Runtime にレスポンスとプッシュ通知を返す（検証結果、セッション状態変更、ハンドオーバーリクエスト）。

通信プロトコル要件：

iFay_Runtime と Protocol_Engine 間はメッセージベースのリクエスト-レスポンスモデルを採用し、メッセージフォーマットは CAP プロトコル Schema 定義に準拠する
生存検知チャネルは長時間接続のサポートが必要であり、アプリケーション層ハートビートとリアルタイム状態プッシュを実現する
通信チャネルは TLS 暗号化をサポートし、認可資格情報とセッション情報の転送中の機密性と完全性を保証する
メッセージシリアライゼーションフォーマットは Schema 定義ファイル（schema.json）と一致させ、クロス実装の相互運用性を保証する

4.2 端末オペレーティングシステムとの統合

端末オペレーティングシステムは Terminal_Resource の管理者であり、端末上のソフトウェアおよびハードウェアリソースの統一管理を担当する。CAP プロトコルはオペレーティングシステムとの統合を通じて、認可検証結果を実際のリソースアクセス制御に変換する——オペレーティングシステムは Protocol_Engine の指令に基づいて、Fay の特定リソースへのアクセスを許可または拒否する。

統合責務：

リソースアクセス制御の実行：オペレーティングシステムは Protocol_Engine が発行するアクセス制御指令に基づいて、システムレベルで Fay の Terminal_Resource へのアクセスを許可またはブロックする。これにはファイルシステムアクセス制御、プロセス権限管理、デバイスアクセス許可などが含まれる
リソース状態の報告：オペレーティングシステムは Protocol_Engine に Terminal_Resource の現在の状態（利用可能、使用中、利用不可）を報告し、Protocol_Engine が正確なリソース割り当て決定を行えるようにする
実行環境の分離：オペレーティングシステムは異なる Fay の操作に対してプロセスレベルまたはサンドボックスレベルの分離を提供し、ある Fay の操作が他の Fay や人間ユーザーのリソースアクセスに影響しないことを保証する
リソースイベントの転送：Terminal_Resource の状態が変化した場合（ハードウェア切断、ソフトウェアクラッシュなど）、オペレーティングシステムはイベント通知を Protocol_Engine に転送し、対応する Session 終了またはリソース回収フローをトリガーする

相互作用の方向： 双方向（Bidirectional）

CAP プロトコル層はオペレーティングシステムにアクセス制御指令とリソース照会リクエストを発行し、オペレーティングシステムは CAP プロトコル層にリソース状態を報告しリソースイベントを転送する。

通信プロトコル要件：

CAP プロトコル層とオペレーティングシステム間はローカルプロセス間通信（IPC）メカニズムを採用し、具体的な方式はオペレーティングシステムプラットフォームに依存する（Unix Domain Socket、Named Pipe、D-Bus など）
アクセス制御指令は同期呼び出し方式で実行し、Protocol_Engine が指令の実行結果を即座に把握できるようにする
リソースイベント通知は非同期プッシュ方式を採用し、オペレーティングシステムはリソース状態の変化時に能動的に Protocol_Engine に通知する
通信インターフェースはオペレーティングシステムネイティブのセキュリティモデルに準拠し、認可された Protocol_Engine プロセスのみがアクセス制御指令を発行できることを保証する

4.3 ハードウェアドライバとの統合

ハードウェアドライバはハードウェア系 Terminal_Resource（カメラ、マイク、GPS モジュール、ストレージデバイスなど）のアクセスインターフェースである。CAP プロトコルはハードウェアドライバとの統合を通じて、ハードウェアリソースのきめ細かい制御権管理を実現する。ハードウェアドライバは CAP プロトコルの統合体系においてオペレーティングシステムの下位に位置し、ハードウェアリソースの低レベルアクセス機能を提供する。

統合責務：

ハードウェアリソースアクセスインターフェースの提供：ハードウェアドライバは CAP プロトコル層にハードウェアリソースの能力記述と操作インターフェースを公開し、Protocol_Engine がハードウェアリソースのサポートするアクセスモード（read、write、execute、configure）を把握できるようにする
ハードウェアレベルアクセス制御の実行：ハードウェアドライバは Protocol_Engine がオペレーティングシステムを経由して伝達する制御指令に基づいて、ハードウェアレベルでアクセスの許可または拒否を実行する。例えば、Fay によるカメラの起動やマイクへのアクセスを許可または禁止する
ハードウェア状態の報告：ハードウェアドライバは上位層にハードウェアデバイスの接続状態、動作状態、異常情報を報告し、これらの情報は最終的に Protocol_Engine に伝達されて Session 管理の意思決定に使用される
ハードウェアリソースの排他制御のサポート：排他アクセスが必要なハードウェアリソース（カメラのビデオストリーム出力など）に対して、ハードウェアドライバは低レベルで同一時点に1つの制御者のみが独占使用できることを保証する

相互作用の方向： 単方向（Unidirectional）——CAP プロトコル層 → ハードウェアドライバ

CAP プロトコル層はオペレーティングシステムを通じてハードウェアドライバに制御指令を発行し、ハードウェアドライバの状態情報はオペレーティングシステムのデバイス管理層を通じて上位に伝達される。CAP プロトコル層はハードウェアドライバと直接通信チャネルを確立せず、オペレーティングシステムを仲介として間接的に相互作用する。ハードウェア状態の報告パスは：ハードウェアドライバ → オペレーティングシステム → Protocol_Engine であり、オペレーティングシステム統合ポイント（4.2）の一部に属する。

通信プロトコル要件：

CAP プロトコル層はハードウェアドライバと直接通信せず、すべての相互作用はオペレーティングシステムのデバイス管理インターフェース（DeviceIoControl、ioctl、sysfs など）を通じて間接的に完了する
ハードウェアリソースの能力記述は統一されたリソース記述フォーマットに準拠し、Protocol_Engine が異なるタイプのハードウェアリソースを一貫した方式で管理できるようにする
ハードウェアドライバはオペレーティングシステムが提供する標準デバイスアクセス制御インターフェースをサポートし、CAP プロトコルのアクセス制御指令がハードウェアレベルで有効になることを保証する
高感度ハードウェアリソース（カメラ、マイクなど）に対して、ハードウェアドライバはハードウェアレベルのアクセスロックメカニズムをサポートし、オペレーティングシステムレベルのアクセス制御のバイパスを防止する

4.4 Registration_Authority との統合

Registration_Authority（登録機関）は CAP プロトコルの信頼基盤インフラストラクチャのコア構成要素であり、端末ハードウェア、ソフトウェア、オペレーティングシステムの登録管理、および端末への検証鍵（Verification_Key）の配布を担当する。端末が Registration_Authority を通じて取得する Verification_Key はオフライン認可検証の信頼アンカーである——合法的な Verification_Key がなければ、端末は Authorization_Descriptor のデジタル署名を検証できない。

統合責務：

端末登録：端末デバイス（ハードウェア、オペレーティングシステム、クライアントソフトウェアを含む）は Registration_Authority を通じて登録を完了し、一意の端末識別子と初期設定情報を取得する
Verification_Key の配布：Registration_Authority は登録済みの端末に Verification_Key を配布し、端末はこの鍵を使用して Authorization_Descriptor のデジタル署名を検証する。鍵配布プロセスはセキュアチャネルを通じて完了しなければならず、鍵の改ざんや窃取を防止する
鍵の更新とローテーション：Verification_Key の更新が必要な場合（鍵の期限切れ、発行者の変更など）、Registration_Authority は端末に新しい鍵をプッシュし、鍵ローテーションプロセス中のスムーズな移行を調整する
登録状態管理：Registration_Authority は端末の登録状態を維持し、登録、一時停止、登録解除を含む。端末の登録状態は Verification_Key の更新を受信できるかどうか、および CAP プロトコルの認可検証フローに参加できるかどうかに影響する

相互作用の方向： 単方向（Unidirectional）——Registration_Authority → 端末

Registration_Authority は端末に Verification_Key と登録情報を配布し、端末は受動的に受信する。端末は Registration_Authority に認可検証リクエストを発行したり、動作状態を報告したりしない——端末の認可検証は完全にローカルで完了する（配布済みの Verification_Key を使用）ため、Registration_Authority とのリアルタイム通信を維持する必要はない。端末が Registration_Authority に発行する登録リクエストは一回限りの初期化フローであり、CAP プロトコルランタイムの通常の相互作用には属さない。

通信プロトコル要件：

Registration_Authority と端末間の通信はセキュアチャネル（TLS/mTLS など）を通じて完了しなければならず、Verification_Key の転送中の機密性と完全性を保証する
鍵配布プロトコルはオフラインプリセットとオンライン更新の2つのモードをサポートする：端末は出荷時に初期 Verification_Key をプリセットでき、その後オンラインチャネルを通じて鍵更新を受信する
鍵更新メッセージにはバージョン番号と発効時刻を含め、新旧鍵のスムーズな移行期間をサポートし、鍵ローテーションによる認可検証の中断を回避する
Registration_Authority は鍵配布の確認メカニズムを提供し、端末が新しい Verification_Key を正常に受信し保存したことを保証する

4.5 統合ポイントの相互作用方向と通信プロトコル総覧

以下の表は CAP プロトコルと4つの外部システムとの統合ポイント情報を集約し、相互作用の方向と通信プロトコル要件を含む：

統合ポイント	外部システム	相互作用の方向	通信プロトコル要件
4.1	iFay_Runtime	双方向（Bidirectional）	メッセージベースのリクエスト-レスポンスモデル；長時間接続サポート（生存検知）；TLS 暗号化；メッセージフォーマットは CAP Schema 定義に準拠
4.2	端末オペレーティングシステム	双方向（Bidirectional）	ローカルプロセス間通信（IPC）；同期呼び出し + 非同期イベントプッシュ；オペレーティングシステムネイティブセキュリティモデルに準拠
4.3	ハードウェアドライバ	単方向（CAP → ハードウェアドライバ）	オペレーティングシステムデバイス管理インターフェースを通じた間接通信；統一リソース記述フォーマット；ハードウェアレベルアクセスロックサポート
4.4	Registration_Authority	単方向（RA → 端末）	TLS/mTLS セキュアチャネル；オフラインプリセットとオンライン更新のサポート；鍵バージョン管理とスムーズなローテーション

相互作用方向の説明：

双方向（Bidirectional）：CAP プロトコル層と外部システム間に双方向のリクエスト-レスポンスまたはイベント通知の相互作用が存在し、双方が能動的に通信を開始できる
単方向（Unidirectional）：情報フローは一方から他方へのみ流れる。4.3 では CAP プロトコル層がオペレーティングシステムを通じてハードウェアドライバに指令を発行する（直接通信なし）。4.4 では Registration_Authority が端末に鍵と登録情報を配布する（端末は受動的に受信）

通信プロトコル設計原則：

セキュリティ：認可資格情報と鍵の転送に関わるすべての通信チャネルは暗号化が必須であり、中間者攻撃と情報漏洩を防止する
プラットフォーム適応性：オペレーティングシステムとハードウェアドライバとの統合はプラットフォームネイティブインターフェースを採用し、異なるオペレーティングシステム上での互換性を保証する
相互運用性：iFay_Runtime と Registration_Authority との統合は標準化されたメッセージフォーマット（CAP Schema ベース）を採用し、異なる実装間の相互運用性を保証する
耐障害性：通信プロトコルはリトライとデグレードメカニズムをサポートし、通信中断時に CAP プロトコルのコア機能（特にオフライン認可検証）の正常な動作に影響しないようにする