摘要

  • RFC 9901 允许持有人发送零项、若干项或全部 Disclosure；每一项被发送的值都可以与发行方已签名 JWT 中的摘要相核对。
  • 这只证明被展示值属于已签名结构，不证明未展示的声明不存在、不重要，或足以支持本地授权。

选择性披露最容易引发的错误，是把“看见了一个经验证的好消息”读成“看见了所有与决定有关的事实”。这不是加密失败，而是把格式特意保留的隐私空间误读成完整性。

RFC 9901 定义 SD-JWT。发行方签发 JWT；对于可选择披露的声明，负载中可保存摘要而不是明文。每一项 Disclosure 包含随机盐、适用时的声明名和声明值。持有人在发行时获得相应内容，随后面对不同验证方时只发送自己选择的 Disclosure。验证方重新计算摘要，并检查该摘要是否位于发行方签名的 JWT 中。

检查成功的结论很具体：这一个被呈示的值属于这一个发行方作出的、未被篡改的承诺。它不等于“这个呈示包含全部重要值”。标准明确允许持有人发送任意子集，包括一个都不发送。发行方可以把部分声明永久置于明文，也可以添加诱饵摘要来隐藏可披露声明的数目。因此，从界面上少了一项，不能推出该项为假、为空，甚至不能可靠推出该项存在。

应当把这条链拆开记录。发行方签署了结构，并决定哪些内容可由持有人选择披露。持有人针对本次交互选择了一组内容。验证方检查了签名和这组内容的摘要。最后，应用系统按自己的规则解释声明、判断证据是否充分并可能执行一个动作。把这些环节压缩为“凭证证明了资格”，会把不同主体的判断混为同一个事实。

发行方签名也不能填补这个空白。它保护签发后的结构完整性，并不自动说明发行方如何观察到声明、声明是否仍符合现实，或所有应用是否应赋予声明同一种含义。RFC 7519 提供 claims 的表示方式，IANA 注册表协调名称。哪个名称是必要条件、可选条件还是失效条件，仍由具体配置文件和本地验证规则决定。

可选的 Key Binding 提供的是另一类、有限的证据。若验证方策略要求，持有人提交 KB-JWT，用私钥对 SD-JWT 的哈希、nonce 和目标 audience 签名。验证方由此可验证该持有人在这一次呈示中控制这把密钥。它不能证明所有相关声明都被交出，不能证明声明此刻仍真实，更不会替本地系统作出准入决定。

没有强制 Key Binding 的情况同样重要。RFC 9901 说明，任何持有 SD-JWT 的实体都可将它转发给不要求 Key Binding 的第三方，并可删去 Disclosure。因此，收到的对象本身不能自动证明当前展示者、原来的受众或真实的实时交互。

标准并未允许把所有关键控制藏起来。发行方不得将评估真实性或有效性所必需的内容设为可选择披露；具体哪些内容关键，取决于应用配置文件。验证方必须检查发行方签名，并检查每一项 Disclosure 的摘要。RFC 8725 还建议在不同 JWT 用途可能混淆时使用明确类型。格式通用，充分性的规则必须专属而清晰。

实际审计应记录：发行方及验证密钥策略、凭证类型和配置文件、政策要求哪些声明、实际得到哪些声明、摘要检查、是否要求 Key Binding、nonce、audience、政策版本和最终状态转换。只有“凭证通过”这一条记录，会抹掉真正决定风险的证据层。

Heng Lu 对表述、局部决定与运行结果的区分，在这里是一种编辑纪律。RFC 9901 使一个边界清楚的声明可携带、可验证，也让隐私选择保留在持有人手中。它没有让被隐藏的部分获得确定含义，更没有让一次验证取代执行者自己的责任。

Sources