題幹與適用場景
公司希望用瀏覽器協調的 Digital Credentials API 取代部分證件驗證流程。你會如何判斷是否採用、先做展示還是簽發，以及如何控制相容性和隱私風險？
面試官考察點
- 是否把 API 能力、憑證生態和業務結果分開評估，而不是把標準草案當成現成網路。
- 是否區分 presentation 與 issuance 兩類旅程及其不同合作方和風險。
- 是否量化覆蓋率、完成率、人工審核成本、詐欺損失和恢復路徑。
- 是否把資料最小化、使用者同意、替代流程和試點止損寫進決策。
回答前需要釐清的問題
- 目標是登入、年齡確認、開戶，還是簽發一張新憑證？
- 使用者已有那些錢包、憑證格式和裝置，目標市場的覆蓋率如何驗證？
- 哪些欄位是業務必需，哪些可以用選擇性揭露或人工流程替代？
- 核驗失敗、錢包不可用、撤銷或憑證過期時，使用者怎樣繼續完成任務？
30 秒回答框架
我會先定義一個高價值、低損失的旅程做小規模 presentation 試點，不直接取代所有身分流程。用漏斗指標比較 API、人工和現有方案的完成率、耗時、成本與詐欺率；同時驗證錢包和憑證覆蓋。資料最小化、使用者明確同意、供應商互通和降級流程是上線門檻。只有在覆蓋、隱私和營運指標達標後，才評估 issuance 或擴大市場。
分步驟深入解答
1. 先明確 API 的產品邊界
W3C 2026-06-01 Working Draft 描述由使用者代理協調數位憑證的展示與簽發。它定義的是瀏覽器與憑證生態之間的協調層，不等於統一的證件格式、錢包網路或法律身分結論。產品要把「瀏覽器能發起流程」和「業務能可信驗證」拆成兩個假設驗證。
2. 區分 presentation 與 issuance
Presentation 由驗證方請求使用者已有憑證，重點是可用錢包、使用者選擇、揭露欄位和核驗結果。Issuance 還需要發行方資格、憑證格式、金鑰綁定、生命週期與撤銷機制，合作和合規成本更高。首個試點優先選擇已有憑證的單一場景，避免同時建設發行網路。
3. 建立可量化的決策門檻
建立對照組，比較端到端完成率、P50/P95 用時、每次驗證成本、人工轉接率、詐欺拒絕率和客服量。按裝置、錢包、瀏覽器、年齡段等切片，防止平均值掩蓋覆蓋缺口。把 API 失敗、使用者取消、憑證過期和撤銷分別計數，不能用「技術成功」代替業務成功。
4. 設計隱私、信任與降級
只請求完成目的所需欄位，保留同意紀錄與用途說明，限制日誌中的憑證內容。驗證方要檢查發行者信任、簽章、有效期和撤銷狀態，不能只相信客戶端回傳。未支援裝置、錢包拒絕或網路故障時，提供現有人工/文件流程；試點設定退出門檻，達到隱私事件、投訴或完成率紅線就暫停。
高品質示範回答
我不會因為瀏覽器提供 API 就立即取代身分驗證。先選一個已有憑證、失敗損失可控的 presentation 場景，驗證目標市場的錢包與瀏覽器覆蓋，再用對照實驗比較完成率、耗時、成本、人工轉接和詐欺指標。Presentation 與 issuance 分開決策，後者要額外承擔發行資格、格式互通和撤銷生命週期。產品只請求必要欄位，記錄使用者同意，服務端驗證發行者、簽章、有效期和撤銷狀態。任何不支援、取消或過期都回到現有流程；設定覆蓋率、隱私事件和投訴的停止線，達標後再擴大市場或評估簽發。
常見錯誤
- 把 Working Draft 當成所有地區、瀏覽器和錢包都支援的統一網路。
- 混淆展示和簽發，低估發行方、格式和撤銷的合作成本。
- 只看 API 呼叫成功率，不看使用者完成率、人工轉接和詐欺結果。
- 讓憑證原文進入日誌，或請求與業務無關的身分欄位。
- 沒有非 API 降級，導致裝置不支援時無法完成開戶。
- 試點沒有對照組、市場切片和明確停止線。
追問及應對
為什麼先做 presentation？
它依賴已有憑證和錢包，範圍比發行網路小，可以先驗證使用者價值、覆蓋率與核驗品質。Issuance 等供應商和合規條件成熟後再單獨立項。
如何判斷「覆蓋率足夠」？
按目標市場的裝置、瀏覽器、錢包和使用者群切片，用真實漏斗資料定義最低完成率，而不是引用單一平台的相容表。低覆蓋人群必須保留等價替代流程。
什麼時候應該停止試點？
預先設定完成率、隱私事件、投訴、詐欺損失和人工成本閾值。任一關鍵指標越過紅線就暫停新增流量，保留稽核資料並復盤是否修復或撤回。