博客 · 2026年7月28日

W3C去中心化标识符（DID）规范详解 (ZH)

W3C DID核心规范的技术解释：标识符和DID URL语法、主体、控制器、DID文档、方法、解析、验证关系、服务、隐私和可验证凭证。.

作者：Didit2026年7月28日更新于 2026年7月28日

W3C去中心化标识符（DIDs）规范定义了URI语法、通用数据模型、DID文档、核心属性、表示形式、方法要求以及用于解析和DID URL解引用的抽象接口。DID核心1.0于2022年7月19日成为W3C推荐标准。DID核心1.1于2026年3月5日作为候选推荐快照发布；它是一个处于不同标准阶段的较新工作。

DID核心不需要区块链，不证明个人的合法身份，不在每个DID文档中存储凭证，也不使每个已解析的端点都值得信任。它标准化了标识符和文档架构。一个独立的DID方法定义了特定DID如何在所选基础设施上创建、读取、更新和停用。

主要收获

DID是一个URI，而不是凭证。它的通用形式是did:<method-name>:<method-specific-id>。
主体和控制器是不同的角色。主体是DID所标识的对象；控制器是由方法授权更改DID文档的实体。
密钥需要明确的用途。验证方法只有通过相应的验证关系才能用于身份验证、断言、密钥协商、能力调用或委托。
方法提供操作规则。DID核心是技术中立的；方法定义了注册表交互、授权、更新、停用和特定于方法的解析。
解析本身不会产生信任。实施者必须验证方法结果，强制执行证明目的，管理密钥和历史记录，保护隐私，并应用应用程序策略。

什么是去中心化标识符？

去中心化标识符是一种标识符，其设计目的是在不需要一个中心身份提供者或证书颁发机构来颁发和维护每个标识符的情况下建立控制。“去中心化”一词描述了架构将标识符控制与单一中心发行方分离的能力；它并不表示每个实现都是匿名的、公开的、不可变的或存储在分布式账本上。

DID可以标识：

一个人；
一个组织或团体；
一个设备或物理对象；
一个数字资源；
一个数据模型；
一个抽象概念。

被标识的实体是DID主体。仅凭字符串无法揭示主体类型。

DID语法

通用语法是：

did:<method-name>:<method-specific-id>

例如：

did:example:123456789abcdefghi

did是URI方案。example是DID方法名称。剩余的字符串是特定于方法的标识符。方法规范定义了该值的含义以及软件如何处理它。

一个看起来有效的DID不一定可用。该方法必须存在，并且解析器必须支持它。

DID URL：路径、查询和片段

DID URL以DID开头，可以添加路径、查询或片段：

did:example:123456789abcdefghi/path?service=messages#key-1

这些组件可以标识或帮助选择：

DID文档中的验证方法；
服务条目；
另一个DID文档片段；
通过服务访问的资源；
版本或方法定义的选项。

片段#key-1通常标识一个验证方法。它不表示私钥在文档中。DID文档发布公共验证材料或引用；秘密材料必须保留在其他地方受到保护。

DID架构

主要概念是相关的，但不可互换：

概念	角色
DID	符合DID语法的全球唯一标识符
DID主体	被标识的人、组织、事物、资源或概念
DID控制器	根据DID方法授权更改DID文档的实体
DID文档	与主体相关的数据，包括允许的验证方法和服务
DID方法	特定于方法的语法和操作的单独规范
可验证数据注册表	方法用于创建、读取、更新或停用DID状态的基础设施
DID解析器	对支持的方法执行DID解析的软件或硬件
DID URL解引用器	获取由DID URL标识的资源的软件或硬件

主体与控制器

主体和控制器可以是同一个实体，但不必如此。父级可以控制子级的DID，组织可以控制设备的DID，或者多个受托人可以控制恢复安排。

顶级controller标识一个或多个DID控制器。验证方法所需的controller标识谁控制该方法；它不自动是顶级DID控制器。混淆它们可能会授予意外的权限。

什么是DID文档？

DID文档是根据DID核心数据模型与DID主体关联的数据。其根id是DID。可选的核心属性可以描述控制器、备用标识符、验证方法、验证关系和服务。

这个简化示例使用规范示例空间中的公共材料：

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    }
  ],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-1"
  ]
}

did:example保留用于示例；生产系统必须使用实际方法及其当前的验证方法套件要求。上面的JSON是故意有效的JSON。许多技术规范中打印的示例包含注释或省略号以提高可读性，不应直接复制到解析器中。

核心属性

id：主体的DID；在文档根部是必需的。
controller：一个或多个根据方法授权进行更改的DID。
alsoKnownAs：被断言标识相同主体的其他URI。
verificationMethod：可通过显式关系引用的公共验证机制。
authentication：授权作为主体进行身份验证的方法。
assertionMethod：授权表达声明的方法，例如凭证颁发。
keyAgreement：旨在导出共享秘密材料的方法。
capabilityInvocation：授权调用能力的方法。
capabilityDelegation：授权委托能力的方法。
service：与主体关联的端点或交互机制。

alsoKnownAs是一个断言，而不是两个标识符等同的加密证明。应用程序应独立验证其信任模型所需的这种关系。

数据模型和表示形式

DID核心定义了一个抽象数据模型和生成和消费表示形式的规则。数据模型与一个JSON序列化不完全相同。

表示形式要求是版本特定的：

2022年的DID核心1.0推荐标准定义了application/did+json和application/did+ld+json。其JSON-LD表示以基本上下文https://www.w3.org/ns/did/v1开头。
DID核心1.1候选推荐标准将核心媒体类型整合为application/did。其JSON-LD表示以https://www.w3.org/ns/did/v1.1开头。

不要将一个版本的媒体类型或基本上下文与声称符合另一个版本的声明混淆。请明确生产者和消费者所实现的规范版本。

实施者应明确协商和验证表示形式。在没有定义的规范化和安全机制的情况下签署任意序列化的JSON字节不等同于正确处理DID数据模型。

验证方法和验证关系

验证方法描述了如何检查证明。它需要：

表示为DID URL的id；
一个type；
一个controller；
适合该类型的验证材料。

公共材料可以通过定义的属性（如publicKeyJwk）或验证方法套件允许的其他形式表示。DID文档中的JWK不得包含私钥材料。在一种方法中，相同的验证材料不得在多个材料属性中重复。

定义验证方法并不能授权其用于所有目的。授权来自五个明确的验证关系。

关系	预期证明目的
`authentication`	通过挑战-响应或其他接受的机制作为DID主体进行身份验证
`assertionMethod`	表达声明，包括签署使用它的可验证凭证（如果选择了安全机制）
`keyAgreement`	建立共享加密材料，通常用于加密
`capabilityInvocation`	调用对象能力
`capabilityDelegation`	委托对象能力

验证者必须检查证明所需的关联。仅列在authentication下的密钥不会自动授权用于凭证断言或密钥协商。

关系可以嵌入完整的验证方法或通过DID URL引用。引用提高了重用性，但需要正确的解引用和精确的标识符比较。

服务和服务端点

可选的service属性可以宣传与DID主体通信或交互的方式。每个服务条目都有：

唯一的id；
一个type；
一个serviceEndpoint。

端点可以是URI或其他允许的结构。服务定义是可扩展的，因此应用程序必须理解所选类型。

发布端点并不能证明其服务器、操作员、传输、内容或目的地是值得信任的。

应用程序必须通过方法验证已解析的DID状态，验证服务类型，应用URL和网络安全控制，并使用具有自身安全属性的应用程序协议。

公共服务端点也可能产生关联。在成对DID之间重用一个端点可能会抵消单独标识符带来的隐私好处。

DID方法定义了什么

DID核心提供了通用架构。符合规范的DID方法定义了实现它所需的特定于方法的规则，包括：

方法名称和特定于方法的标识符语法；
DID和初始DID文档的创建方式；
当前状态的读取方式；
授权更新的提交和验证方式；
DID的停用方式；
解析如何与注册表通信；
结果的真实性和完整性如何建立；
密钥轮换、恢复、版本控制和历史记录如何工作；
特定于方法的安全和隐私考虑。

可验证数据注册表可以是分布式账本、去中心化文件系统、点对点网络、数据库或其他系统。架构应根据治理、可用性、授权、隐私、成本、历史记录和抗攻击性进行评估，而不是仅仅根据“去中心化”一词。

方法选择标准

在选择方法之前，请测试：

规范成熟度和治理；
解析器和库的互操作性；
更新和停用授权；
密钥轮换和恢复；
历史状态支持；
隐私和元数据泄露；
注册表可用性和审查风险；
交易或运营成本；
加密敏捷性；
迁移和方法失败。

更改方法通常意味着引入新的标识符和受信任的迁移路径。

DID解析与DID URL解引用

DID解析接受DID和解析选项，并返回：

DID解析元数据；
DID文档、文档流或无文档；
DID文档元数据。

解析器使用方法定义的“读取”操作。DID核心定义了抽象接口和通用结果概念；特定于方法的通信和认证仍由方法处理。

DID URL解引用接受完整的DID URL，并返回：

解引用元数据；
如果可用，则为标识的资源；
内容元数据。

解引用可能首先解析基本DID，然后选择片段、服务或外部资源。它不是解析的同义词。

独立的W3C DID解析规范开发了详细的解析和解引用算法。其最新出版物是2026年7月24日的W3C工作草案，DID URL解引用被标记为“有风险的功能”。它仍然是标准跟踪工作，而不是2022年DID核心1.0推荐标准的一部分，因此在声称符合性之前，请先确定草案版本。

解析器信任和缓存

解析器是安全和隐私边界。它会看到请求的标识符，并可能返回过时或被操纵的状态。评估：

方法结果验证；
传输和解析器身份验证；
缓存新鲜度和失效；
版本和时间选项；
错误处理和降级行为；
通过查找造成的隐私泄露；
注册表或网络故障期间的行为。

DID与可验证凭证

DID和可验证凭证是互补的规范，而不是相同的对象。

基本DID可以标识：

凭证发行者；
凭证主体；
持有者。

用于安全机制的验证方法则由DID URL标识，通常是DID后跟一个片段，例如#key-1。

W3C可验证凭证数据模型2.0定义了凭证、演示、发行者、持有者、主体、有效性、状态、模式和安全机制。它不要求每个标识符都是DID。

当DID用于发行者时，验证者可能会解析发行者的DID，找到证明的验证方法，并确认该方法在assertionMethod下获得授权。这种加密验证仍然无法确定：

每个凭证声明都是真实的；
发行者在该声明中是值得信任的；
凭证是当前有效的或可接受的；
其状态、模式或证据符合策略；
凭证主体是提交它的人。

这些检查属于安全机制、状态系统、信任框架、演示绑定和验证者策略。

隐私和安全考虑

避免在公共文档中包含个人数据

DID文档可以广泛复制。不要仅仅因为模型可扩展而发布姓名、政府标识符、生物识别信息、凭证或其他个人数据。加密对于永久公开的密文来说不是一个持久的解决方案。

防止关联

成对或特定上下文的DID只有在其他数据也分离的情况下才能减少关联。重复使用的密钥、服务终结点、网络标识符、凭证属性、时间以及注册表活动都可以链接看似独立的DID。

轮换和恢复密钥

在发布之前计划好妥协情况。定义更新授权、恢复控制器、阈值规则、轮换、旧密钥处理和停用。恢复权限需要分离和审计。

验证证明目的

不仅要检查签名是否有效，还要检查验证方法是否在相关时间被授权用于所需的关联。防止身份验证、断言、协商和能力使用之间的替换。

谨慎处理历史记录

当前的DID文档可能不再包含旧密钥。验证历史证明可能需要方法支持的历史版本以及证明时间的可靠证据。“密钥现在不存在”和“证明从未有效”不是等同的结论。

常见的DID实施错误

称DID核心为区块链规范

DID核心是技术中立的。区块链是一种可能的注册表架构。

将DID视为合法身份的证明

DID支持标识符控制和加密验证。现实世界的身份绑定需要单独的证据、发行者断言或信任框架。

将任何列出的密钥用于任何目的

强制执行明确的验证关系和证明目的。

自动信任服务端点

验证方法状态并应用应用程序、传输、URL和内容安全。

假设所有DID都是私有的或匿名的

注册表活动、解析、重复使用的材料和服务可能会暴露持久的关联。

实施清单

在生产之前，请确认：

所选的DID核心版本和DID方法规范已固定；
标识符和DID URL解析使用符合标准的URI处理；
接受的表示形式和媒体类型是明确的；
每个证明都强制执行预期的验证关系；
方法结果经过身份验证，而不是信任来自任何解析器；
缓存、版本控制、历史验证和停用已进行测试；
更新、轮换、泄露、恢复和迁移已进行演练；
公共文档不包含不必要的个人或相关数据；
服务端点接受单独的应用程序层安全审查；
可验证凭证的信任、状态、模式和演示检查保持分离。

DID与身份验证的交汇

DID可以标识主体和验证材料，但它们不执行身份验证。可重用身份系统仍然需要可靠的证据和受治理的决策，然后才能发布或接受声明。Didit的身份验证可以为此类决策提供身份证据，而可重用KYC支持在参与服务之间重用先前的验证，并列为免费。

这种产品邻近性并不意味着每项Didit验证都是DID，也不意味着DID解析取代了KYC。当前模块费率可在定价页面上查看。架构应将标识符控制、身份证据、凭证颁发、演示和依赖方策略作为独立的信任边界。

常见问题

W3C DID规范定义了什么？

它定义了DID和DID URL语法、通用数据模型、核心DID文档属性、表示形式、方法要求以及抽象的解析和解引用接口。

每个DID都使用区块链吗？

不。DID方法可以使用账本、数据库、点对点系统、去中心化文件系统或其他注册表架构。

DID和DID文档有什么区别？

DID是标识符。DID文档是关联数据，可以描述控制器、验证方法及其目的、服务和其他定义的属性。

解析和解引用有什么区别？

解析获取DID的DID文档和元数据。解引用获取由完整DID URL标识的资源，可能在解析其基本DID之后。

DID与可验证凭证相同吗？

不。DID是标识符。可验证凭证是在VC数据模型和安全机制下的一组防篡改、机器可验证的声明。VC可以使用DID，但并不普遍要求它们。

控制DID能证明一个人是谁吗？

不。它可以证明对与DID相关的加密或特定于方法的权限的控制。将这种控制绑定到法律或现实世界的身份需要额外的证据或受信任的断言。

DID文档可以包含私钥吗？

不。DID文档包含公共验证材料或引用。私钥材料不得出现，并且必须由控制器的密钥管理系统保护。

主要参考资料

DID核心在其声明保持精确时最有用。它标准化了标识符、文档、验证目的、服务和方法接口。信任仍然来自方法的治理、经过身份验证的解析、受保护的密钥、明确的证明目的、注重隐私的设计以及应用程序对接受何种证据的决策。

继续阅读