第 1 章：架構與角色
本章定義 CAP 協議中的角色、它們之間的信任關係，以及與外部系統的介面契約。本章內容為後續章節提供共用的術語基礎和架構上下文。
1.1 協議角色
CAP 協議涉及以下規範性角色。每個角色在協議互動中承擔明確的職責，且與其他角色透過受限的介面進行互動。
1.1.1 授權人角色
Natural_Person（自然人）和 Official_Post（官方崗位）是授權的最終來源。授權人不直接參與協議訊息互動——授權人透過授權委派機制將簽發權委派給 Descriptor_Issuer。
授權人 MUST 透過安全的身分驗證機制證明其身分。授權人身分的具體驗證機制超出本規範範圍，但該機制 MUST 滿足以下要求：
- 不可否認性：授權人無法否認其作出的授權決策
- 防偽造性：第三方無法偽造授權人的授權決策
1.1.2 簽發方角色
Descriptor_Issuer 負責產生和簽發 Authorization_Descriptor。Ticket_Issuer 負責簽發 Trusted_Ticket。一個實體 MAY 同時承擔兩種簽發方角色。
簽發方 MUST：
- 僅在收到合法授權人的明確授權後簽發憑證
- 使用第 8 章定義的簽章演算法對憑證進行數位簽章
- 維護已簽發憑證的狀態記錄（至少包括簽發時間、有效期、目前狀態）
- 在收到撤銷請求時及時更新撤銷狀態並發布撤銷聲明
簽發方 MUST NOT：
- 在未獲得授權的情況下簽發憑證
- 簽發超出授權人授權範圍的憑證
- 重複使用已撤銷憑證的識別碼
1.1.3 持有方角色
Fay（包括 iFay 和 coFay）是憑證的持有方和資源存取的請求方。Fay 透過 iFay_Runtime 間接參與協議互動——Fay 自身不直接傳送協議訊息。
Fay MUST 透過其所屬的 iFay_Runtime 完成與終端的所有協議互動。Fay 持有的憑證 MUST 透過 iFay_Runtime 提交給終端。
1.1.4 執行時角色
iFay_Runtime 是 Fay 實例的執行時環境，承擔協議訊息的發起和接收。一個 iFay_Runtime 實例 MAY 管理多個 Fay 實例。
iFay_Runtime MUST 滿足第 0.5.3 節定義的執行時一致性等級要求。
1.1.5 終端角色
終端（Terminal）是 Terminal_Resource 的持有者和存取控制的執行方。終端整合以下規範性元件：
- Protocol_Engine：執行 CAP 協議核心邏輯的系統元件
- Descriptor_Validator：負責校驗
Authorization_Descriptor合法性和有效性的元件 - Session 管理器：維護 Session 狀態機和 Liveness_Detection 機制
- 本地撤銷清單：儲存已知的被撤銷憑證識別碼
終端 MUST 滿足第 0.5.1 節定義的終端一致性等級要求。
1.1.6 信任基礎設施角色
Registration_Authority（註冊機構）負責終端的註冊管理和 Verification_Key 的分發。Registration_Authority 是 CAP 協議信任鏈的根錨點。
Registration_Authority MUST：
- 僅向已通過身分驗證的終端分發 Verification_Key
- 透過安全通道（參見第 8 章）完成金鑰分發
- 提供金鑰更新與輪替機制
- 維護終端註冊狀態的權威記錄
1.2 信任鏈
CAP 協議的信任鏈從授權人傳遞到終端的 Descriptor_Validator，由兩條獨立但協作的信任路徑構成。
1.2.1 授權信任路徑
授權信任路徑決定某個 Fay 是否被授權存取某個資源：
授權人（Natural_Person / Official_Post）
│
│ ① 授權委派（帶不可否認證據）
▼
Descriptor_Issuer
│
│ ② 簽發 Authorization_Descriptor（附數位簽章）
▼
Fay
│
│ ③ 提交 Authorization_Descriptor
▼
Descriptor_Validator
終端 MUST 驗證授權信任路徑上每個環節的真實性：
- 步驟 ① 的真實性由 Descriptor_Issuer 在簽發時校驗，終端不直接參與
- 步驟 ② 的真實性由終端透過驗證 Descriptor_Issuer 的數位簽章校驗（依賴金鑰信任路徑）
- 步驟 ③ 的真實性由終端透過驗證 Authorization_Descriptor 與提交方 Fay 識別碼的繫結關係校驗
1.2.2 金鑰信任路徑
金鑰信任路徑決定終端是否信任某個 Descriptor_Issuer 的簽章：
Registration_Authority（信任錨點）
│
│ ① 分發 Verification_Key（透過安全通道）
▼
終端本地金鑰儲存
│
│ ② 提供 Verification_Key 給 Descriptor_Validator
▼
Descriptor_Validator
│
│ ③ 用 Verification_Key 校驗 Authorization_Descriptor 的簽章
▼
校驗通過 / 拒絕
終端 MUST：
- 僅信任由 Registration_Authority 分發的 Verification_Key
- 安全儲存 Verification_Key（參見第 8 章對金鑰儲存的要求）
- 拒絕使用未透過 Registration_Authority 分發的金鑰進行簽章校驗
1.3 外部介面契約
CAP 協議層與 4 個外部系統透過明確定義的介面進行互動。本節定義這些介面的規範性契約。
1.3.1 與 iFay_Runtime 的介面
iFay_Runtime 與終端 Protocol_Engine 之間的介面為雙向訊息介面。
訊息方向：iFay_Runtime → Protocol_Engine
| 訊息類型 | 用途 | 必填欄位 |
|---|---|---|
AuthRequest | 發起授權校驗請求 | fay_id, resource_id, access_mode, credential |
SessionRelease | 主動釋放會話 | session_id |
Heartbeat | 應用層心跳 | session_id, sequence_number |
HandoverResponse | 回應交接請求 | handover_id, accept |
訊息方向：Protocol_Engine → iFay_Runtime
| 訊息類型 | 用途 | 必填欄位 |
|---|---|---|
AuthResult | 授權校驗結果 | request_id, status, session_id (成功時), error_code (失敗時) |
SessionStateChanged | 會話狀態變更通知 | session_id, new_state, reason |
HandoverRequest | 交接請求通知 | handover_id, target_resource_id, deadline |
HeartbeatAck | 心跳確認 | session_id, sequence_number |
介面實作 MUST：
- 支援長連線以承載
Heartbeat和非同步推送訊息 - 支援 TLS 加密傳輸
- 序列化格式遵循
schema.json定義
介面實作 MAY：
- 選擇具體的傳輸協議（WebSocket、gRPC、HTTP/2 等）
1.3.2 與終端作業系統的介面
Protocol_Engine 與終端作業系統之間的介面為本地雙向介面。
作業系統 MUST 向 Protocol_Engine 暴露以下能力：
- 資源存取控制下發：Protocol_Engine 下發「允許 Fay X 以模式 Y 存取資源 Z」的指令
- 資源狀態查詢：Protocol_Engine 查詢資源的目前可用性和佔用狀態
- 資源事件訂閱：Protocol_Engine 訂閱資源狀態變化事件（如硬體斷線、軟體崩潰）
介面的具體實作方式取決於作業系統平台（Unix Domain Socket、Named Pipe、D-Bus 等）。本規範不規定具體實作方式，但 MUST 滿足：
- 存取控制指令以同步方式執行，並返回執行結果
- 資源事件以非同步推送方式通知
- 介面受作業系統原生安全模型保護，僅授權的 Protocol_Engine 程序可呼叫
1.3.3 與硬體驅動程式的介面（間接）
Protocol_Engine MUST NOT 直接與硬體驅動程式通訊。所有硬體控制透過作業系統轉發。
硬體驅動程式到 Protocol_Engine 的狀態上報路徑：
硬體驅動程式 → 作業系統 → Protocol_Engine
硬體驅動程式 SHOULD 實作硬體級存取鎖定機制，確保即使作業系統層面的存取控制被繞過，硬體本身仍可拒絕未授權存取。
1.3.4 與 Registration_Authority 的介面
Registration_Authority 與終端之間的介面為單向介面（RA → 終端）。
Registration_Authority MUST 向終端推送以下訊息：
| 訊息類型 | 用途 | 必填欄位 |
|---|---|---|
VerificationKeyDistribution | 分發新的校驗金鑰 | key_id, key_material, valid_from, issuer_id |
VerificationKeyRevocation | 撤銷校驗金鑰 | key_id, revocation_time, reason |
RegistrationStatusUpdate | 更新終端註冊狀態 | terminal_id, new_status |
終端 MUST：
- 透過 TLS/mTLS 安全通道接收訊息
- 驗證訊息的簽章來源為已信任的 Registration_Authority
- 在接收新金鑰後向 Registration_Authority 返回確認
終端不主動向 Registration_Authority 發起協議訊息（終端的初始註冊流程不屬於 CAP 協議執行時常態互動，超出本規範範圍）。
1.4 角色與一致性等級對應表
| 實作的角色 | 必須滿足的一致性等級 |
|---|---|
| 終端（含 Protocol_Engine 和 Descriptor_Validator） | 終端一致性等級（§0.5.1） |
| Descriptor_Issuer 或 Ticket_Issuer | 簽發方一致性等級（§0.5.2） |
| iFay_Runtime | 執行時一致性等級（§0.5.3） |
| Registration_Authority | 不在本規範一致性範圍內（註冊流程超出 CAP 協議執行時） |