欧盟数字身份钱包：2026 和 2027 对做工程的人意味着什么

到 2026 年 12 月 24 日，每个欧盟成员国必须向其公民提供至少一个欧盟数字身份钱包。从 2027 年 12 月起，一大批私营服务提供者将被强制接受它。

这是第 (EU) 2024/1183 号条例的简短概括，通常称为 eIDAS 2。它是少数几部创造基础设施而不是设置限制的欧盟数字法案之一，也因此比大多数更有意思。

钱包是什么

EUDI 钱包是由成员国签发或认可的应用，用于保存个人的电子身份数据和电子证明，并允许其选择性出示。

三个特性让它区别于以往的国家电子身份体系。

跨境互认是强制的。 在一个成员国签发的钱包必须在其他所有成员国被承认。这正是旧 eIDAS 体系的薄弱环节。

选择性出示是核心能力。 用户可以证明自己年满 18 岁而不透露出生日期，或证明居住国而不透露住址。这在隐私上是重大差别，也是最能改变集成方产品设计的那个特性。

证明的范围远不止身份。 钱包可以保存电子属性证明：驾照、学位、职业资格、公司授权、医保凭证、年龄，以及随时间增加的更多内容。

时间线

• 2024 年 5 月 20 日：条例生效。
• 2024 和 2025 年：关于技术规范、认证和依赖方注册的实施法案。
• 2026 年 12 月 24 日：成员国必须提供至少一个钱包。
• 2027 年 12 月 24 日：强制依赖方必须接受钱包。

对于认证层已经生长了十年的大型组织来说，两年是很短的时间。

谁必须接受

强制依赖方包括：

• 需要用户认证以提供电子服务的公共部门机构。
• 依法需要强用户认证的私营服务提供者，包括银行和金融服务。
• 数字服务法下的超大型在线平台。
• 需要强认证的行业服务提供者，包括交通、能源、医疗、社会保障和电信。

如果你在这些行业里，2027 年 12 月是硬期限，而工作不是从那天开始。

如果不在，你仍然可以自愿接受钱包，而且有些情形单从用户体验角度就已经值得。

为什么自愿接受值得关注

三个钱包能解决真实问题的用例。

不需要身份证照片的年龄验证。 如果你销售酒类、烟草制品、成人内容或有年龄限制的内容，你现在的方案很可能要么是自我声明，要么是一个要求上传身份证照片的第三方服务。选择性出示给你一个经密码学验证的"年满 18 岁"，而你不需要收集或保存任何东西。

这不只是更方便。它显著缩小了你的 GDPR 暴露面，因为你不再处理身份证件。

免填表的开户。 在金融服务、保险和受监管的开户流程里，认识你的客户这一步很慢，也是用户流失的地方。来自钱包的已验证身份会填好字段，并自带一份保证。

职业资格核验。 对连接专业人士与客户的平台，一份经验证的资格证明消掉了人工核验步骤和伪造风险。

集成怎么运作

如果你实现过 OpenID Connect，这个模型会很熟悉，但它并不相同。

你注册成为依赖方。 这是在某个成员国的正式步骤。你声明自己是谁、打算请求哪些属性、用于什么目的。注册是公开的，它是透明度模型的一部分。

你请求的是属性，不是身份。 你的请求指明需要哪些证明。从设计角度看，关键是请求最小集合。你的注册限定了你能请求什么，而用户会看到这个请求。

用户在自己的钱包里批准。 交互发生在钱包应用里，不在你的界面里。你拿到的是响应。

你验证出示内容。 响应是经密码学签名的，你要验证签名和签发方的信任链。真正的技术工作在这里，而大多数团队在这里会用库而不是自己直接实现。

技术上，规范依托 W3C 可验证凭证、面向手机驾照的 ISO mDL 标准，以及 OpenID for Verifiable Presentations 协议。参考实现是可用的，大规模试点已经在实践中检验过这些。

现在该规划什么

如果 2027 年 12 月与你有关，第一件工作不是钱包集成。是你的认证层。

把认证和身份验证分开。 在多数系统里这两者是混在一起的。用户账户、密码和已验证的身份是三件不同的事，钱包关心的是第三件。如果它们纠缠在一起，任何改动都很危险。

让身份数据带来源信息。 你必须知道哪些字段是用户自述的、哪些是已验证的，以及来自哪个来源。这是字段级的元数据，事后补上很痛苦。

为选择性出示做设计。 如果你的产品需要出生日期只是为了检查年龄，就不要存出生日期。钱包的价值在于你能拿到一个问题的答案而不拿到背后的数据，系统必须知道怎么保存那个答案。

构建带有效期的证明存储。 证明会过期，也可能被撤销。已验证的属性不是永久真理。你需要复检逻辑，以及证明被撤销时该怎么办的决定。

规划回退路径。 不是每个人在 2027 年都会有钱包，2030 年也不会。钱包是新增的一条路径，不是替代，产品必须在没有它的情况下也能运转。

隐私这一面

条例内建了对实现有影响的保护措施。

钱包提供者不得收集用户交易的信息，除非这对钱包运行是必要的。依赖方请求的属性不得多于其声明目的所需。用户必须能看到并控制被分享了什么。

实践中这意味着多要不只是坏习惯，而是与注册相抵触。你的注册描述必须与你实际请求的内容一致。

这直接对接到常规的 GDPR 工作，尤其是数据最小化这条原则，而多数系统在这上面做得不好，因为过去多收集是没有代价的。

与支付的联系

EUDI 钱包和支付领域的变化以有趣的方式相遇。

银行是强制依赖方。钱包可以保存与支付相关的授权。强客户认证是钱包式认证最终有可能简化现有实现的领域。

与此同时，基于转账的结账方式如 Wero 正在扩散，而收款人验证已经把姓名核验带进了每一笔转账。方向是走向身份在基础设施层被验证的支付，而不是从"持有卡片"这件事推断出来。

关于时机的诚实评估

有两点值得直说。

第一，用户端的钱包采用率是不确定的。成员国会交付钱包，但人们用不用取决于里面有没有有用的东西。以往各国的电子身份体系成功程度差异极大，在爱沙尼亚几乎普及，在很多其他国家则很边缘。

第二，生态是不均衡的。有些成员国走得很远，有些没有。跨境互认在技术上可行，但在实践中需要检验。

由此该得出的结论是：如果你是强制方，就把工作做了，但不要假设钱包会很快成为主要认证方式。如果你不是强制方，年龄验证这个用例是提前尝试的最好理由，因为收益立竿见影，而且与整体采用率无关。

从哪里开始

弄清你是不是强制方。 行业清单很宽，包含了一些不认为自己受监管的公司。

盘点你的认证层。 身份在哪里被验证、在哪里被假定，以及你保存了哪些字段、为什么保存。

选一个用例。 不要试图到处集成钱包。挑一个它能解决真实问题的流程，把它做好。

跟进实施法案和参考实现。 技术细节仍在稳定过程中，用自制方案的早期实现会过时。

我们在哪里帮忙

我们为在欧洲经营的公司构建认证和身份系统，包括在一个多年来长在一起的系统里把认证与身份验证拆开这种苦活。

如果 2027 年 12 月与你有关，或者年龄验证这个用例让你更早感兴趣，写信到 office@c9group.dev。更多关于我们工作的内容见欧盟市场进入页面，完整监管图景见我们的 2026 年欧盟数字合规指南。

我们是工程师，不是律师。你是不是强制依赖方，是你们律师的问题。