数字身份的范式转移——DID 与 VC

Thu, 13 Mar 2025 15:30:00 +0800

写在前面

互联网时代的"身份"是一笔奇怪的账：

你的微信账号属于腾讯——封了你就没了
你的 Gmail 属于 Google——他们能 disable 你
你的银行账号属于银行
你的 LinkedIn 简历存在 LinkedIn 服务器

每一个"你的身份"，实际上都是某个公司租给你的。

DID（Decentralized Identifier，去中心化身份标识） 就是要解决这件事——让用户真正拥有自己的身份。

W3C 在 2022 年发布了 DID 1.0 规范，正式成为推荐标准。配合 Verifiable Credentials（可验证凭证） 规范，DID 是**数字身份的范式转移 **——不只是 Web3 的玩具，而是有可能重塑互联网身份模型的基础设施。

本文讲清楚 DID 的结构、几种主流实现方法、可验证凭证的玩法、工程上的意义。

一、DID 长什么样

DID 是一种 URI——格式：

1

did:method:identifier

例子：

1
2
3
4


did:ethr:0x3b0BC51Ab9De1e5B7B6E34E5b960285805C41736
did:web:example.com:user:alice
did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
did:ion:EiClkZMDxPKqC9c-umQfTkR8...

每段含义：

did：固定前缀
method：用什么"方法"实现这个 DID（决定了它在哪解析、什么类型的密钥等）
identifier：方法内的唯一标识

DID 是一个『可解析的身份标识』——给定一个 DID，你能解析出对应的"DID Document"，包含：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


{
 "@context": "https://www.w3.org/ns/did/v1",
 "id": "did:ethr:0x3b0BC51A...",
 "verificationMethod": [{
 "id": "did:ethr:0x3b0BC51A...#controller",
 "type": "EcdsaSecp256k1RecoveryMethod2020",
 "controller": "did:ethr:0x3b0BC51A...",
 "blockchainAccountId": "eip155:1:0x3b0BC51A..."
 }],
 "authentication": ["did:ethr:0x3b0BC51A...#controller"],
 "assertionMethod": ["did:ethr:0x3b0BC51A...#controller"],
 "service": [{
 "id": "did:ethr:0x3b0BC51A...#hub",
 "type": "IdentityHub",
 "serviceEndpoint": "https://hub.example.com/users/alice"
 }]
}

DID Document 描述：

公钥（用于身份验证、签名）
服务端点（这个身份在哪里能联系到）
控制者（可能委托给别的 DID）

二、DID 的核心特性

1. 用户拥有

私钥在用户本地——没有任何中心化机构能"封禁"或"转让"DID。

2. 全局唯一

DID 在全球范围内唯一——不像 username 可能跨平台冲突。

3. 可解析

任何人拿到 DID 字符串都能查出 DID Document——拿到公钥、服务端点等元数据。

4. 可验证

DID Document 里的公钥可以验证签名——证明"这个 DID 的所有者真的是我"。

5. 可演化

私钥泄漏？可以更新 DID Document，启用新公钥废止老的——身份本身不变。

三、几种主流 DID 方法

DID 规范本身只是个"框架"——具体怎么实现叫"方法（method）"。每种方法有自己的 trade-off：

did:web

1

did:web:example.com:user:alice

最简单的方法——DID Document 就是 HTTPS 文件：

1

https://example.com/user/alice/did.json

特点：

✓ 极易部署，企业域名直接用
✓ 不依赖区块链
✗ 中心化（域名所有者能改 DID Document）
✗ 域名失效 DID 也失效

适合企业身份场景——不是真正去中心化，但合规、好用。

did:key

1

did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

身份就是公钥本身——identifier 部分是公钥的 multibase 编码。

特点：

✓ 最简单的真正去中心化 DID
✓ 离线生成，不需要任何外部依赖
✗ 无法升级密钥——公钥泄漏 = 身份泄漏
✗ 没有服务端点

适合临时身份、单次签名场景。

did:ethr

1

did:ethr:0x3b0BC51Ab9De...

基于以太坊地址——身份注册和更新都通过智能合约。

特点：

✓ 真正去中心化，链上可验证
✓ 可以更新公钥（通过合约调用）
✗ 每次更新要付 Gas
✗ 严重依赖以太坊存活

did:ion

微软主导的 ION 网络——基于比特币的"侧链"层 2。

特点：

✓ 极致可扩展（每秒数千次操作）
✓ 几乎免费
✗ ION 自身是新基础设施

did:peer

适合"两人通信"场景——两端互相交换 DID，无需任何公开注册。

适合 P2P 通信、物联网设备身份。

四、Verifiable Credentials：DID 的杀手级用法

DID 解决了"你是谁"——但只是个标识。Verifiable Credentials（VC） 是 DID 的搭档——表达"某机构证明了你的某项属性"。

例子：大学学位证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


{
 "@context": [
 "https://www.w3.org/2018/credentials/v1",
 "https://www.w3.org/2018/credentials/examples/v1"
 ],
 "type": ["VerifiableCredential", "UniversityDegreeCredential"],
 "issuer": "did:web:university.edu",
 "issuanceDate": "2025-03-13T00:00:00Z",
 "credentialSubject": {
 "id": "did:ethr:0x3b0BC51A...",
 "degree": {
 "type": "BachelorDegree",
 "name": "Bachelor of Science in Computer Science",
 "university": "Example University",
 "year": "2025"
 }
 },
 "proof": {
 "type": "Ed25519Signature2020",
 "created": "2025-03-13T00:00:00Z",
 "verificationMethod": "did:web:university.edu#key-1",
 "proofPurpose": "assertionMethod",
 "jws": "eyJhbGciOi..."
 }
}

VC 的几个关键角色

flowchart LR
 Issuer[Issuer
大学] -->|颁发 VC| Holder[Holder
学生]
 Holder -->|出示 VC| Verifier[Verifier
HR/雇主]
 Verifier -.解析签名.-> Issuer

Issuer（颁发者）：大学、政府、银行
Holder（持有者）：用户自己，存在自己的钱包里
Verifier（验证者）：需要验证用户某项属性的方

VC 的革命性

传统流程：

求职者 → 雇主 → “请提供大学学位证明” → 学生联系大学 → 大学开纸质证明 → 寄给雇主 → 雇主再核实

VC 流程：

求职者持有数字 VC → 出示给雇主 → 雇主本地验证签名 → 完成

雇主不需要联系大学——签名就证明了真实性。用户掌握所有凭证——而不是分散在各机构数据库里。

五、零知识证明 + VC：选择性披露

VC 的最强组合是配合零知识证明——可以证明"我满足某个条件，但不暴露具体值"。

例子：买酒要证明已成年：

朴素：出示身份证 → 暴露具体生日、姓名、地址
VC + ZKP：证明"我的 VC 中 birthDate 早于今天减 18 年" → 没暴露任何具体数据

这种选择性披露是 DID + VC 在隐私保护上的杀手级能力——传统身份证根本做不到。

六、典型应用场景

1. 跨平台单点登录

不再用 Google / Apple 第三方登录——用自己的 DID 登录任何网站。网站只验证签名，不依赖第三方。

2. 数字证书

学位、驾照、护照、专业资格——所有"机构颁发的凭证"都能数字化为 VC。

3. 健康记录

疫苗证书、医疗记录——用户掌控、跨境通用、可被官方验证。

4. KYC 一次完成全平台用

Web3 的痛点之一——每个 dapp 都要 KYC。KYC 提供方颁发 VC，用户在每个 dapp 出示同一个 VC——验证一次，处处通用。

5. 物联网设备身份

每个 IoT 设备一个 DID——设备间相互验证身份，不需要中心化注册中心。

6. 内容真伪验证

媒体、政府公告签发 VC——读者验证签名确认内容来自真实来源（防 deepfake）。

七、工程上的挑战

DID + VC 想象很美，工程上挑战不少：

1. 用户体验

普通用户怎么"管理"自己的 DID？钱包是关键基础设施——但 Web3 钱包的体验目前对普通人不友好。需要更人性化的"DID 钱包"产品（如 Microsoft Authenticator、苹果 Wallet 都在向这个方向走）。

2. 私钥丢了怎么办

DID 完全去中心化的代价——没有"找回密码"。私钥丢失就身份永久丢失。社交恢复（social recovery）、多签等机制是部分解决方案。

3. 撤销机制

颁发的 VC 怎么撤销？比如学校发现学位是假的、银行注销账户。目前主流是颁发者维护一个"撤销列表"——验证时检查，但又中心化了。

4. 跨方法互操作

did:web / did:ethr / did:ion 等几十种方法——钱包要支持哪些？验证者要支持哪些？ 互操作性是大问题。

5. 合规

GDPR、个人信息保护法等监管对"链上不可删除的身份数据"有疑虑——DID 设计要明确"链上只放 hash 或公钥，PII 数据存链下"。

6. 普及度

DID 现在主要在 Web3 圈子用——主流互联网公司还没全面拥抱。

八、几个要关注的项目和标准

W3C DID 1.0 (w3.org/TR/did-core/)：核心规范
W3C Verifiable Credentials (w3.org/TR/vc-data-model/)：VC 规范
EBSI：欧盟区块链服务基础设施，已在多国部署 DID 应用
Microsoft Entra Verified ID：企业级 VC 平台
Polygon ID：基于以太坊侧链 + ZK 的 DID 解决方案
Ceramic Network：分布式数据网络，存 DID 关联数据
Veramo：JS SDK 给开发者用 DID + VC

九、对工程师意味着什么

如果你做的不是 Web3 项目——DID 仍然值得了解：

未来 5-10 年企业身份系统会逐步引入 VC——尤其大企业、政府
理解 DID 让你看清"中心化身份"的局限
DID 的设计哲学（私钥控制、自主主权、可验证）会渗透到普通互联网产品

如果你做 Web3 / dapp：

优先用 did:ethr 或 did:web——生态成熟
Sign-in with Ethereum (SIWE) 是 DID 的"轻量版"——Web3 应用先用 SIWE 替代第三方登录
用户钱包 = 身份——不要给用户搞另一套账号体系

小结

把全文压一句：

DID 把『你是谁』的控制权从平台还给用户——加上 VC 让任何机构能签发可验证的凭证——这是数字身份的范式转移。

理解 DID 的几个核心：

DID 是 URI 形式的身份标识
DID Document 描述身份元数据
VC 是对身份的"声明"
不同 DID 方法有不同 trade-off
配合 ZKP 实现选择性披露

DID 不是"现在就用"的技术——但它是值得每个工程师认知的未来基础设施。10 年后再回头看，这一定是数字身份史上的关键节点。

W3C on 牛哥聊技术