1 協議定位與邊界
第一章：協議定位與邊界
1.1 CAP 在 iFay 體系中的職責
Control Authority Protocol（CAP）在 iFay 體系中承擔單一且明確的核心職責：驗證 Fay（iFay 或 coFay）是否已獲得其人類宿主（Natural_Person）或官方崗位（Official_Post）的授權，從而合法存取終端資源（Terminal_Resource）。
具體而言，CAP 協議負責以下工作：
- 授權校驗：當 Fay 請求存取終端上的軟體或硬體資源時，CAP 協議驗證其攜帶的授權憑證（Authorization_Descriptor 或 Trusted_Ticket）是否合法、有效且未被撤銷。例如，使用者的 iFay 要開啟手機攝影機拍照，終端需要先驗證該 iFay 確實被使用者授權使用攝影機
- 會話管理：為通過授權校驗的 Fay 建立控制會話（Session），管理會話的完整生命週期。例如，iFay 獲得授權後開始操作瀏覽器，從開啟瀏覽器到關閉瀏覽器的整個過程就是一個完整的控制會話
- 控制權協調：在多個 Fay 或 Fay 與人類使用者之間協調終端資源的控制權分配與交接。例如，一架人工控制的無人機，現在需要交接給某個 Fay 自主飛行；或者兩個 iFay 需要先後使用同一台印表機
- 資源存取分級：按操作類型（讀、寫、執行、配置）對資源存取進行分級管理。例如，iFay 讀取溫度感測器資料只需 read 權限，而修改空調溫度設定則需要 write 權限
- 存活檢測：監測活躍會話的存活狀態，及時回收失效會話佔用的資源。例如，iFay 因網路中斷失聯後，終端檢測到心跳逾時，自動釋放該 iFay 佔用的攝影機控制權，避免資源被「殭屍會話」長期鎖定
CAP 協議是 iFay 體系中連接智慧代理與終端資源的關鍵橋樑——它不關心 Fay 是誰、能做什麼，只關心 Fay 是否被允許做某件事。
1.2 CAP 不負責的職責範圍
為確保職責邊界清晰，CAP 協議明確不負責以下事項：
- Fay 的身份建立與管理：Fay 實體的註冊、身份標識分配、身份屬性維護等工作由 iFay 體系中的身份管理子系統負責，CAP 僅消費身份資訊用於授權校驗，不參與身份的建立和管理過程。例如，「這個 iFay 叫什麼、屬於誰」由身份管理系統決定，CAP 只關心「這個 iFay 是否被允許使用攝影機」
- Fay 的智慧推理能力：Fay 如何理解使用者意圖、如何規劃操作步驟、如何執行智慧推理等能力屬於 Fay 自身的智慧層，與 CAP 協議無關。CAP 不對 Fay 的智慧水準做任何假設或要求。例如，iFay 決定先開啟瀏覽器再搜尋機票——這個決策過程與 CAP 無關，CAP 只在 iFay 實際請求開啟瀏覽器時進行授權校驗
- 終端資源的具體業務邏輯：終端上的軟體如何回應操作指令、硬體如何執行具體功能，這些業務邏輯由終端資源自身實現。CAP 僅負責授權校驗和存取控制，不介入資源的具體業務處理。例如，印表機如何排版、用什麼墨匣列印，這些是印表機自身的業務邏輯，CAP 只負責驗證 iFay 是否有權使用印表機
- 網路通訊協議的實現：CAP 定義授權校驗的邏輯流程和訊息格式，但不規定底層網路傳輸協議的具體實現方式。例如，終端與 iFay_Runtime 之間是用 WebSocket 還是 gRPC 通訊，CAP 不做限制
- 終端作業系統的內部安全機制：作業系統自身的使用者權限管理、沙箱隔離、行程安全等機制不在 CAP 的管轄範圍內，CAP 透過與作業系統的整合介面進行協作。例如，Android 系統自身的應用沙箱機制由 Android 管理，CAP 透過 Android 提供的介面下發存取控制指令
1.3 與其他子專案的關係
CAP 協議在 iFay 體系中與以下子專案存在明確的互動關係：
| 子專案 | 關係描述 | 互動邊界 |
|---|---|---|
| iFay_Runtime | CAP 的主要呼叫方。iFay_Runtime 負責 Fay 實例的生命週期管理和調度，當 Fay 需要存取終端資源時，由 iFay_Runtime 代為發起控制權請求 | iFay_Runtime → CAP：發起授權校驗請求；CAP → iFay_Runtime：回傳校驗結果和會話資訊 |
| Registration_Authority | CAP 的信任基礎設施依賴。Registration_Authority 負責終端硬體、軟體和作業系統的註冊，並向終端分發校驗金鑰（Verification_Key） | Registration_Authority → 終端：分發 Verification_Key；終端使用 Verification_Key 校驗 Authorization_Descriptor 的簽章 |
| Descriptor_Issuer | CAP 的授權憑證來源。Descriptor_Issuer 受 Natural_Person 或 Official_Post 授權後，負責產生和簽發 Authorization_Descriptor | Descriptor_Issuer → Fay：簽發 Authorization_Descriptor；Fay 攜帶 Authorization_Descriptor 向終端發起存取請求 |
| 身份管理子系統 | CAP 的身份資訊來源。CAP 在授權校驗過程中需要引用 Fay 的身份標識，但不參與身份的建立和管理 | 身份管理 → CAP：提供 Fay 身份標識資訊（單向依賴） |
CAP 協議的設計原則是保持自身職責的內聚性：只做授權校驗和控制權管理，將身份管理、智慧推理、資源業務邏輯等職責留給體系中的其他子專案。
1.4 適用場景
CAP 協議的核心適用場景是：iFay 接管人類宿主的終端，像人一樣使用終端上的軟體和呼叫終端的硬體。
在這一場景下，人類宿主（Natural_Person）將自己終端設備的部分或全部控制權授予其 iFay，由 iFay 代為操作終端上的用戶端軟體（如瀏覽器、郵件用戶端、辦公軟體）和硬體設備（如攝影機、麥克風、儲存設備）。CAP 協議確保這一過程中：
- 授權合法性：終端能夠驗證 iFay 確實獲得了人類宿主的授權，而非未經授權的非法存取。例如，張三的 iFay 試圖操作李四的筆記型電腦，終端會因為缺少李四簽發的授權憑證而拒絕存取
- 離線可用性：即使終端處於離線狀態，只要 iFay 持有有效的 Authorization_Descriptor，仍然可以合法存取被授權的資源。例如，使用者在飛機上開啟飛航模式，其 iFay 仍然可以憑藉預先儲存的離線授權檔案繼續操作筆記型電腦上的辦公軟體
- 多方協調：當多個 Fay 或 Fay 與人類使用者同時需要存取同一終端資源時，CAP 協議提供控制權交接和資源存取模式管理能力。例如，使用者正在用手機拍照，此時 iFay 也需要使用攝影機進行文件掃描，CAP 協議協調兩者的使用順序
- 安全可控：所有授權校驗和資源存取操作均可被稽核，授權可隨時被撤銷。例如，使用者發現 iFay 的行為異常，可以立即撤銷其對所有終端資源的授權，iFay 的活躍會話將被強制終止
同樣的協議框架也適用於 coFay 場景——協作型 Fay 實體受官方崗位（Official_Post）授權後，接管組織終端設備執行協作任務。
1.5 核心設計原則
CAP 協議遵循離線為主、線上為輔的核心設計原則。
離線授權（Authorization_Descriptor）是核心機制。 終端設備不應因為網路不可用而完全剝奪 Fay 的接管權。如果 Fay 事先已獲得人類宿主的授權，這一授權關係應當以加密檔案的形式儲存在終端本地，使終端在離線狀態下仍能獨立完成授權校驗。Authorization_Descriptor 正是這一理念的具體實現——它是一份儲存在終端本地的加密授權描述檔案，包含 Fay 被授權存取的資源範圍、權限類型和有效期，終端透過本地的 Descriptor_Validator 即可完成校驗，無需聯網。
線上票據（Trusted_Ticket）是補充機制。 在聯網環境下，Trusted_Ticket 提供即時授權簽發和撤銷狀態查詢能力，彌補離線授權在時效性和撤銷回應速度上的不足。當線上服務可用時，終端可透過 Trusted_Ticket 取得最新的授權狀態；當線上服務不可用時，終端自動回退到本地 Authorization_Descriptor 校驗，確保服務不中斷。
這一設計原則的核心考量是：
- 可用性優先：網路中斷不應成為 Fay 無法工作的理由，離線授權保障了基本的可用性。例如，使用者在地鐵中手機訊號中斷，iFay 仍然可以憑藉本地授權檔案繼續操作手機上的離線應用
- 安全性增強：線上票據在聯網時提供更強的即時安全保障，包括即時撤銷和動態權限調整
- 漸進降級：從線上到離線的切換是平滑的，不會導致服務突然中斷，線上簽發的 Trusted_Ticket 可轉換為本地 Authorization_Descriptor 格式以供離線使用。例如，使用者在 Wi-Fi 環境下透過線上票據授權 iFay 使用攝影機，當使用者走出 Wi-Fi 覆蓋範圍後，該授權自動降級為離線模式繼續生效