警察、租车柜台、雇主、保险公司：为何他们不能查看相同的数据

未来国际驾驶许可证（IDP）在设计上最大的错误，就是将所有核验方视为同一类核验方。警察、租车柜台、雇主和保险公司所提出的问题各不相同——因此他们收到的答案也不应相同。

同一位驾驶人。同一项基本驾驶权利。同一个数字钱包。但面对四类截然不同的核验方：

• 路边执勤的警察
• 取车时的租车柜台
• 核查车队资格的雇主
• 审核理赔的保险公司

如果未来的国际驾驶许可证向这四类核验方展示相同的数据，那么这套系统从一开始就已经失败。失败的原因不在于凭证不安全，而在于信息披露模型过于简单。

标准化社区已经开始摒弃这种简单模型。W3C的可验证凭证（VC）规范描述了由签发方、持有方和核验方构成的生态系统，并以雇主和网站作为核验方示例。欧盟的移动驾驶许可证（mDL）规范已将路边核查与租车核验视为独立的验证场景，包括租车的远程预审和警察的当面核查。这套架构本就是为多类核验方而设计的。真正的错误，在于将用户体验设计得好像只存在一种核验方。

为何实体卡片让我们形成了错误的思维定式

实体驾照让我们养成了”全盘展示”的习惯。你把卡递过去，对方看到卡上的内容，整个交互就此结束。

在纸质世界里，这种做法尚可接受，因为别无选择。但在数字世界中，这种做法已无法令人接受。

W3C VC数据模型2.0明确指出：驾照可能包含证件号码、身高、体重、生日和家庭住址——但对于某一特定交易而言，这些信息远远超出了实际需要。现行标准的核心要点如下：

• W3C最佳实践：支持选择性披露，且仅请求严格必要的信息
• 欧盟数据保护指南：数据处理必须限定于特定目的，且处理的数据须具有必要性和相称性
• 未来国际驾驶许可证的首要原则：使用同一凭证，不等于拥有相同的查阅权

正确的模型是基于策略的信息披露

若要构建一套严谨的架构，正确的模型应更接近基于属性的访问控制，而非数字卡片的出示展示。

NIST SP 800-205将访问控制决策定义为：依据策略，对主体、客体、请求操作及环境条件相关属性的综合评估。这正是未来国际驾驶许可证所需的结构框架：

• 主体：驾驶人
• 客体：被请求的数据字段
• 操作：不是抽象的”查看驾照”，而是具体行为，例如”在路边核验B类驾驶资格”或”核验某一预订的租车资格”
• 环境：路边执法、租车柜台、远程预审、车队入职和事故后理赔审核属于不同的环境，应导向不同的决策结果

NIST还指出，属性系统需要具备粒度控制、治理机制，以及属性的缩减、分组和最小化机制。

因此，未来的国际驾驶许可证不应追问：这位核验方能否读取驾照？而应追问：这位核验方可以接收哪些声明、用于何种预期用途、在何种环境下、适用何种数据留存规则？

核验方须在请求任何信息之前先证明自身身份

未来的国际驾驶许可证不应以钱包主动展示数据为起点，而应以核验方证明其身份为起点。

欧盟数字身份（EUDI）架构对此有明确规定。依赖方必须：

• 登记其拟请求的属性及对应用途
• 获取访问证书
• 在任何信息披露前向钱包完成身份认证
• 在登记信息可查的情况下，须与其已登记的权限范围进行核对

用户随后可查看是谁在提出请求、请求的内容是什么，以及该请求是否在已登记的权限范围之内。

欧洲电信标准协会（ETSI）当前关于钱包依赖方证书的规范使这一机制更加具体。钱包依赖方登记证书可描述依赖方的预期用途及其已登记的可请求属性。相关访问证书的存在，是为了确保请求来自合法且经授权的一方。ETSI还纳入了依赖方元数据，例如：

• 商业名称
• 支持服务URI
• 预期用途
• 授权权限
• 登记URI
• 监管机构信息

未来国际驾驶许可证的第二项原则：核验方身份未经确认，不得进行任何信息披露。

为何同意确认界面还远远不够

这里还存在另一个错误：将用户批准与法律合规性混为一谈。

EUDI架构明确指出，用户同意提交属性，不得被视为依赖方处理个人数据的合法依据。依赖方仍须具备其自身的合法处理基础。EUDI还要求在所有使用场景中均需取得用户同意，包括依赖方为执法机构或其他政府部门的情形。

良好的钱包界面可以提供辅助，但仅凭界面本身无法解决核验方越权的问题。规则必须先于界面而存在。

因此，未来的国际驾驶许可证需要同时具备：

• 密码学核验方身份认证，以确认请求方的身份
• 策略约束，限定该类核验方可请求的信息范围

若两者缺一，”用户自主选择”便会沦为将政策失职转嫁给个人的借口。

一、警察：核验驾驶权利，而非全面审查个人身份

警察路边核查是所有场景中目的最为明确的一种。

欧盟mDL操作手册对此有直接描述：警察或其他官员在依法要求时核查驾照，内容包括驾照有效性和车辆驾驶资格。在用户流程中，警官通过二维码触发流程、蓝牙、Wi-Fi感知或NFC完成核验。这是一项目的明确的核验任务：

• 此人是否为证件持有人？
• 凭证是否有效？
• 适用哪些车辆驾驶资格和限制条件？

默认允许披露：

• 姓名
• 照片
• 驾照状态
• 签发日期和有效期
• 驾驶车型类别
• 与驾驶相关的限制条件
• 签发机构和管辖地
• 凭证时效/状态结果

默认不允许披露：

• 家庭住址
• 路边执法无需使用的内部标识符
• 来自其他证明文件的无关属性
• 历史出示记录
• 商业元数据

美国机动车辆管理人员协会（AAMVA）的实施指南进一步强调了照片的重要性：若照片被请求，且其他任何信息字段被同时披露，则应一并共享照片，以便核验方将数据与出示证件的当事人相对应。同一指南还规定，相关各方不得追踪mDL持有人或mDL使用情况，法律另有要求者除外。

警察核查的本质，并非国家机关获取一切信息，而是获取路边执法所需的驾驶相关数据。这一区别至关重要。

二、租车柜台：资格核验、身份匹配，不收集多余信息

租车场景更为复杂，因为实际上涉及两个时间节点：到达前的远程预审，以及交车时的当面核验。

欧盟mDL操作手册已对两种情形均有建模。租车公司可在预订时请求mDL及身份证明，对证明文件进行验证，并在取车时当面核验客户身份，确认无误后再交付车辆。用户可当面或远程提前向租车公司共享其mDL。

租车柜台的核心需求并非调查事故，而是作出判断：我能否依据此预订和相关政策，将车辆出租给该客户？

远程预审应包含：

• 身份关联信息
• 照片或等效的身份绑定要素
• 相关车辆类别
• 签发日期和有效期
• 当前有效性
• 可能包括年龄门槛或年龄区间

取车时应确认：

• 持有人与完成预审的为同一人
• 当前有效性
• 相关驾驶资格

默认不需要：

• 当预订档案中已包含联系方式时，无需完整家庭住址
• 当”年龄超过某值”或年龄区间已足够时，无需完整出生日期
• 无关的身份属性
• 在预订证明已存在的情况下，无需重复出示完整凭证

NIST当前的mDL架构展示了依赖方使用DCQL仅请求所需属性的方式，并明确指出，通过结构化请求而非将凭证视为单一整体，可支持数据最小化原则和持有人同意机制。AAMVA补充指出，应用程序应清晰告知用户被请求的数据内容，以及核验方是否有意留存相关信息。

三、雇主：一类核验方，而非打开完整身份信息的入口

W3C概述中以雇主数字系统核查大学学历为例，说明雇主核验是凭证生态系统中已被认可的应用模式。

雇主或车队运营方可能具有合理的知情需求，包括：

• 员工当前是否具备特定车辆类别的驾驶资格
• 是否存在关键限制条件
• 相关资格是否仍在有效期内

这是真实存在的业务需求。但这并不自动赋予其永久访问完整驾驶凭证、完整身份数据或持续反复出示记录的权利。

NIST警告指出，频繁传输可复用标识符、并让用户习惯于反复出示含有身份信息的凭证，是不可取的做法；日常身份认证应依赖专为认证设计的技术，例如通行密钥（Passkeys）。NIST倾向于本地设备认证而非服务器端生物特征比对，因为前者能更好地保护隐私。

未来的国际驾驶许可证不应沦为职场门禁卡。

对于雇主和车队使用场景，正确的做法通常是：

• 进行与岗位相关的驾驶资格核查
• 或许进行定期合规证明
• 或许声明持有人在特定车辆类别上的资格仍然有效
• 但不应默认在每次员工登录系统或开始班次时，均传输全部驾照数据

车队合规是独立的依赖方类别，具有独立的预期用途，以及独立的信息披露档案。

四、保险公司：理赔不等于持续查阅的许可

保险场景往往是真实存在的。在欧盟mDL使用案例资料中，保险公司间接出现于租车场景：保险公司要求租车公司核查租车人是否具备驾驶资格。保险行业已在影响驾驶核验流程。

但这并不意味着保险公司应获取与警察相同的数据，或获得永久访问凭证的权利。

未来的国际驾驶许可证应将保险公司作为独立的核验方类别，并区分各自的预期用途：

• 核保
• 租车风险核验
• 事故后理赔处理
• 欺诈审查

上述用途并非同一目的。依据欧盟数据保护原则，个人数据须为特定目的而收集，且须限于该目的所必要和相称的范围。W3C的VC指南在技术层面得出相同结论：核验方应仅请求严格必要的信息。

合法的、基于特定事件的披露示例：

• 证明驾照在相关时刻处于有效状态
• 证明具备相关车辆驾驶资格
• 在理赔所需时提供身份关联证明
• 针对特定理赔事项的专项披露

默认不允许：

• 对底层凭证的持续访问
• 每次客户与保险公司互动时均进行重复的通用核验
• 将驾驶凭证用作登录令牌
• 收集无关属性

驾驶凭证不是监控订阅服务，也不应悄然演变为这种工具。

为何中间方必须保持可见

现实市场中存在大量中间方。租车平台、车队供应商、企业人力资源系统和保险理赔处理商，往往通过第三方开展业务。

EUDI架构通过以下方式处理这一问题：

• 将中间方视为依赖方
• 要求中间方进行登记注册
• 要求为最终依赖方所请求的属性同样须完成登记
• 向用户同时显示中间方和最终依赖方的信息
• 禁止中间方存储有关交易内容的数据

未来的国际驾驶许可证绝不应出现这种情形：用户以为自己在向租车公司披露信息，实际上却在向一条不可见的核验经纪商、数据分析处理商和理赔供应商链条披露数据。

ETSI在这方面提供了有力支撑。其钱包依赖方证书模型包含支持服务URI、预期用途、登记URI和监管机构元数据。这正是用户理解请求另一端究竟是谁、以及在需要删除或纠错时应向何处求助所需的机器可读基础设施。

数据留存是访问控制的组成部分

大多数关于选择性披露的讨论结束得过早。它们聚焦于披露了什么，却对披露之后数据将保留多久关注不足。

当前的指导原则已逐渐趋于一致：

• AAMVA：钱包必须清晰告知持有人被请求的数据内容，以及核验方是否有意留存该信息；相关各方不得追踪持有人或mDL使用情况，法律另有要求者除外
• W3C：持有人软件应提供与核验方共享信息的日志，以便识别过度请求行为
• EUDI：用户应能访问交易日志、举报可疑请求，并申请数据删除

留存类别应作为信息披露策略本身的组成部分：

• 警察路边核查：默认不留存，仅保留依法要求的执法记录
• 租车预审：交易记录与预订挂钩，而非可复用的身份副本
• 雇主车队合规：保留合规记录或证明结果，而非原始凭证数据
• 保险理赔：理赔记录仅限于该理赔事项，而非永久访问权

一个忽视数据留存问题的未来国际驾驶许可证，只能算是部分意义上的隐私保护。

钱包实际上应该作出什么决策

如果要将本文压缩为一条实施规则，那就是：

钱包不应回答“我能出示这份凭证吗？”它应该回答的是：“我能否向这位已完成身份认证的核验方、为此预期用途、在此情境下、按此留存类别，出示这组声明？”

这一决策至少应基于以下输入要素：

• 核验方身份
• 核验方类别
• 预期用途
• 已登记的属性权限范围
• 签发方的信息披露策略（如有）
• 所处环境（路边执法、取车、远程、车队、理赔）
• 持有人同意
• 适用的留存策略

相关标准已为此提供了大量技术支撑：选择性披露、依赖方身份认证、已登记的预期用途、访问证书、信息披露策略评估，以及目的绑定请求。目前仍欠缺的，是将这些要素视为一套完整信息披露架构加以统筹运用的严谨态度。

核心论点

未来的国际驾驶许可证不应追问数据能否被披露，而应追问：

• 谁在提出请求？
• 出于何种目的？
• 依据何种权限？
• 在何种情境下？
• 将产生何种留存后果？

警察、租车柜台、雇主和保险公司，并非请求另一端的四个商标。他们代表着四种不同的风险模型、四种不同的法律情境、四种不同的请求理由——因此应当产生四套不同的信息披露方案。

这并非多余的复杂性，而是一份现代驾驶凭证在不再将每位核验方一视同仁之后，本应呈现的面貌。