欧盟于 2024 年 5 月正式生效的 eIDAS 2.0 修订条例，正在德国进入实质落地阶段。这项被称作 “欧盟数字身份基础设施” 的重大改革，引入了欧洲数字身份钱包（EUDI Wallet）概念，旨在实现成员国之间电子身份与信任服务的互操作性。然而，随着德国联邦政府推进 eIDAS 合规改造，关于平台绑定与隐私风险的讨论正变得愈发激烈。技术观察者指出，虽然欧盟官方声称 EUDI Wallet 将赋予公民对个人数据的完整控制权，但现实中的技术实现路径正在形成新的依赖关系 —— 这一次，绑定的对象从传统浏览器变成了移动设备厂商。

eIDAS 2.0 的核心架构与德国定位

eIDAS（电子身份识别与信任服务）条例最初于 2014 年制定，核心目标是建立欧盟境内电子识别与电子签名的统一法律框架。2024 年完成的第二次修订（eIDAS 2.0）新增了欧洲数字身份钱包这一核心组件，将此前仅限于政府签发身份证明的适用范围扩展到更广泛的私营服务场景。根据德国联邦内政部的规划，德国将在 2026 年完成与 EUDI Wallet 的技术对接，届时德国公民将能够使用集成了 eID 功能的身份证件通过标准化接口完成跨境认证。

从技术架构来看，eIDAS 2.0 采用了分层设计：底层是由成员国运营的国家身份基础设施，中层是欧盟层面的互操作框架，顶层则是面向终端用户的 Wallet 应用。德国现有的 AusweisApp2 身份验证应用已经实现了与新版 eIDAS 规范的兼容性测试，新一代的 Wallet 实现将在此基础上增加属性选择性披露功能 —— 这意味着用户不再需要暴露完整的身份信息，而可以根据服务提供方的具体需求只提交必要的属性，例如仅证明年龄已满 18 岁而不透露具体出生日期。

德国联邦信息安全办公室（BSI）在技术规范中强调了高安全等级（high assurance level）的要求，这与欧盟对敏感身份数据处理的监管立场一致。然而，正是在这一高安全等级的技术实现层面，平台绑定的争议开始浮现。

平台绑定的技术本质：安全飞地与硬件根信任

理解平台绑定争议，需要理解现代移动设备中安全验证的技术实现逻辑。当前智能手机普遍配备了所谓的 “安全飞地”（Secure Enclave）或 “可信执行环境”（TEE），这些硬件级别的安全组件能够在设备本地处理敏感的身份验证数据，而无需将私钥暴露给操作系统或应用层。Apple 的 Secure Enclave 自 2013 年起集成于所有 iOS 设备，Google 则在 Pixel 系列设备中推广 Titan M 安全芯片，而第三方 Android 设备则普遍依赖基于 ARM TrustZone 的 TEE 实现。

问题在于，eIDAS 2.0 中定义的高等级身份验证流程，其安全依赖于这些硬件级别的密钥保护机制。当欧盟的数字身份钱包需要在设备端存储和运算身份凭证时，不可避免地要利用设备提供的安全飞地功能。从技术角度来看，这意味着如果用户持有的移动设备不包含符合安全等级要求的安全组件，或者这些组件的访问权限被厂商所垄断，那么该用户将无法完整使用 EUDI Wallet 的全部功能。

这种绑定并非欧盟立法的明文要求，但技术实现的现实路径天然倾向于与主流移动平台深度整合。德国数字行业协会（Bitkom）在其立场文件中承认了这一技术现实，指出 “Wallet 解决方案的可获得性与移动操作系统的生态紧密相关”。更为关键的是，当 Apple 和 Google 控制着设备安全能力的访问接口时，第三方 Wallet 实现面临着严峻的互操作挑战 —— 如果在 iOS 上必须使用 Apple Wallet 而在 Android 上必须使用 Google Wallet，那么所谓的 “欧洲数字身份” 实际上将碎裂为两个受制于厂商策略的子集。

隐私风险的核心：数据最小化的技术障碍

eIDAS 2.0 在立法层面确立了数据最小化原则，明确要求 Wallet 实现必须支持 “选择性披露”（selective disclosure）—— 即用户能够只向验证方提供完成任务所必需的最少信息，而非完整的身份副本。这一设计理念源于对传统集中式身份系统弊端的反思：在现有的许多在线身份验证场景中，用户往往被迫提交远多于实际需要的个人数据，例如在注册简单账户时被要求提供完整的实名信息。

然而，EUDI Wallet 的选择性披露功能在技术上依赖于属性基加密（Attribute-Based Encryption）或零知识证明（Zero-Knowledge Proof）等密码学原语。这些技术的成熟度与部署成本仍在演进中，而主流移动平台的 Wallet 实现可能采用更为简化的方案 —— 例如仅在应用层实施访问控制，而非在密码学层面确保数据不可关联。欧洲数字权利组织（EDRi）在其政策分析中警告称，如果 Wallet 架构未能从根本上解决属性泄露问题，那么所谓的 “数据最小化” 将沦为表面文章，实际运作中仍将形成可被追踪的持久标识符。

更深层的隐私忧虑来自于跨服务数据关联的可能性。EUDI Wallet 设计用于在多个服务场景中复用同一数字身份，这本身就创造了将用户在不同服务中的行为进行关联的技术条件。即便每一次身份验证都采用了不同的属性子集，如果验证方能够访问统一的凭证颁发记录，仍然可能通过多次验证的交叉比对构建出完整的用户画像。德国联邦数据保护专员（BfDI）在 2025 年发布的意见书中特别强调了这一点，要求 Wallet 架构必须具备 “不可链接性”（unlinkability）的密码学保证，而不仅仅是访问控制层面的隔离。

争议的实质：数字主权与技术控制的博弈

围绕 eIDAS 2.0 平台绑定的争论，本质上反映了欧盟数字主权目标与现实技术生态之间的结构性张力。欧盟委员会在 eIDAS 2.0 的立法说明中明确提出，要建立 “不依赖非欧洲技术供应商” 的自主数字身份体系，但实际操作中，大多数欧盟公民日常使用的智能终端均来自 Apple 或 Google—— 这两家公司合计占据欧洲智能手机市场超过 70% 的份额。

这种依赖关系在技术层面表现为多层控制：硬件层面由芯片厂商决定安全组件的设计规格，操作系统层面由 Apple 和 Google 控制 API 的开放范围，应用分发层面则受制于 App Store 和 Google Play 的审核政策。虽然欧盟近年来通过《数字市场法案》（DMA）等工具试图打破平台垄断，但涉及设备安全的底层技术接口仍然受到厂商的严格把控。

德国，作为欧盟最大的经济体和数字化转型的重要推动者，其对 eIDAS 2.0 的落地策略将在很大程度上定义整个欧盟数字身份生态的未来走向。德国联邦政府选择了相对审慎的推进路径，强调在实现 eIDAS 合规的同时 “确保数据主权与用户自决”。然而，技术观察者指出，如果没有明确的监管要求强制移动平台开放安全飞地的互操作接口，那么德国公民的数字身份将不可避免地与特定设备厂商形成事实上的绑定关系。

参数清单：评估 Wallet 安全与隐私的实操维度

对于计划部署或使用 EUDI Wallet 的企业与个人而言，以下参数维度可用于评估具体实现的安全与隐私水平。首先是安全飞地的认证等级 ——Wallet 应当使用通过 Common Criteria 或 FIPS 140-2 Level 3 以上认证的安全组件，确保密钥运算在硬件级别得到保护。其次是选择性披露的密码学实现 —— 真正的不泄露属性验证应基于零知识证明或属性基加密，而非简单的数据遮蔽。第三是凭证的不可链接性 —— 每次身份验证应生成独立的验证标识符，防止验证方将不同服务的验证记录进行关联。第四是审计与撤回机制 —— 用户应当能够查看凭证的所有使用记录并在发现异常时远程撤回授权。最后是平台互操作能力 ——Wallet 实现应支持跨操作系统使用，避免用户因更换设备而丢失身份凭证或被迫重新注册。

这些维度不仅是技术选型的参考，也应当成为监管机构审查 Wallet 合规性的具体标准。当前德国 BSI 正就 Wallet 技术规范征求意见，业界普遍呼吁将上述隐私保护要求纳入强制认证的考核范围。

结语

eIDAS 2.0 在德国推进的过程中，平台绑定与隐私风险并非可以简单回避的技术细节，而是关涉数字身份主权的核心议题。当立法者雄心勃勃地规划欧洲数字统一市场时，技术现实却在提醒他们：没有自主可控的硬件安全基础，就难以实现真正的数据自主。未来的博弈将在监管力度与技术开放程度之间展开，而这场较量的结果将决定欧洲公民的数字身份究竟掌握在自己手中，还是继续被锁死在设备厂商的生态围墙之内。

资料来源：德国联邦身份证门户网站（personalausweisportal.de）关于 eIDAS 条例对德国身份证影响的官方说明；Epicenter.works 关于 eIDAS 2.0 隐私风险的公民社会分析报告。