即時入口
暫時身分啟動橋接
公開的 passkey-first 登入流程尚未啟用。若要做第一次擁有者啟動，Ronova ID 可以從既有的 Ronova private 管理工作階段導出一個暫時的高信任工作階段。
這條橋接路徑刻意保持狹窄：它要求既有的 private 管理工作階段，而且不會替其他網域建立共享 Cookie。
治理介面
在完整身分模型中切換
管理治理建立在同一套身分基礎與同一套帳戶端檢視模型之上。
治理
管理介面控制什麼
管理介面是 Ronova ID 從抽象架構走到實際控制面的地方。
用戶端註冊
每個應用程式與每個主控台都要先完成註冊，帶著已知回返目標與已知權限邊界，之後才能要求身分。
高信任介面不應該以無名用戶端出現。
權限組合
權限被打包成角色，好讓重複性工作不必每次都臨時裁切權限。
授權與審查都會因此簡單得多。
稽核流
稽核流應把身分事件、用戶端、操作者與實際改動連在一起。
平時治理與事件應對都能受益。
治理循環
管理變更路徑
敏感的身分變更應該走過一條有意識的流程，而不是變成一鍵魔法。
- 01
替用戶端命名
先為應用程式命名、登錄回返路徑，並把用途寫到之後的審查者也看得懂。
- 02
設定範圍
只附上真正需要的權限，並把重複工作整理成具名角色。
- 03
有意識地核准
在操作者、理由與目標身分都清楚可見的情況下，決定核准或拒絕高權限存取。
- 04
稽核結果
回頭檢視產生的稽核鏈，確認這次變更是否真的按治理預期運作。
管理目錄
管理者治理的內容
管理介面應該像一本受控台帳，而不是一間祕密後台。
用戶端註冊表
維護允許的應用程式、它們的回返路徑，以及它們可以索取的權限。
整份目錄從用戶端註冊開始。
角色目錄
把權限整理成具名角色，讓營運人員、審查者與擁有者使用可預測的責任組合。
打包後能減少臨時拼裝的權限。
稽核總覽
在同一個介面裡檢視登入、核准、撤銷、導轉結果與敏感變更。
稽核檢視讓身分治理保持可讀。
原則
管理治理原則
管理不只是關於權力，也關於證明這份權力有被限制、被審視，而且綁在正確的用戶端上。
先收窄
新的用戶端與新的角色都應該先從保守邊界開始，只有在真實工作證明需求之後才擴張。
最小權限應該是起點，不是補丁。
有意識地升階
高影響變更應要求更強的確認，或要求一個明顯分開的升階工作階段後才繼續。
逐步升階讓敏感工作保持分層。
讓邊界可檢查
身分團隊與應用程式團隊都需要足夠共享視野，才能跨兩邊追查導轉、授權或濫用問題。
邊界越看得見，治理越站得住腳。