第2章：DID规范深度解析：W3C DID Core规范、DID Document结构、DID Method

好，咱们进入正题。上一章我们聊了DID是什么，为什么需要它。这一章，我们来拆解DID的「骨架」——W3C DID Core规范。

说实话，我第一次看W3C的规范文档时，头都大了。满篇的「MUST」、「SHOULD」、「MAY」，像在读法律条文。但啃下来之后发现，核心其实就那么几块东西。我帮你捋一捋。

2.1 W3C DID Core规范：到底在规范什么？

W3C DID Core，说白了就是一套「游戏规则」。它规定了：

• 一个合法的DID长什么样
• DID Document里必须包含什么、可以包含什么
• DID Method应该怎么定义自己的操作

你想想看，如果没有这个规范，大家各搞一套，A系统生成的DID，B系统根本不认。那去中心化身份就变成「去中心化孤岛」了。

我记得2021年刚接触这个规范时，最大的困惑就是：「规范里写了这么多，到底哪些是必须实现的？」后来我总结了一个经验——看关键词。规范里带「MUST」的，一个都不能少；带「SHOULD」的，尽量做；带「MAY」的，看心情。

2.2 DID Document结构：身份的「身份证」

每个DID都对应一份DID Document。你可以把它理解成「身份证」——上面写着你是谁、怎么联系你、用什么验证你。

来看一个最简的DID Document长什么样：

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://www.w3.org/ns/did/v2"
  ],
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
  "authentication": [
    "did:example:123456789abcdefghi#keys-1"
  ],
  "service": [{
    "id": "did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

嗯，这里要注意几个关键字段：

字段	作用	我踩过的坑
@context	声明文档遵循的规范版本	忘记加v2导致解析器报错，排查了半天
id	DID本身，必须与文档关联的DID一致	有人把id写成了别的DID，直接验证失败
verificationMethod	公钥列表，用于签名验证	公钥格式搞错，验签一直不过
authentication	指定哪些公钥可用于身份认证	这个字段容易被忽略，但很多协议强制要求
service	关联的服务端点，比如VC颁发接口	端点URL写错，导致服务不可达

2.3 DID Method：每个DID背后的「引擎」

DID Method，是DID体系里最灵活、也最复杂的一块。它定义了：

• DID的格式（比如 did:ethr:0x... 还是 did:key:z6Mk...）
• DID Document怎么创建、读取、更新、删除（CRUD操作）
• 数据存在哪里（链上、链下、IPFS、还是数据库）

我举个例子你就明白了。同样是DID：

• did:key：公钥直接编码进DID，不需要任何外部存储。适合轻量级场景。
• did:ethr：基于以太坊，DID Document存在链上。适合需要公开验证的场景。
• did:web：基于域名，DID Document存在HTTPS服务器上。适合传统Web迁移。

为什么会这样设计？因为不同场景需求不同。你想想看，一个物联网设备和一个金融机构，对身份管理的需求能一样吗？

所以我的建议是：先想清楚你的场景需要什么操作。

• 如果只需要静态身份，did:key就够了
• 如果需要更新、撤销，选支持CRUD的Method
• 如果需要隐私保护，考虑zk-based的Method

2.4 实战：如何注册一个DID Method？

如果你想自己定义一个DID Method，W3C要求你提交一份规范文档。但说实话，99%的场景不需要自己造轮子。现有的Method已经覆盖了大部分需求。

我个人的建议是：

1. 先看 DID Method Registry（W3C维护的注册表）
2. 找到最接近你场景的Method
3. 如果非要自己写，参考 did:key 的实现——它是最简单的

嗯，这一章内容不少。核心就三句话：

• DID Core规范：定规矩的
• DID Document：写身份的
• DID Method：干活的

下一章，我们会动手搭建一个基于 did:ethr 的认证系统。到时候你会看到，这些规范到底怎么落地。