凭据管理

凭据管理听起来非常工程化——FayID 的签发、签名、撤销、续期，每一项都涉及具体算法与密钥协议。但在本蓝图中，凭据管理被放进价值观，不是技术议题。

原因是这样：Faying Protocol 之所以存在，是为了把"行动归谁负责"这件事显式表达出来。这件事的全部技术承接，落到具体协议层面，就是凭据。凭据回答两个问题：

此刻这个 Fay 是不是它声称的那个 Fay？ 此刻这个 Fay 是否仍被它的人类原型授权？

两个问题都不是工程问题，是责任问题。一旦凭据可以被仿冒、被滥用、或被某个第三方在人类原型之外悄悄签发，Faying Protocol 的全部价值瞬间归零——人类原型不再是责任的真正持有者。

具体的算法、签名格式、密钥协议等技术细节属于协议规范文档与 schema 的范畴，本章不展开。本章只声明在凭据管理上不可被让步的几条立场。

FayID 是 Fay 进入 Faying State 的身份基础

FayID 是 Fay 在 iFay 框架中的统一唯一身份标识。Faying Protocol 的全部监护契约都建立在 FayID 之上。Faying Action 必须明确"哪一个 FayID 进入 Faying State"；Faying State 的归责必须明确"哪一个 FayID 归属于哪一个人类原型"；Faying State 的退出必须明确"哪一个 FayID 转入 Rogue Fay"。

如果 FayID 不可被信赖，上述三处的全部判断都失去意义。

凭据失效即 Faying 失效

第十三章列出的九项 Faying State → Rogue Fay 自动迁移触发条件中，第 6 条明确写着：

Fay 身份不能被验证（例如 FayID 签名失效）。

这一条不是九条之中"恰好"涉及凭据，是凭据管理在协议层面不可被绕过的具体落点。一旦 FayID 的有效性出现问题，无论 Fay 此前的工作多么连续、多么接近完成，Faying State 都必须立即退出：

凭据有效性的疑虑，等同于 Faying State 已经失效。

不存在"凭据可疑但 Faying State 仍然成立"的中间情形，也不存在"先把当前任务做完再处理凭据问题"的工程妥协。

撤销权必须保留在人类原型一侧

凭据管理在协议设计上有一个看似细节、但极其关键的取舍——凭据的撤销权，最终归谁？答案是显然的：归人类原型。

Fay 自身不应拥有撤销自身凭据的合法路径——这与第十三章 D4 同源，Fay 不能自我决定脱离监护，也不能自我决定切断监护链路。

第三方平台、Fay 的运行时供应商、Fay 的能力提供方，均不应拥有不经过人类原型同意即可撤销其 FayID 的权力——除非该第三方是合规意义上的权威机构（参见第十三章触发条件第 8 条）。

人类原型必须始终保有一条对称、可达、可被审计的撤销通路。撤销动作的可达程度，必须不低于发起 Faying Action 的可达程度。这是 Faying Protocol 中"对称性"原则在凭据层面的具体落地：建立监护与撤销监护，必须是同等可达的两条路径。一旦撤销变得比建立更困难，监护关系就在事实上滑向了"不可撤销的委托"，进而违反 Human View 的"干预通路常开"要求。

续期不是默认行为

第十二章给 Faying State 提了一条硬约束：Faying State 必须是有限范围的，无限期 Faying 是反模式。这条约束在凭据层面对应的具体立场是——凭据的续期不应被默认完成。

每一次续期都应是一次显式的、可被见证的动作，而不是"Fay 自动提交、系统自动续签"的隐性循环。蓝图允许在工程层面提供"续期提醒"、"续期建议"等便利机制，但禁止把"续期"做成 Fay 自身可以静默完成的事——那将把 Faying 在事实上变成无限期委托。

从责任视角理解：续期是责任端重新表达监护意图的时刻。如果连续期都被工程默默完成，那么"监护"就只剩一个签名，没有意图。

几条不可被违反的红线

凭据管理的几条价值观立场，是任何技术方案在落地时不可被违反的红线：

• FayID 是身份基础；
• 凭据不可信即 Faying 不成立；
• 撤销权必须保留在人类原型一侧；
• 续期不是默认行为。

具体签名算法、密钥层次、撤销列表传播、续期时间窗的精细化设计、跨厂商互信的根证书结构、撤销的最终一致性等技术细节——属于协议规范的范畴。本章既不复述、也不预决，但任何技术方案都必须先服从上述四条立场。