欧盟数字身份钱包要“验证用户”：该用 PID、EAA 还是 QEAA？
在评估钱包项目之前，按声明内容、签发方、资质状态和依赖方证据，区分个人身份数据、普通电子属性证明与合格电子属性证明。
重点监测信号
- 依赖方能说清一笔交易究竟需要哪个身份事实或属性
- 请求区分了 PID 提供方、普通属性证明提供方与合格信任服务提供方
- 团队能说明验证器要检查的凭证状态、签发方与披露声明
“验证用户”不是一份可执行的凭证需求。一笔交易需要确认“这个人是谁”时，才指向个人身份数据（PID）；需要验证年龄、学历或权利等具体属性时，才指向电子属性证明（EAA）；只有依赖方说清属性、可接受的签发方，以及为什么必须使用合格资质后，才需要讨论合格电子属性证明（QEAA）。
这项区别直接影响数字身份平台合作伙伴经理的判断。他通常查看已获授权的银行、旅游、教育、年龄验证和信任服务 Telegram 群。值得跟进的商业 Signal 不是“我们要接欧盟钱包”，而是某个依赖方已经说出一个明确声明、签发路径和测试日期。晚一天看到，可能就会错过合作伙伴选型会议，而买方仍把三种不同的凭证对象当成一次通用身份核验。
一条示意性的残缺消息可能是：
“学生租房要接 EU wallet。想拿姓名、满 18 岁和在读状态。合作方说是不是都得 qualified？”
这是复合场景，不是真实客户、对话或项目结果。法律上的依赖方、成员国、用户范围、签发方、可接受钱包、准确属性、最小披露规则、合格资质要求、验证器、测试环境和生产规则都还未知。
先问三件事，不要先解释三个缩写
条例 (EU) 2024/1183 修订了 eIDAS（欧盟电子身份与信任服务）框架，并明确区分个人身份数据和电子属性证明。《架构与参考框架》进一步说明这些凭证如何在钱包中签发和出示。
面对上面的学生租房场景，先拆成三个问题：
- 租房账户是否需要确定申请人的身份？
- 是否只需要验证“已满 18 岁”，而不收集完整出生日期？
- 是否需要确认当前在读状态，哪些学校或签发机构可以被接受？
第一个问题可能需要 PID；第二、第三个问题属于属性证明。任何一个答案都不能自动推出“必须合格”。是否需要 QEAA，要看适用规则或依赖方政策是否明确要求合格签发方，以及对方准备接受哪类合格服务。
PID 回答“正在出示凭证的人是谁”
法规把个人身份数据定义为依照欧盟法或成员国法律签发、能够确定身份的一组数据。因此，PID 不是普通用户资料，也不是把平台掌握的所有字段一次性交给依赖方。它是在框架下由相应 PID 提供方签发的身份对象。
做项目发现时，要记录依赖方究竟请求哪些身份字段、PID 提供方是谁、适用哪个成员国或签发环境、使用哪一个钱包测试环境，以及取数目的是什么。如果业务只需要把用户稳定地匹配到一个账户，就不能顺手加上住址、出生日期和国籍。每增加一个字段，都改变了用户披露的数据范围。
PID 验证成功，可以支持“本次披露的身份数据来自预期凭证和验证路径”。它不能证明这个人仍在读、持有驾照、具备职业资格、信用良好，或后来在资料页中自行填写的内容也真实。
EAA 回答“哪个签发方证明了这个属性”
电子属性证明是用电子形式验证属性的凭证。属性可以是“已满 18 岁”这样的判断，也可以是学历、执照、组织角色或某项权利。真正有用的分析单位是依赖方要的那个声明，不是买方随口使用的证件名称。
每个 EAA 请求都应写清：
- 属性或判断，例如
age_over_18 = true； - 谁为该属性背书，依赖方接受哪一类签发方；
- 需要检查什么有效期和状态信息；
- 用户最少要披露哪些数据；
- 验证成功后，依赖方准备执行哪个动作。
年龄门槛和在读状态可以是两份属性证明，即使用户在同一次钱包交互中出示。学校可以成为在读状态的适当来源，却不因此成为法定身份数据的来源。反过来，PID 提供方能确认身份，也不等于它自动签发用户的每一种属性。
QEAA 改变的是签发资质和合格要求，不是声明范围
合格电子属性证明由合格信任服务提供商签发，并满足 eIDAS 框架对合格证明的要求。“合格”是一种有明确定义的资质状态，不等于“更准确”“政府签发”或“优先级更高”。
合作伙伴经理真正需要比较的是：
| 凭证对象 | 能支持什么 | 要问哪个签发问题 | 不能证明什么 |
|---|---|---|---|
| PID | 根据披露的个人身份数据确定身份 | 哪个受认可的 PID 提供方按适用框架签发？ | 不能验证无关的资格或权利 |
| EAA | 验证证明中包含的属性或判断 | 哪个属性证明提供方签发，依赖方是否接受？ | 不能说明凭证以外的其他属性 |
| QEAA | 在合格提供商和合格证明要求下验证其中的属性 | 签发方是否具备该服务的合格资质，业务为何必须使用合格状态？ | 不能因为“合格”就变成完整身份或资格判断 |
如果采购说明写着“所有凭证都必须 qualified”，应追问哪条交易规则要求这个状态，以及依赖方如何识别可接受的合格提供商。普通 EAA 不是因为“不合格”就等于“未经验证”；它仍有自己的签发方、技术验证和依赖方接受规则。
一次出示可以带多个声明，但不能把声明混成一个
实施条例 (EU) 2024/2977 规定了欧盟数字身份钱包处理 PID 与 EAA 时使用的协议和接口规则。技术实现很重要，但成功出示之后仍要逐项阅读声明。
回到学生租房消息：依赖方可以用 PID 建立账户身份，用“已满 18 岁”证明执行年龄规则，再用在读证明决定是否适用学生方案。验证记录必须保留每个声明来自哪份凭证、由谁签发、状态检查结果、用户披露了什么，以及检查时间。租房系统再按自身规则作出决定。
保存这些证据后，三种错误推断就很容易被发现：
- PID 有效，不代表用户目前仍是在读学生；
- 在读 EAA 有效，不代表它能够确定所有法定身份字段；
- 某一属性的 QEAA 有效，不代表其他租房资格也成立。
EUDI Wallet 依赖方信任链 解释钱包提供方、签发方、钱包单元、验证器和依赖方如何连接。当问题是“不知道哪个角色负责”时，先看那篇文章。本篇只回答更窄的问题：这条信任链上究竟要传哪一种声明对象。
声明对象说清楚后，合作机会才可评估
在接受转介或估算集成前，每个声明至少应形成一行记录：
[依赖方]为了[交易]，向[可接受签发方或签发方类型]请求[PID 字段／属性／判断]；因为[规则或政策]，其资质要求是[普通／合格／尚未确定]，并由[验证负责人]在[日期]测试。
成员国是否已经提供目标凭证、生产签发方是否参与、最终法律解释是什么，如果没有证据就继续标为未知。参考钱包演示只能证明一条测试路径，不能证明每个目标用户都有该凭证，也不能证明每个依赖方都会接受。
同一个银行项目若还混淆应用程序编程接口（API）授权标准，可以参考 FAPI 2.0 与 OAuth 安全配置的区别。API 安全配置不会替依赖方决定钱包声明属于 PID、EAA 还是 QEAA。
TOP Prospect 可以把用户主动连接且有权查看的 Telegram 群中残缺的凭证、签发方和测试日期消息合并，保留原文与来源，再将候选机会排给合作伙伴经理复核。它不能读取私聊、签发或认证凭证、注册依赖方、作出法律解释、联系发言者或批准用户。具体能力边界见产品方案页，这里只用于机会发现。
最后的区别并不复杂：PID 用于确定身份，EAA 用于验证明确属性，QEAA 在属性证明上增加合格提供商与合格证明要求。无论使用哪一种，依赖方仍要说清自己要哪个声明，以及准备据此作出什么决定。
常见问题
EUDI Wallet 中的 PID 是什么？
它是按适用的欧盟或成员国框架签发、用于确定身份的个人身份数据，不是收集用户全部属性的一份万能资料。
EAA 是什么？
它是用于验证明确属性或判断的电子证明，例如年龄门槛、学历或某项权利。
QEAA 为什么不同？
QEAA 由合格信任服务提供商签发，并满足框架的合格要求；但它仍然只能证明自身包含的属性。
有效凭证能否证明其中没有的事实？
不能。验证只支持本次凭证的签发方、状态和披露声明。其他属性和最终业务决定需要另外的证据与规则。
常见问题
EUDI Wallet 框架中的个人身份数据是什么？
个人身份数据（PID）是依照欧盟法或成员国法律签发、能够确定自然人或法人身份，或者确定代表另一人的自然人身份的数据。
什么是电子属性证明？
电子属性证明（EAA）是能够验证某个属性的电子证明。这个属性可以是年龄、资格、权利或其他明确陈述的特征。
QEAA 与普通 EAA 的区别是什么？
合格电子属性证明（QEAA）由合格信任服务提供商签发，并满足修订后 eIDAS 框架中的合格要求。合格资质不会把凭证的证明范围扩大到其未包含的属性。
依赖方能否从有效凭证推断未披露的事实？
不能。验证结果只支持本次出示涉及的凭证、签发方、状态和披露声明，不能证明另一个属性、之后发生的事件或完整的业务资格。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
