1.6k 景观
Pinterest LinkedIn LINE

1. RFC 9901 的诞生

2025 年 11 月 19 日，“JSON Web Tokens 的选择性披露”，又名 SD-JWT 定义 (SDJOT) 的规范 RFC 9901 它以如下形式发布：

作者是以下三位。

JSON Web Token (JWT) [RFC 7519]。为了让 JSON Web 签名 (JWS) [RFC 7515]は，ID 令牌やJWT 访问令牌 [RFC 9068]它是一种被广泛使用的互联网标准。
SD-JWT 为我们提供了新的能力，可以提取并显示我们以后需要的部分。

在 JOSE 家族（JWS / JWT / JWE）的谱系中，
这可以看作是正式 RFC 中新增了一个名为“选择性披露”的支柱。

2. SD-JWT 规范是做什么用的？

2-1. 传统 JWT 的问题：“按需发行”或“全包式”

传统的 JWT 基于这样一种模型：将“签名 JSON 块”直接传递给服务。

  • 颁发者（身份提供商或身份验证服务器）将用户信息编译成 JWT。
  • 接收服务（信赖方）可以读取全部内容

这意味着，如果您使用像 OpenID Connect 这样的模型（证书根据需要动态颁发），就可以实现选择性披露、数据最小化以及 RP 之间的不可关联性（RP+RP'-U 不可关联性）（通常使用 PPID，即成对匿名标识符）。但是，如果您想“预先颁发一个不知道其用途的证书，然后在以后使用它”，那么以上所有目标都无法实现。

例如，如果一个 JWT 包含“年龄”、“地址”、“姓名”和“电子邮件地址”，服务端可能只需要知道用户是否超过 20 岁，但如果使用预先颁发并保存的 JWT，则可以看到所有信息，包括用户的地址和姓名。

这种“一体化”结构易于实现，但如果您想保存和使用，

  • 选择性披露是不可能的 = 无法满足数据收集最小化原则
  • RP+RP'-U不可链接性也不满足

这些是局限性（尽管这是实现简单性的权衡）。

2-2. 与钱包型号的兼容性

另一方面，确实存在一些需要稍后使用已保存数据的情况。典型的例子包括在没有信号的地方使用，或者在学校放学后出示毕业证书。你可能会想，“真的有那么常见吗？”，但这主要是因为日本的网络环境比较优越。在欧洲，信号质量很差，尤其是在石头建筑内，即使只是离基站稍远一点，即使在曼海姆这样的大城市，户外也可能失去信号。当然，幅员辽阔的美国也存在同样的问题。或许正因如此，在欧洲， EUDI钱包 近期推出的身份钱包包括：

  • 一个钱包（智能手机应用程序）可以处理多笔交易 可验证凭证 (VC) 攒钱
  • 用户选择“仅显示此服务的此项”，并将其显示出来。

这个模型是前提。在这种情况下，钱包和发卡机构只需在发行时联网即可。

这里需要的是

“一种允许您稍后选择并安全地显示已存储的签名数据文件的一部分的格式。”

这是由……定义的 RFC 9901 这是 SD-JWT。

3. SD-JWT 简述

简单来说，SD-JWT 的工作原理如下：

  1. 底座和以前一样。 签名 JWT (JWS)
  2. 然而，有些说法是仅哈希值在 JWT 中
  3. 将原值和盐放在一起 有关声明 请将其单独存放，仅在必要时才将其交给验证者。
  4. 验证者是
    • 根据披露信息重新计算哈希值。
    • 通过验证它是否与已签名 JWT 中的哈希值匹配
    • 您可以确认“这确实是发行方签名数据的一部分”。

此外，为了防止未经授权的代币转移， 用于关联用户密钥对的机制（密钥绑定） 也可用。
组合结构 SD-JWT+KB 叫它

4. 三个字符和 SD-JWT 的流程

SD-JWT 中的基本角色与 VC 世界相同。

  • 发行人
    政府机关、银行、大学等。对事实负责的组织。
  • 持有者
    用户本人将凭证保存在其智能手机上的钱包应用程序中。
  • 验证者
    服务提供商，例如银行账户开立、年龄验证和门禁控制。

典型流程如下：

  1. 发行
    • 发卡机构将用户的属性信息（地址、出生日期等）编译成 JSON 格式。
    • 关于“您希望稍后选择性披露的项目”，
      根据该值加上一个随机盐值计算哈希值，并将该哈希值嵌入到 JWT 中。
    • 原值加盐单独作为披露信息编制。
    • 签署的 JWT 和多个披露文件捆绑在一起，作为“SD-JWT”传递给持有人。
  2. 推介会
    • 用户尝试使用一项服务
    • 钱包仅从 SD-JWT 中选择它想要向验证者显示的披露信息。
    • 将已签名的 JWT + 选定的披露信息 +（如有必要，还包括密钥绑定 JWT）发送给验证者
  3. 确认
    • 验证者是
      • 使用发行者的公钥验证 JWT 签名
      • 使用 Disclosure 重新计算每个项目的哈希值，并验证其是否与 JWT 中的哈希值匹配。
    • 这样可以确保数据是发行人签署的数据的一部分，同时保护未披露的内容。

5. 一些技术性讨论：Salt 和披露

5-1. 使用加盐哈希进行选择性披露

每项申报信息（地址、出生日期等）

  • 盐 + 价值 + （可能是索赔名称）

计算 JWT 的哈希值，并将哈希值嵌入 JWT 中。

实际披露时，应注明为“披露”。

  • “盐，索赔名称，价值”

致验证者。

验证器使用相同的程序重新计算哈希值，并检查它是否与 JWT 中的哈希值匹配，以查看它是否已被篡改。
盐的存在使得难以估算未披露索赔的价值。

5-2. 披露

RFC 将披露定义为 Base64url 编码的 JSON 数组，例如：

  • 元素0：盐
  • 元素 1：声明名称（数组元素可以省略）
  • 要素 2：索赔价值

钱包里，

“将一份大型凭证作为一系列小型披露信息的集合，并且只发送你需要的信息。”

如果你这样想的话，我觉得更容易理解。

5-3. 按键绑定和 SD-JWT+KB

仅使用 SD-JWT 仍然存在被攻击（重放攻击）的风险，即令牌被复制并由其他人提供。
因此，RFC 9901 规定了一种将 SD-JWT 与持有者的密钥对绑定的机制。 按键绑定 定义：

  • 在 SD-JWT 中包含持有者的公钥（或其引用）。
  • 持钥匙人出示钥匙后即可签字。 密钥绑定 JWT (KB-JWT) 一起寄送
  • 验证者是
    • SD-JWT 和 KB-JWT 绑定到同一个密钥
    • 确认持有者确实拥有私钥。

现在需要按键绑定。 SD-JWT+KB 这将提高对风险投资抄袭的抵抗力。

注意持有者绑定可以是密钥绑定、声明绑定或生物识别绑定。+KB 实现了密钥绑定。但是，使用密钥绑定时，如果存储密钥的设备或其他介质被转移，则可能有人冒充您（这被称为 Alice-to-Bob 攻击）。买卖银行账户就是一个典型的例子。为了防止这种情况，通常需要使用生物识别绑定。

5-4. 对 JSON 结构和数组的支持

RFC 9901 超越了简单的扁平 JSON。

  • 嵌套对象
  • 逐元素披露数组
  • 使用“虚拟哈希（诱饵摘要）”隐藏模式

它还规定了如何处理此类案件。

这样

  • 防止人们猜测“每个人都拥有相同的资质”。
  • 降低仅凭披露物品数量而被追踪的风险

这使得提出诸如此类的想法成为可能：

6. SD-JWT 和 VC 身份钱包

6-1. SD-JWT VC：定位为 VC 格式

IETF 在 RFC 9901 中使用 SD-JWT。 用于表达可验证凭证的规范 如
“基于 SD-JWT 的可验证凭证 (SD-JWT VC)” 草案正在拟定中。

这是

  • JSON 格式的 VC
  • SD-JWT允许选择性披露
  • 确定验证方法

这是一份具有以下作用的规范。目前，该工作组正在进行最终定稿前的审查，我也是审查员之一。大约 28 处编辑改进（部分建议可能涉及技术方面。）（这些建议包括：简化美国人或德国人写作时冗长难懂的句子；解决因过度使用被动语态而导致的义务执行人身份不明的问题；以及考虑安全性、隐私性和公平性。）此外，为了验证规范草案中包含的示例，我们创建了一个静态 HTML/JavaScript 页面。sd-jwt-decoder“也创建了”。它也已在 GitHub 上发布。（它只是一个 HTML 页面，因此可以轻松地在本地运行——我需要在飞机上验证草稿），所以如果您发现任何错误，请提交拉取请求。

6-2. 与 EUDI 钱包一起使用

欧盟委员会 EUDI架构参考框架（ARF） 因此，欧洲数字身份钱包将采用的标准是：

  • 用于可验证凭证的 OpenID (OpenID4VCI / OpenID4VP)
  • SD-JWT / SD-JWT VC
  • ISO/IEC 18013-5 移动驾驶执照 (mDL)

已经证明，可以使用以下几种方法的组合。

在此背景下，RFC 9901 规定：

“存储在身份钱包（例如 EUDI 钱包）中的 VC”
基于 JWT/JOSE 实现的核心格式

它的位置如下。

6-3. 从钱包用户角度来看的好处

整体用户体验大致如下：

  • 年龄确认
    在便利店，你只需要提供你已年满 20 岁的信息，而不需要提供你的出生日期。
  • 地址确认
    仅提供网上购物网站所需的收货地址，并隐藏其他属性
  • 了解你的客户
    仅向银行和证券公司提供必要的属性，并将同一虚拟计算机用于其他服务。

这一切都得益于 SD-JWT 的特性，它允许你将单个签名数据分解成更小的部分，并只提取你需要的部分。

7. 生态系统的扩展（概述）

一些开源软件和商业解决方案已经将 SD-JWT/SD-JWT VC 集成到它们的实现中。

  • 各种钱包框架对 SD-JWT 的支持：西罗斯基金会 其中之一是 wwWallet，由……开发。
  • Authlete 和其他组织提供的 SD-JWT VC 颁发端点
  • EUDI钱包项目和SPRIND计划的采用情况
  • OpenID 基金会开发了一种高安全性配置文件 (HAIP)，它结合了 OpenID4VC 和 SD-JWT VC。

RFC 9901 被定位为这一运动的“基础部分”。

8.总结

  • RFC 9901 是一种互联网标准，它赋予 JWT/JWS “选择性披露”的能力。
  • SD-JWT 是
    • 签名后的 JWT 只包含哈希值。
    • 只有在必要时才会披露原始价值和盐度。
    • 但是，发行人的签名仍然可以确保其真实性。
      它定义了格式。
  • 添加了按键绑定 SD-JWT+KB 这样可以实现与钱包所有者绑定的安全展示。
  • 结合 SD-JWT VC 草案、EUDI ARF 和 OpenID4VC 规范，
    存储在身份钱包中的虚拟货币核心格式之一 它将被用作。

这一新组件已添加到 JOSE/JWT 技术家族中，可以说，基于钱包的数字身份基础设施的现实实现模式已经变得清晰。