规范

Faying Protocol/1.0 — §1 Overview

协议正文导航：章节目录 ｜ 下一章 §2 架构

§1 Overview

本章交代 Faying Protocol 是什么、解决什么、不解决什么：协议命名、它在技术栈里的位置、八项设计目标、与 OAuth/WebAuthn 等现有方案的分工、一句话定义、规范的覆盖范围和明确的非目标，以及版本管理与兼容性规则。读完本章，后面 §2–§11 与附录的术语和约束就有了落脚点。

文中规则后以 Trace: 标出对应的 EARS 子条款编号（出处见本规范需求基线），格式为 R<requirement>.<criterion>.<clause>，方便回查需求来源。

§1.1 协议命名

协议规范名为 Faying Protocol，版本号写作 Faying Protocol/1.0。

协议没有独立缩写，需要简称时就用全名。早期草稿用过 "Faying Auth Protocol（FAP）"，现已弃用：新文档不再出现 FAP、FAP/1.0、Faying Auth Protocol、application/fap+json、POST /fap/v1/... 这类旧写法。如果在外部资料里碰到 FAP，把它当作 Faying Protocol 的旧称即可。

§1.2 协议定位

Faying Protocol 是 TLS 之上的应用层"持续性授权层"协议，承载"人类原型对其 iFay 在何种在场状态下、就何种范围、以何种等级、于何时段授权"这一组语义。

  • TLS 之下：信道机密性与对端身份由 TLS 1.3（含 mTLS 选用）承担，Faying Protocol 不重做。
  • OAuth/OIDC 旁侧：OAuth 给应用授权，OIDC 做身份断言，二者均为"瞬时令牌"模型；Faying Protocol 解决两者都不解决的问题——持续性代理 + 在场绑定 + 等级切换 + 责任归属唯一。
  • WebAuthn 之上：WebAuthn / FIDO2 为人类原型在 Bootstrapping 阶段提供"用户在场"的硬件级证明，Faying Protocol 复用其凭据形态作为派生信任的根。

Faying Protocol 不取代 TLS，亦不重新发明 OAuth；它在 TLS 之上、业务语义之下，强制把每一次 iFay 对外行为经过 Mandate 校验闸门。任何绕开本协议闸门的对外调用即视为 Rogue Action，必须在传输层之上、业务层之下的中间件被拒绝。

§1.3 设计目标

下表给出 Faying Protocol 的 8 项设计目标 G1–G8（核心目标）以及由 §9 / §5 派生的 2 项工程目标（安全属性 / 协议互操作性）。每项目标对齐到需求基线的恰好一条 Requirement，构成本协议正文与 Requirements 文档之间的双向回链锚点。

目标含义蓝图来源对应 Requirement
G1 责任归属唯一任意时刻 iFay 的对外行为都可被无歧义归责到一位 Human Prime（人类原型）第 13 章伦理底线Requirement 1
G2 默认拒绝没有有效 Mandate → 不可对外行动；任一字段缺失即拒绝第 13 章 Rogue 默认Requirement 2
G3 可观测、可审计、可撤销状态迁移、Action 发起、续期 / 撤销三类事件全部可观测、可审计、可独立校验第 11、13 章Requirement 3
G4 对称撤销撤销通路的可达性 ≥ 建立通路的可达性，撤销不可逆第 10、12 章Requirement 4
G5 持续校准在场信号与 Mandate 等级在每一时刻可被重新确认；不缓存过期信任第 11、12 章Requirement 5
G6 等级化授权单一 Mandate 不可代表所有强度；等级必须可表达、可切换、可降级；升级必带 HP 见证用户原始要点 3Requirement 6
G7 跨设备可派生同一 iFay 跨终端工作时，信任可派生但责任端不变；scope / grade 严格收敛Phase 2/3 演进预留Requirement 7
G8 后量子可演进算法套件可协商、可滚动升级；PQC 协商位预留工程通用要求Requirement 8
—（派生）安全属性抗重放 / 抗劫持 / 抗钓鱼 / 脱钩态识别 / AI-Era Adversarial Threats§9 安全考量Requirement 9（含 13 派生）
—（派生）协议互操作性CBOR / JSON 等价、Deterministic CBOR、跨实现兼容矩阵§5 协议报文Requirement 10

目标 ↔ Requirement 一对一原则：本表是协议正文与 Requirements 文档之间的唯一权威映射。后续章节在阐述任何不变式或机制时引用的 EARS 子条款编号 R<n>.<m>.<k>，其根 Requirement 编号 <n> 必落在本表"对应 Requirement"列内；由 G6 / G4 / G5 / G7 派生的 Endorsed_Mandate（Requirement 11）、Disconnection 策略（Requirement 12）、AI-Era 防护（Requirement 13）作为 G1–G8 的细化要求，分别在 §4 / §8 / §9 给出协议级落地。

§1.4 与现有方案的核心差异（一句话版）

现有方案解决了没解决 Faying Protocol 必须解决的
OAuth 2.0 / 2.1应用对资源的访问授权一次性 token，无等级、无在场、无对称撤销
OIDC SSO身份断言（who）没有持续性代理（acting on behalf of），无等级
mTLS信道两端的对端身份"谁在何种在场状态下委托谁做什么"无法表达
JWT自包含声明的签名无吊销、无等级语义、长寿命与"对称撤销"冲突
FIDO2 / WebAuthn人类原型的硬件级在场证明仅覆盖登录瞬时，不覆盖 iFay 的持续代理
Macaroons带 caveats 的可派生 token无在场绑定、无人类原型显式见证
SPIFFE / SPIRE工作负载身份工作负载视角，无人类责任端

Faying Protocol 不与上述任一方案竞争——它在 TLS 之上、业务语义之下补齐"人类原型 ↔ iFay"这一组专属语义：持续性代理 + 在场绑定 + 等级切换 + 责任归属唯一 + 对称撤销。

§1.5 一句话定义

Faying Protocol = "Mandate（替代 token）+ Presence Signal（在场信号）+ Attestation Chain（证言链）+ Revocation Registry（撤销登记）"四元在 TLS 之上协同表达的、由人类原型与 iFay 双向发起、由人类原型显式认可生效、持续校准、对称撤销的授权契约。

§1.5.1 双向 Faying 由 HP 显式认可生效（核心断言）

Faying 关系（建立或调整）的发起为双向：

  • HP-initiated：Human Prime（人类原型）可主动发起 Faying，走 BOOTSTRAP 通道（详见 §2.4 Phase A、§5.3.1）；
  • IF-initiated：iFay 可主动向 Human Prime 寻求 Faying（即 FAYING_REQUEST），走 §2.4 Phase A0 → BOOTSTRAP 两步路径（详见 §5.3.6）。

但无论哪一方发起，Faying 状态变化的最终生效条件均为 Human Prime 给出明确的、不被欺骗的、可验证的认可确认（默认形态为 WebAuthn 用户在场断言或等价的硬件级证明）。

由此立刻得出本协议的三条不可逾越的硬约束：

  1. iFay 自身不构成 Faying 生效条件：iFay 主动发起的 FAYING_REQUEST 若未在 BootstrapTimeout（默认 60s，详见附录 B）内获 HP 明确认可即过期或被拒，不产生任何 Faying 状态变化。Mandate_Service 必须返 E_FAYING_REQUEST_NOT_CONFIRMED（错误码 1014），并将事件写入 Attestation Chain 以保留"何方发起、何时确认、是否生效"的不可逆证据。
    • Trace：R1.3.2（IF-initiated 路径仅在 HP 明确认可确认后生效）、R1.3.3（BootstrapTimeout 内未认可即拒绝且无状态变化）、R1.3.4（无论生效与否均写入 AC）。
  2. 替代见证路径不存在：协议层不提供任何由 iFay、Mandate_Service、Supervisory_Agent 替代 Human Prime 完成 Faying 认可确认的合法路径。任何缺失 human_witness 或 human_witness 校验失败的 BOOTSTRAP 都必须以 E_HUMAN_WITNESS_REQUIRED（错误码 1010）拒绝。
    • Trace：R1.3.5（不提供任何由 IF / MS / SA 替代 HP 完成 Faying 认可确认的合法路径）。
  3. 撤销不可被 iFay 单方面绕过：iFay 可发起"请求断开 Faying"的报文（视为 Disclosure_Report），但 iFay 不拥有撤销自身 Mandate 的权力；任何撤销最终必须由 Human Prime 或合规意义上的权威机构发起并经 HP 视野通道可见（详见 §4 / §10）。
    • Trace：R4.1.4（IF 不拥有撤销自身 Mandate 的权力）、R4.1.5（断开请求作为 Disclosure_Report 写入 AC 并推送 HP 视野）。

本款是 §2.4 Phase A0、§5.3.6 FAYING_REQUEST、§5.4 错误码 1010 / 1014 在 Overview 层的统一锚点，亦是后续章节关于"无 HP 见证则无 Faying"的所有论证起点。

§1.6 协议产出物范围与非目标

§1.6.1 范围内（Normative，本协议正文承担）

本协议正文（即本单一文件）规范且仅规范下列内容：

  • 协议数据对象：Mandate / Presence_Signal / Attestation / SignatureBundle / Faying Protocol Envelope / Endorsed_Mandate / Disclosure_Report 等的 CBOR 主格式与 JSON 回退格式（CDDL 权威，详见 §4 / §5）。
    • Trace：R10.1.1、R10.1.2、R10.2.1–R10.2.4。
  • 协议组件接口：Mandate_Service / Presence_Channel / Attestation_Chain / Revocation_Registry / Liveness_Channel / Behavior_Baseline_Service 的职责边界与不变式（详见 §3）。
  • 协议报文：BOOTSTRAP / PRESENCE / GRADE_SWITCH / DELEGATE / REVOKE / FAYING_REQUEST / DISCLOSURE 七类报文的字段定义、错误码与协议级硬约束（详见 §5）。
  • 密码学规则：算法套件协商、密钥派生层次、签名输入规范化（含 Endorsed_Mandate 的签名输入锚点，详见 §6）。
    • Trace：R8.1.1–R8.1.4、R8.2.1–R8.2.4。
  • 授权等级语义：G0–G4 五档等级精确定义、触发条件矩阵、降级单调性原则、Endorsement Grades 子等级（详见 §7）。
    • Trace：R5.1.1、R6.1.1、R6.1.2。
  • 生命周期与状态机：Unpaired / Pairing / Active / Degraded / Disconnected / Suspended / Revoked 七个状态的迁移条件与重连对账事务（详见 §8）。
  • 安全考虑：STRIDE 威胁模型、抗重放 / 抗劫持 / 抗钓鱼 / 脱钩态识别、跨设备派生信任传递、AI-Era Adversarial Threats T1–T7（详见 §9）。
  • 错误处理：14 项错误码（含 1010 E_HUMAN_WITNESS_REQUIRED、1013 E_ENDORSEMENT_INVALID、1014 E_FAYING_REQUEST_NOT_CONFIRMED）的协议响应、恢复路径、可观测性约束、Default-Deny 收敛（详见 §10）。
    • Trace：R2.1.1–R2.1.4（默认拒绝）、R3.3.1（HP 视野通道必达）。
  • 附录：术语对齐速查（附录 A）、默认参数预算（附录 B）。

§1.6.2 范围外（Non-normative，本协议不承担）

下列内容不属于本协议正文规范范围，仅作为参考实现 / 工程指导，与本协议正文的兼容性测试无关：

  • 业务语义：iFay 的具体业务行为、终端驱动、应用集成方式；
  • UI / UX 设计：Human Prime 视野通道的具体呈现形式、确认弹窗设计、移动端 / 桌面端交互；
  • 运维与部署：Mandate_Service / Revocation_Registry 的高可用部署模型、扩缩容策略、跨区域同步；
  • 传输层细节：TLS 1.3 自身的握手细节（由 RFC 8446 规范）、HTTP/2 / gRPC / QUIC 的具体参数调优；
  • PD（Presence Device）实现：WebAuthn authenticator / TPM / Platform Keystore 自身的硬件实现（由 W3C / ISO / TCG 各自规范）；
  • 法律与合规细节：监管 / 合规方在协议外如何实施法律意义上的"权威机构"角色（协议层只规定其在 RevokeReason 枚举中的位置与签名链要求，不规定其法律建制）；
  • 参考实现代码：本协议任何 reference 实现（如 schemas/types.ts TypeScript 视图、pbt/ 属性测试套件）均明确标注 "Reference Implementation, Not Normative"，不构成协议本体；
  • 未决议题：§11 Open Questions 中所有 status: open 的条目。

§1.6.3 交付形态

本规范的正文按章拆分，共 §1–§11 共 11 个文件，加附录 A/B/C 三份，都放在 docs/zh-CN/specification/2025-10-25/ 下，章号文件名见 目录。其中附录 A（术语对齐速查）、附录 B（默认参数预算）为规范级参考；附录 C（变更日志）记录协议从草案到定稿的演进与版本号策略，供参与者了解协议如何成形与如何演进。

英文规范在 docs/en/specification/2025-10-25/，为单文件结构——协议正文（§1–§11 + 附录 A/B）全部内联在 Faying-Protocol-1.0.md 一个文件里，英文侧不维护附录 C（变更日志）这类中文侧独立文件。两侧的"一一对应"是章节锚点层面的对应：章节编号、Mermaid 图、CDDL / TypeScript 代码块、错误码表、附录 A/B 逐一对齐，而非文件逐一对应。中英文出现歧义时以中文为准，并在下次评审同步修正英文。

§1.7 版本管理与兼容性

本节是 Faying Protocol 版本编号的权威定义。版本号不只是文档标记，它是互操作契约的一部分——会出现在线信封、schema、协商位中，直接决定两个独立实现能否对话。因此本节为 Normative：实现者必须按本节规则解读版本号、执行版本协商。附录 C 变更日志只记录历史，不重复定义规则。

§1.7.1 三条正交的版本轴

Faying Protocol 用三条相互独立的轴描述一份规范的版本，三者不可混为一个号：

轴回答的问题形态载体示例
协议版本（互操作契约）两个实现能否对话MAJOR.MINOR散文 / 线信封 version 字段 / schema 文件名Faying Protocol/1.0
文档状态（生命周期）这份规范定稿了没枚举front matter statusDraft / Final / Deprecated / Obsolete
编辑版次（勘误与澄清）同一协议版本下的第几次文字修订发布日期发布目录名 / front matter date2025-10-25

核心约束：只有"协议版本"MAJOR.MINOR 进入线格式（信封 version 字段、schema 文件名）。文档状态与编辑版次不得进入线格式——它们是文档治理标记，不参与互操作判定。一个实现绝不能因为对端的文档状态或编辑版次不同而改变其报文处理行为。

§1.7.2 协议版本 MAJOR.MINOR 语义

协议版本号写作 Faying Protocol/MAJOR.MINOR，只设两级，不设 PATCH 位——线格式与互操作语义只区分两档兼容性。

  • MAJOR（破坏性变更）：任何会使一个严格按旧版规范实现的对端拒绝或误解新报文的变更。例如：改变 §4.2 CDDL 权威 schema 的字段语义、删除报文类型、重定义错误码语义、改变状态机的吸收态。
    • 规则：MAJOR 进位、MINOR 归零（如 1.4 → 2.0）。
    • 兼容性：不同 MAJOR 之间不保证互操作。
  • MINOR（向后兼容增补）：新实现能理解旧报文、旧实现可安全忽略其不认识的可选项的增补。例如：增加可选字段、新增报文或错误码、新增 AI-Era 威胁目录条目、新增附录参数、新增 Correctness Property。
    • 规则：MINOR 自增（如 1.0 → 1.1）。
    • 兼容性：同 MAJOR 内,高 MINOR 必须保持对低 MINOR 的向后兼容。

判据（实现者自检）：改动会不会让一个严格按旧版规范实现的对端拒绝或误解新报文？

  • 会 → MAJOR；
  • 不会、但新增了线格式可见的内容 → MINOR；
  • 只动文字、不动任何线格式语义（修 typo、补例子、澄清歧义）→ 不动协议版本，走 §1.7.4 编辑版次。

当前基线为 Faying Protocol/1.0。

§1.7.3 版本协商与兼容性规则（Normative）

版本协商复用 §6.1 算法套件协商的同一口径（各自声明、取共同支持的最高值）。实现必须遵循：

  1. 声明：BOOTSTRAP 阶段，客户端与服务端各自声明其支持的协议版本集合（如 supported: [1.0, 1.1]）。
  2. 同 MAJOR 取最高 MINOR：双方 MAJOR 相同时，必须选择二者共同支持的最高 MINOR 作为本次会话的生效版本；高 MINOR 实现必须能服务低 MINOR 对端（向下兼容到 MAJOR.0）。
  3. 跨 MAJOR 拒绝：双方不存在共同支持的 MAJOR 时，不进行协商，必须以 E_PROTOCOL（错误码 1099）拒绝该次 BOOTSTRAP，不得"尽力而为"地降级互通。
  4. 滚动升级不破坏既有 Mandate：通过版本协商引入新的默认算法套件或新 MINOR 时，必须保证既有 Mandate 在其 not_after 之前仍可被校验；版本升级不得使在途的有效 Mandate 失效。
    • Trace：R8.2.4（版本协商滚动升级且不破坏既有 Mandate 可校验性）。
  5. 未知高 MINOR 的处理：收到声明为同 MAJOR、但 MINOR 高于自身的报文时，实现必须按自身支持的最高 MINOR 解读，并忽略其不认识的可选字段（而非拒绝）；这正是 MINOR 向后兼容承诺的运行期落点。

§1.7.4 编辑版次与勘误（Non-normative 改动）

Faying Protocol/1.0 定稿（Final）之后，难免出现纯文字勘误——修 typo、补充示例、澄清歧义、修内部链接。这类改动：

  • 不得改动协议版本号（否则等于谎称互操作契约变了）；
  • 以发布日期作为版次锚点：例如 Faying Protocol/1.0 (2025-10-25) 为 1.0 的首个 Final 版次，后续勘误产生新的发布目录（如 2026-03-xx/），协议版本仍为 1.0；
  • 在附录 C 变更日志中以 Editorial 类目登记，并在 front matter 以 edition 字段标注版次迁移；
  • 硬约束：编辑版次只允许 Non-normative 改动。任何动到线格式语义的修改,必须升 MINOR 或 MAJOR,不得伪装成编辑勘误发布。

§1.7.5 版本号的落点与标准执行者注意事项

下表给出版本号在各处的确切落点；实现者据此判断"哪些差异影响互操作、哪些不影响"：

落点写什么注意事项
线信封 version 字段（§5.2）"Faying Protocol/MAJOR.MINOR"只放 MAJOR.MINOR；不放版次日期、不放文档状态
schema 文件名（fap-1.0.cddl 等）跟随 MAJOR.MINOR文件名不随编辑版次改名——勘误不改 fap-1.0.cddl，以保持已有引用稳定（早期 fap 前缀的保留亦同此理，见附录 C）
content-type（§5.1）application/faying-protocol+cbor（或 +json）content-type 标识协议族；如需在网关层按版本路由，可附带 version= 参数作为部署便利，但该参数不属于线格式语义、不影响兼容性判定
front matter status / date文档状态 / 编辑版次文档治理标记，不进线格式，对端不得据此改变报文处理
git tagfaying-protocol-v<MAJOR.MINOR>-<状态>定稿 faying-protocol-v1.0-final；版次快照 faying-protocol-v1.0-2026-03-xx；tag 必须同时覆盖正文 + vectors/ + schemas/，互操作三件套一起冻结

标准执行者必读注意事项：

  1. 判定互操作只看协议版本：决定"能否对话"的唯一依据是 MAJOR.MINOR。对端的文档状态（Draft/Final）、编辑版次（发布日期）都不改变互操作行为——绝不要因为对端标的是 Draft 或版次较旧就拒绝其合法报文。
  2. 同 MAJOR 必须向下兼容：实现一个高 MINOR 版本时，必须同时能正确服务 MAJOR.0 起的所有低 MINOR 对端。
  3. 不要把勘误当升级：看到发布目录日期变化（编辑版次）不代表协议变了；只有 MAJOR.MINOR 变化才需要评估互操作影响。
  4. schema 文件名稳定性：不要依赖文件名编码版次；同一 MAJOR.MINOR 的勘误复用同名 schema 文件，以 git tag / 发布目录区分版次。
  5. Draft 期间无兼容性承诺：status: Draft 期间，MAJOR.MINOR 可能在未冻结的前提下调整；只有 Final 之后,本节的 MAJOR/MINOR 兼容性承诺才完全生效。