去中心化身份 （DID）v1.0

内容翻译自2022年07月19日由W3C正式推荐的标准：去中心化身份 （DID） v1.0 (w3.org)

该标准主要主要含有：核心体系结构、数据模型和表示形式。

去中心化身份（DID）是一种新型身份，可实现可验证的去中心化数字身份。DID是指由DID的管理者确定的任何主体（例如，人、组织、事物、数据模型、抽象实体等）。与典型的联合身份相比，DID的设计使其可以与集中式注册表、身份提供程序和证书颁发机构分离。具体而言，虽然其他方可用于帮助发现与 DID 相关的信息，但该设计使 DID 的管理者能够证明对它的控制权，而无需任何其他方的许可。DID 是将 DID 订阅者与 DID 文档相关联的 URI，允许与该订阅者关联的可信任交互。
每个 DID 文档都可以表达加密材料、验证方法或服务，这些材料、验证方法或服务提供了一组机制，使 DID 管理者能够证明对 DID 的控制。服务支持与 DID 订阅者关联的可信交互。如果 DID 主体是信息资源（如数据模型），则 DID 可能会提供返回 DID 主体本身的方法。
本文档指定 DID 语法、通用数据模型、核心属性、序列化表示形式、DID 操作，以及将 DID 解析为它们所表示的资源的过程的说明。

作为个人和组织，我们中的许多人在各种上下文中使用全球唯一标识符。它们用作通信地址（电话号码，电子邮件地址，社交媒体上的用户名），身份证号码（护照，驾驶执照，税号，健康保险）和产品标识符（序列号，条形码，RFID）。URI（统一资源标识符）用于 Web 上的资源，您在浏览器中查看的每个网页都有一个全局唯一的 URL（统一资源定位器）。
这些全球唯一标识符中的绝大多数都不在我们的控制之下。它们由外部当局发布，这些当局决定他们指的是谁或什么，以及何时可以撤销它们。它们只在某些情况下有用，并且只被某些不是我们选择的机构所承认。它们可能会随着组织的失败而消失或不再有效。他们可能会不必要地泄露个人信息。在许多情况下，它们可能被恶意第三方以欺诈方式复制和断言，这通常被称为“身份***”。
本规范中定义的去中心化身份（DID） 是一种新型的全局唯一身份。它们旨在使个人和组织能够使用他们信任的系统生成自己的身份。这些新身份使实体能够通过使用加密证明（如数字签名）进行身份验证来证明对它们的控制。
由于去中心化身份的生成和断言是实体控制的，因此每个实体可以根据需要拥有尽可能多的DID，以保持其所需的身份，角色和交互的分离。这些身份的使用可以适当地限定为不同的上下文。它们支持与其他人、机构或系统的交互，这些人员、机构或系统需要实体识别自己或他们控制的东西，同时提供对应披露多少个人或私人数据的控制，所有这些都不依赖于中央机构来保证身份的继续存在。这些想法在 DID 用例文档 [DID-USE-CASES] 中进行了探讨。
本规范并不以任何特定技术或加密技术为前提，以支持 DID 的生成、保持、解析或解释。例如，实施者可以根据在联合或集中式身份管理系统中注册的身份创建去中心化身份。事实上，几乎所有类型的身份系统都可以添加对DID的支持。这在集中式、联合式和去中心化身份之间创建了一个互操作性桥梁。这也使实施者能够设计特定类型的DID，以与他们信任的计算基础设施一起使用，例如分布式账本，去中心化文件系统，分布式数据库和P2P网络。
本规范适用于：

• 任何想要了解作为去中心化身份基础的核心架构原则的人；
• 想要生成和使用去中心化身份及其相关数据格式的软件开发人员；
• 想要了解如何在其软件和硬件系统中使用去中心化身份的系统集成商；
• 希望创建符合本文档所述生态系统的新 DID 基础结构（称为 DID 方法）的规范作者。

一个简单的例子

本节是非规范性的。

一个DID是一个简单的文本字符串，由三部分组成：1）URI模式的标识符，2）DID方法的标识符，以及3）DID特定方法的标识符。

上面的示例DID解析为一个DID文档。DID文档包含与DID相关联的信息，例如以加密方式验证DID管理者的方法。

示例1：一个简单的DID文档

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

设计目标

本节是非规范性的。

去中心化身份是大型系统的一个组成部分，例如可验证凭证生态系统[VC-DATA-MODEL]，它影响了本规范的设计目标。这里总结了去中心化身份的设计目标。

目标	描述
去中心化	在身份管理中消除对集中授权机构或单点故障的要求，包括注册全局唯一身份、公共验证密钥、服务和其他信息。
控制	赋予实体（包括人类和非人类）直接控制其数字身份的权力，而不需要依赖外部当局。
隐私	允许实体控制其信息的隐私，包括属性或其他数据的最小、选择性和渐进式公开。
安全	为请求方提供足够的安全性，使其依赖于DID文档以获得所需的保证级别。
基于证据的	启用DID管理者，在与其他实体交互时提供密码证明。
可发现性	使实体能够发现其他实体的DID，了解更多关于这些实体的信息或与这些实体交互。
互操作性	使用可互操作的标准，这样DID基础设施就可以利用为互操作而设计的现有工具和软件库。
可移植性	独立于系统和网络，使实体能够在任何支持DIDs和DID方法的系统上使用它们的数字身份。
简单	减少一些简单的特性，使技术更容易理解、实现和部署。
可扩展性	在可能的情况下，在不严重影响互操作性、可移植性或简单性的前提下，启用可扩展性。

体系结构概述

本节是非规范性的。
本节提供去中心化身份体系结构的主要组件的基本概述。

上图描述了DID体系结构概述和基本组件之间的关系。

DIDs和DID url

分布式身份（Decentralized Identifier，简称DID）是一个由三部分组成的URI：方案、方法身份和由DID方法指定的唯一的、特定于方法的身份。DID可解析为DID文档。DID URL扩展了基本DID的语法，以合并其他标准URI组件，如路径、查询和片段，以便定位特定的资源（例如，DID文档内的加密公钥或DID文档外部的资源）。这些概念在3.1 DID语法和3.2 DID URL语法中有详细阐述。

DID订阅者

根据定义，DID的主体是由DID标识的实体。DID主体也可能是DID的管理者。任何事物都可以是DID的订阅者：人、团体、组织、事物或概念。这在5.1.1 DID Subject中有进一步的定义。

DID管理者

DID的管理者是一个实体（个人、组织或自主软件），它具有对DID文档进行更改的能力（由DID方法定义）。这种功能通常通过代表管理者的软件使用的一组加密密钥的控制来断言，不过也可以通过其他机制断言。注意，一个DID可能有多个管理者，DID订阅者可以是DID管理者，或其中之一。这个概念在5.1.2 DID Controller中有记录。

可核查的数据登记

为了能够解析为DID文档，DID通常被记录在某种底层系统或网络上。不管使用什么特定的技术，任何支持记录DID并返回生成DID文档所需数据的系统都被称为可验证的数据注册中心。示例包括分布式账本、去中心化的文件系统、任何类型的数据库、点对点网络和其他形式的可信数据存储。这个概念在第8章中有进一步的阐述。

DID文档

DID文档包含与DID相关联的信息。它们通常表示验证方法（如加密公钥）和与DID订阅者交互相关的服务。在5中指定了DID文档中支持的通用属性。核心属性。一个DID文档可以被序列化为字节流（见6.表示）。可以根据8中概述的适用操作更新DID文档中出现的属性。

DID方法

DID方法是一种机制，通过它创建、解析、更新和停用特定类型的DID及其关联的DID文档。使用8.方法中定义的独立DID方法规范定义DID方法。

DID解析器和DID解决方案

一个DID解析器是一个系统组件，它接受一个DID作为输入，并产生一个符合DID的文档作为输出。这个过程称为DID解析。相关的DID方法规范定义了解析特定类型DID的步骤。7中详细阐述了DID的解析过程。

DID URL解引用器和DID URL非关联化
一个DID URL解引用器是一个系统组件，它接受一个DID URL作为输入，并产生一个资源作为输出。这个过程称为DID URL解引用。在7.2 DID URL 解引用器中详细介绍了DID URL 解引用的过程。

除了标记为非规范的部分外，本规范中所有的创作指南、图表、示例和注释都是非规范的。本规范中的其他一切都是规范的。
本文档中的关键字MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD, and SHOULD NOT应按照BCP 14 [RFC2119] [RFC8174]中描述的解释，当且仅当它们以所有大写字母出现时，如下所示。
本文档包含包含JSON和JSON-ld内容的示例。其中一些示例包含无效的字符，例如内联注释()和使用省略号()来表示对示例没有什么价值的信息。如果实现者希望将该信息用作有效的JSON或JSON-ld，请谨慎删除该内容。/ /……
一些示例包含本规范中没有定义的术语，包括属性名和值。这些是用注释()表示的。当在DID文档中使用这些术语时，期望在DID规范注册表（DID-spec-registry）中注册，并提供到正式定义和JSON-LD上下文的链接。//外部（property name|value）
通过评估实现创建和解析符合此规范的DIDs和DID文档的能力来测试DIDs和DID文档实现的互操作性。通过确保DIDs和DID文档符合，可以为DIDs和DID文档的生产者和消费者提供互操作性。每个DID方法规范中的细节提供了DID方法规范的互操作性。可以理解的是，就像web浏览器不需要实现所有已知的URI方案一样，与DIDs兼容的软件也不需要实现所有已知的DID方法。但是，给定的DID方法的所有实现都希望该方法是可互操作的。

• 符合规范的DID是3.身份中规定的规则的任何具体表达，并且符合该节中的相关规范陈述。
• 符合规范的DID文档是本规范中描述的数据模型的任何具体表达，它符合4.数据模型和5.核心属性中的相关规范语句。一致性文档的序列化格式是确定性的、双向的和无损的，如6.表示形式所述。
• 符合性生产者是指任何以软件和/或硬件形式实现的算法，该算法生成符合性的DIDs或符合性的DID文档，并符合6.表示形式中的相关规范声明。
• 符合性消费者是指使用符合性DIDs或符合性DID文档并在6.表示形式中遵守相关规范声明的软件和/或硬件实现的任何算法。
  
• 符合规范的DID解析器是任何实现为软件和/或硬件的算法，符合7.1 DID解析中的相关规范陈述。
• 符合规范的DID URL解引用器是任何实现为软件和/或硬件的算法，符合7.2 DID URL解引用中的相关规范陈述。
• 符合规范的DID方法是符合8.方法中相关规范陈述的任何规范。

本节是非规范性的。
本节定义了本规范和整个去中心化身份基础结构中使用的术语。只要这些术语出现在本规范中，就会包含到它们的链接。
放大的攻击

一类攻击，攻击者试图耗尽目标系统的CPU、存储、网络或其他资源，方法是向系统提供小的、有效的输入，导致破坏性影响，处理成本可能比输入本身高指数级。

进行身份验证

身份验证是一个实体通过使用一种或多种验证方法证明其具有特定属性或控制特定秘密的过程。对于DIDs，一个常见的例子是证明与在DID文档中发布的公钥相关联的加密私钥的控制。

密码套件

为实现特定的安全目标，定义特定密码原语用法的规范。这些文档通常用于指定验证方法、数字签名类型、它们的标识符和其他相关属性。

分布式身份（DID）

全局唯一的持久的身份，不需要集中的注册机构，通常以加密方式生成和/或注册。DID的通用格式在3.1 DID语法中定义。在DID方法规范中定义了一个特定的DID方案。许多（但不是全部）DID方法利用分布式账本技术（DLT）或其他形式的去中心化网络。

去中心化的身份管理

基于去中心化身份的身份管理。去中心化的身份管理扩展了身份生成、注册和分配的权限，超出了X.500目录服务、域名系统和大多数国家ID系统等传统的信任根。

DID管理者
能够对DID文档进行更改的实体。一个DID可能有多个DID管理者。可以用DID文档顶层的可选属性来表示DID管理者。注意，DID管理者可能是DID订阅者。
DID委托
一个实体，DID管理者通过DID文档向其授予使用与DID关联的验证方法的权限。例如，控制孩子DID文档的父母可能会允许孩子使用他们的个人设备进行身份验证。在本例中，子对象是DID委托。孩子的个人设备将包含私有密码材料，使孩子能够使用DID进行身份验证。但是，如果没有父母的允许，孩子可能不被允许添加其他个人设备。
DID文档
描述DID订阅者的一组数据，包括加密公钥等机制，DID订阅者或DID委托可以使用这些机制对自身进行身份验证，并证明其与DID的关联。正如6中定义的那样，一个DID文档可能有一个或多个不同的表示。表示或在W3C DID规范注册表中[DID- spec-registry]。
DID片段
在第一个散列符号字符()之后的DID URL部分。DID片段语法与URI片段语法相同。
DID方法
如何实现特定DID方法方案的定义。DID方法由DID方法规范定义，该规范指定了创建、解析、更新和停用DIDs和DID文档所需的精确操作。
DID路径
以并包含第一个正斜杠()字符开始，以问号()字符、片段哈希符号()字符或DID URL结束的部分。DID路径语法与URI路径语法相同。
DID查询
跟在第一个问号字符()之后的DID URL的一部分。DID查询语法与URI查询语法相同。看到查询。
DID决议
该过程以一个DID和一组解析选项作为输入，并以符合要求的表示返回一个DID文档，外加额外的元数据。这个过程依赖于适用的DID方法的“读取”操作。这个过程的输入和输出在7.1 DID Resolution中定义。
DID解析器
DID解析器是一种软件和/或硬件组件，它通过将DID作为输入并生成符合DID的文档作为输出来执行DID解析功能。
DID方案
分布式身份的形式语法。泛型DID模式以3.1 DID语法中定义的前缀开始。每个DID方法规范都定义了一个特定的DID方法方案，该方案与特定的DID方法一起工作。在一个特定的DID方法方案中，DID方法名称在第一个冒号之后，以第二个冒号结束，例如：DID: DID:example:
DID订阅者
由DID身份并由DID文档描述的实体。任何事物都可以成为DID订阅者：人、团体、组织、物理事物、数字事物、逻辑事物等等。
DID URL
一个DID加上任何符合3.2 DID URL语法中的定义的附加语法组件。这包括可选的DID路径（带前导字符）、可选的DID查询（带前导字符）和可选的DID片段（带前导字符）。
DID URL非关联化
进程将一个DID URL和一组输入元数据作为其输入，并返回一个资源。这个资源可以是一个DID文档加上额外的元数据、一个包含在DID文档中的辅助资源，或者一个完全外部于DID文档的资源。该进程使用DID解析来获取一个DID文档，该文档由DID URL中包含的DID指示。然后，解除引用进程可以对DID文档执行额外的处理，以返回由DID URL指示的解除引用的资源。这个过程的输入和输出在7.2 DID URL解引用中定义。
分布式分类帐（DLT）
用于记录事件的非中心化系统。这些系统为参与者建立了充分的信心，使他们能够依靠其他人记录的数据做出操作决策。它们通常使用分布式数据库，其中不同的节点使用共识协议来确认加密签署的事务的顺序。随着时间的推移，数字签名交易的链接往往使分类帐的历史有效地不可更改。
公钥描述
包含在DID文档中的数据对象，它包含使用公钥或验证密钥所需的所有元数据。
资源
如[RFC3986]所定义:“…术语‘资源’一般用于URI可能标识的任何东西。”类似地，任何资源都可以作为DID标识的DID订阅者。
表示
正如[RFC7231]对HTTP的定义：“旨在反映给定资源过去、当前或期望状态的信息，其格式可以通过协议轻松通信，由一组表示元数据和潜在的无限表示数据流组成。”DID文档是描述DID订阅者的信息表示。看到6.表示。
特定于表示的条目

在DID文档中，其意义是特定表示的条目。在4.数据模型和6表示形式中定义。例如，JSON-LD表示中的@context是一个特定于表示的条目。
服务
通过一个或多个服务端点与DID订阅者或关联实体通信或交互的方法。示例包括发现服务、代理服务、社交网络服务、文件存储服务和可验证的凭证存储库服务。
服务端点
网络地址，如HTTP URL，服务在该地址上代表DID订阅者进行操作。
统一资源标识符
万维网上所有资源的标准标识符格式，由[RFC3986]定义。DID是一种URI模式。
可验证的凭据
一种用于加密可验证数字凭证的标准数据模型和表示格式，由W3C可验证凭证规范[VC-DATA-MODEL]定义。
可验证的数据注册表
一种有助于创建、验证、更新和/或停用去中心化身份和DID文档的系统。可验证的数据注册表也可以用于其他加密可验证的数据结构，如可验证的凭证。有关更多信息，请参阅W3C可验证凭据规范[VC-DATA-MODEL]。
可验证的时间戳
可验证的时间戳使第三方能够验证数据对象在特定时间存在，并且自那个时间点以来它没有被修改或损坏。如果数据完整性在那个时间点之后被合理地修改或损坏，则时间戳是不可验证的。
验证方法
一组参数，可以与一个过程一起使用，以独立地验证一个证明。例如，可将加密公钥用作关于数字签名的验证方法;在这种用法中，它会验证签名者是否拥有相关的加密私钥。
本定义中的“验证”和“证明”适用范围较广。例如，可以在Diffie-Hellman密钥交换期间使用加密公钥来协商用于加密的共享对称密钥。这保证了关键协议过程的完整性。因此，它是另一种类型的验证方法，尽管过程的描述可能不会使用“验证”或“证明”等词。
验证的关系
DID主体与验证方法之间关系的表达。验证关系的示例为5.3.1认证。
通用唯一标识符(UUID)
由[RFC4122]定义的一种全局唯一标识符。uuid与DIDs类似，因为它们不需要集中的注册机构。uuid与DIDs的不同之处在于，它们是不可解析的或不可通过密码验证的。

除了上面的术语外，本规范还使用了来自[INFRA]规范的术语来正式定义数据模型。当使用[INFRA]术语时，例如字符串、集合和映射，它直接链接到该规范。

本章略

该规范定义了一个数据模型，可用于表示DID文档和DID文档数据结构，然后可以将其序列化为多个具体表示。本部分提供数据模型的高级描述，描述在数据模型中表示不同类型属性的方式，以及扩展数据模型的说明。

一个DID文档由一个条目映射组成，其中每个条目由一个键/值对组成。DID文档数据模型至少包含两个不同类别的条目。第一类条目称为属性，在第5.节 核心属性中指定。第二个类由特定于表示的条目组成，在第6节中指定。

上图是DID文档中的条目，参见：叙述描述。

DID文档数据模型中的所有输入键都是字符串。所有条目值都使用下表中的一种抽象数据类型表示，每种表示指定每种数据类型的具体序列化格式。

数据类型	注意事项
map	键/值对的有限有序序列，没有键出现两次，如[INFRA]中规定的那样。在[INFRA]中，地图有时被称为有序map。
list	在[INFRA]中指定的有限有序的项目序列。
set	一种有限的有序序列，不包含[INFRA]中规定的两次相同的项。在[INFRA]中，集合有时被称为有序集合。
datetime	一个日期和时间值，它能够无损地表示[XMLSCHEMA11-2]中指定的由A表示的所有值。
string	一组代码单元序列，通常用来表示[INFRA]中指定的人类可读语言。
integer	一个没有[XMLSCHEMA11-2]中指定的小数部分的实数。为了最大化互操作性，敦促实现者注意RFC8259第6节：Numbers中关于整数的建议。
double	通常用于近似[XMLSCHEMA11-2]中指定的任意实数的值。为了最大限度地提高互操作性，敦促实现者注意RFC8259第6节:数字中关于双精度的建议。
boolean	在[INFRA]中定义的值为真或假。
null	一个值，用于指示缺少[INFRA]中定义的值。

使用[INFRA]中的术语定义数据模型的结果是，可以包含多个项的属性值（如列表、映射和集）被显式地排序。在[INFRA]中所有类似列表的值结构都是有序的，不管这个顺序是否重要。对于本规范而言，除非另有说明，否则映射和集合排序并不重要，实现不期望产生或使用确定性排序的值。

数据模型支持两种类型的可扩展性。

1. 为了获得最大的互操作性，建议扩展使用W3C DID Specification registry机制[DID-spec-registry]。对新属性或其他扩展的这种机制的使用是确保两种不同表示能够一起工作的唯一指定机制。
2. 表示可以定义其他的扩展机制，包括那些不需要使用DID规范注册表的机制。这种扩展机制应该支持无损转换到任何其他一致性表示。表示的扩展机制应该定义所有属性和表示语法到数据模型及其类型系统的映射。

注意：未注册的扩展不太可靠
两个特定的实现总是可能同意带外使用一个在DID规范注册表中没有记录的相互理解的扩展或表示；这样的实现和更大的生态系统之间的互操作性将不那么可靠。

核心属性

一个DID与一个DID文档相关联。使用数据模型表示DID文档，可以将其序列化为表示。以下部分定义了DID文档中的属性，包括这些属性是必需的还是可选的。这些属性描述DID订阅者和属性值之间的关系。
下面的表包含了本规范定义的核心属性的有用引用、期望值以及是否需要它们。表中的属性名称与每个属性的规范定义和更详细的描述相链接。

注意：在不同类型的映射中使用的属性名称
属性名称、和可以出现在不同类型的映射中，约束条件可能存在差异。

DID文档属性

属性	必需？	值的约束
id	yes	一个符合3.1 DID语法规则的字符串。
alsoKnownAs	no	一组符合uri规则[RFC3986]的字符串。
controller	no	一个或一组符合3.1 DID语法规则的字符串。
verificationMethod	no	一组符合“验证方法”属性规则的“验证方法”映射。
authentication	no	一组验证方法映射符合验证方法属性中的规则)或符合3.2 DID URL语法中的规则的字符串。
assertionMethod	no
keyAgreement	no
capabilityInvocation	no
capabilityDelegation	no
service	no	一组符合服务属性中的规则的服务端点映射。

验证方法的属性

属性	必需？	值的约束
id	yes	一个符合3.2 DID URL语法规则的字符串。
controller	yes	一个符合3.1 DID语法规则的字符串。
type	yes	一个字符串。
publicKeyJwk	no	一个符合RFC7517的JSON Web Key的映射。有关其他约束，请参阅publicKeyJwk的定义。
publicKeyMultibase	no	符合[MULTIBASE]编码的公钥的字符串。

服务属性

属性	必需？	值的约束
id	yes	符合uri规则[RFC3986]的字符串。
type	yes	一串或一组字符串
serviceEndpoint	yes	一个符合[RFC3986] uri规则的字符串，一个映射，或者一个或多个字符串组成的集合，这些字符串符合[RFC3986]的uri和/或映射规则。

其余小节略。

略

本节定义了DID解析和DID URL解引用的输入和输出。它们的确切实现超出了本规范的范围，但是在[DID-RESOLUTION]中讨论了对实现者的一些考虑。
所有一致性DID解析器必须为至少一个DID方法实现DID解析函数，并且必须能够以至少一个一致表示返回DID文档。

DID解析

如8.2方法操作中所述，使用适用的DID方法的“读取”操作，DID解析函数将一个DID解析为一个DID文档。这个过程是如何完成的细节超出了这个规范的范围，但是所有符合规范的解析器都实现了下面的功能，这些功能具有以下抽象形式：

resolve(did, resolutionOptions) →
   « didResolutionMetadata, didDocument, didDocumentMetadata »

resolveRepresentation(did, resolutionOptions) →
   « didResolutionMetadata, didDocumentStream, didDocumentMetadata »

函数以抽象形式（映射）返回DID文档。函数返回以相应表示格式格式化的DID文档的字节流。

上图表示函数resolve()和resolveRepresentation()。另见：叙述描述。

resolveresolveRepresentation和函数的输入变量如下

DID

这是要解决的问题。这个输入是必需的，并且该值必须与3.1 DID语法中定义的一致。

resolutionOptions

包含7.1.1中定义的属性的元数据结构有解析选项。这个输入是必需的，但是结构可能是空的。

这些函数都返回多个值，并且对如何一起返回这些值没有任何限制。返回值是didResolutionMetadata，didDocument和didDocumentMetadata。返回值是didResolutionMetadata，didDocumentStream和didDocumentMetadata。这些值如下所示：

didResolutionMetadata

一种元数据结构，由与DID解析过程结果相关的值组成，这些值通常在and函数的调用之间变化，因为它表示关于解析过程本身的数据。此结构是必需的，在解析过程中出现错误的情况下，此结构不能为空。这个元数据由7.1.2 DID Resolution metadata定义。如果被调用，此结构必须包含一个属性，该属性包含在。如果解析不成功，此结构必须包含描述错误的属性。

didDocument

如果解析成功，并且调用了函数，则必须是如4所述的DID文档抽象数据模型(映射)。能够使用表示所指定的产生式规则转换为符合DID的文档(表示)的数据模型。解析后的DID文档中的值必须与解析后的DID匹配。如果解析不成功，此值必须为空。

didDocumentStream

如果解析成功，并且函数被调用，则这必须是以一致性表示之一解析的DID文档的字节流。然后，函数的调用者可以将字节流解析为数据模型，然后对数据模型进行验证和处理。如果解析不成功，此值必须是空流。

didDocumentMetadata

如果解析成功，这必须是一个元数据结构。此结构包含属性中包含的关于DID文档的元数据。除非DID文档发生更改，否则此元数据通常不会在and函数调用之间更改，因为它表示关于DID文档的元数据。如果解析不成功，此输出必须是一个空元数据结构。该规范定义的属性在7.1.3 DID文档元数据中。

一致性DID解析器的实现不会以任何方式改变这些函数的签名。DID解析器的实现可能会将and函数映射到一个特定于方法的内部函数，以执行实际的DID解析过程。除了这里指定的和函数外，DID解析器实现还可以实现和公开其他具有不同签名的函数。

此结构中的可能属性及其可能的值在DID规范注册表中注册[DID-spec-registry]。本规范定义了以下公共属性。

接受

调用者对DID文档的首选表示的媒体类型。媒体类型必须用ASCII字符串表示。如果支持并可用这种表示，则DID解析器实现应使用此值来确定返回的表示中包含的表示。此属性对于函数是可选的，不能与函数一起使用。

DID解析元数据

此结构中的可能属性及其可能的值在DID规范注册表中注册[DID-spec-registry]。该规范定义了以下DID解析元数据属性：

contentType

返回的媒体类型。如果解析成功并且调用了函数，则需要此属性。如果调用了函数，则不能出现此属性。此属性的值必须是符合表示的媒体类型的ASCII字符串。函数的调用者在确定如何解析该函数返回的函数并将其处理到数据模型时必须使用此值。

error

解析过程中的错误码。当解析过程中出现错误时，需要此属性。此属性的值必须是单个关键字ASCII字符串。该字段可能的属性值应该在DID规范注册表中注册[DID- spec - registry]。本规范定义了以下常见错误值：

invalidDid

提供给DID解析函数的DID不符合有效语法。(参见3.1 DID语法。)

notFound

DID解析器无法找到由此解析请求产生的DID文档。

representationNotSupported

如果DID方法和/或DID解析器实现不支持通过输入元数据属性请求的表示，则返回此错误代码。

这个结构中的可能属性和它们可能的值应该在DID规范注册表中注册[DID- spec - registry]。本规范定义了以下公共属性。

created

DID文档元数据应该包括一个属性来指示创建操作的时间戳。该属性的值必须是一个格式化为XML Datetime格式的字符串，规范化为UTC 00:00:00，并且没有亚秒级的十进制精度。例如:。created2020-12-20T19:17:47Z

updated

DID文档元数据应该包括一个属性，用于指示所解析的文档版本的最后一次更新操作的时间戳。属性的值必须遵循与属性相同的格式化规则。如果从未对DID文档执行过更新操作，则省略该属性。如果存在某个属性，则当两个时间戳之间的差异小于一秒时，该属性的值可以与该属性的值相同。updatedcreatedupdatedupdatedcreated

deactivated

如果已禁用DID，则DID文档元数据必须包含此属性和布尔值。如果DID未被停用，此属性是可选的，但如果包含，则必须具有布尔值。

nextUpdate

如果解析的文档版本不是文档的最新版本，则DID文档元数据可能包括一个属性。表示下一次更新操作的时间戳。属性的值必须遵循与属性相同的格式化规则。

versionId

DID文档元数据应该包括一个属性，用于指示所解析的文档版本的最后一次更新操作的版本。属性的值必须是ASCII字符串。

nextVersionId

如果解析的文档版本不是文档的最新版本，则DID文档元数据可能包括一个属性。下一次更新操作的版本号。属性的值必须是ASCII字符串。

equivalentId

一个DID方法可以定义逻辑上等价的不同形式的DID。例如，当一个DID在可验证的数据注册中心注册之前使用一个表单，在注册之后使用另一个表单。在这种情况下，作为DID文档的属性，DID方法规范可能需要表示一个或多个在逻辑上与解析后的DID等价的DID。这就是财产的用途。

文档元数据可能包括一个属性。如果该值存在，则该值必须是一个集合，其中每一项都是符合3.1节DID语法规则的字符串。关系是一个语句，即每个值在逻辑上与属性值相等，因此引用相同的DID订阅者。每个DID值必须由与属性值相同的DID方法产生，并且具有相同的形式。(例如，equivalent dequivalentididequivalentididdid:example:abc == did:example:abc)

符合规范的DID方法规范必须保证每个值在逻辑上等价于属性值。

请求方希望保留and属性中的值，以确保与它们包含的任何值的任何后续交互都被正确地作为逻辑等价处理(例如，在数据库中保留所有变体，以便与任何一个交互映射到相同的基础帐户)。

如果请求方不保留and属性中的值，并确保与它们包含的任何值的任何后续交互都被正确地作为逻辑等价处理，则可能会出现负面或意想不到的问题。强烈建议实现者遵守与此元数据属性相关的指令。

canonicalId

该属性与该属性相同，不同之处是:a)它与单个值相关联，而不是与一个集合相关联;b) DID被定义为包含DID文档范围内的DID订阅者的规范ID。

文档元数据可能包括一个属性。如果该值存在，则该值必须是符合3.1节DID语法规则的字符串。关系是一个语句，该值在逻辑上等价于属性值，并且该值由DID方法定义为包含DID文档的范围内的DID订阅者的规范ID。一个值必须由与属性值相同的DID方法产生，且形式相同。(例如,= =)。

canonicalIdcanonicalIdidcanonicalIdcanonicalIdiddid:example:abcdid:example:ABC

符合规范的DID方法规范必须保证值在逻辑上等价于属性值。

请求方希望将该值用作DID订阅者的主ID值，并将所有其他等效值视为次要别名(例如，更新其系统中相应的主引用以反映新的规范ID指令)。

注意：规范等价
canonicalId是相同的等价语句，只是它被限制为一个值，该值被定义为DID文档范围内的DID订阅者的规范值。表示完整的图合并，因为同一个DID文档同时描述了DID和属性DID。equivalentIdequivalentIdcanonicalIdcanonicalIdid
如果解决方不使用该值作为DID订阅者的主ID值，并将所有其他等效值视为次要别名，则可能会出现与用户体验相关的负面或意外问题。强烈建议实现者遵守与此元数据属性相关的指令。

DID URL解引用函数将一个DID URL解引用到一个资源中，其内容取决于DID URL的组件，包括DID方法、特定于方法的标识符、路径、查询和片段。这个过程依赖于DID URL中包含的DID的DID解析。DID URL解引用可能涉及多个步骤(例如，当被解引用的DID URL包含一个片段时)，函数被定义为在所有步骤完成后返回最终资源。如何完成这个过程的细节不在本规范的范围之内。下图描述了上面描述的关系。

上图是概述DID URL解引用参见：叙述描述。

所有符合规范的DID解析器都实现了以下抽象形式的函数：

函数的输入变量如下：dereference

didUrl

conformant将URL作为单个字符串。这是要解引用的DID URL。要解引用一个DID片段，必须使用包含DID片段的完整DID URL。这个输入是必需的。

注意：URL解引用器模式
虽然传递给DID URL解引用器的任何内容都是有效的，但实现者希望引用[DID- resolution]来进一步理解如何解引用DID URL的常见模式。
dereferencingOptions

一种元数据结构，除函数本身外，还包括函数的输入选项。该规范定义的属性在7.2.1 DID URL解引用选项中。这个输入是必需的，但是结构可能是空的。

此函数返回多个值，并且对如何一起返回这些值没有任何限制。和:dereferencedereferencingMetadatacontentStreamcontentMetadata的返回值

dereferencingMetadata

一个元数据结构，由与DID URL解引用过程的结果相关的值组成。此结构是必需的，并且在解引用过程中出现错误的情况下，此结构不能为空。该规范定义的属性在7.2.2 DID URL解引用元数据中。如果解引用不成功，此结构必须包含描述错误的属性。

contentStream

如果函数被调用并且成功，那么它必须包含一个对应于DID URL的资源。它可以是资源，例如以一致性表示之一、验证方法、服务或任何其他资源格式序列化的DID文档，这些资源格式可以通过媒体类型识别并通过解析过程获得。如果解引用不成功，此值必须为空。

contentMetadata

如果解引用成功，这必须是一个元数据结构，但该结构可能为空。此结构包含关于。如果是一个DID文档，这必须是一个diddocument元数据结构，如DID解析中所述。如果解引用不成功，此输出必须是空元数据结构。

符合DID的URL解引用实现不会以任何方式改变这些函数的签名。DID URL解引用实现可能会将函数映射到一个特定于方法的内部函数，以执行实际的DID URL解引用过程。除了这里指定的函数外，DID URL解引用实现可能还会实现并公开其他具有不同签名的函数。

这个结构中的可能属性和它们可能的值应该在DID规范注册表中注册[DID- spec - registry]。这个规范为解引用选项定义了以下通用属性:

accept

调用者喜欢的媒体类型。媒体类型必须用ASCII字符串表示。如果支持并可用这种表示，则DID URL解引用实现应该使用此值来确定返回值中包含的表示的值。

此结构中的可能属性及其可能的值在DID规范注册表中注册[DID- spec - registry]。本规范定义了以下公共属性。

contentType

如果解引用成功，则应使用此属性表示返回的媒体类型。媒体类型值必须用ASCII字符串表示。

error

来自解引用进程的错误代码。当解引用过程中出现错误时，需要此属性。此属性的值必须是表示为ASCII字符串的单个关键字。该字段可能的属性值应该在DID规范注册表中注册[DID- spec - registry]。本规范定义了以下常见错误值:

invalidDidUrl

提供给DID URL解引用函数的DID URL不符合有效语法。(参见3.2 DID URL语法。)

notFound

DID URL解引用器无法找到此解引用请求的结果。

在DID解析、DID URL解引用和其他与DID相关的过程中，经常涉及到输入和输出元数据。用于通信此元数据的结构必须是属性的映射。每个属性名必须是字符串。每个属性值必须是字符串、map、list、set、boolean或null。任何复杂数据结构(如映射和列表)中的值也必须是这些数据类型之一。在DID规范注册表[DID- spec - registry]中注册的所有元数据属性定义必须定义值类型，包括该值的任何附加格式或限制(例如，格式化为日期或十进制整数的字符串)。建议属性定义使用字符串作为值。根据[INFRA]规范中的JSON序列化规则，整个元数据结构必须是可序列化的。实现可以将元数据结构序列化为其他数据格式。
所有使用元数据结构作为输入或输出的函数实现都能够以确定的方式完全表示这里描述的所有数据类型。由于使用元数据结构的输入和输出是根据数据类型而不是它们的序列化定义的，因此表示方法是函数实现的内部方法，超出了本规范的范围。
下面的示例演示了一个json编码的元数据结构，它可以作为解析输入元数据使用。

方法

DID方法定义了实现者如何实现该规范所描述的特性。DID方法通常与特定的可验证数据注册表相关联。在它们自己的规范中定义了新的DID方法，以支持同一DID方法的不同实现之间的互操作性。

从概念上讲，这个规范和一个DID方法规范之间的关系类似于IETF通用URI规范[RFC3986]和一个特定URI方案[IANA-URI-SCHEMES]之间的关系，例如方案[RFC7230]。除了定义特定的DID方案外，一个DID方法规范还定义了使用特定类型的可验证数据注册表创建、解析、更新和停用DIDs和DID文档的机制。它还记录了与DIDs以及安全和隐私相关的所有实现注意事项。
本节指定编写DID方法规范的需求。

方法的语法

定义特定于方法的DID语法时，对所有DID方法规范的要求如下：

1. 一个DID方法规范必须精确定义一个特定于方法的DID方案，该方案由3.1 DID语法中的规则指定的一个方法名来标识。
2. DID方法规范必须指定如何生成DID的组件。
3. DID方法规范必须定义方法特定id值的敏感性和规范化
4. 该值在一个DID方法中必须是唯一的。值本身可能是全局唯一的。
5. 由DID方法生成的任何DID必须是全局惟一的。
6. 为了减少冲突的机会，一个DID方法规范应该在DID规范注册表中注册[DID- spec - registry]。
7. 一个DID方法可以定义多种格式。
8. 格式可以包含冒号。冒号的使用必须在语法上符合ABNF规则。
9. 一个DID方法规范可以为DID路径指定比Path中的一般规则更有限制性的ABNF规则。
10. 一个DID方法规范可以为DID查询指定比本节中一般规则更严格的ABNF规则。
11. 一个DID方法规范可以为DID片段指定比本节中一般规则更严格的ABNF规则。
    

注意：method-specific-id中有冒号
中冒号的含义完全与方法相关。冒号可以被DID方法用于建立层次划分的名称空间，用于标识可验证数据注册表的特定实例或部分，或用于其他目的。建议实现者避免假定与冒号相关的任何意义或行为通常适用于所有DID方法。

定义方法操作时，对所有DID方法规范的要求如下：

1. DID方法规范必须定义如何执行授权以执行所有操作，包括任何必要的加密进程。
2. 一个DID方法规范必须指定一个DID管理者如何创建一个DID及其关联的DID文档。
3. DID方法规范必须指定DID解析器如何使用DID解析器解析DID文档，包括DID解析器如何验证响应的真实性。
4. 一个DID方法规范必须指定什么构成了对一个DID文档的更新，以及一个DID管理者如何更新一个DID文档或者声明更新是不可能的。
5. DID方法规范必须指定DID管理者如何停用DID，或者说明不可能停用DID。

执行授权以执行操作的一方的权限特定于一个DID方法。例如，一个DID方法可能

• 好好利用这个财产。
• 使用下面列出的验证方法。
• 使用DID文档中的其他构造，例如通过验证关系指定的验证方法。
• 不使用这个决定的DID文档，而是依赖于带外机制。

在编写安全考虑部分时，对所有DID方法规范的要求如下:

1. 一个DID方法规范必须遵循RFC3552中提供的所有指南和规范语言：为DID方法规范中定义的DID操作编写安全考虑部分。
2. 安全考虑部分必须记录对DID方法规范中定义的DID操作的下列攻击形式：窃听、重放、消息插入、删除、修改、拒绝服务、放大和中间人。还应记录其他已知的攻击形式。
3. 安全考虑部分必须讨论剩余风险，例如在部署威胁缓解后，相关协议、不正确的实现或密码遭到破坏的风险。
4. 安全考虑部分必须为8.2节方法操作所需的所有操作提供完整性保护和更新身份验证。
5. 如果涉及身份验证，特别是用户-主机身份验证，则必须清楚地记录身份验证方法的安全特征。
6. 安全考虑部分必须讨论证明DIDs是唯一分配的策略机制。
7. 必须讨论特定于方法的端点身份验证。当DID方法使用具有不同网络拓扑的DLT（有时作为轻节点或瘦客户端实现来减少所需的计算资源）时，必须讨论可用于DID方法实现的拓扑的安全性假设。
8. 如果协议包含密码保护机制，DID方法规范必须清楚地指出哪些部分的数据受到保护，受到什么保护，并且它应该指出密码保护可能受到的攻击类型。一些示例仅包括完整性、机密性和端点身份验证。
9. 要保密的数据（密钥材料、随机种子等）应明确标记。
10. 如果适用的话，DID方法规范应该解释和指定在DID文档上签名的实现。
11. 在哪些方法使用了对等计算资源（如所有已知的DLT）的情况下，应该讨论这些资源的预期负担与拒绝服务的关系。
12. 如5.4服务中所述，引入新的认证服务类型的DID方法应该考虑所支持的认证协议的安全需求。

隐私需求

当编写隐私考虑部分时，对所有DID方法规范的要求是：

1. DID方法规范的隐私考虑部分必须讨论[RFC6973]第5节中任何可以以特定方法的方式应用的小节。要考虑的子部分是:监视、存储数据泄露、非请求流量、错误归因、相关性、识别、二次使用、披露和排除。

本节是非规范性的。
本节包含使用分散式标识符的人在将该技术部署到生产环境之前应该考虑的各种安全考虑。DIDs被设计为在许多IETF标准和文档[RFC3552]中使用的威胁模型下操作。本节详细阐述了[RFC3552]中的一些注意事项，以及DID架构特有的其他注意事项。

DID规范注册表[DID- spec - registry]包含DID方法名称及其对应的DID方法规范的信息列表。实现者需要记住，没有中央机构来强制指定哪一个DID方法规范要与任何特定的DID方法名称一起使用。如果对一个特定的DID解析器是否正确地实现了一个DID方法有疑问，可以使用DID规范注册表来查找已注册的规范，并就使用哪个DID解析器实现做出明智的决定。

将数字世界或物理世界中的实体与DID、DID文档或密码材料绑定需要使用本规范所设想的安全协议。下面几节将描述一些可能的场景，以及其中的实体如何证明对DID或DID文档的控制，以便进行身份验证或授权。

证明对DID和/或DID文件的控制

在可验证的数据注册表中进行更新或使用远程系统进行身份验证时，证明对DID和/或DID文档的控制是有用的。密码学数字签名和可验证时间戳使与DID文档相关的某些安全协议能够得到密码学验证。出于这些目的，本规范在5.3.1身份验证和5.3.4功能调用中定义了有用的验证关系。与验证方法相关联的秘密密码材料可用于生成密码数字签名，作为认证或授权安全协议的一部分。

与物理身份绑定

DID和DID文件本身不包含任何个人数据，强烈建议非公共实体不要在DID文件中发布个人数据。
以可证明的方式表示DID与个人或组织的物理身份的绑定可能是有用的，这种绑定可以由可信的权威机构（如政府）断言。为此，本规范提供了5.3.2断言验证关系。该功能可以支持隐私的交互，并且可以在一个或多个司法管辖区下被认为是合法的；建立这样的绑定必须仔细权衡隐私方面的考虑（见10.隐私方面的考虑）。
将一个DID绑定到物理世界中的某物（例如一个人或一个组织）的过程，例如，通过使用与DID相同订阅者的可验证凭证是本规范所考虑的，并在可验证凭据数据模型[VC-DATA-MODEL]中进一步定义的。

身份验证服务端点

如果一个DID文档发布了一个用于认证或授权DID主体的服务（见5.4服务节），那么服务端点提供者、主体或请求方就有责任遵守在该服务端点支持的认证协议的要求。

如果以下情况，则支持DIDs和DID文档更新的不可抵赖性：

• 可验证数据注册表支持可验证的时间戳。有关在DID解析过程中可以使用的有用时间戳的进一步信息，请参见7.1.3 DID文档元数据。
• 订阅者是监测未经授权的更新，如9.5 DID文档变更通知所述。
• 根据DID方法的授权机制，主体有足够的机会恢复恶意更新。

通知DID文档更改

防止对DID文档进行未经授权的更改的一种方法是，当发生更改时，监控并主动通知DID主体。这类似于通过向文件中的电子邮件地址发送密码重置通知来帮助防止传统用户名/密码帐户的帐户接管。
在DID的情况下，没有中介注册商或帐户提供者来生成这样的通知。但是，如果注册DID的可验证数据注册中心直接支持更改通知，则可以向DID管理者提供订阅服务。通知可以直接发送到现有DID中列出的相关服务端点。
如果DID管理者选择依赖第三方监控服务（而不是可验证数据注册表本身），这将引入另一个攻击向量。

密钥和签名过期

在去中心化身份的体系结构中，可能没有中心化的机构来强制执行密码材料或密码数字签名过期策略。因此，使用诸如DID解析器和验证库等支持软件，请求方可以验证密码材料在使用时是否未过期。请求方除了在验证过程中使用输入外，还可能使用自己的过期策略。例如，一些请求方可能接受过去5分钟的身份验证，而其他访问高精度时间源的请求方可能要求在最近500毫秒内对身份验证进行时间戳。
有一些请求方有合法的需求来延长已经过期的密码材料的使用，例如验证遗留密码的数字签名。在这些场景中，请求方可能指示其验证软件忽略密码密钥材料过期，或者确定密码密钥材料在使用时是否已经过期。

验证方***换

轮换是一种管理过程，一旦新的验证方法被添加到DID文档中，与现有验证方法相关的秘密密码材料将被停用或销毁。进一步，管理者使用旧的秘密密码材料生成的任何新证明现在都可以使用新的密码材料生成，并可以使用新的验证方法进行验证。
轮换是防止验证方法被攻击者窃取的一种有效机制，因为管理者对一个验证方法的频繁轮换会降低单个验证方法被窃取后对攻击者的价值。在轮换之后立即执行撤销对于管理者指定用于短期验证的验证方法非常有用，例如那些涉及加密消息和身份验证的验证方法。
在考虑使用验证方法的轮换时，下列考虑可能有用：

• 验证方法的轮换是一种主动的安全措施。
• 通常认为，最好的做法是定期进行验证方法的轮换。
• 安全性越高的环境，验证方法的轮换越频繁。
• 验证方法的轮换只显示为对DID文档的当前版本或最新版本的更改。
• 当一个验证方法已经活跃了很长一段时间，或用于许多操作时，管理者可能希望执行轮换。
• 频繁地轮换验证方法可能会使被迫不断更新或刷新关联凭据的参与者感到沮丧。
• 依赖于DID文档最新版本中不存在的验证方法的证明或签名不受轮换影响。在这些情况下，验证软件可能需要额外的信息，例如期望某一特定的验证方法何时有效，以及访问包含历史记录的可验证数据注册表，以确定证明或签名的有效性。此选项可能在所有DID方法中都不可用。
• 关于DID方法操作的一节指定了一个DID方法规范所支持的DID操作，包括用于执行验证方法的轮换的更新。
• 当管理者添加一个新的验证方法，意味着在一段时间后替换现有的验证方法时，就会执行轮换。
• 并不是所有的DID方法都支持验证方法的轮换。

验证方法撤销

撤销是一种管理过程，它使与现有验证方法相关的秘密密码材料失效，从而使其不再是创建新数字签名证明的有效形式。
撤销是应对验证方法妥协的一种有效机制。在轮换之后立即执行撤销对于管理者指定用于短期验证的验证方法非常有用，例如那些涉及加密消息和身份验证的验证方法。
与验证方法相关联的秘密泄露允许攻击者根据DID文档中管理者表示的验证关系使用它们，例如用于身份验证。从注册验证方法到撤销验证方法，攻击者对秘密的使用可能与合法管理者的使用没有区别。
在考虑使用撤销核查方法时，下列考虑可能有用：

• 验证方法的撤销是一种被动的安全措施。
• 支持密钥撤销被认为是一种最佳实践。
• 期望管理者立即撤销已知被破坏的任何验证方法。
• 验证方法的撤销只能体现在对一个DID文档的最新版本的更改中；它不能追溯调整以前的版本。
• 如5.2.1验证材料所述，对所有支持撤销的DID方法来说，缺少验证方法是唯一的撤销形式。
• 如果控制人或受信任代表控制人行事的各方不再能够独家访问验证方法，则预计将立即撤销该验证方法，以降低伪装、***和欺诈等妥协的风险。
• 撤销被理解为一种管理者，表示在被撤销验证方法被撤销后创建的与该验证方法相关的证明或签名应被视为无效。它还可能意味着现有的证明或签名可能是由攻击者创建的，但情况不一定如此。但是，验证者仍然可以自行选择接受或拒绝任何此类证明或签名。
• 关于DID方法操作的一节指定了一个DID方法规范所支持的DID操作，包括update和deactivate，这些操作可用于从DID文档中删除验证方法。
• 并不是所有的DID方法都支持验证方法撤销。
• 即使在DID文档中存在验证方法，也可以使用其他信息（如公钥撤销证书或外部允许或拒绝列表）来确定验证方法是否已被撤销。
• 当验证方法被公开撤销时，任何依赖于被泄露的验证方法的软件（例如个人的操作系统、杀毒软件或端点保护软件）的日常操作都可能受到影响。

撤销语义

尽管验证者可能选择不接受来自撤销验证方法的证明或签名，但要知道是否使用了撤销验证方法进行了验证，这比看起来更棘手。有些DID方法提供了在某个时间点或特定版本的DID文档中回顾DID状态的能力。当这样的特性与一种可靠的方法相结合，以确定当一个密码学可验证的语句被提出时存在的时间或DID版本，那么撤销不会撤销该语句。这可以作为使用DIDs作出具有约束力的承诺的基础；例如，签署抵押贷款。
如果满足这些条件，撤销不具有追溯效力；它只会使以后对该方法的使用无效。
但是，为了保证这种语义的安全性，需要应用第二个条件——能够知道在做出断言时DID文档的状态是什么。如果没有这种保证，有人可能会发现一个被撤销的密钥，并使用它对过去的模拟日期进行密码学验证。
有些DID方法只允许检索DID的当前状态。当这是真的，或者当一个在密码学可验证语句时的DID状态不能可靠地确定时，那么唯一安全的过程是不允许考虑任何关于时间的DID状态，除了当前时刻。采用这种方法的DID生态系统本质上提供了作为临时令牌的密码学可验证语句，这些令牌可以在任何时候被DID管理者失效。
不可信系统中的撤销

在不可信系统中，所有的信任都来自密码学上可证明的断言，更具体地说，在确定系统中的信任时没有考虑密码学系统之外的元数据。为了验证验证方法在不可信系统中被撤销的证明签名，DID方法需要支持or元数据属性中的一个或两个，以及DID元数据属性中的两个。当且仅当以下条件满足时，验证者才能验证签名或撤销密钥的证明

• 证明或签名包括在创建签名或证明时使用的DID文件的。
• 验证人可以确定签名或证明产生的时间点；例如，它被锚定在区块链上。
• 对于解析的DID文档元数据，时间戳在签名或证明的时间点之前，时间戳在之后。

在愿意接受构成密码输入的元数据以外的其他元数据的系统中，可能会实现类似的信任——但总是基于相同的基础，即仔细判断签名事件发生时DID文档的内容是否包含预期的内容。

恢复是一种反应式安全措施，管理者在失去执行DID操作的能力(例如由于设备的丢失)后，能够重新获得执行DID操作的能力。
在考虑使用DID recovery时，下列考虑可能有用：

• 在不频繁但定期的基础上主动进行恢复，可以帮助确保控制没有失去。
• 最佳实践是永远不要将与恢复相关的密码材料用于任何其他目的。
• 恢复通常与验证方法的轮换和验证方法撤销同时进行。
• 当受信任的代表它们执行操作的管理者或服务不再具有排他性能力来执行如8.2方法操作所述的DID操作时，建议进行恢复。
• DID方法规范可以选择启用受信任方的quorum支持，以促进恢复。在5.1.2 DID Controller中建议了一些这样做的设施。
• 并不是所有的DID方法规范都将从使用其他DID方法注册的DIDs中识别控件，它们可能会将第三方控件限制为使用相同方法的DIDs。
• 在DID方法规范中的访问控制和恢复还可以包括一个时间锁特性，通过维护用于恢复的第二条控制轨道来防止密钥泄露。
• 目前没有适用于所有DID方法的通用恢复机制。

人类友好身份的作用

DIDs实现了全局惟一性，而不需要中央注册机构。这是以人类的记忆性为代价的。能够生成全局无歧义身份的算法将会产生没有人类意义的随机字符串。这种取舍通常被称为Zooko三角。
在一些用例中，当从一个对人类友好的标识符开始时，需要发现一个DID。例如，自然语言名称、域名或DID管理者的常规地址，例如移动电话号码、电子邮件地址、社交媒体用户名或博客URL。然而，将人类友好的标识符映射到DIDs以及以一种可验证和可信的方式进行映射的问题不在本规范的范围之内。
这个问题的解决方案在引用此规范的单独规范中定义，例如[DNS-DID]。强烈建议这些规范仔细考虑:

• 大量基于欺骗用户对目标实体真实友好标识符的安全攻击。
• 使用具有内在相关性的人类友好标识符的隐私后果，特别是如果它们是全局唯一的。

DIDs作为增强的URNs

如果一个DID管理者需要，那么一个DID或一个DID URL能够充当持久的、与位置无关的资源标识符。这些类型的标识符被分类为统一资源名(urn)，并在[RFC8141]中定义。DIDs是一种增强形式的URN，它为数字资源提供了密码学安全的、与位置无关的标识符，同时还提供了支持检索的元数据。由于DID文档和DID本身之间的间接关系，DID管理者可以调整资源的实际位置-甚至直接提供资源-而不需要调整DID。这种类型的DIDs可以确定地验证所检索的资源实际上就是所标识的资源。
如果一个DID管理者打算为此使用一个DID，建议遵循[RFC8141]中的安全考虑。特别是：

• 期望DID管理者选择一个支持管理者持久化需求的DID方法。去中心化特征Rubric [DID- Rubric]是一个可用的工具，可以帮助实现者决定最合适的DID方法。
• 预期DID管理者将发布其操作策略，以便请求方可以确定他们可以在多大程度上依赖于由该DID管理者控制的DID持久性。在没有这种策略的情况下，请求方不需要假设一个DID是否是同一个DID主体的持久性标识符。

不变性

许多网络安全滥用依赖于利用现实与理性、诚信行为者假设之间的差距。DID文档的不变性可以提供一些安全方面的好处。个体DID方法应该考虑那些会消除它们不需要的行为或语义的约束。在提供相同特征集的同时，锁定的DID方法越多，它被恶意行为者操纵的可能性就越小。
例如，假设对DID文档的一次编辑可以更改文档的根属性以外的任何内容。但是，服务在定义后是否真的需要更改它呢？或者让一个键改变它的值？或者当一个对象的某些基本属性发生变化时，需要一个新的会更好吗？恶意收购一个网站的目的通常是使网站保留其主机名身份，但在下面微妙地改变。如果该网站的某些属性，如与其IP地址相关的ASN，被规范要求是不可变的，异常检测将更容易，而攻击将更难实施，成本也更高。
对于绑定到全局真值源的DID方法，总是可以直接、即时地查找DID文档的最新版本。然而，缓存层可能最终会位于DID解析器和真相来源之间。如果是这样，相信DID文档中对象的属性具有给定的状态，而实际上它们略有不同，可能会招致攻击。如果一些查找是完整的DID文档，而另一些查找是假定有更大上下文的部分数据，则尤其如此。

加密数据在DID文档

众所周知，由于密码学和计算能力的进步，加密算法是会失败的。建议实现者假设放置在DID文档中的任何加密数据最终可能以明文的形式提供给可访问加密数据的同一受众。如果DID文档是公开的，这一点尤其重要。
从长远来看，加密DID文档的全部或部分并不是保护数据的适当方法。同样，在DID文档中放置加密的数据也不是保护个人数据的适当方法。
考虑到上面的注意事项，如果在DID文档中包含加密的数据，则建议实现者不要关联任何可用于推断加密数据和关联方之间关系的相关信息。相关信息的例子包括接收方的公钥、已知在接收方控制下的数字资产的标识符或接收方的人类可读描述。

等价属性

由于and属性是由DID方法本身生成的，因此适用于DID文档域中已解析的DID的安全性和准确性保证也适用于这些属性。不能保证该属性是准确的等价语句，在不执行超出DID文档解析范围的验证步骤之前，不应依赖该属性。
而且属性表示与同一个DID方法产生的单个DID的变体的等价断言，并且在请求方信任DID方法以及符合条件的生产者和解析器的程度上是可信的。
该属性允许对不受相同DID方法治理的uri进行等价断言，如果不在治理的DID方法之外执行验证步骤，则不能信任这些uri。参见5.1.3中的附加指导，也称为。
与DID文档中任何其他与安全相关的属性一样，依赖于DID文档中任何等价语句的参与者应该防止在执行了适当的验证之后，这些属性的值被攻击者替换。在执行了验证之后，对存储在内存或磁盘中的DID文档的任何写访问都是一个攻击向量，它可能会绕过验证，除非重新验证DID文档。

内容完整性保护

包含到外部机器可读内容（如图像、web页面或模式）的链接的DID文档很容易被篡改。强烈建议使用hashlink [hashlink]等解决方案来保护外部链接的完整性。如果不能保护外部链接的完整性，并且DID文档的完整性依赖于外部链接，则应避免外部链接。
外部链接中影响DID文档本身完整性的一个例子是JSON-LD上下文[JSON-LD11]。为了防止妥协，建议DID文档使用者缓存JSON-LD上下文的本地静态副本和/或根据已知与外部JSON-LD上下文的安全版本相关联的密码散列验证外部上下文的完整性。

持久性

DIDs被设计为持久化，这样管理者就不需要依赖单个可信第三方或管理员来维护其标识符。在理想情况下，任何管理员都不能剥夺管理者的控制权，也不能阻止将其标识符用于任何特定目的，如身份验证、授权和证明。未经控制人同意，任何第三方不得代表控制人删除实体标识符或使其不可操作。
然而，值得注意的是，在所有实现密码控制证明的DID方法中，控制证明手段总是可以通过传输秘密密码材料转移到另一方。因此，依赖于标识符持久性的系统必须定期进行检查，以确保标识符实际上仍然处于预期方的控制之下。
遗憾的是，仅从密码学无法确定与给定验证方法相关的秘密密码材料是否已被泄露。很可能预期的管理者仍然可以访问秘密密码材料-因此可以执行控制证明作为验证过程的一部分-而与此同时，不良行为者也可以访问这些密钥或其副本。
因此，密码控制证明预计只被用作评估高风险场景所需的身份保证级别的一个因素。基于did的身份验证比用户名和密码提供了更大的保证，这是因为它能够确定对密码秘密的控制，而无需在系统之间传输该秘密。然而，它也不是绝对正确的。涉及敏感、高价值或生命攸关操作的场景预计将酌情使用其他因素。
除了由不同的管理者使用可能产生的歧义之外，一般来说，不可能保证给定的DID在任何给定的时间点被用于指代相同的订阅者。从技术上讲，管理者可以为不同的订阅者重用DID，更微妙的是，订阅者的精确定义可能会随着时间的推移而变化或被误解。
例如，考虑一个用于独资企业的DID，它接收用于金融交易的各种凭证。对于管理者，该标识符引用业务。随着业务的发展，它最终被注册为有限责任公司。管理者继续使用相同的DID，因为对它们来说，DID指的是业务。然而，对于国家、税务机关和地方市政当局来说，它不再是指同一个实体。意义上的微妙变化对信贷提供者或供应商是否重要，必须由他们来决定。在许多情况下，只要账单被支付，收款可以被强制执行，这种转变是微不足道的。
由于这些潜在的歧义，DIDs被认为是上下文上的有效而不是绝对的。它们的持久性并不意味着它们指向完全相同的主体，也不意味着它们处于相同的管理者的控制之下。相反，我们需要理解创建DID的上下文，如何使用它，并考虑其意义上可能的变化，并采用程序和策略来解决潜在的和不可避免的语义漂移。

水平的保证

出于遵从性的原因，经常需要关于认证事件的安全上下文的额外信息，特别是在金融和公共部门等受监管的领域。此信息通常称为保证级别（LOA）。示例包括秘密密码材料的保护、身份证明过程和验证者的形式因素。
支付服务（PSD 2）和eIDAS将这种需求引入到安全上下文中。保证框架的级别由法规和标准分类和定义，如eIDAS, NIST 800-63-3和ISO/IEC 29115:2013，包括它们对安全上下文的要求，并就如何实现它们提出建议。这可能包括FIDO2/WebAuthn可以满足需求的强用户身份验证。
一些受管制的场景要求实现特定级别的保证。由于在某些情况下可能会使用和等验证关系，因此可能需要表达有关应用的安全上下文的信息，并将其提供给验证者。是否以及如何在DID文档数据模型中编码这些信息超出了本规范的范围。感兴趣的读者可能会注意到，1）信息可以使用可验证的凭证[VC-DATA-MODEL]传输，2）DID文档数据模型可以被扩展，以纳入4.1可扩展性中描述的信息，其中10.隐私方面的考虑也适用于此类扩展。

隐私方面的考虑

本节是非规范性的。
由于DIDs和DID文档被设计为由DID管理者直接管理，因此将设计隐私原则应用于去中心化身份体系结构的所有方面是至关重要的。这七个原则在本规范的开发过程中都得到了应用。本规范中使用的设计不假设存在注册商、托管公司或其他中间服务提供商来推荐或应用额外的隐私保护措施。本规范中的隐私是预防性的，而不是补救性的，并且是嵌入的默认值。下面几节讨论了实施者在构建利用分散化标识符的系统时可能会发现有用的隐私注意事项。

保护个人资料的隐私

如果一个DID方法规范是为一个面向公众的可验证数据注册中心编写的，在这个注册中心中，相应的DIDs和DID文档可能是公开的，那么至关重要的是那些DID文档不包含个人数据。个人数据可以通过其他方式进行传输，例如1)可验证的凭证[VC-DATA-MODEL]，或2)DID主体或DID管理者控制下的服务端点。
预计将对服务端点中URL的使用进行尽职调查，以防止个人数据泄露或服务端点URL内的相关性。例如，包含用户名的URL包含在DID文档中是危险的，因为用户名很可能是有意义的，在某种程度上可能泄露DID主体不同意共享的信息。在该规范建议的隐私体系结构中，个人数据可以在一个私有的、对等的基础上交换，使用在DID文档中通过验证方法识别和保护的通信通道。这也使DID主体和请求方能够实现GDPR被遗忘的权利，因为没有个人数据被写入不可变的分布式账本。

做相关的风险

与任何类型的全局无歧义标识符一样，DIDs可以用于相关性。DID管理者可以通过使用对每个关系唯一的两两DID来降低这种隐私风险;实际上，每个DID都充当了一个笔名。当明确需要相关性时，成对数据确实只需要与多于一方共享。如果成对的DID是默认的，那么唯一需要公开发布一个DID，或与多方共享它的是当DID管理者(s)和/或DID主体明确地希望公开识别和相关性。

是否记录了相关风险

如果两两DID文档中的数据之间存在相关性，则两两DID文档的反相关保护机制容易失效。例如，在多个DID文档中使用相同的验证方法或定制服务端点可以提供与使用相同DID一样多的相关性信息。因此，成对DID的DID文档也需要使用成对唯一的信息，例如确保验证方法对于成对关系是唯一的。
对于成对的DID，在DID文档中使用成对惟一的服务端点似乎是很自然的。然而，唯一的端点允许两个DIDs之间的所有流量被完美地隔离到唯一的桶中，在这些桶中很容易进行时间相关性和类似的分析。因此，一个更好的端点隐私策略可能是在由许多不同主体控制的大量DIDs之间共享一个端点（见10.5群体隐私）。

DID订阅者分类

向DID文档中添加属性是危险的，这些属性可以显式地或通过推断来指示DID订阅者是什么类型或性质，特别是如果DID订阅者是一个人的话。
这些属性不仅可能导致个人数据（见10.1保持个人数据隐私）或相关数据（见10.2是否相关风险和10.3是否文档相关风险）出现在DID文档中，而且它们可以用于对特定的DID进行分组，以使它们包含在某些操作或功能中或排除在某些操作或功能之外。
在DID文档中包含类型信息可能会导致个人隐私的伤害，即使是对于非人实体的DID主体，如物联网设备。围绕着DID管理者的这些信息的聚合可以作为数字指纹的一种形式，这是最好避免的。
为了将这些风险降到最低，DID文档中的所有属性都应该用于表示与使用DID相关的密码材料、端点或验证方法。

群体隐私

当一个实验对象与群体中的其他对象无法区分时，隐私是可用的。当与另一方私下接触的行为本身就是一面可识别的旗帜时，隐私就大大减少了。
DIDs和DID方法需要努力改善群体隐私，特别是对那些最需要它的人。选择默认保留匿名性和伪匿名性的技术和人机接口。为了减少数字指纹，在请求方实现之间共享公共设置，在有线协议中尽量减少协商选项，使用加密传输层，并将消息垫到标准长度。

服务的隐私

管理者在DID文档中有选择地表示至少一个服务端点的能力增加了它们的控制和代理能力。由于相关性（如跨端点描述），或者由于服务不受授权机制保护，或者这两种原因，DID文档中的每个额外端点都增加了隐私风险。
DID文档通常是公开的，由于它们是标准化的，因此将根据它们非常基于标准的性质有效地存储和索引。如果将文档发布到不可变的可验证数据注册中心，这种风险会更大。访问由一个DID引用的DID文档的历史记录代表了一种通过使用标准而变得更有效的流量分析形式。
在一个DID文档中使用多个服务端点所导致的额外隐私风险程度很难估计。隐私损害通常是意想不到的后果。DIDs可以引用文档、服务、模式和其他可能与个人、家庭、俱乐部和雇主相关的东西——它们的服务端点之间的相关性可以成为强大的监视和推断工具。这种潜在危害的一个例子可以看到，当多个共同的国家级顶级域名，例如可能被用来以更大的概率推断DID订阅者的大致位置。
维护群隐私
各种可能的端点使得维护群体隐私特别具有挑战性，在这些端点中，DID订阅者的信息不会泄露（见10.5群体隐私）。
首先，由于服务端点可能被指定为uri，因此由于服务的体系结构，它们可能无意中泄漏个人信息。例如，的服务端点正在将术语泄漏给每个可以访问DID文档的人。当链接到遗留系统时，这是一个不可避免的风险，在这种情况下应该小心。该规范鼓励新的、感知DID的端点只使用DID本身来进行任何必要的标识。例如，如果要包括一个服务描述，就不会造成损害，因为它已经在DID文档中暴露了；它没有泄露额外的信息。http://example.com/MyFirstNameMyFirstNamehttp://example.com/did%3Aexample%3Aabc123did:example:abc123
其次，因为一个DID文档可以列出多个服务端点，所以可以不可逆地关联在任何其他上下文中没有关联的服务。这种相关性本身可能会导致隐私损害，因为它会泄露关于DID主体的信息，即使所使用的uri不包含任何敏感信息。
第三，由于某些类型的DID订阅者可能或多或少地会列出特定的端点，因此给定服务的列表本身可能泄漏可用于推断关于DID订阅者的信息。例如，用于汽车的DID可能包括指向机动车管理局公共所有权记录的指针，而用于个人的DID则不包括该信息。
群体隐私的目标是确保特定DID被试的性质被整体人群所掩盖。为了最大化群体隐私，实施者需要依赖于且仅依赖于一个服务端点，该端点提供管理者愿意依赖的代理或中介服务，以保护这种关联并盲化对最终服务的请求。
服务端点的替代品
考虑到上一节中的问题，我们敦促实现者考虑以下任一服务端点方法:

• 协商端点-协商双方同意的通信信道的服务，最好使用私有设置交集。协商的输出是一个通信通道和访问它可能需要的任何凭证。
• Tor端点（Tor***）——为到达服务端点提供一个尊重隐私的地址。任何可以在线提供的服务都可以通过TOR提供，以增加隐私。
• 中介端点——中介为多方提供通用端点，代表各方接收加密消息，并将其转发给预期的接收方。这就避免了每个订阅者都需要一个特定的终点，这可能会产生关联风险。这种方法也称为代理。
• 机密存储——专有的或机密的个人信息可能需要从可验证的数据注册表中保留下来，以提供额外的隐私和/或安全保证，特别是对于那些将DID文档发布在公共分类账上的DID方法。指向外部资源服务提供了一种授权检查和删除的方法。
• 多态代理——代理端点可以充当任意数量的服务，这取决于它的调用方式。例如，根据重新路由的机制，可以将同一个URL用于协商器和中介函数。

这些服务端点类型仍然是创新和探索的领域。

下图显示了数据模型，核心属性，方法和解析之间的关系。

上图，详细概述了DID的体系结构和基本组件之间的关系。

创建一个DID

创建一个DID是一个由每个DID方法定义的进程。一些DID方法，例如，是纯生成的，这样，一个DID和一个DID文档是通过转换一个单一的密码材料到一致性表示生成的。其他DID方法可能需要使用可验证的数据注册表，其中DID和DID文档只有在注册完成时才被第三方承认存在，正如各自的DID方法所定义的那样。其他进程可能由相应的DID方法定义。

确定DID主体

一个DID是一个特定类型的URI（统一资源标识符），所以一个DID可以引用任何资源。每[RFC3986]:

资源可以是数字的或实体的，抽象的或具体的。任何可以分配URI的资源都可以分配DID。被DID引用的资源是DID订阅者。
DID管理者确定DID订阅者。通过查看DID本身来确定DID对象是不可能的，因为DID通常只对机器有意义，而对人没有意义。一个DID不太可能包含关于DID订阅者的任何信息，因此关于DID订阅者的进一步信息只有通过将DID解析到DID文档、获得关于DID的可验证凭证或通过DID的其他描述才能发现。
虽然检索到的DID文档中的属性值必须始终匹配正在解析的DID，但DID所引用的实际资源是否会随时间而变化取决于DID方法。例如，允许更改DID的DID方法可用于为特定角色（例如公司的CEO）的当前占用者生成DID，其中实际占用该角色的人可以根据DID的解析时间不同而有所不同。

参考DID文档

DID引用DID订阅者并解析到DID文档（通过遵循DID方法指定的协议）。DID文档不是一个独立于DID订阅者的资源，也没有一个独立于DID的URI。相反，DID文档是DID解析的产物，由DID管理者控制，目的是描述DID订阅者。
下面的图模型说明了这种区别。

DID是一个由DID管理者分配的标识符，用于引用DID订阅者并解析到描述DID订阅者的DID文档。DID文档是DID解析的产物，而不是与DID订阅者不同的独立资源。另见：叙述描述。

DID文档中的声明

一个DID文档中的每个属性都是一个由DID管理者描述的语句：

• 定义DID订阅者标识符的字符串（例如and属性）
• 如何与DID订阅者交互（例如，and属性)。
• 如何解释DID文档的特定表示（例如，JSON-LD表示的属性）。

DID文档中唯一必需的属性是，这是唯一保证出现在DID文档中的语句。图8用DID和DID订阅者之间的直接链接说明了该语句。

发现更多关于DID订阅者的信息

用于发现关于DID订阅者的更多信息的选项取决于DID文档中出现的属性。如果存在该属性，则可以从服务端点请求更多信息。例如，通过查询支持描述DID订阅者的一个或多个声明（属性）的可验证凭据的服务端点。
另一种选择是，如果该属性存在于DID文档中，则使用该属性。DID管理者可以使用它来提供引用相同DID订阅者的其他uri（包括其他DIDs）的列表。解析或解引用这些uri可能会产生如下图所示的DID订阅者的其他描述或表示。

一个DID文档可以使用alsoKnownAs属性来断言另一个URI（包括，但不一定是另一个DID）引用相同的DID订阅者。另见:叙述描述。

作为DID主体的代表

如果DID订阅者是一个可以从internet检索的数字资源，那么一个DID方法可以选择构造一个DID URL，该URL返回DID订阅者本身的表示。例如，一个需要持久的、密码学可验证的标识符的数据模式可以被分配一个DID，传递一个指定的DID参数（参见3.2.1 DID参数）可以作为检索该模式表示的标准方法。
类似地，如果适用的DID方法支持该功能，则可以使用DID来引用可直接从可验证的数据注册中心返回的数字资源（如图像）。

将DIDs分配给现有的web资源

如果web页面或任何其他web资源的管理者希望为其分配一个持久的、可加密验证的标识符，管理者可以给它一个DID。例如，由博客托管公司(在该公司的域名下)托管的博客的作者可以为博客创建一个DID。在DID文档中，作者可以包含指向博客当前URL的属性，例如:alsoKnownAs
"alsoKnownAs": ["https://myblog.blogging-host.example/home"]

如果作者随后将博客转移到不同的托管公司(或作者自己的域名)，作者可以更新DID文档以指向博客的新URL，例如：

"alsoKnownAs": ["https://myblog.example/"]

DID有效地为博客URL添加了一层间接链接。这一间接层是在作者的控制下，而不是在一个外部管理机构的控制下，如博客托管公司。这就是DID如何有效地充当增强的URN(统一资源名)的方式——一个信息资源的持久标识符，它的网络位置可能随着时间的推移而变化。

DID管理者和DID受试者之间的关系

为了避免混淆，根据DID受试者与管理者的关系将其分为两个不相关的集合。

集合1：DID订阅者就是DID管理者
第一种情况（如图10所示）是常见的场景，其中DID订阅者也是DID管理者。这就是当个人或组织创建一个DID来自我识别的情况。

DID主体与DID管理者是同一个实体。另见：叙述描述。

从图模型的角度来看，尽管图10中标识为DID controller和DID subject的节点是不同的，但有一个逻辑弧将它们连接起来，以表达语义等价关系。

集合2：DID订阅者不是DID管理者

第二种情况是，DID主体是与DID管理者分离的实体。例如，父节点为子节点创建并维护一个DID的控制时就是这种情况;公司为子公司创建并维持对DID的控制;或者制造商为产品、物联网设备或数字文件创建并维护DID的控制。
从图模型的角度来看，与集合1唯一的区别是DID主体和DID管理者节点之间不存在等价弧关系。

多个DID管理者

一个DID文档可能有多个DID管理者。这种情况有两种可能发生。

独立控制

在这种情况下，每个DID管理者都可以独立地进行操作，也就是说，每个管理者都有独立地更新DID文档的全部能力。从图模型的角度来看，在这种配置中:

• 每个附加的DID管理者都是另一个不同的图节点（可能由它自己的DID标识）。
• 相同的弧（“控件”和“管理者”）存在于每个DID管理者和DID文档之间。

多个独立的DID管理者，每个管理者可以独立行动。另见：文本说明

集团控制
在群控制的情况下，DID管理者期望以某种方式一起行动，例如使用需要多个数字签名（“多重签名”）或数字签名门限数量（“m-of-n”）的密码算法时。从功能的角度来看，这个选项类似于单个DID管理者，因为尽管DID管理者组中的每个DID管理者都有自己的图节点，但实际的控制折叠为表示DID管理者组的单个逻辑图节点，如图12所示。

多个DID管理者将作为一个DID管理者组一起行动。另见：叙述描述。

当DID订阅者是一个组织、公司、政府机构、社区或其他不受单个个人控制的团体时，这种配置经常适用。

改变DID订阅者

一个DID文档恰好有一个DID，它指的是DID订阅者。DID表示为属性的值。此属性值在DID文档的生命周期内是不可变的。
但是，由DID标识的资源，即DID订阅者，可能会随着时间的推移而变化。这是在DID管理者的独占权限下。详细信息请参见9.16持久化章节。

改变DID管理者

一个DID文档的DID管理者可能会随着时间的推移而改变。但是，根据实现方式的不同，对DID文档本身的更改可能不会显示出明显的变化。例如，如果更改是通过底层加密密钥或用于DID文档中的一个或多个验证方法的其他控件的所有权转移来实现的，那么它可能与标准密钥轮换无法区分。
另一方面，如果更改是通过更改controller属性的值来实现的，那么它将是透明的。
如果验证DID管理者的更改很重要，建议实现者根据修改后的DID文档中的验证方法验证新的DID管理者。