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 覆盖范围后，该授权自动降级为离线模式继续生效