第 7 章 Open Questions（未決議題）
本章列出在當前協定層暫不決定、留待實作側 spec、後續協定版本或獨立 ADR 解決的開放問題。每條議題都對應 design.md 第 10 節的相同條目，可在後續任務 8 完成 open-questions.md 歸檔時進一步細化。
這些議題不是 FayID 協定的缺陷，而是有意保留的擴展點。它們的共同特徵是：在協定層過早決定會限制實作自由度，或會因生態演進而需要調整。
1. 具體雜湊 / 簽章 / KDF 演算法
議題：協定層僅給出候選（Ed25519 / HKDF-SHA256 / BIP-39），最終選型留待實作 spec 決定。
影響範圍：跨實作互通操作性、密碼學稽核
解決方向：在實作 spec 中固定演算法，並伴隨版本化（如 fayid/dyn/v1、fayid/gmc/v1 中的 v1 後綴）。未來升級演算法時透過新版本號實作共存。
2. Dynamic Code 時間窗長度
議題：協定層僅要求 Dynamic Code 存在 expiresAt，具體長度（分鐘級 / 小時級）由實作策略決定。
影響範圍：使用者體驗、隱私強度、輪換頻率
解決方向：實作側根據場景客製。高安全場景使用短窗口（如 5 分鐘），常規場景可放寬到小時級。
3. Verification Code 校驗失敗的限速閾值
議題：VERIFICATION_RATE_LIMITED 的窗口寬度、失敗次數閾值、退避策略均為實作側決策。
影響範圍：抗暴力破解、使用者體驗
解決方向：參考業界標準（如指數退避），由實作 spec 給出預設值。
4. Authorization Grant 預設 TTL 與續期模型
議題：協定層只要求 expiresAt 顯式存在；續期 / 滑動過期 / 短 TTL + 重新整理權杖等具體模型留待實作 spec。
影響範圍：使用者體驗、安全性、與傳統鑑權來源的互通操作
解決方向：實作 spec 中可能引入 RefreshGrant 類型；亦可針對不同 legacySourceKind 套用差異化 TTL。
5. Human ID 撤銷語義
議題：當前協定層 Human ID 不進入 REVOKED 狀態。Mnemonic 洩漏後的「補救」路徑（如 Human ID 重發、信譽遷移）超出本規範範圍。
影響範圍：災難復原、信譽連續性
解決方向：可能演化為：
- 在更高層引入「信譽遷移」機制（舊 opaqueRef → 新 opaqueRef 的鏈上聲明）
- 或在協定 v2 中引入有限制的 Human ID 撤銷 + 接班機制
6. resourceRef 命名空間規範
議題：本規範僅給出 <scheme>://<authority>/<path> 形式建議，正式語法可能演化為獨立 spec 或對接現有 URI 標準。
影響範圍：跨實作互通操作
解決方向：可能形成獨立的「FayID Resource Identifier」規範，或直接採用 RFC 3986 URI 標準。
7. 跨 FayID System 實例的互通操作性
議題：當存在多個 FayID System 部署（不同營運方）時，Human ID / iFay ID / Organization ID 的全域唯一性需要全域命名空間或前綴分區機制。
影響範圍：多營運方生態、跨鏈互通操作
解決方向：可能演化為 FayID v2 的核心議題。候選方案包括：
- 命名空間前綴（如
hid_us_xxxvshid_eu_xxx） - DNSSec 風格的根命名權威
- 鏈上註冊表
8. GMC opaqueRef 的金鑰滾動
議題：gmc_namespace_secret 的輪換會破壞長期信譽關聯——同一 Human ID 在新舊金鑰下派生的 opaqueRef 不同。
影響範圍：信譽連續性、金鑰安全
解決方向：
- 設計新舊 namespace_secret 共存窗口
- 或透過鏈上「opaqueRef 遷移聲明」建立新舊引用的等價關係
- 此議題需要獨立 ADR
9. Property P9 的執行機制
議題：協定層規定「Human ID 不出站不入日誌」的行為；實作側的強制機制（型別系統標籤、序列化 redact、CI 靜態掃描）由實作 spec 選擇。
影響範圍：實作品質、安全稽核
解決方向：
- 型別系統層面：使用 newtype / branded type 區分 Human ID 與其他實體
- 序列化層面：預設 redact，顯式開關白名單
- CI 層面：靜態掃描出站載荷與日誌路徑
10. 傳統鑑權來源的可信度分級
議題：所有傳統憑據是否平權地兌換 Authorization Grant？是否對 SMART_CONTRACT 與 PASSWORD 套用不同 TTL 上限？
影響範圍：安全策略、風險控制
解決方向：
- 引入
legacySourceKind到 TTL 上限的對應 - 對低可信來源（如簡單 PASSWORD）套用更短 TTL
- 對高可信來源（如 SMART_CONTRACT）放寬限制
歸檔與追蹤
上述 10 條議題將在後續任務 8 中歸檔至 .kiro/specs/fayid-identity-system/open-questions.md，每條標註：
- owner：議題主理人
- 影響範圍：受影響的子系統
- 解決里程碑：v1 / v2 / 實作 spec / ADR
本章作為藍圖的「未決議題」索引，僅複述議題概要；詳細的歸檔與追蹤請查閱後續生成的
open-questions.md。