零知识证明专题第8期：ZK 身份与数字主权：从 EU eIDAS 到 Google Wallet 的隐私凭证

第1章当护照不再是护照，而只是"已满18"

2025年7月14日，欧洲委员会发布了欧盟全年龄验证系统的技术规范。根据 Digital Services Act 框架，所有提供成人内容的网站在2026年底前必须实施合规年龄验证。同月稍早，Google 正式开源了其 Zero-Knowledge Proof 库 Longfellow，并将它嵌入 Google Wallet——你只需要在手机上打开钱包，点击"生成年龄证明"，然后一个不到2KB的零知识证明就能让平台确信"你已满18岁"，而对方看不到你的姓名、住址、生日，甚至不知道你的证件号码。

这不是科幻。

2025年10月，Discord 遭遇了一次严重的数据泄露：一个第三方年龄验证服务商的漏洞暴露了数十万用户上传的身份证照片。攻击者拿到了用户的姓名、地址、证件号码——不仅是"未成年人"，而是完整的身份档案。这次事件成为了一个关键的转折点：它暴露了传统"上传证件→人工核验"模式的根本缺陷——中间商拥有你的全部数据，而你没有能力控制它被如何使用。

今天，三条平行的技术路线正在以惊人的速度交汇。

欧盟 eIDAS 2.0 法规（Regulation (EU) 2024/1183）强制要求27个成员国在2026年底前向公民提供支持隐私增强技术（PETs）的 EUDI 数字身份钱包。Google 则在商业侧打开了大门，将基于 ECDSA 的匿名凭证方案推向主流消费者——一个拥有数十亿用户的平台第一次提供了真正的零知识身份验证。而在标准层，W3C 的 Verifiable Credentials Data Model 2.0 和 BBS 签名标准正在为"选择性披露"和"不可链接性"提供密码学基础设施。

这个故事的主角不是区块链，也不是加密货币——而是"你能否在不交出整本护照的情况下，证明你需要证明的那一件事"。

这是一个关于密码学与主权博弈的故事。让我们从头说起。

第2章数字身份的三层技术架构：谁持有你的身份？

要理解 ZK 身份的革命性在哪里，首先要回答一个基础问题：在现有的数字身份系统中，谁持有你的数据？谁控制披露？谁验证信任？

2.1 中心化身份（Centralized Identity）

这是最古老的模型。政府、平台、机构持有用户的全量身份数据，用户只是"被标识的对象"。传统的身份证系统、社保账号、以及大多数平台的"上传证件"流程都属于这一类。

数据持有：发证方/平台保存完整数据
控制权：用户无法控制滥用或泄露
隐私风险：数据集中泄露（如 Discrod 2022 泄露事件）
典型代表：传统身份证、护照数据库

2.2 联邦化身份（Federated Identity）

"用 Google 登录"、"用 Apple 登录"——巨头作为身份提供商（IdP）代理用户的认证。用户不再需要为每个服务单独注册，但代价是将身份认证入口暴露给一家或几家科技巨头。

数据持有：IdP 持有核验能力和用户行为数据
控制权：用户可以选择"不用"，但无法阻止 IdP 追踪
隐私风险：跨平台追踪、广告关联
典型代表：OAuth 2.0 / OpenID Connect / Sign in with Apple

2.3 自证主权身份（Self-Sovereign Identity, SSI）

SSI 的核心哲学是：用户持有凭证（Wallet），通过密码学可验证凭证（Verifiable Credentials）自主授权披露。没有一个中心化的"身份数据库"——发证方签发签名的凭证后，不再参与每一次验证。

数据持有：只有用户（钱包端）
控制权：用户决定披露哪些属性，何时披露
隐私增强：最小披露 + ZK 证明
典型代表：W3C DID + VC 标准栈

以下三种范式的对比矩阵可以直观看到差异：

flowchart LR
    subgraph 中心化
        C1[政府/平台持有全量数据]
        C2[用户=被标识对象]
        C3[隐私风险: 数据集中泄露]
    end
    subgraph 联邦化
        F1[巨头为身份提供商 IdP]
        F2[SSO登录 依赖信任第三方]
        F3[隐私风险: 跨平台追踪]
    end
    subgraph 自证主权SSI
        S1[用户持钱包]
        S2[密码学凭证 自主授权]
        S3[隐私增强: 最小披露+ZK]
    end
    C3 --> F3 --> S3
    style C3 fill:#ffebee
    style F3 fill:#fff3e0
    style S3 fill:#e8f5e9

图1：三种数字身份范式对比。从左到右，隐私控制权递增。

SSI 的关键基础设施是 W3C 定义的 DID（Decentralized Identifiers）和 VC（Verifiable Credentials）。DID 不是区块链地址，而是可解析为 DID 文档的 URI——文档中声明了公钥和服务端点。VC 则是一种标准化的数据结构，定义了 Issuer（发证人）、Holder（持有人）、Verifier（验证方）的三方关系。

但 VC 本身并不内置零知识证明。这是当前 SSI 生态最为关键的密码学缺口——也是 Longfellow 和 BBS 签名试图填补的空白。

第3章 EU eIDAS 2.0：监管驱动的隐私革命

2024年5月20日，欧盟正式通过了 eIDAS 2.0 法规（Regulation (EU) 2024/1183），替代了2014年的原始 eIDAS（Regulation (EU) No 910/2014）。如果说原始 eIDAS 的目标是"电子签名互认"，那么 eIDAS 2.0 的目标是用隐私增强技术重构整个数字身份基础设施。

3.1 EUDI Wallet 架构

EUDI Wallet 是由成员国发行的手机应用，存储 PID（个人身份数据）和电子签名证书。根据法规，每个欧盟公民、居民、企业都有权获得至少一个符合 eIDAS 兼容标准的数字钱包。成员国可以自主开发、委托第三方开发，或认可私营部门创建的钱包。

截至2026年7月，各成员国的推进进度极不均衡：

前行者：丹麦、法国、希腊、意大利、西班牙被选为首批技术试点国家
已宣布项目但无公开沙箱：克罗地亚、捷克等十余国已启动钱包项目，但开发者仍无法获取测试环境
现有国家身份 App 确认升级：部分成员国已确认将现有国民身份应用升级至 EUDI 标准
关键 deadline：2026年12月31日前，所有27国必须提供至少一个兼容钱包；大型在线平台随后有一年时间强制接入

3.2 ZKP 集成要求

eIDAS 2.0 并未强制要求 ZKP 本身的使用，但明确鼓励成员国集成隐私增强技术（PETs）用于选择性披露。法规的隐私框架基于以下几个核心原则：

数据最小化（Data Minimization）：钱包应支持用户在验证时仅披露必要的属性
选择性披露（Selective Disclosure）：从驾照中提取"已满18岁"或"居住国为法国"，而不暴露完整驾照数据
不可链接性（Unlinkability）：同一用户在不同服务上出示凭证时，验证方不能将其关联为一个身份

这正是 ZKP 发挥关键作用的地方。通过零知识证明，用户可以将已签名的数字凭证转化为一个"关于事实的证明"，而不是"关于数据的呈现"。

3.3 技术标准：ISO 18013-5 mDL

EUDI Wallet 的底层架构基于 ISO/IEC 18013-5 移动驾照（mDL）标准。这一标准原本是为"手机上呈现驾照"设计的，但它的数据结构（mDOC）恰好适用于更广泛的身份凭证。技术栈的关键要素包括：

存储与通信：基于设备的 Secure Element（SE）存储凭证密钥；传输使用 BLE 和 NFC 进行离线验证
签名标准：使用 ECDSA 和 COSE（CBOR Object Signing and Encryption）进行签名
选择性披露缺口：原始的 mDL 标准不支持 ZK 式的选择性披露。Google 的 Longfellow 方案恰好填补了这个空白——它可以在不修改发证方流程的情况下，为 mDOC 格式的凭证生成 ZK 证明

3.4 隐私争议

2026年6月，成员国就生物特征图像存储达成妥协——允许用户在钱包中选择性退出肖像图片存储，但非强制禁用。这一争议反映了监管路线上的核心张力：国家发行的钱包本质上仍然是"主权背书"的产物，它不完全是去中心化身份的理想形态，而是"主权监管下的自主使用"。

以下时序图展示了 EUDI Wallet 的选择性披露与 ZK 证明流程：

sequenceDiagram
    autonumber
    participant 用户
    participant EU数字钱包
    participant 发证方（政府）
    participant 服务平台
    用户->>发证方（政府）: 身份核验&申领凭证
    注 over 发证方（政府）: 签发带签名可验证凭证
    发证方（政府）->>用户: 凭证存入钱包
    用户->>EU数字钱包: 选择披露属性（如"已满18岁"）
    EU数字钱包->>EU数字钱包: 生成ZK证明
    注 over EU数字钱包: 证明事实但不暴露证件全本
    EU数字钱包->>服务平台: 提交ZK证明
    服务平台->>服务平台: 验证证明&验证签名源
    服务平台->>用户: 授权访问（仅知"成年"）

图2：EUDI Wallet 选择性披露 + ZK 流程时序图。发证方签发凭证后不再参与每次验证——用户自行决定披露哪些属性。

第4章 Google Longfellow：巨头打开 ZK 证据开源大门

如果说 eIDAS 2.0 是来自监管侧的推力，那么 Google Longfellow 就是 2026 年 ZK 身份领域最具影响力的商业化事件。

4.1 密码学基础：Anonymous Credentials from ECDSA

Longfellow 方案基于 Matteo Frigo 和 Abhi Shelat 在 2024 年 ePrint 上发表的论文《Anonymous Credentials from ECDSA》。该论文的核心洞察是：现有的匿名凭证方案（如 BBS+）要求发证方更换签名基础设施，这在现实世界中几乎不可能推行。

回顾已有的密码学方案：

BBS / BBS+：支持选择性披露和不可链接性，但它要求使用配对友好曲线（如 BLS12-381），发证方需要部署新的签名系统
CL 签名：基于 RSA 假设，要求发证方升级支持交互式签发协议
IBS（Identity-Based Signatures）：同样需要发证方接受新的密码学假设

Frigo 和 Shelat 的方案走了一条完全不同的路：不改变发证方的任何流程。它接受现有的 ECDSA 签名（ISO mDOC 标准使用的正是 ECDSA），然后为已签名的数据构建 ZK 论证，证明"某个属性（如出生日期）满足特定条件（如≥18岁）"，而无需暴露该属性的原始值。

关键性能数据：

证明生成时间：在标准手机上，针对 mDOC 标准的 ZK 证明生成时间约 1.2 秒（根据凭证大小有所浮动）
证明大小：约 1.5 KB - 2 KB，可在常规网络连接中传输
通信轮次：非交互式（一次性提交证明）
零密钥基础设施变更：发证方仍然使用其现有的 ECDSA 签名流程和硬件安全模块（HSM）

4.2 开源部署与集成

2026 年 5-6 月，Google 正式开源了其 ZKP 库，嵌入 Google Wallet，并与斯帕克银行（Sparkasse）合作支持欧盟年龄验证。关键里程碑：

代码仓库：github.com/google/longfellow-zk（C++ 实现，Apache 2.0 许可）
并行实现：Internet Security Research Group (ISRG) 正在开发 Rust 语言实现的 zk-cred-longfellow
已部署场景：Google Wallet 用户已可以使用 Longfellow 向特定服务（如 Bumble）证明年龄
独立安全审计进行中：Google 公开声明正在进行两项独立的学术和行业安全审计
IETF 标准化：草案 draft-google-cfrg-libzk 已在 CFRG 讨论

4.3 对比意义：为什么这是分水岭时刻

Longfellow 的意义不在于密码学创新本身，而在于第一次由主流科技巨头将 ZKP 以消费级产品的形式推向亿万用户。

对比 BBS：BBS 提供了更全面的安全属性（完整的三方不可链接性），但要求发证方升级签名方案；Longfellow 向后兼容现有基础设施
对比 EUDI 原生方案：部分 EUDI 原型依赖 SD-JWT（Selective Disclosure JWT），但学术界分析表明 SD-JWT 无法满足 eIDAS 2.0 要求的严格三方不可链接性（见 BBS_SAC2026 论文，Alexopoulos et al. 2026）
关键限制：Google 的仓库明确标注本项目 "currently undergoing two independent security reviews"。Dyne.org 的独立安全分析指出了一些需要考虑的攻击面

4.4 ISRG 的 Rust 实现

IETF 124 会议讨论显示，ISRG 正在并行开发 Rust 实现的 zk-cred-longfellow，目标是为 EUDI 钱包实施者提供一种内存安全语言的参考实现。目前感兴趣的 EUDI 钱包实施方包括 Multipaz 和 wwWallet。

第5章 SSI 与 W3C 标准：去中心化的身份密码学

如果说 eIDAS 提供了"主权叙事"，Google 提供了"商业入口"，那么 W3C 和 SSI 社区提供的则是标准化的互操作底座。

5.1 DID + VC 标准栈

W3C 的 Verifiable Credentials 标准定义了一套完整的数据模型：

Verifiable Credentials（VC）：持有者从发证人处获得的签名凭证
Verifiable Presentations（VP）：持有者向验证方出示的凭证组合
Decentralized Identifiers（DID）：可解析的 URI，声明公钥和服务端点

关键事实：VC 标准本身不强制要求 ZK。一个常规的 VC 验证是"解密/验证签名→读取数据"，不存在"选择性证明"的能力。ZK 凭证的定位是：在不暴露底层凭证原文的情况下，由持有人自主决定披露哪些属性。

5.2 BBS 签名方案

BBS 签名是当前 W3C VC 生态中最受关注的选择性披露密码学方案。

原理：BBS 签名生成一个单一的签名值，该签名验证多个消息。持有人可以只披露其中一部分消息，同时生成一个"证明"向验证方保证所有消息都是同一个被签名的集合中的
不可链接性：每次出示都使用不同的随机数，验证方无法将两次出示关联到同一签名
性能：根据 Alexopoulos 等人 2026 年发表在 SAC 2026 的论文，BBS 在资源受限设备上的性能如下（VB13 变体，C 语言实现）：
- 桌面（Intel i7）：~30 ms 证明生成
- 智能手机（高通骁龙）：~200 ms 证明生成
- 智能手表：~1.5 秒证明生成
标准化状态：W3C 已发布 "Data Integrity BBS Cryptosuites v1.0" 候选推荐草案；IETF CFRG 正在进行 Blind BBS 和 BBS Pseudonyms 的标准化讨论

5.3 AnonCreds v2.0

AnonCreds 是 Linux Foundation Trust over IP (ToIP) 基金会采纳的开源匿名凭证方案。其 v2.0 版本基于 BBS+ 签名，支持选择性披露和不可链接性，是 Hyperledger Indy 生态之外更通用的凭证方案。

5.4 SD-JWT 的局限

当前 EUDI Wallet 原型大量使用 SD-JWT（Selective Disclosure JWT）实现最小披露。SD-JWT 的优势是简单——它基于 JSON Web Token，开发者生态成熟。但 Alexopoulos 等人的研究明确指出：SD-JWT 无法满足 eIDAS 2.0 要求的严格三方不可链接性。这是因为 SD-JWT 中仍然存在一个"凭证唯一标识"（jti 或签名的唯一性），允许恶意验证方追踪同一用户在不同场景下的凭证出示。BBS 方案通过每出示生成一次随机化证明，天然实现了不可链接——这是 ZK 密码学方案在身份场景中的根本优势。

第6章三条路线的交汇与张力

现在我们将三条路线的全景对比放在一起：

graph LR
    subgraph 监管路线
        R1[eIDAS 2.0 法规]
        R2[EUDI 钱包]
        R3[国家发证背书]
        R4[ISO 18013-5 mDL]
    end
    subgraph 巨头路线
        C1[Google Longfellow ZKP]
        C2[Google Wallet]
        C3[开源 ZKP 库]
        C4[ECDSA 匿名凭证]
    end
    subgraph 开源标准社区
        O1[W3C DID+VC]
        O2[BBS 密码签名]
        O3[AnonCreds v2]
        O4[跨平台互操作]
    end
    R4 --> C4
    C3 --> O4
    O1 --> R1
    style R2 fill:#e1f5fe
    style C2 fill:#f3e5f5
    style O1 fill:#e8f5e9

图3：三条技术路线全景对比与交汇。监管路线提供主权背书，巨头路线提供消费级入口，标准社区提供互操作底座。

6.1 Sovereignty 悖论

这是一个难以回避的矛盾：欧盟要求"用户控制数据"，但钱包本身由主权国家发行和背书。它不是完全去中心化的——EUDI Wallet 是"主权的自主使用"，而不是"无主的自主权"。

谁来恢复丢失的私钥？在完全去中心化的 SSI 中，恢复是一个未有理想答案的难题。eIDAS 2.0 的 Wallet 保留了国家的恢复渠道（通过发证方重新签发凭证），但代价是：恢复过程需要用户再次完成 KYC，这为"胁迫攻击"（coercion）留下了空间——攻击者可以强迫用户去国家窗口"重置"钱包来获取历史凭证。
生物特征争议：2026 年 6 月的妥协——允许用户选择不存储肖像，而非强制禁用肖像存储——反映了主权国家在隐私设计上的二元立场。

6.2 商业巨头 vs 开放标准

Google Wallet 的 Longfellow 是 ECDSA 路线；部分 EUDI 钱包选用 SD-JWT 路线；W3C 社区推动 BBS 路线。三者能否互操作？

交叉点：ISO 18013-5 mDL 标准是实际最大的重叠面——EUDI 钱包使用 mDL 格式，Google Wallet 的 Longfellow 优化目标正是 mDOC。Google 的 ECDSA 方案也证明了"对 mDOC 的 ZK 证明生成是可行的"
分歧点：Google 的密码学选择（基于 ECDSA）不与 BBS 签名直接兼容。虽然两者都能实现选择性披露，但 BBS 的不可链接性更强，而 Longfellow 的后向兼容性更好

6.3 ZK 身份 vs 匿名滥用

年龄验证虽然保护了隐私，但也带来了新的安全困境：如果用户可以生成"可证明已成年但不可关联真实身份"的证据，那么：

不良行为者可以更容易绕过基于"账户实名"的内容管制（如防沉迷系统、黑名单）
匿名凭证的"不可链接性"原则上可以用来规避跨平台禁令

这是隐私与安全的经典两难——没有技术方案能直接解决制度层面的伦理选择。目前欧盟的妥协是：钱包中的"年龄证明"需要由发证方签发的凭证生成（即有可信的身份起源），但出示时不可关联到具体凭证——"来源可信，但身份不可识别"。

第7章 2026 实践挑战与未来展望

7.1 密钥丢失恢复

数字身份最大的用户体验问题：用户丢失了手机钱包的密钥，谁来恢复？

eIDAS 2.0 路径：保留国家的恢复渠道——用户重新完成 KYC 后获取新凭证
纯 SSI 路径：社会恢复（Social Recovery）或多密钥碎片方案（如 Shamir Secret Sharing）
混合方案：欧盟正在评估"分片密钥 + 政府备份"的混合方案

7.2 跨链互操作性

DID 方法碎片化严重。目前已有几十种注册 DID 方法，包括基于区块链的（did:ethr、did:sol）和非链的（did:web、did:ion）。不同方法之间的凭证无法相互验证。W3C 目前的工作重点之一是推动 DID 解析器的通用化和 DID 方法的互联。

7.3 量子安全迁移

当前 ZK 身份证明的主流方案（BBS 基于配对的密码学、Longfellow 基于 ECDSA）都面临量子威胁。随着 NIST 后量子标准（ML-DSA / ML-KEM）的逐步落地，ZK 签名方案也需要支持后量子密码学迁移。这是一个替换周期很长的基础设施问题——证书和签名基础设施的轮换需要数年时间。

7.4 用户体验门槛

这是最容易被忽视的问题。用户是否能正确理解"我确实在证明什么，以及没有泄露什么"？

如果用户向验证方出示了"年龄≥18"的 ZK 证明，验证方确实不知道用户的出生日期
但验证方是否能够通过用户的 IP 地址、设备指纹、时间模式推断用户身份？——这是 ZKP 无法覆盖的外部侧信道
如果用户不理解 ZK 保证的范围，可能会在看似安全的流程中意外暴露额外信息

7.5 证明代理与硬件加速

移动设备上的 ZK 证明生成虽然已优化到可接受范围（Longfellow ~1.2秒，BBS ~1.5秒智能手表），但大规模实时场景（如地铁闸机、入场核验）仍然需要更快。行业正在探索以下方向：

证明代理（Proof Proxy）：用户将凭证授权给受信任的云端服务器，替代手机生成证明。这是一种安全-延迟的折中方案——手机端只做简单的授权签名，云端完成计算密集的 ZK 证明生成
硬件加速：Qualcomm 和 Apple 的移动芯片已经内置了密码学加速指令。BBS 的双线性对运算和 Longfellow 的多标量乘（MSM）都能受益于专用硬件优化
NFC 离线验证：ISO 18013-5 mDL 标准已经定义了 NFC 作为离线验证通道。如果 ZK 证明能在 200ms 以内生成，就能做到"碰一下手机就完成年龄验证"——这个性能目标目前仅在高配桌面端可达，移动端仍有 3-5 倍差距
端侧证明委托模式：一种折中的技术路线是"基于可信执行环境（TEE）的端侧证明"——手机中的安全飞地完成凭证存储和证明生成的敏感部分，外部应用只接收验证结果。这种模式在 Apple Secure Enclave 和 Qualcomm SPU 中已有工程实现，能够在不依赖云端的情况下将证明生成时间压缩到 300-500ms 区间。

第8章结语：主权的密码学定义

数字主权不是一个口号。它是一个密码学命题。

只有当你能持有无法被伪造的凭证，在不暴露核心数据的情况下独立向第三方证明事实，并保留对信息披露的完全决定权时，主权才成立。

2024年10月，Frigo 和 Shelat 发表了让现有 ECDSA 签名系统支持匿名凭证的方案。2024年5月20日，eIDAS 2.0 正式生效写入法规。2025年1月，英国在线安全法开始要求平台提供年龄验证。2025年7月，欧盟发布全年龄验证技术规范。同年10月，Discord 数据泄露事件为隐私凭证提供了现实的道德紧迫性。2026年5-6月，Google 开源 Longfellow 并集成到 Google Wallet。2026年7月，SAC 2026 发表了 BBS 方案在智能手表上的性能基准，证明隐私保护凭证在资源受限设备上也是可行的。

这三条路线在 2026 年以出人意料的方式交汇——不是通过某个统一的"全球数字身份标准"，而是通过各自领域的"最小公共交集"（ISO mDL + ZK 选择性披露）达成的实际兼容。

但真正的"全民自主可控的数字身份"，仍有很长的路要走。

参考文献

EU eIDAS 2.0 — Regulation (EU) 2024/1183, entered into force 20 May 2024. Member States must provide EUDI Wallets by December 2026.
Google, "Open-sourcing our Zero-Knowledge Proof libraries for age assurance", Google Innovation & Technology Blog, 2026. https://blog.google/innovation-and-ai/technology/safety-security/opening-up-zero-knowledge-proof-technology-to-promote-privacy-in-age-assurance/
Matteo Frigo & Abhi Shelat, "Anonymous Credentials from ECDSA", Cryptology ePrint Archive, Report 2024/2010, 2024. https://eprint.iacr.org/2024/2010
Google, "Longfellow Zero Knowledge Credentials", IETF 124 Meeting Slides, Dispatch/Secdispatch. https://datatracker.ietf.org/meeting/124/materials/slides-124-dispatch-longfellow-zero-knowledge-credentials-00
Alexopoulos, Chondros, et al., "Measuring the Performance of Candidate Verifiable Credential Schemes for the EU Digital Identity Wallet", SAC 2026. https://www.alexopoulos.ch/files/BBS_SAC2026.pdf
Dyne.org, "The Longfellow ZK (also known as Google-zk)", 2026. https://news.dyne.org/longfellow-zero-knowledge-google-zk
W3C, "Verifiable Credentials Data Model 2.0". https://www.w3.org/TR/vc-data-model-2.0/
W3C, "Decentralized Identifiers (DIDs) v1.0". https://www.w3.org/TR/did-core/
W3C, "Data Integrity BBS Cryptosuites v1.0". https://www.w3.org/TR/vc-di-bbs/
eID Easy, "EU Digital Identity Wallet Rollout Status by Member State (July 2026)". https://www.eideasy.com/blog/eu-digital-identity-wallets-july-2026
Gataca, "eIDAS 2.0 & EUDI Wallet Timeline: What to Expect in 2026". https://www.gataca.io/resources/blog/eIDAS2-timeline
Dock.io, "Self-Sovereign Identity: The Ultimate Guide 2026". https://www.dock.io/post/self-sovereign-identity
Lewis Silkin, "Age Assurance in 2026: what do digital businesses operating in the UK and EU need to know?". https://www.lewissilkin.com/en/insights/2026/04/17/age-assurance-in-2026-what-do-digital-businesses-operating-in-the-uk-and-eu-need-to-know
Decentralized Identity Foundation, "BBS: Where Proof Meets Privacy". https://blog.identity.foundation/bbs-where-proof-meets-privacy

零知识证明专题第8期：ZK 身份与数字主权：从 EU eIDAS 到 Google Wallet 的隐私凭证

本页目录

第1章当护照不再是护照，而只是"已满18"

第2章数字身份的三层技术架构：谁持有你的身份？

2.1 中心化身份（Centralized Identity）

2.2 联邦化身份（Federated Identity）

2.3 自证主权身份（Self-Sovereign Identity, SSI）

第3章 EU eIDAS 2.0：监管驱动的隐私革命

3.1 EUDI Wallet 架构

3.2 ZKP 集成要求

3.3 技术标准：ISO 18013-5 mDL

3.4 隐私争议

第4章 Google Longfellow：巨头打开 ZK 证据开源大门

4.1 密码学基础：Anonymous Credentials from ECDSA

4.2 开源部署与集成

4.3 对比意义：为什么这是分水岭时刻

4.4 ISRG 的 Rust 实现

第5章 SSI 与 W3C 标准：去中心化的身份密码学

5.1 DID + VC 标准栈

5.2 BBS 签名方案

5.3 AnonCreds v2.0

5.4 SD-JWT 的局限

第6章三条路线的交汇与张力

6.1 Sovereignty 悖论

6.2 商业巨头 vs 开放标准

6.3 ZK 身份 vs 匿名滥用

第7章 2026 实践挑战与未来展望

7.1 密钥丢失恢复

7.2 跨链互操作性

7.3 量子安全迁移

7.4 用户体验门槛

7.5 证明代理与硬件加速

第8章结语：主权的密码学定义

参考文献

延伸阅读

评论

发表评论

零知识证明专题第8期：ZK 身份与数字主权：从 EU eIDAS 到 Google Wallet 的隐私凭证

本页目录

第1章 当护照不再是护照，而只是"已满18"

第2章 数字身份的三层技术架构：谁持有你的身份？

2.1 中心化身份（Centralized Identity）

2.2 联邦化身份（Federated Identity）

2.3 自证主权身份（Self-Sovereign Identity, SSI）

第3章 EU eIDAS 2.0：监管驱动的隐私革命

3.1 EUDI Wallet 架构

3.2 ZKP 集成要求

3.3 技术标准：ISO 18013-5 mDL

3.4 隐私争议

第4章 Google Longfellow：巨头打开 ZK 证据开源大门

4.1 密码学基础：Anonymous Credentials from ECDSA

4.2 开源部署与集成

4.3 对比意义：为什么这是分水岭时刻

4.4 ISRG 的 Rust 实现

第5章 SSI 与 W3C 标准：去中心化的身份密码学

5.1 DID + VC 标准栈

5.2 BBS 签名方案

5.3 AnonCreds v2.0

5.4 SD-JWT 的局限

第6章 三条路线的交汇与张力

6.1 Sovereignty 悖论

6.2 商业巨头 vs 开放标准

6.3 ZK 身份 vs 匿名滥用

第7章 2026 实践挑战与未来展望

7.1 密钥丢失恢复

7.2 跨链互操作性

7.3 量子安全迁移

7.4 用户体验门槛

7.5 证明代理与硬件加速

第8章 结语：主权的密码学定义

参考文献

延伸阅读

评论

发表评论

第1章当护照不再是护照，而只是"已满18"

第2章数字身份的三层技术架构：谁持有你的身份？

第6章三条路线的交汇与张力

第8章结语：主权的密码学定义