第 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 协议运行时） |