D-20260806-01｜OPAQUE 角色邀請驗證¶
背景與驅動力¶
D-20260710-05 的自訂 SHA-256 挑戰－應答讓 participant 密碼不直接上行，D-20260802-07 則允許 spectator 密碼在加密的 room-control request 上行。兩者符合當時假設，但若把惡意或 偽造 successor host 納入 credential-confidentiality 威脅模型，自訂 verifier、角色間不同的 密碼處理與未綁完整 admission context 的 proof 都不是合適的開發期安全基線。
考慮過的選項¶
- 保留 participant challenge-response，只替 spectator 補同形 proof：仍是自訂協議，且 verifier 可被離線猜測，否決。
- 使用 SPAKE2+：標準本身可行，但評估到的瀏覽器套件仍為 pre-1.0 且明示未完成獨立稽核， 不作目前實作基線。
- 使用 TLS／DataChannel 加密後直接傳送角色 secret：傳輸層只保護線路，不防已連線的惡意 admission server 取得 secret，否決。
- 採 RFC 9807 OPAQUE，並限定使用有獨立安全稽核、可驗 RFC 向量的實作（採納）。
決定¶
- participant 與 spectator 統一使用 RFC 9807 OPAQUE；舊
sha256(nonce ‖ password ‖ joinerPeerId)、spectator plaintext field 與 wire fallback 一次移除，版本不相容時 fail closed。 - 角色 invitation 由 CSPRNG 產生 192-bit secret，不接受人類自訂低熵密碼。credential 依
roomId、role 與 epoch 隔離；連結只可放 URL fragment，讀取後立即清除網址顯示。 - OPAQUE 後再以輸出的 session key 做雙向 key confirmation，涵蓋 protocol version、
roomId、 role、epoch、joiner PeerId、expected host PeerId、雙方 nonce 與 OPAQUE transcript hash。 任一欄不符即拒絕，不可把一次 admission proof 用到其他角色、房間、主機或 epoch。 - participant successor 只接收維持 participant admission 所需的 OPAQUE server state，經已 驗證 session 加密傳送、只存於目前 RoomSession；不得包含 participant plaintext secret。 spectator server state 與 secret 不進 succession bundle；房主接替時 spectator policy fail closed、epoch 遞增，必須由新房主重新啟用並產生新 invitation。
- invitation secret 只可存在建立／加入流程記憶體與既有 reload 所需的
sessionStorage，離房、 lock、角色撤銷或 epoch 變更時清除；不得進localStorage、IndexedDB、log、telemetry、URL query、錯誤訊息或 Graphify 輸出。錯誤對外統一，host 端另作每 PeerId／房間的線上限速。 - 實作必須鎖定精確版本、通過 RFC／套件向量與專案負向測試。現行候選為以已稽核
opaque-ke為核心的@serenity-kit/opaque；若稽核狀態、RFC 相容性或瀏覽器供應鏈檢查 不成立，實作必須停住重新裁決，不得退回自訂密碼學。
後果與影響¶
惡意 admission server 不再直接取得角色 secret；偽造 successor、跨房、跨角色與跨 epoch 重放也無法只靠搬運 proof 通過。代價是 room wire、host succession、invite UX、測試向量與 依賴供應鏈需同步重構，且舊房間不相容。
本決策保護的是 credential confidentiality、server authentication 與 context binding，不宣稱 能強迫已合法當選的惡意房主提供服務或遵守其本地 admission policy；持有可轉讓 invitation 的合法參與者也可能主動外洩該 invitation。若要抵抗這兩者，必須另行採一人一憑證與 quorum admission，不能以 PAKE 名義擴張保證。