题干与适用场景
公司希望用浏览器协调的 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 等供应商和合规条件成熟后再单独立项。
如何判断“覆盖率足够”？
按目标市场的设备、浏览器、钱包和用户群切片，用真实漏斗数据定义最低完成率，而不是引用单一平台的兼容表。低覆盖人群必须保留等价替代流程。
什么时候应该停止试点？
预先设置完成率、隐私事件、投诉、欺诈损失和人工成本阈值。任一关键指标越过红线就暂停新增流量，保留审计资料并复盘是否修复或撤回。