摘要

  • RFC 9901 是 IETF Standards Track 规范，定义 JWS 负载中 JSON 元素的选择性披露，JWT 是主要使用场景；RFC 7515 与 RFC 7519 只提供所引用的 JWS/JWT 基线。
  • 控制链条不是“发行者签发一次就结束”：发行者决定可隐藏的结构，持有人选择 Disclosure，验证者提出证据要求，应用配置决定是否需要持有人密钥绑定。
  • SD-JWT 不是加密、零知识证明或匿名凭证，也不自动保证不可关联。

它如何工作

对对象属性，发行者以摘要替代签名负载中的明文，并另行给出包含 salt、属性名和属性值的 Disclosure。对数组元素，Disclosure 包含 salt 和值。JSON 数组先以 UTF-8 编码，再进行 base64url 编码后计算摘要。每个可披露声明都应使用密码学随机、彼此独立且唯一的盐；推荐随机部分至少为 128 位，并在披露前只让持有人知道。

顶层 _sd_alg 指定披露哈希算法；该字段不能嵌套，缺省为 sha-256，实现必须支持 sha-256。发行者签名的 JWT 必须验证，不能使用 none。验证者先检查发行者签名，再对每个提交的 Disclosure 重算摘要，与签名负载中的摘要比对，之后才重建处理后的负载。摘要匹配失败、签名无效、算法不接受、格式错误或必需声明缺失，都应拒绝。

结构可以嵌套。隐藏的子项可能依赖父 Disclosure；持有人必须提交完整而有效的递归依赖链。诱饵摘要可以模糊隐藏声明的数量或是否存在，但会增大令牌；它是侧信道缓解措施，不是防关联机制。

密钥绑定由策略决定，并非普遍强制。若配置文件或用例要求绑定，SD-JWT 携带持有人公钥或其引用，持有人再签署 KB-JWT。其 typ 为 kb+jwt，并包含 iat、aud、nonce 与 sd_hash。sd_hash 绑定确切的发行者签名 JWT 及所选 Disclosure。验证者还必须检查持有人密钥、签名、算法、类型、时间窗口、受众、nonce 和 sd_hash。

exp 等影响有效性的声明若被设计为可选择披露，验证者可能缺少拒绝所需的数据；应用必须规定必要声明，并在缺失时拒绝。SD-JWT 依赖传输协议提供机密性，本身没有加密机制；隐私或被动关联风险重要时必须使用机密传输，JWE 可以在易泄漏信道上封装 SD-JWT。盐不能替代机密传输，也不能从令牌中恢复未披露的值。

隐私边界

选择性披露不是匿名凭证的不可关联性。稳定的发行者签名凭证可能让串通的发行者和验证者识别同一凭证。批量签发时使用新盐和新的持有人密钥，可以改善验证者之间及不同展示之间的不可关联性，但不能抵抗发行者与验证者串通。RFC 也没有推出部署规模、采用率、法律合规、实现性能、钱包体验或特定撤销方式的结论。

来源