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 协议核心功能（特别是离线授权校验）的正常运行