移动身份系统的密码学基础：ISO/IEC 18013-5 企业架构蓝图
本文面向企业架构师、安全架构师、身份工程师、平台负责人、技术评估人员，以及负责集成或选型移动驾驶证（mDL）能力的产品团队。对于通过第三方提供商、SDK、钱包平台或验证服务接入 mDL 的组织而言，本文尤其具有参考价值，因为这些组织需要了解集成边界背后隐藏着什么。
本文提供了一个框架，帮助企业在决定采用某家 mDL 提供商或某个库之前，提出正确的架构问题。文章将说明哪些组件可以安全地进行抽象，哪些信任边界必须对企业保持可见，需要验证哪些密码学属性和互操作性特征，以及在不同的实际应用场景中，相关要求会发生怎样的变化。
引言：移动身份集成很容易被隐藏，架构设计却没那么简单
从实体凭证转向数字移动驾驶证，不仅仅是用户界面的变化。它还改变了身份信息的存储位置、身份声明的认证方式、设备建立可信关系的方式、依赖方请求信息的方式，以及在网络连接不可用时执行验证的方式。
集成 mDL 的企业可能会发现，开发者体验看起来相当简单：
从应用程序的角度来看，这可能只是几个 API，但底层架构要复杂得多：
这种抽象很有用，但也带来了风险。
企业不一定需要自行实现每一个组件。在许多情况下，采用专业提供商或库才是正确的工程决策。然而，将实现工作外包，并不意味着可以将架构责任一并外包。
提供商可能成功地提供了诸如 verifyCredential()、requestPresentation() 和 issueCredential() 等操作的 API，但企业仍然需要做出几项关键决策，包括：
凭证存储在哪里？设备密钥如何受到保护？
谁负责管理签发方信任锚？证书如何验证和轮换？
如何处理凭证有效性和撤销问题，尤其是在验证方处于离线状态时？
哪些身份属性会被披露？企业能否强制执行数据最小化策略？
提供商会收集哪些遥测数据？凭证出示事件是否可能与具体用户关联起来？
如果提供商不可用，会发生什么？企业能否在不重新设计集成方案的情况下迁移到其他提供商？
即使相应功能由其他方实现，这些问题仍然属于架构层面的要求。
因此，本文介绍的架构可以有两种用途：
作为实现蓝图，供负责构建 mDL 生态系统部分组件的组织使用。
作为评估框架，供需要选择 mDL 提供商、SDK、钱包平台或验证库的组织使用。
第二种用途尤为重要。评估提供商时，不应仅仅看其 SDK 能否成功完成一次演示交易。企业还应评估 SDK 背后隐藏的信任模型、密码学边界、互操作性、隐私控制、运行行为和故障模式。
本文如何分析 mDL 架构
本文将移动身份视为一个企业架构与信任边界问题，而不只是一个 SDK 集成问题。首先，文章将身份核验与凭证配置分开，因为这两个阶段涉及不同的参与方、信任决策和安全责任。由此便引出了评估提供商时需要考虑的问题：哪些职责可以委托给 mDL 提供商，哪些信任决策必须继续对企业保持可见？随后，文章将介绍凭证结构和数据模型，说明实际配置和验证的内容究竟是什么。
接下来，文章将沿着凭证在一次验证交易中的流转过程展开。高层级的凭证出示流程将说明钱包、依赖方、签发方信任、设备认证以及请求的属性如何相互作用。后续章节将进一步探讨如何通过密码学、双向 TLS（mTLS）和证书基础设施保护这一交易。随后，文章会区分必须立即可用的操作与可以在后台执行的操作，并通过讨论离线运行和状态协调，分析提供商故障、网络故障和信任列表故障等问题。
最后几节将探讨这些原则在不同依赖方应用场景中的变化、治理和隐私策略如何限制实现方案的选择，以及企业如何避免过度依赖提供商，同时确保重要的架构决策始终清晰可见。文章还将通过架构审查以及 Build、Buy 和 Govern 决策模型，将这些观点整合起来，帮助企业判断哪些能力应由企业自行掌控，哪些能力可以委托给专业提供商。
本文的目标是将这些主题整合到一个统一的架构视图中：了解信任的对象是什么、披露了哪些信息、如何进行验证、连接或提供商发生故障时会怎样，以及企业如何继续对实现方案进行治理和调整。
谁应该阅读本文？
本文的主要读者包括：正在决定如何将 mDL 能力融入现有身份、API、移动、安全和数据架构的企业架构师与解决方案架构师；评估密钥管理、设备信任、证书基础设施、密码学边界、认证和隐私控制的安全架构师；负责将移动凭证与身份验证、依赖方应用程序、数字钱包和企业身份平台集成的身份与 IAM 工程师；负责评估商业 mDL 提供商、SDK、验证平台、钱包技术或托管身份服务的技术与供应商评估团队；需要决定哪些内容应当在内部构建、哪些可以委托给提供商，以及哪些架构控制必须由企业掌握的工程负责人；以及负责设计面向客户的应用程序、需要在包括在线和离线场景在内的多种环境中执行身份验证的产品与平台团队。
对于上述所有读者而言，核心问题并不是：
这个 SDK 能验证 mDL 吗？
更重要的问题是：
这个 SDK 背后具备怎样的信任、安全、隐私、互操作性和运行架构？它是否满足我所在企业的要求？
身份核验与凭证配置架构
身份核验和凭证配置是凭证生命周期中的两个不同阶段。身份核验用于确认用户确实拥有相关身份声明，而凭证配置则负责建立硬件信任、签发加密载荷，并在设备上安装移动安全对象（Mobile Security Object，mSO）。
阶段 1：身份核验
身份核验主要包括四个步骤：
采集身份凭据： 用户直接在应用程序中拍摄实体驾驶证的正面和背面照片，同时录制一段实时人脸视频，用于活体检测。
提交载荷： 将采集的图像、提取的元数据和活体检测视频提交给验证系统。
授权检查： 机动车管理部门（DMV）或权威身份系统根据官方记录，使用自动人脸识别技术评估相关证据，并在必要时通过人工审核流程进行复核。
核验决策： 验证引擎返回明确的状态响应：批准或拒绝。
阶段 2：身份凭证配置
身份凭证配置通过四个步骤完成：
生成硬件密钥： 收到批准状态后，钱包客户端会请求 Secure Enclave 或硬件安全元件生成非对称设备密钥。
组装证明材料包： 客户端提取生成的设备公钥以及硬件证明 X.509 证书。
提交配置载荷： 钱包将设备公钥、公开证书、身份核验参考 ID 和设备元数据打包，并将其发送给签发方后端。
凭证摘要计算与加密： 签发机构对驾驶证身份属性进行摘要计算，将这些属性与设备公钥绑定到经过签名的移动安全对象中，对凭证包进行加密，然后将其发送回钱包。
存储与呈现： 钱包使用会话传输密钥解密收到的载荷，将经过签名的 mSO 数据和密钥写入由硬件保护的存储空间，并使凭证可以显示给用户。
企业不一定需要自行实现这九个步骤。不过，企业应当明确每个步骤由哪一方执行，以及最终的信任决策由哪一方控制。
因此，在评估提供商时，应建立一份职责分配图，明确每项必要功能由谁提供。例如：
具体的职责归属模式可能有所不同，但企业应当能够清楚解释信任边界，而不是简单接受提供商默认的抽象方式。
企业应该向 mDL 提供商提出哪些问题
黑盒式集成可以是合理的实现方式，但对于架构尽职调查而言，这还远远不够。
企业在评估 mDL 提供商时，应确保对方能够清楚解释以下六个方面：
密码学架构： 密钥生成与保护、设备证明、算法、签名和密钥生命周期。
信任与 PKI： 信任锚、文档签名者证书、信任列表、撤销机制和证书生命周期。
隐私与数据最小化： 选择性披露、遥测、凭证出示数据的保留、位置信息以及关联风险。
离线运行： 缓存的信任材料、撤销 / 状态同步、过期信息，以及网络中断时的行为。
互操作性： 对 ISO/IEC 18013-5 的合规性、不同钱包与验证方之间的互操作性、标准化数据结构，以及提供商可替换性。
运行韧性： 对提供商的依赖、服务中断时的行为、凭证连续性、恢复机制和故障处理。
目标并不是消除抽象，而是确保抽象能够隐藏实现复杂性，却不会掩盖架构风险。
详细的提供商尽职调查清单见附录 A。
凭证结构与数据模型
ISO/IEC 18013-5 使用结构化、紧凑的数据表示来承载由签发方签名的身份声明。凭证包含由签发方签名的命名空间、元素标识符、摘要、签发方认证信息、设备密钥信息和有效期信息。
从架构角度来看，重要的是：企业接收的并不只是“身份数据”，而是经过密码学结构化处理的声明。这些声明的真实性和完整性取决于签发方签名、数值摘要、设备密钥以及周围的信任基础设施。
附录 B 提供了一个具有代表性的凭证结构，其中包括签发方签名数据、移动安全对象（mSO）、设备认证和凭证有效性之间的关系。
这一区别也会影响企业对 mDL 提供商或库的评估方式。不能仅仅因为集成方案能够解析或反序列化凭证载荷，就认定其符合要求。它还必须能够暴露并正确执行该载荷所代表的安全属性。
因此，企业应当确认实现方案是否能够：
正确验证签发方签名；
验证移动安全对象；
验证设备认证；
验证证书链；
支持选择性披露；
保护敏感凭证材料；
向应用程序提供充分的验证结果；
保持基于标准的互操作性。
从凭证结构到企业级验证
理解凭证结构只是第一步。企业还必须了解凭证如何在在线和离线环境中出示、受到保护、得到验证并接受治理。
接下来的章节将沿着验证生命周期，逐步梳理这些问题，从凭证出示和密码学保护，到信任基础设施、可用性、离线状态协调和企业策略。
用户凭证出示的高级流程
凭证出示流程展示了在一次验证交易中，mDL 如何从用户的钱包传递给依赖方。验证方发起凭证出示请求，钱包建立适当的安全通信通道，用户授权披露所请求的信息，随后验证方对返回的凭证数据、签发方信任、设备认证以及适用策略进行验证。
这一流程为后续架构主题提供了运行层面的背景。接下来的章节将探讨支持这类交易的安全机制，包括密码学保护、证书与信任基础设施、同步与异步交互，以及离线运行和状态协调机制，并说明这些机制如何影响企业集成和提供商评估。
安全与密码学：集成 HPKE
RFC 9180 定义的混合公钥加密（HPKE）用于保护在线传输，以及验证方与钱包服务器之间直接进行的 API 交互。HPKE 将非对称密钥封装机制与带有关联数据的对称认证加密结合起来，从而实现低延迟加密。
HPKE 参数
KEM：DHKEM(P-256, HKDF-SHA256)（ID：0x0010）
KDF：HKDF-SHA256（ID：0x0001）
AEAD：AES-128-GCM（ID：0x0001）
关键的架构要点是：加密应当被视为更广泛信任模型的一部分，而不是一个独立的安全功能。
评估 mDL 提供商时，可以询问：
提供商只是宣称自己采用了“加密通信”，还是能够解释清楚密码学边界、密钥生命周期、算法选择、密钥存储和端点认证？
提供商应当能够说明：
加密从哪里开始；
加密在哪里终止；
哪些密钥由设备生成；
哪些密钥由后端系统生成；
密钥如何受到保护；
密钥轮换如何进行；
哪些组件位于提供商的信任边界之内。
如果信任边界不够清晰，即使使用了加密，也可能带来虚假的安全感。
双向 TLS（mTLS）与证书基础设施
钱包服务器、签发方平台和验证系统之间的服务器到服务器通信，需要采用双向 TLS 认证，并结合 PKI 验证。
该信任拓扑依赖于几种专用证书类型。
对企业而言，重要的问题不一定是提供商是否自行运营这些基础设施。
真正需要回答的问题是：
哪些证书基础设施由提供商运营，哪些由企业运营，又有哪些信任关系仍由签发机构控制？
提供商应当能够解释证书生命周期管理、证书轮换、信任锚管理、故障时的行为，以及发生证书泄露或失陷时各方承担的责任。
同步与异步操作
企业级 mDL 架构不会对所有操作采用同一种交互模式。有些操作必须在面向用户的验证交易中完成，而另一些操作则可以在后台执行，不会延迟凭证出示。因此，架构设计的目标不是在同步处理和异步处理之间二选一，而是明确哪些操作需要立即可用，哪些操作可以容忍延迟、使用缓存或通过最终同步完成。
当企业依赖外部 mDL 提供商时，这一区别尤为重要。如果提供商变得不可用，影响程度取决于哪些操作在运行时与该提供商紧密耦合。设计良好的架构应当允许现有凭证和离线验证在适用的信任与策略要求允许的情况下继续运行，同时允许签发、凭证配置、在线验证和信任列表同步等操作在必要时依赖后端服务的可用性。
同步实时交互
现场扫描： 通过近场通信（NFC）传输。验证方读取器通过 NFC 发起轻触交互，建立会话密钥，请求特定的身份命名空间，并通过安全 NFC 通道直接接收签名载荷响应。
直接 API 验证： 在线交易直接查询钱包验证 API。验证方发送凭证出示请求，用户完成身份认证，数据在单个 HTTP 请求—响应周期内返回。
异步后台处理
身份核验评估： 身份证据验证，包括人工审核或查询 DMV 记录，可以异步运行。结果可用后，客户端会收到回调通知或通过轮询获取更新。
推送式凭证配置： 身份核验获批后，异步通知可以触发钱包密钥生成和最终凭证交付。
密钥轮换与信任列表同步： 验证方可以通过后台同步获取更新后的信任材料和撤销信息，而不必要求每次凭证出示交易都完成这些更新。
架构层面的影响
企业应明确列出每项操作对应的可用性要求：
这一分类的目的是识别运行时对提供商的依赖，以及故障边界。企业不应因为提供商具有很高的可用性，就假定每笔 mDL 交易都必须依赖该提供商在线可达。
即使提供商具有很高的可用性，如果每笔验证交易都要求其在线基础设施参与，它仍然可能成为架构上的单点故障。反过来，如果架构有意将面向用户的验证与后台同步分离，那么即使提供商或网络暂时发生故障，也能保留关键的验证能力。
状态协调与离线注意事项
状态变化必须在不同系统之间同步，同时维护用户隐私。
网络中断期间的同步
离线验证方： 终端缓存文档签名者证书和证书撤销列表。扫描完全通过本地 NFC 完成。网络恢复后，数据会同步到中央云端日志。
设备有效期强制检查： mSO 载荷包含
validFrom和validUntil时间戳。如果离线手机的安全时钟显示的时间已超过validUntil，读取器就会拒绝该凭证。
离线能力应当是评估 mDL 提供商时最重要的标准之一。
如果提供商的演示完全依赖高速互联网连接，就不能证明其具备离线运行能力。
严谨的评估应要求提供商演示以下场景：
在没有网络连接的情况下出示凭证。
在没有网络连接的情况下验证凭证。
使用缓存的信任材料。
处理过期凭证。
处理过期的撤销信息。
恢复网络连接。
重新连接后执行同步。
处理设备时钟异常。
处理提供商服务中断。
目标是测试故障场景下的架构，而不仅仅是验证一切正常时的流程。
特定应用场景
尽管 mDL 验证具有共同的技术基础，但不同的依赖方在保证级别、请求属性、运行限制和隐私预期方面存在差异。以下示例说明了这些区别：机场需要进行全面的身份验证，而零售场景中的年龄验证则应尽量减少信息披露。
航空安检检查点
机场需要将身份信息与乘客名单进行全面核对。
请求的属性： 名字、姓氏、照片、出生日期、证件号码、签发机构，以及是否符合 Real ID 要求的标志。
运行集成： TSA 读取器提取相关属性，根据联邦信任列表验证文档签名者证书，并执行生物特征人脸匹配。
酒类商店年龄验证
零售环境需要快速完成验证，同时尽可能减少数据暴露。
请求的属性：
age_over_21布尔值和用户肖像。数据最小化： 姓名、地址、证件号码和出生日期不会包含在数据载荷中。
运行集成： 终端验证密码学签名，在屏幕上显示肖像，并显示年龄验证通过的状态标志。
运行集成
终端验证密码学签名，核实所需声明，在适当情况下显示肖像，并输出年龄验证通过的状态。
这一场景的架构重点是数据最小化和交易流程的简洁性。
这两个示例说明，企业不应仅凭一次演示来评估 mDL 提供商。
针对机场身份验证优化的实现方案，可能会暴露零售应用并不需要的数据。
反过来，针对简单年龄验证优化的提供商，可能无法提供高保证级别身份验证所需的控制能力。
因此，必须根据企业实际的依赖方策略和交易类别来评估提供商。
治理、合规与技术策略
治理、隐私、安全和互操作性要求会影响 mDL 系统请求哪些属性、保留哪些信息、如何管理密码学材料，以及如何执行标准。以下策略将这些要求转化为适用于企业应用和第三方提供商的控制措施。
数据最小化要求： 验证方软件只能请求交易所必需的元素。除非适用法规规定了例外情况，否则商业验证方不得存储个人身份信息（PII）。
零追踪保证： 签发机构不得构建能够追踪用户何时或何地出示凭证的配置系统或状态系统。
密码学规范： 文档签名者密钥必须每隔 30 至 90 天轮换一次。系统必须使用 SHA-256 或 SHA-384 密码学原语。
硬件密钥绑定强制要求： 应用必须在安全硬件中配置密钥，并要求用户通过生物特征或 PIN 码进行身份认证。
互操作性合规： 所有钱包软件和验证方都必须通过 ISO/IEC 18013-5 标准合规性认证。
避免供应商锁定
mDL 提供商可以降低实现的复杂性，但过度抽象可能造成长期依赖。
例如：
这种架构可能很方便，但也可能难以替换。
更具韧性的架构会在企业与提供商之间设置一个面向标准的抽象边界：
企业不一定需要自行实现协议。
相反，企业应避免让特定提供商的实现细节与业务逻辑变得密不可分。
例如，应用程序代码理想情况下应该表达为：
RequestAgeOver21()而不是在整个应用程序中嵌入特定提供商的凭证结构。
同样，验证结果应当被规范化为企业策略决策，而不是让特定提供商的专有响应贯穿整个应用程序。
这种架构可以让提供商保持可替换性，同时维持业务应用程序的独立性。
抽象层背后，哪些内容仍应保持可见？
企业架构中有一条实用原则：
隐藏实现复杂性，但暴露架构决策。
mDL SDK 可以合理地隐藏以下内容：
CBOR 序列化；
APDU 构造；
密码学库调用；
底层 NFC 会话处理；
特定平台的安全存储 API。
但是，企业应当继续了解以下内容：
信任锚；
凭证签发方身份；
验证结果；
已披露的属性；
证书状态；
凭证有效性；
撤销 / 状态信息；
对提供商的依赖；
隐私与遥测行为；
离线能力；
安全边界；
故障条件。
这种区分可以让提供商集成更易于运维，同时避免将提供商变成一个不透明的信任权威。
上线前的架构审查
在投入生产环境之前，企业必须验证 mDL 集成的信任边界、隐私、安全、韧性和互操作性，而不能仅仅确认验证是否成功。以下五个问题提供了一个实用框架，可用于审查这些责任并评估对提供商的依赖。
1. 我们信任什么？
明确识别以下对象：
签发方；
钱包；
设备；
提供商；
验证方；
证书颁发机构；
信任列表；
后端服务。
2. 我们披露什么？
将每一种依赖方交易映射到其所需的最少属性。
3. 离线时会发生什么？
准确记录哪些功能可以在没有网络连接的情况下继续运行。
4. 发生故障时会怎样？
测试以下场景：
凭证过期；
签名无效；
设备认证无效；
证书已撤销；
信任列表过期；
提供商服务中断；
网络中断；
设备遭到入侵；
同步失败。
5. 我们能否更换提供商？
确定企业能否在不重写应用程序业务逻辑、不改变身份策略模型的情况下，替换 SDK 或提供商。
即使企业从未自行实现底层密码学组件，这些问题仍然能够为架构审查提供有用的框架。
企业采用 mDL 的实用决策模型
企业可以将 mDL 能力划分为三类。
Build（自建）
代表企业战略策略或信任决策的能力，包括：
针对具体交易的披露策略；
企业授权规则；
应用层身份策略；
审计要求；
集成编排。
Buy（采购）
专业提供商能够显著提升实现效率的能力，包括：
钱包 SDK；
协议实现；
NFC 协议栈集成；
密码学库；
凭证验证服务。
Govern（治理）
可以由提供商运营，但必须继续接受企业监督的能力，包括：
密钥管理；
证书基础设施；
设备证明；
撤销机制；
遥测；
隐私；
可用性；
互操作性。
这一模型可以避免两个极端。第一个极端是试图在内部构建所有组件。第二个极端是将整个身份系统视为一个不透明的第三方服务。更合适的企业做法是：
采购实现效率，自建企业策略，治理信任边界。
留给读者与身份架构师的一个思考题
如果移动身份验证逐渐转向密码学绑定、保护隐私且支持离线运行的模式，签发机构和商业依赖方应如何协调严格的监管审计要求与现代隐私法律？后者通常不鼓励不必要地保留敏感个人信息。
另一个相关的架构问题是：
签发机构、提供商和依赖方应如何在不引入新的追踪机制、避免记录用户在何时何地出示移动身份的前提下，实现保护隐私的撤销与状态检查？
这些问题仍然十分重要，因为密码学上的正确性并不能单独保证隐私。
一个在技术上有效的身份系统，仍然可能因为遥测、集中式状态查询、过度保留数据或设计不当的提供商集成而产生隐私风险。
结论
从实体卡片演进到符合 ISO/IEC 18013-5 标准的移动驾驶证，代表着企业信任模型的一次根本性转变。
最重要的架构经验并不是要求每家企业都自行实现完整的 mDL 技术栈。
而是，即使企业并不亲自构建系统，也需要理解自己购买的架构究竟是什么。
提供商或 SDK 可以合理地抽象掉 CBOR 编码、NFC APDU 处理、密码学库调用、安全存储 API 以及其他实现细节。但企业仍然需要了解：谁控制签发方信任，设备密钥如何受到保护，选择性披露如何执行，撤销机制如何运作，离线时会发生什么，系统会收集哪些信息，以及提供商不可用时系统会如何运行。
高速 NFC 凭证出示、硬件保护的设备密钥、密码学签名、HPKE、PKI、选择性披露和离线验证，并不是彼此孤立的技术功能，而是企业信任模型中相互关联的组成部分。
因此，最出色的架构不一定是采用了最先进的提供商，或者拥有最多 API 的架构。
真正出色的架构，是企业能够清楚回答以下问题的架构：我们信任谁？我们披露什么？我们如何验证？离线时会发生什么？提供商发生故障时会怎样？我们能否在不改变信任模型的情况下更换实现方案？
通过将 mDL 集成视为架构与治理问题，而不只是 SDK 集成问题，企业就可以在采用供应商能力的同时，继续掌控安全、隐私、互操作性和长期技术战略。
附录 A——mDL 提供商架构尽职调查清单
评估提供商或库时，至少应覆盖以下六个维度。
密码学架构
需要询问：
支持哪些算法？
私钥在哪里生成？
设备密钥是否由硬件保护？
如何验证设备证明？
如何验证签发方签名？
密码学密钥如何轮换？
证书过期时会发生什么？
使用了哪些密码学库？
能否对密码学配置进行独立审计？
信任与 PKI
需要询问：
谁控制信任锚？
如何验证文档签名者证书？
如何处理主列表（Master Lists）？
如何分发证书撤销列表？
信任列表多久更新一次？
验证方能否使用缓存的信任信息运行？
信任锚变更如何分发？
隐私与数据最小化
需要询问：
依赖方能否单独请求特定属性？
应用程序能否执行针对具体交易的披露策略？
提供商是否保留凭证出示数据？
提供商是否收集位置信息？
能否禁用或减少遥测数据收集？
凭证出示事件是否可能与用户关联起来？
PII 在哪里处理和存储？
离线运行
需要询问：
能否在没有网络连接的情况下验证凭证？
哪些信任材料必须缓存？
如何同步证书更新和状态更新？
状态信息过期时会发生什么？
设备时钟不准确时会发生什么？
提供商能否演示网络中断期间的验证过程？
互操作性
需要询问：
实现方案是否支持 ISO/IEC 18013-5？
能否与独立实现的钱包进行互操作？
能否与独立实现的验证方进行互操作？
提供商是否支持标准化数据结构？
专有扩展是否与基于标准的功能明确分离？
企业能否迁移到其他提供商？
运行韧性
需要询问：
提供商 API 不可用时会发生什么？
凭证出示能否继续进行？
现有凭证能否继续使用？
运行时存在哪些对提供商的依赖？
签发过程中存在哪些对提供商的依赖？
证书或信任列表服务中断时会发生什么？
恢复机制是什么？
目标并不是消除抽象。
目标是确保抽象能够隐藏实现复杂性，却不会掩盖架构风险。
附录 B——符合 ISO/IEC 18013-5 的代表性凭证数据结构
JSON
{
"docType": "org.iso.18013.5.mDL",
"issuerSigned": {
"nameSpaces": {
"org.iso.18013.5.1": [
{
"digestID": 0,
"random": "4F9A01B2C",
"elementIdentifier": "family_name",
"elementValue": "Smith"
},
{
"digestID": 1,
"random": "8E12C3D4A",
"elementIdentifier": "given_name",
"elementValue": "Jane"
},
{
"digestID": 2,
"random": "1F3A89C0D",
"elementIdentifier": "birth_date",
"elementValue": "1990-05-15"
},
{
"digestID": 3,
"random": "7C6B54A21",
"elementIdentifier": "issue_date",
"elementValue": "2024-01-10"
},
{
"digestID": 4,
"random": "9A8B7C6D5",
"elementIdentifier": "expiry_date",
"elementValue": "2029-05-15"
},
{
"digestID": 5,
"random": "3E2D1C0B9",
"elementIdentifier": "issuing_authority",
"elementValue": "CA-DMV"
},
{
"digestID": 6,
"random": "6F5E4D3C2",
"elementIdentifier": "document_number",
"elementValue": "D1234567"
},
{
"digestID": 7,
"random": "0A1B2C3D4",
"elementIdentifier": "portrait",
"elementValue": "<JPEG_2000_BYTE_ARRAY>"
},
{
"digestID": 8,
"random": "5E4D3C2B1",
"elementIdentifier": "age_over_21",
"elementValue": true
}
]
},
"issuerAuth": {
"algorithm": "ES256",
"signature": "<ISSUER_DIGITAL_SIGNATURE_BYTES>",
"mSO": {
"version": "1.0",
"digestAlgorithm": "SHA-256",
"valueDigests": {
"org.iso.18013.5.1": {
"0": "<SHA256_HASH_OF_ELEMENT_0>",
"1": "<SHA256_HASH_OF_ELEMENT_1>",
"2": "<SHA256_HASH_OF_ELEMENT_2>",
"8": "<SHA256_HASH_OF_ELEMENT_8>"
}
},
"deviceKeyInfo": {
"deviceKey": "<DEVICE_PUBLIC_KEY_COSE_KEY>"
},
"validityInfo": {
"signed": "2024-01-10T00:00:00Z",
"validFrom": "2024-01-10T00:00:00Z",
"validUntil": "2029-05-15T23:59:59Z"
}
}
}
},
"deviceSigned": {
"nameSpaces": {},
"deviceAuth": {
"signature": "<DEVICE_PRIVATE_KEY_SIGNATURE>"
}
}
}