ISO/IEC 18013-5企业架构：mDL集成前要问清楚的七件事

这篇文章写给企业架构师、安全架构师、身份工程师、平台负责人和技术评估人员，也写给负责集成或选型移动驾驶证（mDL）能力的产品团队。对那些通过第三方提供商、SDK、钱包平台或验证服务接入 mDL 的组织来说，文章尤其有参考价值——这些组织需要弄清楚，集成边界背后到底藏着什么。

文章给出一个框架，帮企业在选定某家 mDL 提供商或某个库之前，把该问的架构问题问对。哪些组件可以安全地抽象掉，哪些信任边界必须对企业保持可见，哪些密码学属性和互操作性特征需要验证，以及换到不同的实际场景后相关要求会怎么变，文中都会讲到。

引言：移动身份集成很容易被隐藏，架构设计却没那么简单

从实体凭证转向数字移动驾驶证，不只是用户界面变了。身份信息存放在哪里、身份声明怎么认证、设备怎样建立可信关系、依赖方如何请求信息、断网时又怎么完成验证，这些都跟着变了。

集成 mDL 的企业可能会觉得，开发者体验看起来挺简单：

可站在应用程序的角度看，也许只是几个 API，底下的架构却复杂得多：

这种抽象很好用，风险也随之而来。

企业未必需要自己实现每一个组件。很多情况下，采用专业提供商或库就是正确的工程决策。不过，把实现工作外包出去，不等于把架构责任也一并外包。

提供商可能已经把verifyCredential()、requestPresentation() 和 issueCredential()这些操作的 API 都做成功了，企业仍要拍板几件关键事：

• 凭证存在哪里？设备密钥怎么保护？

• 签发方信任锚由谁管理？证书如何验证、如何轮换？

• 凭证有效性和撤销问题怎么处理，特别是验证方离线的时候？

• 哪些身份属性会被披露？企业能不能强制执行数据最小化策略？

• 提供商会收集哪些遥测数据？凭证出示事件有没有可能被关联到具体用户？

• 提供商一旦不可用会怎样？企业能不能不重新设计集成方案就迁到别的提供商？

就算相应功能由别人实现，这些问题依然属于架构层面的要求。

所以，文中这套架构可以派两种用场：

1. 一是当实现蓝图，给负责构建 mDL 生态系统部分组件的组织用。

2. 二是当评估框架，给需要挑选 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：身份核验

身份核验大致分四步：

1. 采集身份凭据： 用户在应用内直接拍摄实体驾驶证的正面与背面照片，同时录一段实时人脸视频，供活体检测使用。

2. 提交载荷： 采集到的图像、提取出的元数据以及活体检测视频，一并交给验证系统。

3. 授权检查： 机动车管理部门（DMV）或权威身份系统依据官方记录，用自动人脸识别技术评估这些证据，必要时再走人工审核流程复核。

4. 核验决策： 验证引擎给出明确的状态响应：批准或拒绝。

阶段 2：身份凭证配置

身份凭证配置分四步走完：

1. 生成硬件密钥： 拿到批准状态后，钱包客户端会向 Secure Enclave 或硬件安全元件请求生成一对非对称设备密钥。

2. 组装证明材料包： 客户端把生成的设备公钥和硬件证明 X.509 证书取出来。

3. 提交配置载荷： 钱包将设备公钥、公开证书、身份核验参考 ID 与设备元数据打成包，发送给签发方后端。

4. 凭证摘要计算与加密： 签发机构对驾驶证身份属性做摘要计算，把这些属性连同设备公钥一起绑定进经过签名的移动安全对象，再加密凭证包，回传给钱包。

5. 存储与呈现： 钱包用会话传输密钥解密收到的载荷，把经过签名的 mSO 数据和密钥写入硬件保护的存储空间，并让凭证能显示给用户。

这九个步骤，企业未必都得自己实现。但每一步由哪一方来做、最终的信任决策握在谁手里，企业应当讲清楚。

所以评估厂商的时候，得先画一张职责分配图，把每项必要功能落到具体一方头上。举例来说：

职责归属的具体模式可以不一样。关键是企业要能把信任边界讲明白，不能直接照单全收厂商默认的那套抽象。

该向 mDL 提供商追问什么

黑盒集成本身未必不合理，但拿它当架构尽职调查的全部，显然不够。

评估 mDL 提供商时，企业要确认对方能把下面六件事说清楚：

1. 密码学架构：密钥怎么生成、怎么保护，设备证明、算法、签名以及密钥生命周期如何安排。

2. 信任与 PKI：信任锚、文档签名者证书、信任列表、撤销机制和证书生命周期。

3. 隐私与数据最小化：选择性披露、遥测、凭证出示数据的留存、位置信息，以及关联风险。

4. 离线运行：缓存了哪些信任材料、撤销与状态如何同步、信息过期怎么处理，断网时系统又会怎么表现。

5. 互操作性：是否合规于 ISO/IEC 18013-5、不同钱包与验证方之间能否互通、数据结构是否标准化，以及提供商能不能被替换。

6. 运行韧性：对提供商的依赖程度、服务中断时的行为、凭证连续性、恢复机制和故障处理。

目标不是把抽象消灭掉。抽象可以藏住实现上的复杂度，但不能把架构风险一起盖住。

更细的提供商尽职调查清单，附录 A 里有。

凭证长什么样、数据怎么建模

ISO/IEC 18013-5 用结构化且紧凑的数据表示，来承载签发方签名的身份声明。一份凭证里有签发方签名的命名空间、元素标识符、摘要、签发方认证信息、设备密钥信息和有效期信息。

从架构上看，重点在于企业拿到的不只是“身份数据”，而是经过密码学结构化处理的声明。这些声明真不真、完不完整，取决于签发方签名、数值摘要、设备密钥，还有外围那套信任基础设施。

附录 B 给了一个有代表性的凭证结构，里面包含签发方签名数据、移动安全对象（mSO）、设备认证与凭证有效性之间的关系。

这个区别同样影响企业怎么看 mDL 提供商或库。集成方案能解析、能反序列化凭证载荷，不代表它就达标。它还得把载荷所代表的安全属性暴露出来，并且正确执行。

所以企业要确认，这套实现能不能做到以下几点：

• 正确验证签发方签名；

• 验证移动安全对象；

• 验证设备认证；

• 验证证书链；

• 支持选择性披露。

• 敏感凭证材料要得到妥善保护；

• 验证结果需要足够完整地交到应用手里；

• 基于标准的互操作性也要维持住。

从凭证结构到企业级验证

看懂凭证结构只是开头。凭证在在线和离线场景里怎么出示、怎么受保护、怎么被验证、又由谁来治理，企业同样得弄清楚。

后面的章节会沿着验证生命周期逐项展开：从凭证出示和密码学保护，到信任基础设施、可用性、离线状态协调以及企业策略。

用户凭证出示的高级流程

一次验证交易中，mDL 从用户钱包交到依赖方手里，走的就是凭证出示流程。验证方先发起出示请求，钱包随后建立相应的安全通信通道，用户授权披露所请求的信息，接着验证方对返回的凭证数据、签发方信任、设备认证和适用策略逐项核验。

这套流程给后面讨论的架构话题提供了运行层面的背景。密码学保护、证书与信任基础设施、同步与异步交互、离线运行和状态协调机制如何支撑这类交易，以及它们怎样影响企业集成和提供商评估，后续章节会逐一说明。

安全与密码学：集成 HPKE

在线传输，以及验证方与钱包服务器之间直接进行的 API 交互，都靠 RFC 9180 定义的混合公钥加密（HPKE）来保护。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 提供商时，离线能力应该算最重要的标准之一。

如果一家厂商的演示全程离不开高速网络，那就说明不了它有离线运行的本事。

真正严格的评估，会要求提供商把这些场景演一遍：

1. 断网状态下出示凭证。

2. 断网状态下验证凭证。

3. 用缓存下来的信任材料。

4. 对付已过期的凭证。

5. 对付过期的撤销信息。

6. 把网络接回来。

7. 重连之后做一次同步。

8. 处理设备时钟不正常的情况。

9. 处理提供商服务中断。

重点在于检验出故障时架构扛不扛得住，而不只是走一遍一切正常时的流程。

具体应用场景

mDL 验证的技术底座是共通的，可不同依赖方在保证级别、要哪些属性、运行限制和隐私期待上并不一样。下面这些例子能看出差别：机场要做的是完整身份核验，零售场景里的年龄验证则要把信息披露压到最少。

航空安检口

机场方面需要把身份信息和乘客名单做完整比对。

• 机场核验要的属性包括姓名、姓氏、照片、出生日期、证件号码、签发机构，以及是否满足 Real ID 要求的标志。TSA 读取器会把这些相关属性取出来，先按联邦信任列表核对文档签名者证书，再做生物特征人脸比对。

酒类商店的年龄核验

零售场景讲究的是验证快，同时把数据暴露压到最低。

• 需要请求的内容包括：布尔值和用户肖像。age_over_21

• 数据最小化体现在：姓名、地址、证件号码、出生日期都不会进入数据载荷。终端一侧会验密码学签名，在屏幕上显示肖像，并给出年龄验证通过的状态标志。

运行集成

终端验密码学签名，核对所需声明，在合适的情况下显示肖像，最后输出年龄验证通过的状态。这一场景在架构上盯的是数据最小化和交易流程的简洁。

从这两个例子看，企业评估 mDL 提供商时，不能只看一次演示就下判断。

为机场身份验证做过优化的实现，可能带出零售应用根本用不到的数据；反过来，主打简单年龄验证的提供商，也未必拿得出高保证级别身份验证所需的控制能力。

所以评估提供商，得看企业自身的依赖方策略和交易类别。

治理、合规与技术策略

治理、隐私、安全、互操作性这几方面的要求，会决定 mDL 系统请求哪些属性、留存哪些信息、密码学材料怎么管、标准怎么执行。下面这些策略，就是把上述要求落成适用于企业应用和第三方提供商的控制措施。

• 数据最小化方面：验证方软件只能请求交易必需的元素，除法规规定的例外情形，商业验证方不得存储个人身份信息（PII）。零追踪方面：签发机构不得搭建能追踪用户何时、何地出示凭证的配置系统或状态系统。

• 密码学规范上，文档签名者密钥须每 30 至 90 天轮换一次，系统须采用 SHA-256 或 SHA-384 密码学原语。硬件密钥绑定是硬性要求：应用须把密钥配置在安全硬件中，并要求用户通过生物特征或 PIN 码完成身份认证。

• 互操作性合规上，所有钱包软件和验证方都须通过 ISO/IEC 18013-5 标准合规性认证。

避免供应商锁定

mDL 提供商能把实现复杂度降下来，但抽象过头，长期看会形成依赖。

例如：

这样的架构是方便，可替换起来也可能很费劲。

更有韧性的做法，是在企业和提供商中间划出一条面向标准的抽象边界。协议本身，企业未必要自己动手实现。但有一条要避开：别让某家提供商的具体实现细节和业务逻辑缠得太死。

打个比方，应用代码理想状态下应该写成下面这样，[[保留2]] [[保留3]] 而不是把某家提供商的凭证结构塞得满应用都是。

RequestAgeOver21()

验证结果也是同理，应当归一成企业自己的策略判断，别让提供商的专有响应在程序里到处流。这么设计，提供商换起来才方便，业务应用的独立性也保得住。

抽象层背后，哪些东西还该看得见？

企业架构里有个挺实用的原则：实现上的复杂性藏起来，架构层面的决策露出来。

mDL SDK 把这些藏起来是合理的：CBOR 序列化、APDU 构造、密码学库调用、底层 NFC 会话处理，还有特定平台的安全存储 API。

不过下面这些，企业还是得心里有数：凭证签发方是谁，[[保留4]] [[保留5]]

• 信任锚；

• 验证结果；

• 披露了哪些属性，凭证是否有效，[[保留6]]

• 证书状态；

• 撤销和状态信息怎么样，对提供商的依赖有多深，隐私与遥测行为如何。[[保留7]] [[保留8]] [[保留9]]

• 离线能力；

• 安全边界；

• 故障条件。

这样分开之后，提供商集成运维起来更省事，也不至于把提供商供成一个看不透的信任权威。

上线前的架构审查

真要把mDL集成推进生产环境，企业得先看信任边界、隐私、安全、韧性和互操作性这几项过不过关，光确认验证能跑通不算数。下面五个问题可以当作一套现成的框架，用来逐项核对责任归属，顺带掂量对提供商的依赖有多重。

1. 我们信任什么？

先把信任的对象一个个点清楚：

• 签发方；

• 钱包；

• 设备；

• 提供商；

• 验证方；

• 还有证书颁发机构；

• 信任列表；

• 后端服务。

2. 我们披露什么？

每一笔依赖方交易，都要对着它真正需要的那几个属性做映射，只给最少的那部分。

3. 离线时会发生什么？

断网之后哪些功能还能照常跑，要一笔一笔写清楚。

4. 发生故障时会怎样？

下面这些场景都得测：

• 凭证过期；

• 签名无效；

• 设备认证失效；

• 证书被撤销；

• 信任列表过期；

• 提供商服务中断；

• 网络中断；

• 设备被攻破；

• 同步失败。

5. 我们能否更换提供商？

要弄清楚的是：企业换掉SDK或提供商时，能不能不动应用程序的业务逻辑，也不改身份策略模型。

即便底层密码学组件企业从来没自己写过，这五个问题照样能撑起一份架构审查的框架。

企业采用mDL的实用决策模型

mDL能力在企业里可以分成三类。

Build（自建）

凡是牵涉企业战略取舍或信任判断的能力，都归到自建这一边，具体包括：

• 针对具体交易的披露策略；

• 落到企业一侧，授权规则由谁定、应用层的身份策略怎么设，这两件事得握在自己手里。

• 审计要求；

• 集成编排。

买（采购）

能明显加快落地速度的部分，可以交给专业厂商来做，比如钱包 SDK、NFC 协议栈的集成。

• 协议实现；

• 密码学库；

• 还有凭证验证服务。

管（治理）

这类能力可以让提供商来运营，但企业的监督权不能交出去，其中包括：

• 密钥管理；

• 证书基础设施。

• 设备证明；

• 撤销机制；

• 遥测；

• 隐私；

• 可用性；

• 互操作性。

走这条路，能躲开两种走法。一种是所有组件都自己从零搭；另一种是把整套身份系统当成一个看不透的第三方服务包出去。对企业来说，更合适的做法是：

效率靠采购，策略自己定，信任边界自己管。

留一道题给读者和身份架构师

移动身份验证要是逐步走向密码学绑定、隐私受保护、还能离线跑，签发机构和商业依赖方该怎么把严格的监管审计要求，跟现代隐私法律协调起来？后者一般并不希望敏感个人信息被不必要地留着。

还有一个架构层面的问题：

签发机构、提供商和依赖方，怎样才能做到保护隐私的撤销与状态检查，同时不新增追踪手段、不记录用户何时何地出示移动身份？

这些问题至今仍然要紧，原因在于密码学上算得对，并不等于隐私就守得住。

一套身份系统在技术上跑得通，照样可能因为遥测、集中式状态查询、数据留得过多，或者提供商集成设计得不好，而冒出隐私风险。

结论

移动驾驶证（mDL）按 ISO/IEC 18013-5 标准做出来，从一张实体卡走到手机里，企业原来那套信任模型也跟着变了底子。

要说最要紧的架构经验，并不是让每家公司都自己去把整条 mDL 技术栈搭一遍。就算企业不亲手建系统，也得弄明白自己买回来的到底是什么架构。

CBOR 编码、NFC APDU 处理、密码学库调用、安全存储 API，这些实现层面的细活，提供商或 SDK 大可以合理地藏起来。但有几件事企业绕不过去：签发方信任握在谁手里，设备密钥怎么护住，选择性披露靠什么执行，撤销机制怎么跑，断网之后会出什么状况，系统会收走哪些信息，以及提供商一旦不可用系统还能不能转。

高速 NFC 凭证出示、硬件保护的设备密钥、密码学签名、HPKE、PKI、选择性披露、离线验证——这些不是各管一摊的技术功能，它们在企业的信任模型里是彼此咬合的部件。

所以最强的架构，未必是选了最前沿的提供商，也未必是 API 数量最多的那个。真正拿得出手的架构，是企业能把下面几问答得清清楚楚：我们信谁？我们披露什么？我们怎么验证？离线时怎么办？提供商出故障会怎样？换一套实现方案，信任模型能不能不动？

把 mDL 集成当成架构和治理的事来看，而不是只当成接个 SDK，企业就能一边用上供应商的能力，一边把安全、隐私、互操作性和长期技术路线攥在自己手里。

附录 A——mDL 提供商架构尽职调查清单

挑提供商或库的时候，下面六个维度至少要全覆盖。

密码学架构

需要询问：

• 算法上支持哪些？私钥在哪儿生成？设备密钥有没有硬件保护？设备证明怎么验？签发方签名怎么验？密码学密钥如何轮换？证书到期之后会发生什么？用的是哪些密码学库？密码学配置能不能请外部独立审计？

信任与 PKI

需要询问：

• 信任锚由谁掌控？文档签名者证书怎么验证？主列表（Master Lists）如何处理？证书撤销列表又靠什么分发？

• 信任列表的刷新频率是怎样的？

• 验证方在运行过程中，能否直接复用已经缓存的信任信息？

• 信任锚发生变动后，通过什么方式下发？

隐私与数据最小化

需要询问：

• 依赖方可以只申请某几个指定属性吗？

• 针对某一笔具体交易，应用层能否落实相应的披露策略？

• 凭证出示过程中产生的数据，提供商会留存吗？

• 提供商会不会采集位置信息？

• 遥测数据的收集能否关闭，或者调低范围？

• 每一次凭证出示事件，有没有可能被关联到具体用户？

• PII 的处理和存放分别在哪里完成？

离线运行

需要询问：

• 没有网络连接时，凭证还能不能验证？

• 哪些信任材料属于必须缓存的范围？

• 证书更新与状态更新之间如何保持同步？

• 状态信息一旦过期，会出现什么情况？

• 设备时钟本身不准时，又会怎样？

• 网络中断期间的验证流程，提供商能拿出来演示吗？

互操作性

需要询问：

• 实现方案对 ISO/IEC 18013-5 的支持情况如何？

• 与独立实现的钱包之间能否互操作？

• 与独立实现的验证方之间能否互操作？

• 提供商是否采用标准化数据结构？

• 专有扩展和基于标准的功能之间，是否做了清晰区分？

• 企业日后想换一家提供商，迁移可行吗？

运行韧性

需要询问：

• 提供商 API 一旦不可用，会发生什么？

• 出示环节碰到提供商 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>"    }  }}