題干與適用場景
多個教育機構希望共享可驗證的機構與簽發者目錄，但不想依賴單一中心註冊表。請說明如何建模 RecognizedEntity、RecognizedAction 和 VerifiableRecognitionCredential，並處理隱私、撤銷、冒充和多目錄衝突。
W3C Recognized Entities v1.0 目前是 First Public Working Draft。它描述實體被某個生態認可執行特定動作的資料模型，允許把認可資訊發布或直接交給驗證者。題目考察可驗證資料建模和信任決策，不要求把工作草案當作最終標準。
面試官考察點
面試官會關注你是否把實體、動作、認可者、憑證有效期和驗證策略分開，能否建立多目錄交叉驗證、撤銷和隱私邊界。高品質回答還會指出持有者提供的憑證不一定被驗證者接受，認可聲明不能自動等於業務授權。
回答前需要釐清的問題
- 誰是認可者、被認可實體和最終驗證者？各自信任哪些目錄？
- 認可是簽發、驗證還是其他動作，動作範圍和輸出 schema 如何定義？
- 憑證是否直接交給驗證者，還是必須回源查詢最新狀態？
- 需要支援哪些撤銷、有效期、金鑰輪換和隱私要求？
- 不同目錄出現衝突時，誰負責裁決和記錄理由？
30 秒回答框架
「我會把實體、動作、認可者和憑證聲明拆成可驗證物件。RecognizedEntity 透過全域識別關聯 recognizedTo 動作，動作帶有 recognizedBy 和輸出 schema，VerifiableRecognitionCredential 記錄簽發者、有效期和主體集合。驗證器先驗證憑證簽名、狀態和時間，再按信任策略選擇認可者、追溯認可鏈並檢查輸出 schema。持有者提供的憑證可減少回源查詢，但不能取代最新狀態檢查。對個人資訊採用最小揭露，對衝突、撤銷和金鑰輪換保留稽核與可回滾決策。」
分步驟深入解答
1. 建模實體、動作和認可關係
實體使用全域 URL 識別，recognizedTo 指向一個或多個 RecognizedAction。動作包含動作名、認可者和用於驗證輸出的 schema；不要把「機構是可信的」寫成無範圍布林值。recognizedIn 可以引用現有信任列表或另一份認可憑證，讓驗證器知道聲明來自哪個生態。
2. 封裝為可驗證憑證
憑證必須符合 Verifiable Credentials Data Model v2.0，並包含類型、issuer、validFrom、validUntil 和 credentialSubject 中的認可實體。簽名驗證只證明資料由某個金鑰簽發，不證明驗證者應該信任該簽發者，因此還要套用本地信任根、目錄允許清單和動作範圍。
credential = {
type: ["VerifiableCredential", "VerifiableRecognitionCredential"],
issuer: "did:web:accreditor.example",
validFrom: "2026-01-01T00:00:00Z",
credentialSubject: [{
id: "did:web:university.example",
recognizedTo: [{ action: "issue", outputValidation: [schema] }]
}]
}3. 設計驗證和認可鏈
驗證器先檢查格式、簽名、issuer、有效期、撤銷狀態和 schema，再判斷認可者是否在本地信任集合。若 recognizedBy 或 recognizedIn 形成多級鏈，設定最大深度、循環檢測和每一級有效期；不能因鏈條更長就自動提高信任。必要時同時比對 ETSI Trust Service Lists、X.509 CA 列表或其他受控目錄。
4. 處理新鮮度和撤銷
憑證可以直接由持有者提供，減少驗證者回源查詢，但驗證器仍需按風險決定是否檢查最新狀態。使用短有效期、狀態列表、撤銷通知或目錄版本；記錄驗證時間、使用的信任根和上下文雜湊。金鑰輪換、issuer 被攻破或動作範圍改變時，撤銷必須優先於快取命中。
5. 保護隱私與防止濫用
公開列出個人姓名、識別、組織關係和認可動作可能形成監控或「連帶污名」。按場景最小化欄位，優先讓持有者選擇性揭露；驗證器不應把一次認可擴展為對個人的其他推斷。防止惡意持有者傳播偽造認可憑證，實施簽名、狀態、來源和 schema 的聯合驗證，並限制可接受的 issuer。
6. 處理衝突和治理回滾
不同認可目錄可能對同一實體給出不同動作、有效期或狀態。先定義優先級、作用域、時間和衝突證據，再把選擇理由寫入稽核。Working Draft 變更時版本化上下文、schema 和驗證演算法，灰度讀取而不改變業務授權；出現冒充、隱私洩露或驗證回歸時，關閉新路徑並恢復舊目錄。
高品質示範回答
我會把 RecognizedEntity、RecognizedAction、認可者和 VerifiableRecognitionCredential 分開建模。實體使用全域 URL，動作明確名稱、認可者和輸出 schema，憑證符合 VC Data Model 2.0，記錄 issuer、有效期和主體。驗證器先檢查簽名、時間、撤銷和 schema，再用本地信任根和允許清單判斷是否接受認可者；多級認可鏈要限制深度並檢測循環，必要時與 ETSI 或 X.509 目錄交叉驗證。持有者提供憑證可以減少回源，但高風險場景仍需檢查新鮮狀態。隱私上最小化個人欄位，避免公開目錄形成監控或連帶污名。衝突按作用域、時間和治理優先級裁決並稽核，工作草案升級時版本化上下文和驗證器，出現冒充、撤銷延遲或隱私問題立即回滾到舊信任路徑。
常見錯誤
- 把簽名有效當成業務信任有效 → 簽名只證明簽發者控制金鑰 → 繼續驗證信任根、狀態和動作範圍。
- 把認可實體寫成無範圍的可信標記 → 無法判斷認可了什麼動作 → 明確建模
recognizedTo和輸出 schema。 - 永遠相信持有者提供的最新憑證 → 憑證可能已撤銷或過期 → 按風險檢查狀態和有效期。
- 公開完整個人目錄 → 可形成監控和連帶污名 → 最小揭露並限制聚合。
- 多目錄衝突時取第一條結果 → 決策不可稽核且易被操縱 → 定義優先級、範圍、時間和證據規則。
追問及應對
為什麼認可憑證不能直接授予業務權限？
它只表達某個認可者對實體執行特定動作的聲明；業務權限還要考慮資源、租戶、時間、風險和本地政策。
如何防止認可鏈無限遞迴？
設定最大深度、已訪問的識別集合和總預算；遇到循環或超限直接失敗並記錄原因。
何時必須回源檢查？
高價值交易、短撤銷窗口、金鑰洩露或目錄版本變化時應檢查最新狀態；低風險場景可使用帶版本和有效期的快取。
如何處理個人被錯誤認可的情況？
提供撤銷、申訴和更正流程，限制公開欄位，記錄簽發與驗證證據，並讓驗證器在新狀態生效後停止接受舊憑證。
Working Draft 階段如何上線試驗？
只在隔離租戶影子驗證，不直接改變業務授權；固定規範版本、測試向量和回滾開關，等實作報告和安全評審通過後再擴大。