SD-JWT VC 与 mdoc（ISO/IEC 18013-5）：EUDI 钱包格式对比

最近审阅：2026年10月5日 · 非法律意见

SD-JWT VC 是一种可验证凭证，封装为经签名的 JSON Web Token，其声明可以逐项披露。mdoc 是采用 ISO/IEC 18013-5 格式的移动文档，该标准最初为移动驾驶证制定。EUDI 钱包的架构与参考框架（ARF）将两者列为钱包必须支持的格式，并将第三种格式 W3C Verifiable Credentials Data Model 2.0 列为可选格式，且"仅适用于非合格 EAA"。^[1]

本指南面向构建验证方的开发人员，依据 ARF v3.0.0、OpenID for Verifiable Presentations（OpenID4VP）1.0 文本和《欧盟官方公报》对两者进行比较。PID 指个人身份识别数据。

什么是 SD-JWT VC

ARF 将"基于 SD-JWT 的可验证凭证"描述为用于表达可验证凭证的数据格式和处理规则，其中 SD-JWT"代表'可选择性披露的 JSON Web Token'"。^[1] 它涵盖 JSON 编码、带选择性披露的证明机制，以及可选的设备绑定。^[1]

在 OpenID4VP 中，格式标识符为 dc+sd-jwt，查询通过 vct_values 指定凭证类型。^[4] 以下是规范中签发载荷的示例，八个摘要仅保留两个：^[4]

{ "_sd": [ "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo" ], "vct": "https://credentials.example.com/identity_credential", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256" } } }

什么是 mdoc（ISO/IEC 18013-5）

ISO/IEC 18013-5 定义了驾驶证属性、属性在简明二进制对象表示（CBOR）中的编码、防止标识符冲突的命名空间、带选择性披露的证明机制、强制性设备绑定，以及近场交换。^[1]

只有驾驶证数据模型是驾驶专用的。ARF 指出，所有其他方面"都是通用的，可用于任何其他证明类型，包括 PID"。^[1]

OpenID4VP 将这类凭证描述为"以 CBOR 编码并使用 COSE_Sign1 保护"，并为其指定格式标识符 mso_mdoc。查询通过 doctype_value 指定文档类型。^[4]

两种格式中的选择性披露如何运作

选择性披露让用户可以共享部分属性并隐藏其余属性，同时验证方仍可校验签发方的签名。eIDAS 2 要求钱包实现这一功能。^[6] ARF 将 SD-JWT 的机制称为"加盐哈希"，并指出它"在概念上与 [ISO/IEC 18013-5] 中用于同一目的的机制相同"。^[1]

同一机制，两种编码。^[1][4]

在上面的示例中，_sd 数组包含 SHA-256 摘要。每个披露项都是一个数组，包含一个随机值、声明名称和声明值。对于名字，披露项是 ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]，其哈希值是列表中的第一个摘要。验证方对收到的每个披露项计算哈希值，并在已签名的载荷中查找该摘要。^[4]

声明的寻址方式不同。对于 JSON 凭证，声明路径是一组键，例如 ["address", "street_address"]。对于 mdoc，路径“包含两个字符串类型的元素”：命名空间和数据元素标识符，例如 ["org.iso.18013.5.1", "first_name"]。^[4]

密钥绑定与设备接洽

设备绑定将凭证与用户钱包中持有的密钥绑定，因此凭证无法被复制。验证方的检查方式是：要求钱包使用与凭证中公钥相对应的私钥，对新生成的随机数据进行签名。^[1] 名称有所不同：“在 [ISO/IEC 18013-5] 中称为‘mdoc 认证’。在 [SD-JWT VC] 中称为‘密钥绑定’。”^[1]

在两种格式中，设备绑定对 PID 都是强制要求。^[1][4]

对于 SD-JWT VC，OpenID4VP 中的规则很严格。当 require_cryptographic_holder_binding 为 true（即默认值）时，钱包“必须返回 SD-JWT”，并附带 Key Binding JWT。nonce 声明必须与您请求中的 nonce 一致，aud 必须与您的 Client Identifier 一致。通过 Digital Credentials API 时除外，此时它必须与带有 origin: 前缀的您的源一致。^[4]

设备接合（device engagement）仅属于 mdoc。在近场流程中，用户出示二维码或提供 NFC 标签。其中包含读取方所需的信息，用于建立 NFC、低功耗蓝牙或 Wi-Fi Aware 连接，并在该连接上构建经过认证的加密通道，双方之间无需互联网连接。^[1]

使用 mdoc（ISO/IEC 18013-5）的近场出示流程（简化版）。^[1]

用户看到的界面：

出示协议：OpenID4VP、ISO/IEC 18013-7 与近距离出示

ARF 列出了钱包需要处理的协议：近距离场景使用 ISO/IEC 18013-5，远程场景使用 OpenID4VP 或 ISO/IEC 18013-7。^[1]

根据 ARF，各协议承载哪种格式。^[1]

SD-JWT VC 证明“不能用于近距离出示”。ISO/IEC 18013-7“只能用于请求和出示符合 [ISO/IEC 18013-5] 格式的证明”。OpenID4VP“仅适用于远程出示交易流程”，并承载两种格式。^[1] OpenID4VP 1.0 于 2025年7月10日成为最终规范（Final Specification）。^[5]

ARF 不建议在跨设备场景中使用自定义 URI 方案，因为这些流程“容易受到网络钓鱼和中继攻击”，并将 Digital Credentials API 列为替代方案。^[1] 该 API 目前仍是 W3C 草案，Chrome 141 默认启用该 API。^[9][10] ISO 将 18013-7 的 2024 年技术规范列为已撤销并被取代，第三版正在制定中，因此请确认您的代码针对的是哪一版。^[7][8] 请求细节见OpenID4VP 验证方指南。

实施条例 (EU) 2026/1731 对 PID 的要求

关于 PID 格式的第一部规则，即实施条例 (EU) 2024/2977，规定 PID“应以两种格式签发”：ISO/IEC 18013-5:2021 和 Verifiable Credentials Data Model 1.1。^[2][3] 2026年7月的修订法案替换了这句话。PID 现在“应按照实施条例 (EU) 2024/2979 附件 II 条款 5（SD-JWT VC 格式）和条款 6（ISO/IEC-mdoc 格式）规定的标准签发”。^[2]

1. 2024年12月4日首部规则2024/2977：18013-5 与 VCDM 1.1。
2. 2026年7月22日修订2026/1731：SD-JWT VC 与 mdoc。
3. 2026年7月23日ARF v3.0.0与修订法案保持一致。
4. 2026年12月24日钱包截止期限每个成员国一个钱包。
5. 2028年8月11日肖像在适用情况下，肖像要求适用，除非用户明确选择退出。

PID 格式相关法律的演变。^[1][2][3][6]

同一法案在其关于实施条例 (EU) 2024/2982 的附件中设定了两个出示配置文件：“ISO/IEC-mdoc 配置文件”和“OpenID4VC-HAIP 配置文件”。^[2]

• 发送您的注册证书：verifier_info 中的一个元素“应包含注册证书”。^[2]
• 将您的访问证书用作叶证书，并配合 x509_hash 客户端标识符前缀使用。^[2]
• 通过 Digital Credentials API 传输 mdoc 时，遵循“ISO/IEC 18013-7:2025 附件 C”。^[2]

注册事项见 EUDI 钱包依赖方指南，时间表见 2026年和2027年 EUDI 钱包截止日期。

SD-JWT VC 与 mdoc (ISO/IEC 18013-5)：对比表

数据来自 ARF，PID 一行（第 2026/1731 号实施条例）和最后两行（OpenID4VP 1.0）除外。^[1][2][4]

美国的移动驾照基于 ISO/IEC 18013-5 实现近场场景。^[7][8]欧盟年龄验证方案将零知识证明列为强制出示机制，“以普通 mDoc 出示作为后备”。^[13]摩尔多瓦的 EVO Wallet 文档说明其采用 OpenID4VP 1.0 和 ISO/IEC 18013-5 mdoc，并按 HAIP 1.0 进行配置。^[11]

依赖方必须支持哪种格式

钱包单元同时处理两种格式，PID 也以两种格式签发。^[1][2]本指南查阅的文本中，没有任何条文要求依赖方同时请求两种格式。实务上的理解是：远程验证方可以请求任一格式，而没有互联网连接的读取设备需要 mdoc，这是唯一可用于近场场景的格式。^[1]

OpenID4VP 中的数字凭证查询语言（DCQL）允许一个请求同时包含 dc+sd-jwt 查询和 mso_mdoc 查询；规范中给出了此类请求的示例。^[4]根据 ARF，依赖方需对照可信列表或可信实体列表中的信任锚验证签发方签名，通过状态列表或撤销列表检查撤销状态，并验证设备绑定。^[1]

根据 eIDAS 2，即 Regulation (EU) 2024/1183，每个成员国必须在 2026年12月24日前提供至少一个钱包；被要求使用强用户认证的私营依赖方必须在 2027年12月24日前应用户要求接受该钱包，微型和小型企业豁免。^[6]各国进展见 EUDI 钱包上线追踪。

库与测试工具

本指南所依据的资料未列出任何开源库，因此本节也不列出。但这些资料说明了在哪里测试，以及对你选择的任何库应检查哪些内容。

• 在 conformance.eudi.dev 运行一致性测试，该地址见于 ARF v3.0.0 发布说明。^[1]
• 阅读 docs.eudi.dev 上的参考实现文档。^[1]
• 研究已公开的验证方：摩尔多瓦国家银行为金融机构发布了一个附带源代码的演示验证方。^[12]
• 确认该库遵循 HAIP，而不仅是基础规范。^[1]
• 确认该库实现的是 ISO/IEC 18013-7 的哪个版本。^[2][8]

Didit 如何协助 EUDI 钱包验证

Didit 即将支持接受 EUDI 钱包：该功能已列入我们的路线图，与 EUDI 钱包的时间表保持一致，并将在你目前使用的同一工作流程中提供。你现在即可远程验证用户身份。

• 目前有五种国家 eID 通过数字身份钱包在 Didit 中运行：MitID、BankID Sweden、Finnish Trust Network、Smart-ID 和 Mobile-ID。参见 eID 验证。
• 其他所有用户使用证件验证，配合 NFC 芯片读取、活体检测和人脸比对。一次完整的 KYC 核验费用为 $0.33。
• AML 筛查在同一流程中运行，费用为 $0.20。

钱包文档说明了如何按国家启用 eID。

常见问题

资料来源

1. 架构与参考框架 v3.0.0，GitHub 上的 eu-digital-identity-wallet，2026年7月23日发布。
2. 委员会实施条例 (EU) 2026/1731，EUR-Lex，2026年7月22日《官方公报》。
3. 关于个人身份识别数据的委员会实施条例 (EU) 2024/2977，EUR-Lex，2024年12月4日《官方公报》。
4. OpenID for Verifiable Presentations 1.0，OpenID Foundation，最终规范。
5. OpenID for Verifiable Presentations 1.0 最终规范获批，OpenID Foundation，2025年7月10日。
6. 条例 (EU) 2024/1183（eIDAS 2），EUR-Lex，2024年4月30日《官方公报》。
7. ISO/IEC 18013 系列，移动驾驶执照，ISO 标准页面。
8. ISO/IEC 18013-7，ISO 标准页面。
9. Digital Credentials，W3C 草案。
10. Digital Credentials API 已发布，Chrome for Developers。
11. EVO Wallet 开发者指南，摩尔多瓦政府，egov4dev。
12. BNM 演示验证方，摩尔多瓦政府，egov4dev。
13. 欧盟年龄验证解决方案技术门户，ageverification.dev。

SD-JWT VC 和 mdoc（ISO/IEC 18013-5）是同一承诺的两种编码方式：由用户掌控的已签名属性。请在 EUDI Wallet 解决方案页面了解 Didit 如何处理钱包接入，并在各国 eID 方案中查看每个国家方案。