規範

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-TW/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 逐一對齊，而非檔案逐一對應。中英文出現歧義時以中文為準，並在下次評審同步修正英文。此外，本繁體中文版以簡體中文（zh-CN）為正源；繁體版若與簡體正源有歧義，以簡體中文為準。

§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 相容性承諾才完全生效。