题干与适用场景
多个教育机构希望共享可验证的机构与签发者目录，但不想依赖单一中心注册表。请说明如何建模 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 阶段如何上线试验？
只在隔离租户影子验证，不直接改变业务授权；固定规范版本、测试向量和回滚开关，等实现报告和安全评审通过后再扩大。