去中心化标识符解析（DID Resolution）v0.3

除标记为非规范性的章节外，本规范中的所有编写指南、图表、示例和注释均为非规范性内容。除此之外，本规范中的所有内容均为规范性内容。

本文档中的关键词 MAY、MUST、MUST NOT、NOT REQUIRED、OPTIONAL、RECOMMENDED、REQUIRED 和 SHOULD 应按 BCP 14 [RFC2119] [RFC8174] 中的说明解释，且仅当它们如本文所示全部以 大写字母出现时才如此解释。

一致性 DID 解析器是指任何 以软件和/或硬件实现、并符合 4. DID 解析中相关规范性陈述的算法。

一致性基于网络的 DID 解析器 是一种 一致性 DID 解析器，并且还符合 12.1 HTTP(S) 绑定中的 规范性陈述。

一致性 DID URL 解引用器是指 任何以软件和/或硬件实现、并符合 5. DID URL 解引用中相关规范性陈述的算法。

一致性基于网络的 DID URL 解引用器 是一种 一致性 DID URL 解引用器，并且还 符合 12.1 HTTP(S) 绑定中的规范性陈述。

本规范中的所有日期时间值 MUST 是一个 ASCII 字符串，且是 [VC-DATA-MODEL] 在 可验证凭证数据模型 v2.0中定义的有效 XML 日期时间值。 此外，DID Resolution 中使用的时间戳 MUST 调整为 UTC，且不得具有亚秒十进制精度。例如： 2020-12-20T19:17:47Z

DID URL 查询字符串 通常会在解析流水线中的多个独立组件之间被构造、解析、 记录、缓存和比较——例如客户端、缓存代理、下游 解析器以及 DID 方法特定解析器（见 8.2 解析器 架构）。这些组件之间对 DID URL 查询字符串 的规范化不一致，可能会 悄然产生错误的解析结果、缓存污染或破坏 互操作性。本节列举了鼓励实现者和 DID 方法规范作者明确处理的边界情形。

这是一个 元数据结构，其中包含 DID 解析过程的输入选项。

此结构中的可能属性及其可能值 SHOULD 注册到 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]。 本规范定义以下常见输入选项：

accept

调用者首选的 DID 文档 表示的媒体类型。 该值 MUST 按 HTTP 语义 第 12.5.1 节中定义的 Accept 标头值来表示。DID 解析器 实现 SHOULD 使用此值来确定返回的 didDocument 的 表示， 前提是此类 表示 受支持且可用。此属性是 OPTIONAL。

expandRelativeUrls

一个布尔标志，指示 DID 解析器将 相对 DID URL 在 DID 文档中展开为符合 DID URL 语法的一致性绝对 DID URL。

versionId

定义见 3. DID 参数。

versionTime

定义见 3. DID 参数。

这是一个 元数据结构，其中包含关于 DID 解析过程的元数据。

此元数据通常会在每次调用 DID 解析 函数时发生变化，因为它表示关于 解析过程本身的数据。

此元数据的来源是 DID 解析器。

DID 解析元数据的示例包括：

• 返回内容的媒体类型（contentType）。
• 错误对象（error）（见第 11. 错误节）。
• 由 DID 解析器生成的证明，例如用于 建立可信解析（proof）。
• DID 解析过程的持续时间。
• 缓存信息（见第 13.2 缓存节）。
• DID 解析过程中所使用的 可验证数据注册表 的 URL、IP 地址和/或其他网络信息。

此结构中的可能属性及其可能值 SHOULD 注册到 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]。 本规范定义以下常见元数据属性：

contentType

返回的 didDocument 的媒体类型。此 属性是 OPTIONAL。如果存在，此属性的值 MUST 是 一个 ASCII 字符串，并且是 一致性 表示的媒体类型。在这种情况下， resolve 函数的调用者 MUST 在 确定如何解析和处理 didDocument 时使用此值。

error

错误数据结构定义于 [RFC9457]。本 规范定义的错误可见第 11. 错误节。 其他错误 SHOULD 注册到 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]。

proof

一些 DID 解析器和 DID URL 解引用器 在执行 DID 解析或 DID URL 解引用 函数时使用证明。详情见 8.2 解析器架构。

DID 解析元数据 MAY 包含 proof 属性。 如果存在，该值 MUST 是一个 集合，其中每个 项都是表示证明的 映射。此属性的使用 和证明类型与 DID 方法无关。

这是一个 元数据结构，其中包含关于 DID 解析过程的元数据。

此元数据通常不会在每次调用 DID 解析 函数时发生变化，除非 DID 文档 发生变化，因为它表示关于 DID 文档的数据。

此元数据的来源是 DID 控制者和/或 DID 方法。由 DID 控制者证明的 DID 文档元数据本身并不天然保证准确性。建议客户端在依赖 DID 文档元数据来指导业务 逻辑时谨慎行事。

DID 文档元数据的示例包括：

• DID 及其关联 DID 文档 被创建或更新时的时间戳（例如 created、 updated、nextUpdate）。
• 关于 DID 文档的版本信息（例如 versionId、 nextVersionId）。
• 由 DID 控制者添加的证明，或由 DID 方法的 可验证数据 注册表生成的证明，这些证明可能 用于建立控制权限或启用 可验证 解析 （例如 proof）。
• 关于控制者、能力、委托等的元数据。
• 方法特定元数据，例如区块链或其他 可验证数据 注册表中某条记录的区块号、索引、交易哈希、确认数等。

此结构中的可能属性及其可能值 SHOULD 注册到 DID Document Properties Extensions [DID-EXTENSIONS-PROPERTIES]。本 规范定义以下常见 元数据属性。

created

DID 文档 元数据 SHOULD 包含 created 属性， 用于指示 Create 操作的时间戳。该 属性的值 MUST 以 3.1 日期时间中定义的日期时间格式表示。

updated

DID 文档 元数据 SHOULD 包含 updated 属性，用于指示已解析文档版本的最后一次 Update 操作 的时间戳。该属性的值 MUST 以 3.1 日期时间中定义的日期时间格式表示。 如果从未对该 DID 文档执行过 Update 操作，则省略 updated 属性。如果存在 updated 属性，当两个时间戳之间的差异 小于一秒时，它可以与 created 属性具有相同值。

deactivated

如果 DID 已被 停用， DID 文档 元数据 MUST 包含此属性， 且布尔值为 true。如果 DID 尚未被停用， 此属性是 OPTIONAL，但如果包含，则 MUST 具有布尔值 false。

nextUpdate

如果已解析文档版本不是文档的最新版本， DID 文档 元数据 MAY 包含 nextUpdate 属性。它表示下一次 Update 操作的时间戳。 该属性的值 MUST 以 3.1 日期时间中定义的日期时间格式 表示。

versionId

DID 文档 元数据 SHOULD 包含 versionId 属性，用于指示已解析文档 版本的最后一次 Update 操作的版本。该属性的值 MUST 是 ASCII 字符串。

nextVersionId

如果已解析文档版本 不是文档的最新版本，DID 文档 元数据 MAY 包含 nextVersionId 属性。它表示下一次 Update 操作的版本。 该属性的值 MUST 是 ASCII 字符串。

equivalentId

DID 方法 可以定义逻辑等价的 DID的不同形式。 一个示例是，当某个 DID 在注册到 可验证数据 注册表之前采用一种形式， 而在完成此类注册之后采用另一种形式。在这种情况下， DID 方法 规范可能需要将一个或多个与已解析 DID逻辑等价的 DID 表达为 DID 文档的属性。这就是 equivalentId 属性的目的。

DID 文档元数据 MAY 包含 equivalentId 属性。如果存在，该值 MUST 是 一个 集合，其中每一项都是符合 字符串规则且符合 去中心化标识符（DID） v1.0一节的字符串。该关系是一项 声明，表示每个 equivalentId 值都与 id 属性值在逻辑上 等价，因此指向同一 DID 主体。每个 equivalentId DID 值 MUST 由与 id 属性 值相同的 DID 方法 产生，并且是该方法的一种形式。（例如 did:example:abc == did:example:ABC）

一致性 DID 方法规范 MUST 保证每个 equivalentId 值都与 id 属性值在逻辑上 等价。

请求方预期保留 id 和 equivalentId 属性中的值，以确保 与它们包含的任何值的后续交互 都会被正确处理为逻辑等价（例如，在数据库中保留所有 变体，以便与其中任意一个的交互都映射到同一 底层账户）。

注： 更强的等价性

equivalentId 是一种比 alsoKnownAs 强得多的等价形式，因为 这种等价性 MUST 由管辖性的 DID 方法保证。使用 equivalentId 意味着同一个 DID 文档 同时描述 equivalentId DID 和 id 属性的 DID。

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

canonicalId

canonicalId 属性与 equivalentId 属性相同，但有以下区别：a) 它关联的是单个值而不是一个集合；b) 该 DID 被定义为 所含 DID 文档范围内该 DID 主体的规范 ID。

DID 文档元数据 MAY 包含 canonicalId 属性。 如果存在，该值 MUST 是一个 字符串，且 符合 去中心化标识符（DID）v1.0一节中的规则。 该关系是一项声明，表示 canonicalId 值与 id 属性值在逻辑上等价，并且 该 canonicalId 值由 DID 方法 定义为所含 DID 文档范围内 DID 主体的规范 ID。一个 canonicalId 值 MUST 由与 id 属性值相同的 DID 方法产生，并且是该方法的一种形式。 （例如 did:example:abc == did:example:ABC）。

一致性 DID 方法规范 MUST 保证 canonicalId 值与 id 属性值在逻辑上等价。

请求方预期将 canonicalId 值用作该 DID 主体的主要 ID 值，并将所有 其他等价值视为次要别名（例如，更新 其系统中的相应主要引用，以反映新的 规范 ID 指令）。

注： 规范等价性

canonicalId 与 equivalentId 是相同的等价性声明， 只是它被限制为单个值， 且该值被定义为 DID 主体在 DID 文档范围内的规范值。与 equivalentId 一样，使用 canonicalId 意味着同一个 DID 文档 同时描述 canonicalId DID 和 id 属性的 DID。

如果解析方不将 canonicalId 值用作 DID 主体的主要 ID 值，并将所有其他等价值 视为次要别名，则可能会出现与用户体验相关的负面或意外问题。 强烈建议实现者遵守与此元数据 属性相关的指令。

proof

许多 DID 方法在执行 方法操作时使用证明。详情见 8.1 方法 架构。

DID 文档元数据 MAY 包含 proof 属性。如果存在，该值 MUST 是一个 集合，其中每一项都是表示证明的 映射。此属性的使用 以及证明类型是 DID 方法特定的。

DID 解析器 实现以下 DID 解析 算法。

1. 验证 input DID 是否符合 DID 语法的 did 规则。 如果不符合，DID 解析器 MUST 返回以下结果：
   1. didResolutionMetadata：error object，其 type 设为 https://www.w3.org/ns/did#INVALID_DID
   2. didDocument：null
   3. didDocumentMetadata：«[ ]»
2. 确定实现此算法的 DID 解析器 是否支持 input DID 的 DID 方法。如果 不支持，DID 解析器 MUST 返回以下 结果：
   1. didResolutionMetadata：error object，其 type 设为 https://www.w3.org/ns/did#METHOD_NOT_SUPPORTED
   2. didDocument：null
   3. didDocumentMetadata：«[ ]»
3. 确定 input DID 解析选项 是否受实现此算法的 DID 解析器支持。 如果不支持，DID 解析器 MUST 返回以下结果：
   1. didResolutionMetadata：error object，其 type 设为 https://www.w3.org/ns/did#FEATURE_NOT_SUPPORTED
   2. didDocument：null
   3. didDocumentMetadata：«[ ]»
4. 确定 input DID 解析选项 是否有效。如果无效，DID 解析器 MUST 返回以下结果：
   1. didResolutionMetadata：error object，其 type 设为 https://www.w3.org/ns/did#INVALID_OPTIONS
   2. didDocument：null
   3. didDocumentMetadata：«[ ]»
5. 通过执行由 input DID 方法定义的 Resolve 操作，获取 input DID 的 DID 文档：
   1. 如果 input DID 不存在，则返回以下结果：
      1. didResolutionMetadata：error object，其 type 设为 https://www.w3.org/ns/did#NOT_FOUND
      2. didDocument：null
      3. didDocumentMetadata：«[ ]»
   2. 如果 input DID 已被 停用，则返回以下结果：
      1. didResolutionMetadata：«[ ... ]»
      2. didDocument：null
      3. didDocumentMetadata：«[ "deactivated" → true, ... ]»
   3. 否则，Resolve 操作的结果称为 output DID 文档。 此结果 MUST 以 一致性表示来表示。
6. 如果 input DID 解析选项 包含值为 true 的 expandRelativeUrls 选项：
   1. 遍历 output DID 文档中的所有 服务、 验证方法、 验证 关系 以及任何扩展定义的属性。
   2. 对于每一项，如果该项是对象，并且 id 属性的值是 相对 DID URL， 或者如果某个 验证 关系是 相对 DID URL：
      1. 根据 去中心化标识符（DID） v1.0中 相对 DID URL一节的规则，将该 相对 DID URL 解析为符合 DID URL 语法的一致性绝对 DID URL。
   3. 通过将 相对 DID URL替换为已解析的 绝对 DID URL，更新 output DID 文档。
7. 返回以下结果：
   1. didResolutionMetadata：«[ ... ]»
   2. didDocument：output DID document
   3. didDocumentMetadata： «[ "contentType" → output DID document media type, ... ]»

如果 DID 解析器 在执行 DID 解析算法期间 遇到任何意外错误，它 MUST 返回以下 结果：

1. didResolutionMetadata：error object，其 type 设 为 https://www.w3.org/ns/did#INTERNAL_ERROR
2. didDocument：null
3. didDocumentMetadata：«[ ]»

这是一个 元数据结构，其中包含 DID URL 解引用过程的输入选项。

此结构中的可能属性及其可能值 SHOULD 注册到 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]。 本规范定义以下常见输入选项：

accept

调用者首选用于 contentStream 的媒体类型。该值 MUST 按 HTTP 语义 第 12.5.1 节中定义的 Accept 标头值来表示。DID URL 解引用器 实现 SHOULD 使用此值来确定返回值中所含 表示 的 contentType，前提是此类 表示受支持且可用。

verificationRelationship

调用者期望从 DID URL 解引用得到的 verificationMethod 被授权用于的 verificationRelationship。如果存在，关联值 MUST 是一个 ASCII 字符串。如果 DID URL 未 解引用到 verificationMethod，或者 DID 文档未针对指定的 verificationRelationship 授权该 verificationMethod，则 MUST 引发错误。

这是一个 元数据结构，其中包含关于 DID URL 解引用过程的元数据。

此元数据通常会在每次调用 DID URL 解引用函数时发生变化，因为它表示关于 解引用过程本身的数据。

此元数据的来源是 DID URL 解引用器。

此结构中的可能属性及其可能值 SHOULD 注册到 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]。 本规范定义以下常见元数据属性：

contentType

返回的 contentStream 的媒体类型在解引用成功时 SHOULD 使用此属性来表示。该 媒体类型值 MUST 表示为 ASCII 字符串。

error

定义于 [RFC9457] 的错误数据结构。当 解引用过程中出现错误时，此属性 是 REQUIRED。本 规范定义的错误可见第 11. 错误节。 其他错误 SHOULD 注册到 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]。

proof

一些 DID 解析器和 DID URL 解引用器在执行 DID 解析或 DID URL 解引用 函数时使用证明。详情见 8.2 解析器架构。

DID URL 解引用元数据 MAY 包含 proof 属性。如果存在，该值 MUST 是一个 集合，其中每一项都是表示证明的 映射。此属性的使用 和证明类型与 DID 方法无关。

这是一个 元数据结构，其中包含关于 DID URL 解引用过程的元数据。

此元数据通常不会在每次调用 DID URL 解引用函数时发生变化，除非内容发生变化，因为它 表示关于内容的数据。

此元数据的来源是 DID 控制者和/或 DID 方法。

此结构中的可能属性及其可能值 SHOULD 注册到 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]。 本规范未定义任何通用属性。

DID URL 解引用器实现以下 DID URL 解引用算法。按照 [RFC3986]，它包括 以下三个步骤：解析 DID；解引用资源；以及解引用片段（仅当 input DID URL 包含 DID 片段时）：

DID 解析 算法涉及根据某个 DID 的 DID 方法执行其上的 Resolve 操作（见 4. DID 解析）。

每种 DID 方法都会定义此方法操作，即 DID 解析器如何 从 DID 获得 DID 文档。底层数据格式、协议、技术基础设施和过程在 各种 DID 方法之间可能 差异很大。

DID 方法考量示例包括以下内容：

• DID 方法可能使用不可变区块链、分布式账本、分布式 文件系统、点对点网络或其他去中心化基础设施作为其 可验证数据 注册表（的一部分）。
• DID 方法可能使用 DNS、HTTP 或 Web 服务器作为其 可验证数据 注册表（的一部分）。
• DID 方法可能使用上述技术基础设施的任意组合。
• DID 方法可能以明文形式在 可验证数据注册表中存储实际的 DID 文档， 并可能在 “Resolve” 操作期间简单地检索该 文档。
• DID 方法可能以更复杂的方式定义其 “Resolve” 操作， 该方式可能涉及中间的、部分的或临时的 DID 文档， 并使用多步骤过程“即时”构造 DID 文档。
• DID 方法在执行 “Resolve” 操作期间可能需要与远程服务器或网络交互。
• DID 方法可能以完全本地的方式执行 “Resolve” 操作， 不需要与任何远程服务器或网络交互。例如， 在 [DID-KEY] 方法中，DID 本身封装了一个公钥， 而 “Resolve” 操作只是一个简单的本地转换过程。

基于上述考量，并结合 DID 方法的 “Resolve” 操作的性质， DID 解析器与 可验证数据注册表 之间的交互 可以被视为 可验证解析或 不可验证解析：

可验证解析会在适用 DID 方法可达到的范围内，最大化对 “Resolve” 操作结果完整性和 正确性的信心。这可以通过多种方式完成， 例如以下方式：

• 如果可以在本地、可信 网络环境中访问 可验证数据注册表， 则可以完成 可验证解析。
  • 例如，在基于区块链的 DID 方法中，如果 区块链全节点部署在本地服务器上，则可能完成 可验证解析。
• 如果通过远程服务器访问 可验证数据注册表， 那么如果该远程服务器 可信，且可以通过安全信道访问，仍可能完成 可验证解析。
• 如果通过 远程服务器访问 可验证数据注册表， 但 可验证解析可能通过以下方式 完成：DID 解析器有某种方式 验证由 DID 方法返回的 DID 文档和 DID 文档元数据。
  • 例如，在基于区块链的 DID 方法中，即使无法直接访问 区块链全节点，仍可以通过使用 处理元数据来验证数据的轻客户端，实现 可验证解析。

不可验证解析不具有此类保证， 因此 较不理想，例如：

• 如果通过远程且不可信的 中介访问 可验证数据注册表， 则会发生 不可验证解析。
  • 例如，在基于区块链的 DID 方法的情况下，可以使用由第三方运营的远程区块链浏览器 API 从 区块链中查找数据。

为了启用 可验证解析，许多 DID 方法使用数字 签名、状态证明、Merkle 树中的包含证明、密码学 事件日志或其他类型的证明。如果 DID 方法使用 此类证明，则它 MUST 在其 DID 方法规范中说明如何使用这些证明 来验证 “Resolve” 操作结果的正确性。

DID 方法 MAY 也将此类证明包含在 DID 文档 本身中，或包含在 DID 文档元数据的 proof 属性中。 即使 客户端不信任 DID 解析器， 这也可能使其能够独立验证 DID 解析 过程的结果。

请注意，源自 DID 方法的证明是 DID 方法特定的， 并且必须在适用 DID 方法的技术范围内理解。对 DID 文档 或 DID 文档元数据 的简单签名并不一定证明对 DID 的控制，也不保证该 DID 文档就是 该 DID的 正确文档。 这些证明有助于在 DID 方法 本身所关涉的范围内，验证 DID 解析过程结果的完整性和 真实性。然而，它们并不 保证 客户端与 DID 解析器之间的 绑定是 安全的。另请参见 8.2 解析器 架构。

DID 解析和 DID URL 解引用算法被定义为抽象函数（见 4. DID 解析和 5. DID URL 解引用）。

这些算法由 DID 解析器和 DID URL 解引用器实现，并由 客户端通过 绑定调用。绑定 定义了如何使用具体的编程或 通信接口访问抽象函数。

绑定示例包括以下内容：

• DID 解析器 可以在应用程序中通过 调用软件库或 SDK 来调用。
• DID 解析器 可以作为命令行工具调用。
• DID 解析器 可以通过 HTTP(S) API 或其他 网络协议调用，例如见 12.1 HTTP(S) 绑定。

基于上述考量，并结合绑定的性质， 客户端与 DID 解析器或 DID URL 解引用器之间的交互 可以被视为 本地绑定或 远程绑定：

在可能的情况下，优先使用 本地绑定，因为它们 最大限度减少对第三方和中介的依赖，降低安全 风险，并最大化对 DID 解析和 DID URL 解引用 函数结果完整性和正确性的信心。

在某些情况下，可能无法使用 本地绑定；例如，在受限的 IoT（物联网） 环境中，或当 DID 方法需要复杂 基础设施时，或当需要支持许多不同 DID 方法时。

如果 客户端 使用 远程绑定，则适用 以下考量：

• 远程绑定 SHOULD 使用 可信的 DID 解析器 实例，最好由 客户端 自身控制（例如自托管）。
• 远程绑定 SHOULD 使用 安全信道，例如 VPN 和/或带有双向认证的 TLS。
• 客户端可以通过 远程绑定查询多个 DID 解析器， 并比较结果。

DID 解析器 MAY 也可以在 DID 解析元数据的 proof 属性中包含证明。

请注意，源自 DID 解析器的证明 与 DID 方法无关，并且可由 DID 解析器 跨所有 DID 方法统一应用。这些证明有助于 在 DID 解析器本身 所关涉的范围内，验证 DID 解析 过程结果的完整性和真实性。然而，它们并不 保证适用 DID 方法的 “Resolve” 操作结果本身是 正确的。另请参见 8.1 方法架构。

8.2.1 多种方法

DID 解析器 可能支持用于多种 DID 方法的 DID 解析 算法：

在这种情况下，8.1 方法架构中关于 可验证解析和 不可验证解析 实现的上述考量，分别适用于每个受支持的 DID 方法。

8.2.2 代理解析

DID 解析器 MAY 调用另一个 DID 解析器， 后者作为代理执行 DID 解析 算法，如 4. DID 解析中所定义。

第一个 DID 解析器随后充当 客户端， 并选择适合的 绑定来调用第二个 DID 解析器。 例如，DID 解析器 可以通过 本地绑定（例如命令行 工具）调用，而该工具又通过 远程绑定（例如 HTTP(S) 绑定）调用另一个 DID 解析器。

使用代理解析时，“下游”解析器 SHOULD 以透明方式保留来自 “上游”解析器的所有 DID 解析元数据和 DID 文档元数据， 包括可能存在的任何证明。在此过程中，“下游”解析器 MAY 添加其自己的 DID 解析元数据， 包括关于代理解析过程本身的任何元数据。

注： 与 DNS 的比较

这类似于 DNS 架构中的“存根解析器”调用“递归解析器”， 尽管这些概念并不完全可比（DNS 解析 使用单一的具体协议，而 DID 解析是一个抽象函数， 由不同 DID 方法和不同 绑定实现）。

给定 DID URL did:xyz:1234#keys-1，可以通过 本地绑定调用 DID 解析器来 解引用资源 （即 DID 文档），而 客户端可以通过 解引用片段 （即 DID 文档的一部分） 完成 DID URL 解引用算法。

给定 DID URL did:xyz:1234?service=agent&relativeRef=%2Fsome%2Fpath%3Fquery#frag， 可以调用 DID 解析器 来 解引用资源 （即 DID 服务端点 URL），而 客户端可以通过 解引用片段 （即带有片段的 DID 服务端点 URL） 完成 DID URL 解引用算法。

给定 DID URL did:xyz:1234#keys-1，可以通过 本地绑定调用 DID 解析器，该解析器又通过 远程绑定调用另一个 DID 解析器来 解引用资源 （即 DID 文档），而 客户端可以通过 解引用片段 （即 DID 文档的一部分） 完成 DID URL 解引用算法。

本节定义了一个 DID 解析器 绑定， 该绑定通过 HTTP(S) 端点暴露 DID 解析 和/或 DID URL 解引用函数 （包括所有解析/解引用选项和元数据）。参见 8.2 解析器 架构。

HTTP(S) 绑定需要一个已知的 HTTP(S) URL，可在该 URL 调用 DID 解析器。此 URL 称为 DID 解析器 HTTP(S) 端点。

此绑定通常被视为 远程绑定，但如果 HTTP(S) 端点运行在 本地环境中，例如 localhost 上，也可以是 本地绑定。

所有 一致性 DID 解析器 MUST 实现 HTTPS 绑定的 GET 版本， 并且 MAY 实现 POST 版本。所有 HTTPS 绑定 MUST 使用 TLS。不 REQUIRED 在证书中使用 DNS 名称； 解析器 MAY 使用为 IP 地址签发的 TLS 证书。

使用此绑定， DID 解析函数（见 4. DID 解析）和/或 DID URL 解引用函数 （见 5. DID URL 解引用）可以 按如下方式执行：

1. 使用 DID 解析器 HTTP(S) 端点初始化一个 request HTTP(S) URL。
   示例 23

   https://resolver.example/1.0/identifiers/

2. 对于 DID 解析函数：
   1. 将 input DID 追加到 request HTTP(S) URL。
      示例 24

      https://resolver.example/1.0/identifiers/did:example:1234

   2. 将 Accept HTTP request header 设为 application/did-resolution，以请求完整的 9. DID 解析 结果，或者
   3. 将 Accept HTTP request header 设为 accept resolution option 的值，以 仅请求结果中的 didDocument 值。
3. 对于 DID URL 解引用函数：
   1. 将 input DID URL 追加到 request HTTP(S) URL。
      示例 25

      https://resolver.example/1.0/identifiers/did:example:1234?service=files&relativeRef=/resume.pdf

   2. 将 Accept HTTP request header 设为 application/did-url-dereferencing，以请求完整的 10. DID URL 解引用结果，或者
   3. 将 Accept HTTP request header 设为 accept dereferencing option 的值，以仅请求结果中的 contentStream 值。
4. 对于 HTTP(S) GET 绑定：
   1. 如果提供了除 accept 以外的任何其他 resolution options 或 dereferencing options：
      1. input DID MUST 进行 URL 编码（如 RFC3986 第 2.1 节所规定）。
      2. 将除 accept 以外的所有 resolution options 编码为 request HTTP(S) URL 中的查询参数。
   2. 在 request HTTP(S) URL 上执行 HTTP GET 请求。这会调用远程 DID 解析器上的 DID 解析或 DID URL 解引用函数。
      示例 26

      GET https://resolver.example/1.0/identifiers/did%3Aexample%3A1234?option1=value1&option2=value2 HTTP/1.1
      Accept: application/did-resolution

      示例 27

      GET https://resolver.example/1.0/identifiers/did%3Aexample%3A1234%3Fservice%3Dfiles%26relativeRef%3D%2Fresume.pdf?option1=value1&option2=value2 HTTP/1.1
      Accept: application/did-url-dereferencing

5. 对于 HTTP(S) POST 绑定：
   1. 如果提供了除 accept 以外的任何其他 resolution options 或 dereferencing options：
      1. 将除 accept 以外的所有 resolution options 编码为 HTTP 请求的 POST 正文中的 JSON 结构。
   2. 在 request HTTP(S) URL 上执行 HTTP POST 请求。这会调用远程 DID 解析器上的 DID 解析或 DID URL 解引用函数。
      示例 28

      POST https://resolver.example/1.0/identifiers/did:example:1234 HTTP/1.1
      Accept: application/did-resolution
      
      {
      "option1": "value1",
      "option2": "value2"
      }

      示例 29

      POST https://resolver.example/1.0/identifiers/did:example:1234?service=files&relativeRef=/resume.pdf HTTP/1.1
      Accept: application/did-url-dereferencing
      
      {
      "option1": "value1",
      "option2": "value2"
      }

6. 如果 DID 解析或 DID URL 解引用函数在 didResolutionMetadata 或 dereferencingMetadata 中返回 error 元数据属性，则 HTTP 响应状态码 MUST 根据下表 对应于 error object 的 type 属性：

   error type URI	HTTP 状态码
   https://www.w3.org/ns/did#INVALID_DID	400
   https://www.w3.org/ns/did#INVALID_DID_URL	400
   https://www.w3.org/ns/did#INVALID_OPTIONS	400
   https://www.w3.org/ns/did#NOT_FOUND	404
   https://www.w3.org/ns/did#REPRESENTATION_NOT_SUPPORTED	406
   https://www.w3.org/ns/did#INVALID_DID_DOCUMENT	500
   https://www.w3.org/ns/did#METHOD_NOT_SUPPORTED	501
   https://www.w3.org/ns/did#FEATURE_NOT_SUPPORTED	501
   https://www.w3.org/ns/did#INTERNAL_ERROR	500
   （任何其他错误 URI）	500

7. 如果 DID 解析或 DID URL 解引用函数在 didDocumentMetadata 或 contentMetadata 中返回值为 true 的 deactivated 元数据属性：
   1. HTTP 响应状态码 MUST 为 410。
8. 对于 DID 解析函数：
   1. 如果 Content-Type HTTP response header 的值是 application/did-resolution：
      1. HTTP body MUST 包含一个 DID 解析结果（见 9. DID 解析结果），该结果是 DID 解析 函数的结果。
   2. 如果函数成功并返回 didDocument：
      1. HTTP 响应状态码 MUST 为 200。
      2. HTTP 响应 MUST 包含一个 Content-Type HTTP response header。其值 MUST 是 didResolutionMetadata 中 contentType 元数据属性的值（见 4.2 DID 解析元数据）。
      3. HTTP 响应正文 MUST 包含 DID 解析 函数结果中的 didDocument，并使用 与 Content-Type HTTP response header 对应的 表示。
9. 对于 DID URL 解引用函数：
   1. 如果 Content-Type HTTP response header 的值 是 application/did-url-dereferencing：
      1. HTTP body MUST 包含一个 DID URL 解引用结果 （见 10. DID URL 解引用结果），该结果是 DID URL 解引用函数的结果。
   2. 如果函数成功并返回 contentStream，并且 dereferencingMetadata 中的 contentType 元数据属性 值为 text/uri-list：
      1. HTTP 响应状态码 MUST 为 303。
      2. HTTP 响应 MUST 包含一个 Location 标头。此标头的值 MUST 是 selected DID service endpoint URL。
      3. HTTP 响应正文 MUST 为空。
   3. 如果函数成功并返回具有任何其他 contentType 的 contentStream：
      1. HTTP 响应状态码 MUST 为 200。
      2. HTTP 响应 MUST 包含一个 Content-Type HTTP response header。其值 MUST 是 dereferencingMetadata 中 contentType 元数据属性的值（见 5.2 DID URL 解引用元数据）。
      3. HTTP 响应正文 MUST 包含 DID URL 解引用函数结果中的 contentStream，并使用 与 Content-Type HTTP response header 对应的表示。

给定以下 DID 解析器 HTTP(S) 端点：

https://resolver.example/1.0/identifiers/

并给定以下 input DID：

did:example:123

则 request HTTP(S) URL 为：

https://resolver.example/1.0/identifiers/did:example:123

GET https://resolver.example/1.0/identifiers/did:example:123 HTTP/1.1
Accept: application/did-resolution

HTTP 200 OK
Content-Type: application/did-resolution

{
	"didDocument": {
		"@context": [ "https://www.w3.org/ns/did/v1.1" ],
		"id": "did:example:123",
		"verificationMethod": [{
			...
		}],
		"service": [{
			...
		}]
	},
	"didResolutionMetadata": {
		"contentType": "application/did"
	},
	"didDocumentMetadata": {
		...
	}
}

GET https://resolver.example/1.0/identifiers/did:example:123 HTTP/1.1
Accept: application/did

HTTP 200 OK
Content-Type: application/did

{
	"@context": [ "https://www.w3.org/ns/did/v1.1" ],
	"id": "did:example:123",
	"verificationMethod": [{
		...
	}],
	"service": [{
		...
	}]
}

DID 解析和 DID URL 解引用不 涉及任何身份验证或授权功能。类似于 DNS 解析，任何人都可以执行该过程，而无需任何凭证 或非公开知识。

DID 解析器可以 维护一个通用的 DID 文档缓存。它 也可以维护特定于某些 DID 方法的缓存。

noCache 解析选项可用于请求 某种缓存行为。

此 resolution option 是 OPTIONAL。

此属性的可能值为：

• "false"（默认值）：允许缓存 DID 文档。
• "true"：请求禁用缓存，并从 可验证数据 注册表检索一个新的 DID 文档。

缓存行为可以通过 DID 解析器的配置、 noCache 解析选项、DID 文档的内容（例如 cacheMaxTtl 字段），或这些 属性的组合来控制。

实现 noCache 的解析器可能更容易受到拒绝 服务攻击，因为恶意客户端可以绕过缓存来强制 代价高昂的网络请求和资源消耗。使用 noCache 请求解析的客户端预期某些 解析器会拒绝绕过缓存的解析请求。 拒绝无缓存解析的解析器 MUST 以 FEATURE_NOT_SUPPORTED 错误响应，并明确说明 不允许绕过缓存，以便客户端可以尝试 不使用 noCache 进行解析。

如果从远程位置获取 JSON-LD Context 文件，攻击者可能会篡改该上下文 文件（例如，通过攻陷服务器 或通过中间人攻击拦截请求）。

因此，强烈建议任何执行远程检索 JSON-LD Context URL 的 DID 解析器使用上下文文件及其对应哈希的注册表 （或功能等效机制），以帮助确保 端到端安全。预期实现会在 资源的密码学哈希值与预期哈希值不匹配时抛出错误。

如果提供了 versionId 或 versionTime DID 参数，则 DID 解析算法会返回 DID 文档的特定版本。

DID 参数 versionId 和 versionTime 互斥。

versionId DID 参数的使用是特定于 DID 方法的。其可能值可 包括顺序编号、随机 UUID、内容哈希等。

DID 文档元数据 MAY 包含一个 versionId 属性， 该属性会随着对 DID 文档执行的每次 Update 操作而变化。

使用分布式系统（例如 分布式账本）作为 VDR（可验证数据注册表）的 DID 方法 需要管理 网络分叉可能发生的潜在情况。因此，使用 分布式系统作为 VDR 的 DID 方法规范 SHOULD 指定一种方式，以便将其使用的 VDR 与此类 分叉区分开来。

当 DID URL 解引用器客户端解引用 DID 文档中的标识符 和链接资源时——尤其是 verificationMethod、controller 或 alsoKnownAs 等字段——可能会遇到 解引用循环。当 DID 文档 引用另一个 DID（或 URL），并且该引用最终 又指回先前已解引用的标识符，从而形成 循环时，可能会发生这种情况。DID URL 解引用器在解引用引用 DID 服务端点的 DID URL时， 也可能遇到此类情况。

did:example:alice
	└── verificationMethod.controller → did:example:bob
		└── verificationMethod.controller → did:example:alice

执行递归解引用的 DID URL 解引用器及其客户端应当预期、检测并处理 此类循环。

安全和性能风险：如果未检测并缓解 循环，递归解引用可能导致：

• 软件中的无限循环或 栈溢出。
• 资源耗尽（例如内存、网络或 CPU）。
• 客户端或中介中的拒绝服务（DoS）漏洞。

缓解指导：鼓励递归跟随外部 DID 文档引用的组件 跟踪已经解引用过的标识符， 并检测循环何时发生，然后采取适当行动。 此外，开发者可能希望限制递归深度或广度， 以减少潜在攻击面。

DID 解析器和 DID URL 解引用器将能够 记录其服务收到的解析和解引用请求。随着时间推移， 这些日志可用于跟踪请求这些服务的客户端并为其画像。 为缓解此隐私风险，客户端应向其信任的服务发出此类请求， 例如，因为存在既有业务 关系，或因为该服务运行在其控制的基础设施上。

客户端还可以采取步骤混淆其向服务发出的请求，以降低 关联和画像分析的可能性。混淆技术 包括 Oblivious HTTP、使用可信代理执行解析 请求，以及使用可信缓存。

不同 DID 方法会根据方法的设计决策和底层 VDR 具有不同的额外隐私影响和考量。 建议实现者审查其打算支持的 特定 DID 方法的隐私考量。鼓励 DID 方法设计者遵循 W3C 威胁建模指南 来生成威胁模型，以帮助实现者理解方法设计的 隐私影响。