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 管理決策
• 支援硬體資源的排他控制：對於需要排他存取的硬體資源（如攝影機的視訊串流輸出），硬體驅動在底層確保同一時刻只有一個控制方能夠獨佔使用

互動方向： 單向（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 在傳輸過程中的機密性和完整性
• 金鑰分發協議應支援離線預置和線上更新兩種模式：終端出廠時可預置初始 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 協議核心功能（特別是離線授權校驗）的正常運行