Article: Cryptographic Foundation of Mobile ID Systems: An ISO/IEC 18013-5 Enterprise Architecture Blueprint

移动身份证系统的密码学基础：ISO/IEC 18013-5 企业架构蓝图 - InfoQ

InfoQ 首页 文章 移动身份证系统的密码学基础：ISO/IEC 18013-5 企业架构蓝图

移动

从令牌到功能：为AI辅助工程构建成本归因架构（10月29日网络研讨会）

移动身份证系统的密码学基础：ISO/IEC 18013-5 企业架构蓝图

2026年10月16日 22分钟阅读

作者：

• Praveen Kumar Gopalakrishnan

审阅者：

• Sergio De Simone

#### 关注我们

YouTube

232K 粉丝

LinkedIn

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 点赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

• 阅读列表

关键要点

• 将身份验证与凭证发放解耦，以在身份验证和凭证签发之间建立清晰的架构边界。

• 通过评估移动驾照（mDL）提供商的底层架构（而不仅仅是其API），包括其集成模式、安全控制和信任边界来评估mDL提供商。

• 在适当的情况下使用混合公钥加密（HPKE）进行受保护的在线身份传输，并围绕基于标准的NFC交互设计近距离展示。

• 实施领域特定的选择性披露，以在满足个人验证需求的同时最大限度地减少身份属性的披露。

• 将mDL提供商视为更广泛信任架构中的一个组件，明确治理信任边界需超越提供商的SDK范围。

本文面向企业架构师、安全架构师、身份工程师、平台负责人、技术评估人员以及负责集成或选择移动驾照（mDL）功能的产品团队。对于将通过第三方提供商、SDK、钱包平台或验证服务消费mDL的组织而言，本文尤其相关，因此需要理解集成边界背后隐藏的内容。

本文为企业在承诺使用mDL提供商或库之前提供了一个框架，用于提出正确的架构问题。它展示了哪些组件可以安全地抽象化，哪些信任边界必须对企业的可见，应验证哪些密码学和互操作性属性，以及在实际使用案例中需求如何变化。

引言：移动身份证集成易于隐藏，但架构不易实现

从实体凭证向数字移动驾照的转变不仅仅是用户界面的变化。它改变了身份存储的位置、身份声明的认证方式、设备如何成为可信实体、依赖方如何请求信息，以及在网络连接不可用时如何进行验证。

集成mDL的企业可能会遇到看似简单的开发体验：

图1. mDL提供商SDK（来源：作者创建）

从应用程序的角度来看，这可能看起来只是几个API，但底层架构要复杂得多：

图2. 整体移动身份证架构（来源：作者创建）

这种抽象是有用的，但它也带来了风险。

企业并不一定需要自行实现每个组件。在许多情况下，使用专门的提供商或库是正确的工程决策。然而，将实现外包并不等同于将架构责任外包。

提供商可能成功地公开一个提供 verifyCredential()、requestPresentation()、issueCredential() 等操作的 API，但企业仍需做出若干关键决策，包括：

• 凭证存储在何处，设备密钥如何保护？
• 谁控制发行方信任锚点，证书如何验证和轮换？
• 凭证有效性与撤销如何处理，尤其是在验证方离线时？
• 披露哪些身份属性，企业能否强制执行数据最小化策略？
• 提供商收集哪些遥测数据，能否将展示事件与用户关联？
• 当提供商不可用时，企业能否在不重新设计集成的情况下迁移到其他提供商？

即使相应功能由其他人实现，这些问题仍然是架构需求。

因此，本文所述的架构可用于以下两种方式：

• 作为构建 mDL 生态系统部分组件的实施蓝图。
• 作为选择 mDL 提供商、SDK、钱包平台或验证库的评估框架。

第二种用途尤为重要。不应仅通过 SDK 是否能成功完成演示交易来评估提供商。企业应评估信任模型、密码学边界、互操作性、隐私控制、操作行为以及 SDK 后面隐藏的故障模式。

本文对 mDL 架构的处理方式

本文将移动身份识别视为企业架构和信任边界问题，而非单纯的 SDK 集成问题。首先将身份验证与凭证发放分离，因为这两个阶段涉及不同的参与者、信任决策和安全责任。这种区分引出了提供商评估问题：哪些责任可以委托给 mDL 提供商，哪些信任决策必须对企业可见？随后，文章介绍了凭证结构和数据模型，以展示实际被发放和验证的内容。

接下来，文章追踪凭证在验证交易中的流程。高层次的展示流程明确了钱包、依赖方、发行方信任、设备认证和请求属性之间的交互。后续章节将探讨如何通过密码学、mTLS 和证书基础设施保护该交易。讨论随后区分需要即时可用的操作与可在后台运行的操作，并通过离线操作和对账来处理提供商、网络和信任列表故障。

最终章节将探讨这些原则如何在不同依赖方使用案例中发生变化，治理和隐私政策如何限制实现选择，以及企业如何避免过度依赖供应商的同时保持关键架构决策的可见性。本文通过架构审查和“构建、采购、治理”决策模型，将这些理念整合在一起，帮助企业确定哪些能力应保留在企业控制范围内，哪些可以委托给专业供应商。

目标是将这些主题整合成统一的架构视图：明确信任对象、披露内容、验证方式、连接性或供应商失效时的应对措施，以及企业如何持续治理和调整实现方案。

谁应该阅读这篇文章？

主要受众包括：决定移动驾驶执照（mDL）能力如何融入现有身份、API、移动、安全和数据架构的企业和解决方案架构师；评估密钥管理、设备信任、证书基础设施、加密边界、认证和隐私控制的安全架构师；将移动凭证与身份验证、依赖方应用、数字钱包和企业身份平台集成的身份及IAM工程师；评估商业mDL供应商、SDK、验证平台、钱包技术和托管身份服务的技术及供应商评估团队；需要确定内部构建、委托给供应商以及必须保留在企业控制下的架构控制措施的工程领导者；以及设计面向客户的应用程序的产品和平台团队，这些应用需要在包括在线和离线场景在内的多种环境中实现身份验证。

对于所有这些受众，核心问题不是：

"这个SDK能否验证mDL？"

更重要的是：

"SDK背后存在哪些信任、安全、隐私、互操作性和运营架构，是否满足我企业的需求？"

验证与配置架构

验证和配置是凭证生命周期中的两个不同阶段。验证用于确认用户拥有身份声明，而配置则建立硬件信任、发放加密负载，并在设备上安装移动安全对象。

图3. 验证与配置流程（来源：作者原创）

[点击此处查看上方图片的完整尺寸]

#### 阶段1：身份验证

身份验证包含四个主要步骤：

• 身份证据采集：用户在应用内直接拍摄实体驾照（正反面）图像，并录制实时面部视频（活体检测）。

• 负载提交：收集的图像、提取的元数据和活体视频提交至验证系统。

• 授权检查：州机动车管理局（DMV）或权威身份系统使用自动面部识别与官方记录进行比对，并在必要时通过人工审核流程评估证据。

• 验证决策：验证引擎返回明确的状态响应：批准或拒绝。

#### 阶段2：身份配置

身份配置通过以下四个步骤完成：

• 硬件密钥生成：在收到批准状态后，钱包客户端请求安全飞地或硬件安全元件生成非对称设备密钥。

• 证明包组装：客户端提取生成的设备公钥和硬件证明X.509证书。

• 预配载荷提交：钱包将设备公钥、公钥证书、证明参考ID和设备元数据打包，传输给发卡方后端。

• 凭证摘要和加密：发卡机构对驾照身份属性进行摘要，将其绑定到签名的移动安全对象内的设备公钥中，对凭证包进行加密后发送回钱包。

• 存储与展示：钱包使用会话传输密钥解密接收到的载荷，将签名的mSO数据和密钥写入硬件支持的存储，并使凭证可供用户展示。

企业无需自行实现这九个步骤。但应确定各方分别执行哪些步骤，以及哪一方控制最终的信任决策。

因此，供应商评估应建立映射关系以定义各方将提供哪些必要功能。例如：

架构功能

企业

供应商

发卡方/DMV

共享/外部

身份证明

✓

设备密钥生成

✓ / SDK

设备证明

凭证签发

文档签名

钱包存储

✓ / 设备

展示

✓ / App

验证

✓ / RP

✓ / 服务

信任管理

撤销/状态

审计与遥测

确切的所有权模型会有所不同，但企业应能够解释信任边界，而非简单接受供应商的默认抽象。

企业应向mDL供应商提出的问题

黑盒集成可能适用于实现，但不足以进行架构尽职调查。

评估mDL供应商的企业应确保供应商能清晰解释六个领域：

• 密码架构：密钥生成与保护、设备证明、算法、签名和密钥生命周期。

• 信任与PKI：信任锚点、文档签署人证书、信任列表、撤销和证书生命周期。

• 隐私与数据最小化：选择性披露、遥测、展示数据保留、位置信息和关联风险。

• 离线操作：缓存的信任材料、撤销/状态同步、过时信息以及网络中断期间的行为。

• 互操作性：ISO/IEC 18013-5符合性、独立钱包和验证器互操作性、标准化数据结构以及供应商可移植性。

• 运营韧性：供应商依赖项、停机行为、凭证连续性、恢复和故障处理。

目标不是消除抽象。目标是确保抽象隐藏实现复杂性而不隐藏架构风险。

附录A提供了详细的供应商尽职调查清单。

凭证结构与数据模型

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

架构上的重要意义在于，企业接收的并非仅仅是“身份数据”。它接收的是通过加密结构化声明，这些声明的真实性和完整性依赖于发行方签名、值摘要、设备密钥以及周围的信任基础设施。

附录B中提供了一个典型的凭证结构示例，包括发行方签名数据、移动安全对象（mSO）、设备认证与凭证有效性的关系。

这一区别也影响着企业如何评估mDL提供商或库。集成评估不应仅基于其是否能解析或反序列化凭证负载，还必须暴露并正确执行该负载所代表的安全属性。

因此，企业应确认实现是否满足以下条件：

• 正确验证发行方签名；
• 验证移动安全对象；
• 验证设备认证；
• 验证证书链；
• 支持选择性披露；
• 保护敏感凭证材料；
• 向应用程序暴露足够的验证结果；
• 保持基于标准的互操作性。

从凭证结构到企业验证

理解凭证结构只是第一步。企业还必须了解该凭证如何在在线和离线环境中被呈现、保护、验证和管理。

以下章节将通过验证生命周期追踪这些关注点，涵盖从呈现和加密保护到信任基础设施、可用性、离线对账和企业策略的各个方面。

高级用户呈现流程

图4. 用户呈现流程（来源：作者创作）

呈现流程展示了mDL如何在验证交易期间从用户的钱包传输到依赖方。验证者发起呈现请求，钱包建立适当的加密通信通道，用户授权请求的披露，验证者验证生成的凭证数据、发行方信任、设备认证和适用策略。

该流程为后续架构主题提供了操作背景。后续章节将检查支持此交易的安全机制，包括加密保护、证书和信任基础设施、同步和异步交互、离线和对账行为，并展示这些机制如何影响企业集成和提供商评估。

安全与加密：HPKE集成

RFC 9180定义的混合公钥加密（HPKE）用于保护验证者与钱包服务器之间的在线传输和直接API交互。HPKE将非对称密钥封装机制与对称认证加密（带关联数据）结合，实现低延迟加密。

图5. 负载加密序列（来源：作者创作。）

#### 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 验证。

图 6. mTLS 通道（来源：作者创作。）

信任拓扑依赖于专用证书类型

图 7. 信任拓扑（来源：作者创作。）

证书类型 | 用途 | 生命周期 | 密钥类型 | 存储位置 ---|---|---|---|--- 根信任锚点 | 建立根身份层级 | 10 至 20 年 | ECDSA P-384 / RSA 4096 | 离线 HSM 发行机构 CA | 签署特定状态的发行密钥 | 3 至 5 年 | ECDSA P-256 | 高安全 HSM 文档签署者 | 签署短期身份结构 | 30 至 90 天 | 在线 HSM mTLS 客户端/服务器 | 认证系统间 API 连接 | 1 年 | RSA 3072 / ECDSA P-256 | API 网关密钥库 验证者读取器证书 | 认证依赖方终端 | 安全硬件 | 设备认证证书 | 验证设备密钥真实性 | 1 至 3 年 | 设备安全元件

对企业而言，重要问题不一定是服务提供商是否自行运营此基础设施。

真正的问题是：

服务提供商运营哪种证书基础设施？企业自身运营哪种证书基础设施？哪些信任关系仍由发行机构控制？

服务提供商应能够解释证书生命周期管理、证书轮换、信任锚点管理、故障行为以及证书泄露时的责任划分。

同步与异步操作

企业 mDL 架构不会为所有操作使用单一交互模式。某些活动必须在面向用户的验证事务中完成，而其他操作可以在后台执行，而不会延迟凭证展示。因此，架构目标不是选择同步或异步处理作为单一模型，而是识别哪些操作需要即时可用性，哪些操作可以容忍延迟、缓存或最终一致性。

当企业依赖外部 mDL 提供商时，这种区分尤为重要。如果提供商不可用，影响程度取决于运行时与该提供商耦合的操作类型。设计良好的架构应允许现有凭证和离线验证在适用的信任和策略要求允许的范围内继续执行，同时允许发行、配置、在线验证和信任列表同步等操作在必要时依赖后端可用性。

异步后台进程

身份验证评估：身份证据验证（包括人工审核或DMV记录查询）可以异步执行。一旦结果可用，客户端将收到回调或轮询更新。

推送配置：在身份验证通过后，异步通知可以触发钱包密钥生成和最终凭证交付。

密钥轮换与信任列表同步：验证器可以通过后台同步获取更新的信任材料和撤销信息，而无需在每次凭证展示交易时都进行更新。

架构影响

企业应明确将每个操作映射到其可用性要求：

| 操作 | 服务提供商故障是否应阻止它？ | |------|-----------------------------| | 现有离线凭证展示 | 理想情况下不应阻止 | | 离线凭证验证 | 可能会阻止 | | 在线验证 | 可延迟执行 | | 信任列表同步 | 可延迟执行 | | 凭证撤销更新 | 可根据策略临时延迟 | | 新凭证配置 | - |

该分类的目的是识别运行时服务提供商依赖关系和故障边界。企业不应假设因为某个服务提供商具有高可用性，所有mDL交易都应依赖该提供商的可达性。

如果每个验证交易都需要使用在线基础设施，即使服务提供商具有高可用性，仍可能造成架构单点故障。相反，如果架构有意将用户验证与后台同步分离，可以在临时服务提供商或网络故障时保持关键验证能力。

协调与离线考量

状态变更必须在保持用户隐私的同时跨系统同步。

图8. 协调拓扑结构（来源：作者创作。）

#### 网络中断时的同步

• 离线验证器：终端设备缓存文档签名者证书和撤销列表。扫描完全通过本地NFC执行。网络恢复后数据会同步到中央云日志。

• 设备过期强制执行：mSO负载包含validFrom和validUntil时间戳。如果离线手机的安全时钟超过validUntil，读取器将拒绝该凭证。

离线能力应是评估mDL提供商最重要的标准之一。

完全通过高速互联网连接进行的提供商演示无法证明离线准备就绪。

严肃评估应要求提供商演示：

• 无网络连接时的凭证展示
• 无网络连接时的验证
• 缓存的信任材料
• 过期凭证行为
• 过时的撤销信息
• 网络恢复
• 重新连接后的同步
• 设备时钟异常
• 服务提供商故障行为

目标是测试故障架构，而不仅仅是正常流程。

虽然mDL验证共享共同基础，但依赖方在保证要求、请求属性、操作约束和隐私预期方面存在差异。以下示例说明这些差异：机场的全面身份验证与零售年龄验证的最小披露。

图9. 验证请求路由（来源：作者创建。）

航空公司安全检查点

图10. TSA验证流程（来源：作者创建。）

机场需要根据乘客名单进行完整身份验证。

• 请求属性：名字、姓氏、照片、出生日期、证件编号、签发机构和真实ID合规标志。

• 操作集成：TSA读卡器提取属性，验证文档签署者证书与联邦信任列表，执行生物特征面部匹配。

酒店商店年龄验证

图11. 商店验证流程（来源：作者创建。）

零售环境需要快速验证并最小化数据暴露。

• 请求属性：年龄是否超过21岁布尔值和用户肖像。

• 数据最小化：姓名、地址、证件编号和出生日期从数据负载中省略。

• 操作集成：终端验证加密签名，在屏幕上显示肖像，并显示年龄验证通过状态指示器。

操作集成

终端验证加密签名，验证所需声明，在适当位置显示肖像，并生成年龄验证通过状态。

架构优先级是数据最小化和交易简洁性。

这两个示例说明了为什么企业不应基于单一演示评估mDL提供商。

针对机场身份验证优化的实现可能暴露比零售应用所需更多的数据。

相反，针对简单年龄验证优化的提供商可能无法提供高保证身份验证所需的控制。

因此，提供商必须根据企业的实际依赖方政策和交易类别进行评估。

治理、合规与技术政策

治理、隐私、安全和互操作性要求决定了mDL系统如何请求属性、保留信息、管理加密材料和执行标准。以下政策将这些要求转化为企业应用和第三方提供商的控制措施。

• 数据最小化要求：验证软件必须仅请求交易所需的元素。商业验证者存储PII被禁止，除非有法规例外。

• 零跟踪保证：签发机构不得建立跟踪用户何时何地出示凭证的凭证或状态系统。

• 加密卫生：文档签署者密钥必须每30至90天轮换一次。系统必须使用SHA-256或SHA-384加密原语。

• 硬件密钥绑定强制：应用程序必须在安全硬件中配置带有生物特征或PIN用户认证要求的密钥。

• 互操作性合规：所有钱包软件和验证器必须认证符合ISO/IEC 18013-5标准。

避免供应商锁定

mDL提供商可以降低实现复杂性，但过度抽象可能造成长期依赖。

例如：

图12. 提供商SDK（来源：作者创建。）

这种架构可能便于使用，但难以替换。

一种更具弹性的架构会在企业与服务提供方之间设置一个以标准为导向的抽象边界：

图13. 移动ID企业应用（来源：作者创建）

企业不一定需要自行实现协议。

相反，应避免让特定于服务提供方的实现细节与业务逻辑紧密耦合。

例如，应用程序代码应理想地表达：

RequestAgeOver21()

而不是在应用程序各处嵌入特定于服务提供方的凭证结构。

同样，验证结果应归一化为企业的策略决策，而不是在应用程序各处暴露专有的服务提供方响应。

这种架构允许服务提供方保持可替换性，同时保持业务应用的独立性。

抽象层后应保持可见的内容

对企业架构而言，一个有用的规则是：

隐藏实现复杂性，但暴露架构决策。

一个mDL SDK可以适当隐藏：

• CBOR序列化；
• APDU构建；
• 加密库调用；
• 低级NFC会话处理；
• 平台特定的安全存储API。

然而，企业应保留对以下内容的可见性：

• 信任锚点；
• 凭证签发者身份；
• 验证结果；
• 披露的属性；
• 证书状态；
• 凭证有效性；
• 撤销/状态状态；
• 服务提供方依赖项；
• 隐私和遥测行为；
• 离线功能；
• 安全边界；
• 和故障条件。

这种区分使得服务提供方集成更容易操作，而不会将服务提供方变成不透明的信任权威。

生产前的架构审查

在投产前，企业必须验证mDL集成的信任边界、隐私、安全、弹性和互操作性，而不仅仅是成功的验证。以下五个问题为审查这些责任和评估服务提供方依赖项提供了实用框架。

1. 我们信任什么？

识别：

• 签发者；
• 钱包；
• 设备；
• 服务提供方；
• 验证者；
• 证书颁发机构；
• 信任列表；
• 后端服务。

2. 我们披露什么？

将每个依赖方交易映射到所需的最小属性。

3. 离线时会发生什么？

详细记录在无连接情况下继续运行的功能。

4. 当某些东西发生故障时会发生什么？

测试：

• 过期的凭证；
• 无效的签名；
• 无效的设备认证；
• 被撤销的证书；
• 过时的信任列表；
• 服务提供方故障；
• 网络故障；
• 设备被入侵；
• 同步失败。

5. 我们能否更换服务提供方？

确定企业是否可以在不重写应用程序业务逻辑或更改其身份策略模型的情况下替换SDK或服务提供方。

这些问题提供了一个架构审查框架，即使企业本身从未实现底层加密组件，该框架也具有实用性。

企业采用的实用决策模型

企业可以将mDL功能分为三类。

自建

代表企业战略政策或信任决策的功能，包括：

• 交易特定的披露策略；
• 企业授权规则；
• 应用级身份策略；
• 审计要求；
• 集成编排。

购买

治理

由供应商运营但必须接受企业监管的能力，包括：

• 密钥管理；
• 证书基础设施；
• 设备认证；
• 撤销机制；
• 远程监控；
• 隐私保护；
• 可用性；
• 互操作性。

此模型避免了两种极端情况。第一种是试图内部构建所有组件。第二种是将整个身份系统视为不透明的第三方服务。更合适的企业的做法是：

购买实现效率。构建企业政策。治理信任边界。

给读者和身份架构师的思考问题

如果移动身份验证向密码学绑定、隐私保护、支持离线的模式发展，发卡机构和商业依赖方如何在严格监管审计要求与现代隐私法律之间取得平衡？现代隐私法律倾向于避免不必要的敏感个人信息保留。

一个相关的架构问题：

发卡机构、供应商和依赖方如何在不引入新的用户身份使用追踪机制的前提下，实现隐私保护的撤销和状态检查？

这些问题仍然重要，因为密码学正确性本身并不能保证隐私。

一个技术上有效的身份系统仍可能通过远程监控、集中式状态检查、过度的数据保留或设计不佳的供应商集成，造成隐私风险。

结论

数字身份从实体卡片向符合ISO/IEC 18013-5标准的移动驾照的演变，代表了企业信任模型的根本性转变。

最重要的架构教训不是每个企业都应该自行实现完整的mDL堆栈。

而是企业需要理解他们购买的架构，即使他们没有自行构建它。

供应商或SDK可以适当抽象掉CBOR编码、NFC APDU处理、密码学库调用、安全存储API和其他实现细节。但企业仍然需要理解谁控制发卡方信任、设备密钥如何保护、选择性披露如何执行、撤销机制如何运作、离线时会发生什么、收集了哪些信息，以及当供应商不可用时系统的行为。

高速NFC展示、硬件支持的设备密钥、密码学签名、HPKE、PKI、选择性披露和离线验证并不是孤立的技术特性。它们是企业信任模型相互关联的组成部分。

因此，最强的架构不一定是拥有最先进供应商或最多API的架构。

而是企业能够清晰回答以下问题的架构：我们信任谁？我们披露了什么？我们如何验证？离线时会发生什么？当供应商失效时会发生什么？我们能否在不改变信任模型的情况下更改实现？

通过将mDL集成视为架构和治理问题而非单纯的SDK集成问题，企业可以在采用供应商能力的同时，保持对安全、隐私、互操作性和长期技术战略的控制权。

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

对提供方或库的评估应至少涵盖六个维度。

加密架构

需确认：

• 支持哪些算法？
• 私钥在何处生成？
• 设备密钥是否由硬件支持？
• 如何验证设备认证？
• 如何验证签发方签名？
• 如何轮换加密密钥？
• 证书过期时会发生什么？
• 使用了哪些加密库？
• 加密配置能否独立审计？

信任与PKI

• 谁控制信任锚点？
• 如何验证文档签署者证书？
• 如何处理主列表？
• 如何分发证书吊销列表？
• 信任列表更新频率如何？
• 验证方能否使用缓存的信任信息？
• 信任锚点变更如何分发？

隐私与数据最小化

• 依赖方能否请求单个属性？
• 应用能否强制执行交易特定的披露策略？
• 提供方是否会保留呈现数据？
• 提供方是否会收集位置信息？
• 是否可禁用或最小化遥测数据？
• 呈现事件能否与用户关联？
• 个人身份信息（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>"
    }
  }
}

作者部分主容器

关于作者

部分标题

每个作者的主容器

#### Praveen Kumar Gopalakrishnan

显示更多

显示更少

#### 本内容属于移动主题

##### 相关主题：

• 开发
• 架构与设计
• 认证
• 标准化
• 数字身份
• 监管
• 身份管理
• 互操作性
• 企业架构
• 移动
• 企业
• 移动隐私
• 安全
• 政府
• 架构
• 配置
• 访问控制
• 相关编辑
• 相关赞助商 AI 安全手册：加速 AI 进程，同时不牺牲安全性
• 相关赞助商 Equal Experts 帮助组织利用 AI、现代化技术并通过专家工程、协作和创新交付实践构建更好的软件。了解更多。

InfoQ 电子报

每周二发送的InfoQ上周内容精选。加入超过25万名高级开发者的社区。查看示例

我们保护您的隐私。