憑證管理

憑證管理聽起來非常工程化——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 不成立；
• 撤銷權必須保留在人類原型一側；
• 續期不是預設行為。

具體簽章演算法、金鑰層次、撤銷列表傳播、續期時間窗的精細化設計、跨廠商互信的根憑證結構、撤銷的最終一致性等技術細節——屬於協定規範的範疇。本章既不複述、也不預決，但任何技術方案都必須先服從上述四條立場。