一个 符合规范的DID解析器 是任何实现为软件和/或硬件的算法，它遵守 中的相关规范性声明。

一个 符合规范的DID URL解引用器 是任何实现为软件和/或硬件的算法，它遵守 中的相关规范性声明。

DID解析选项

此结构中的可能属性及其可能值在DID规范注册表 [[?DID-SPEC-REGISTRIES]] 中注册。本规范定义了以下常见属性。

accept

调用者首选的 DID文档 的媒体类型。媒体类型必须表示为 ASCII 字符串。DID解析器 实现应使用此值来确定返回的 didDocument 的 表示，如果支持并可用此类 表示。此属性是可选的。

expandRelativeUrls

一个布尔标志，指示 DID解析器 将 相对DID URL 扩展为符合 DID URL语法 的绝对DID URL。

versionId

参见 中的定义。

versionTime

参见 中的定义。

DID解析元数据

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

contentType

返回的 didDocument 的媒体类型。此属性是可选的。如果存在，此属性的值必须是一个 ASCII 字符串，它是符合规范的 表示 的媒体类型。在这种情况下，resolve 函数的调用者必须使用此值来确定如何解析和处理 didDocument。

error

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

invalidDid

提供给 DID解析 函数的 DID 不符合有效语法。（参见 。）

notFound

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

representationNotSupported

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

DID文档元数据

此结构中的可能属性及其可能值应在DID规范注册表 [[?DID-SPEC-REGISTRIES]] 中注册。本规范定义了以下常见属性。

created

DID文档 元数据应包括一个 created 属性，以指示 创建操作 的时间戳。属性的值必须是一个 字符串，格式化为 XML 日期时间，规范化为 UTC 00:00:00，并且不包含亚秒级小数精度。例如：2020-12-20T19:17:47Z。

updated

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

deactivated

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

nextUpdate

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

versionId

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

nextVersionId

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

equivalentId

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

DID文档 元数据可以包含一个 equivalentId 属性。如果存在，值必须是一个 集合，其中每个项目是一个 字符串，符合 中的规则。关系是每个 equivalentId 值在逻辑上等同于 id 属性值，因此指的是相同的 DID主体。每个 equivalentIdDID值必须由与 id 属性值相同的 DID方法 生成，并且是该 DID方法 的一种形式。（例如，did:example:abc == did:example:ABC）

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

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

equivalentId 是一种比 alsoKnownAs 更强的等价形式，因为等价性必须由治理的 DID方法 保证。equivalentId 表示一个完整的图合并，因为相同的 DID文档 描述了 equivalentId DID 和 id 属性 DID。

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

canonicalId

canonicalId 属性与 equivalentId 属性相同，除了：a) 它与单个值而不是集合相关联，b) DID 被定义为包含 DID文档 范围内的 DID主体 的规范 ID。

DID文档 元数据可以包含一个 canonicalId 属性。如果存在，值必须是一个 字符串，符合 中的规则。关系是 canonicalId 值在逻辑上等同于 id 属性值，并且 canonicalId 值由 DID方法 定义为包含 DID文档 范围内的 DID主体 的规范 ID。一个 canonicalId 值必须由与 id 属性值相同的 DID方法 生成，并且是该 DID方法 的一种形式。（例如，did:example:abc == did:example:ABC）。

一个符合规范的 DID方法 规范必须保证 canonicalId 值在逻辑上等同于 id 属性值。

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

canonicalId 是与 equivalentId 相同的等价性声明，除了它被约束为单个值，该值被定义为包含 DID文档 范围内的 DID主体 的规范。与 equivalentId 一样，canonicalId 表示一个完整的图合并，因为相同的 DID文档 描述了 canonicalIdDID和 id 属性 DID。

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

算法

以下 DID解析 算法必须由符合规范的 DID解析器 实现。

1. 验证 输入 DID 是否符合 DID语法 中的 `did` 规则。 如果不符合，DID解析器 必须返回以下结果：
   1. didResolutionMetadata: «[ "error" → "invalidDid", ... ]»
   2. didDocument: null
   3. didDocumentMetadata: «[ ]»
2. 确定 输入 DID 的DID方法是否由实现此算法的 DID解析器 支持。如果不支持，DID解析器 必须返回以下结果：
   1. didResolutionMetadata: «[ "error" → "methodNotSupported", ... ]»
   2. didDocument: null
   3. didDocumentMetadata: «[ ]»
3. 通过执行 读取 操作，从 输入 DID 的 可验证数据注册表 中获取 DID文档，如 输入 DID方法 所定义：
   1. 除了 输入 DID 外，此算法的所有其他 解析选项 都必须传递给 输入 DID方法 的 读取 操作。
   2. 如果 输入 DID 不存在，返回以下结果：
      1. didResolutionMetadata: «[ "error" → "notFound", ... ]»
      2. didDocument: null
      3. didDocumentMetadata: «[ ]»
   3. 如果 输入 DID 已被停用，返回以下结果：
      1. didResolutionMetadata: «[ ... ]»
      2. didDocument: null
      3. didDocumentMetadata: «[ "deactivated" → true, ... ]»
   4. 否则，读取 操作的结果称为 输出 DID文档。此结果必须以与 accept 输入 DID解析选项 对应的符合规范的 表示 表示。
4. 如果 输入 DID解析选项 包含值为 true 的 expandRelativeUrls 选项：
   1. 遍历 服务、验证方法 和 验证关系 中的所有 输出 DID文档。
   2. 如果 服务 或 验证方法 的 id 属性值（包括嵌入在 验证关系 中的值）是 相对DID URL，或者如果 验证关系 是 相对DID URL：
      1. 根据 相对DID URL 的规则，将 相对DID URL 解析为符合 DID URL语法 的绝对 DID URL。
   3. 更新 输出 DID文档，将 相对DID URL 替换为解析后的绝对 DID URL。
5. 返回以下结果：
   1. didResolutionMetadata: «[ ... ]»
   2. didDocument: 输出DID文档
   3. didDocumentMetadata: «[ "contentType" → 输出DID文档媒体类型, ... ]»

关于如何处理已被 停用 的DID的讨论正在进行中。

指定在DID解析过程中如何验证DID文档上的签名/证明。

我们是否应该定义功能，使客户端能够发现 DID解析器 支持的 DID方法 列表或其他功能？或者这是实现特定的，超出本规范的范围？例如，参见 这里 和 这里。

DID URL解引用选项

此结构中的可能属性及其可能值应在DID规范注册表 [[?DID-SPEC-REGISTRIES]] 中注册。本规范定义了以下常见的解引用选项属性：

accept

调用者首选的 contentStream 的媒体类型。媒体类型必须表示为 ASCII 字符串。DID URL解引用 实现应使用此值来确定返回的 表示 的 contentType，如果支持并可用此类 表示。

DID URL解引用元数据

此结构中的可能属性及其可能值已在DID规范注册表 [[?DID-SPEC-REGISTRIES]] 中注册。本规范定义了以下常见属性。

contentType

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

error

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

invalidDID URL

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

notFound

DID URL解引用器 无法找到此解引用请求产生的 contentStream。

算法

以下 DID URL解引用 算法必须由符合规范的 DID解析器 实现。根据 [[RFC3986]]，它包含以下三个步骤：解析DID；解引用资源；以及解引用片段（仅当 输入 DID URL 包含 DID片段 时）：

示例

给定以下 输入 DID URL：

did:example:123456789abcdefghi#keys-1

... 以及以下 解析的 DID文档：

{
	"@context": "https://www.w3.org/ns/did/v1",
	"id": "did:example:123456789abcdefghi",
	"verificationMethod": [{
		"id": "did:example:123456789abcdefghi#keys-1",
		"type": "Ed25519VerificationKey2018",
		"controller": "did:example:123456789abcdefghi",
		"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
	}],
	"service": [{
		"id": "did:example:123456789abcdefghi#agent",
		"type": "AgentService",
		"serviceEndpoint": "https://agent.example.com/8377464"
	}, {
		"id": "did:example:123456789abcdefghi#messages",
		"type": "MessagingService",
		"serviceEndpoint": "https://example.com/messages/8377464"
	}]
}

... 那么 算法的结果是以下 输出资源：

{
	"@context": "https://www.w3.org/ns/did/v1",
	"id": "did:example:123456789abcdefghi#keys-1",
	"type": "Ed25519VerificationKey2018",
	"controller": "did:example:123456789abcdefghi",
	"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}

给定以下 输入 DID URL 和与上述相同的 解析的 DID文档：

did:example:123456789abcdefghi?service=messages&relativeRef=%2Fsome%2Fpath%3Fquery#frag

... 那么 算法的结果是以下 输出 服务端点 URL：

https://example.com/messages/8377464/some/path?query#frag

更改图表和/或示例以使其一致。

方法架构

DID解析 算法涉及根据其 DID方法 对 DID 执行 读取 操作（参见 ）。

例如，提到“解析”对等/离链/微链/边缘链DID的含义（例如，参见 [[DID-PEER]] 和 这里）。

例如，提到“解析”仅仅是包装的公钥的DID的含义（例如，参见 [[DID-KEY]] 和 这里）。

根据 DID方法 的“读取”操作的确切性质，DID解析器 与 可验证数据注册表 之间的交互可以实现为 可验证读 或 不可验证读：

可验证读 最大限度地提高了对“读取”操作结果的完整性和正确性的信心——在适用的 DID方法 下尽可能做到这一点。它可以通过多种方式实现，例如：

• 如果可以通过本地、受信任的网络主机访问 可验证数据注册表，则“读取”操作可能被视为“可验证”。在基于区块链的 DID方法 中，可以在本地网络主机上运行区块链全节点以实现 可验证读。
• DID解析器 可以远程连接到 可验证数据注册表，但有一些方法可以验证“读取”操作响应的内容。在基于区块链的 DID方法 中，即使无法直接访问区块链全节点，仍然可以通过运行轻客户端来处理元数据以验证“读取”操作的结果是否被篡改。
• 如果通过远程网络主机访问 可验证数据注册表，并且该主机被认为是可信的，因为它运行在家中的个人设备上并通过安全通道访问，则可以实现 可验证读。

不可验证读没有这样的保证，因此不太理想，例如：

• 如果访问可验证数据注册表是通过远程的、不可信的中介进行的，那么“读取”操作可能被认为是“不可验证的”。在基于区块链的DID方法中，第三方操作的远程区块链浏览器API可能被用来从区块链中查找数据。

是否可以进行可验证读不仅取决于DID方法本身，还取决于DID解析器的实现方式。DID方法可以定义多种不同的“读取”操作实现方式，并且应该至少提供一种实现可验证读的指导。

可验证读的保证仍然始终受到底层可验证数据注册表的架构、协议、加密和其他方面的限制。最强的可验证读实现形式被认为是不需要与远程网络进行任何交互的形式（例如，参见[[DID-KEY]]），或者将依赖特定网络基础设施的需求降到最低，并将“信任根”仅归结为经过验证的熵和加密（例如，参见[[KERI]]）。

TODO: 描述客户端如何在不信任DID解析器的情况下独立验证“读取”操作的结果（例如，使用状态证明）。

一个DID解析器必须支持至少一种DID方法的DID解析算法，并且可以支持多种DID方法：

在这种情况下，上述关于可验证读和不可验证读实现的考虑适用于每个支持的DID方法。

解析器架构

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

TODO: 讨论在受限用户代理（如移动应用和浏览器）中的DID解析。

代理解析

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

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

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

客户端解引用

DID URL解引用算法的不同部分可以由解析器架构的不同组件执行。

具体来说，当解引用带有DID片段的DID URL时，解引用资源由DID解析器完成，而解引用片段由客户端完成。

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

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

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

示例

{
	"@context": "https://w3id.org/did-resolution/v1",
	"didDocument": {
		"@context": "https://www.w3.org/ns/did/v1",
		"id": "did:example:123456789abcdefghi",
		"authentication": [{
			"id": "did:example:123456789abcdefghi#keys-1",
			"type": "Ed25519VerificationKey2018",
			"controller": "did:example:123456789abcdefghi",
			"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
		}],
		"service": [{
			"id":"did:example:123456789abcdefghi#vcs",
			"type": "VerifiableCredentialService",
			"serviceEndpoint": "https://example.com/vc/"
		}]
	},
	"didResolutionMetadata": {
		"contentType": "application/did+ld+json",
		"retrieved": "2024-06-01T19:73:24Z",
	},
	"didDocumentMetadata": {
		"created": "2019-03-23T06:35:22Z",
		"updated": "2023-08-10T13:40:06Z",
		"method": {
			"nymResponse": {
				"result": {
					"data": "{\"dest\":\"WRfXPg8dantKVubE3HX8pw\",\"identifier\":\"V4SGRU86Z58d6TV7PBUe6f\",\"role\":\"0\",\"seqNo\":11,\"txnTime\":1524055264,\"verkey\":\"H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV\"}",
					"type": "105",
					"txnTime": 1.524055264E9,
					"seqNo": 11.0,
					"reqId": 1.52725687080231475E18,
					"identifier": "HixkhyA4dXGz9yxmLQC4PU",
					"dest": "WRfXPg8dantKVubE3HX8pw"
				},
				"op": "REPLY"
			},
			"attrResponse": {
				"result": {
					"identifier": "HixkhyA4dXGz9yxmLQC4PU",
					"seqNo": 12.0,
					"raw": "endpoint",
					"dest": "WRfXPg8dantKVubE3HX8pw",
					"data": "{\"endpoint\":{\"xdi\":\"http://127.0.0.1:8080/xdi\"}}",
					"txnTime": 1.524055265E9,
					"type": "104",
					"reqId": 1.52725687092557056E18
				},
				"op": "REPLY"
			}
		}
	}
}

参见相应的开放问题。

需要定义此数据结构的确切工作方式，以及它是否始终包含DID文档，或者也可以包含其他结果。

DID文档

与DID关联的DID文档。的结果。

DID解析元数据

这是一个元数据结构（参见[[DID-CORE]]中的元数据结构部分），包含有关DID解析过程的元数据。

此元数据通常在DID解析函数的调用之间变化，因为它表示解析过程本身的数据。

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

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

• 返回内容的媒体类型（contentType元数据属性）。
• 错误代码（error元数据属性）。
• DID解析过程的持续时间。
• 有关DID文档的缓存信息（参见部分）。
• 在DID解析过程中使用的各种URL、IP地址或其他网络信息。
• 由DID解析器添加的证明（例如，以建立可信解析）。

另请参见[[DID-CORE]]中的DID解析元数据部分。

DID文档元数据

这是一个元数据结构（参见[[DID-CORE]]中的元数据结构部分），包含有关DID文档的元数据。

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

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

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

• DID及其关联DID文档创建或更新的时间戳（created和updated元数据属性）。
• 有关控制器、能力、委托等的元数据。
• DID文档的版本信息（参见部分）。
• 由DID控制者添加的证明（例如，以建立控制权限）。

DID文档元数据还可以包括方法特定的元数据，例如：

• 来自可验证数据注册表的状态证明。
• 区块链或其他可验证数据注册表中的记录的区块号、索引、交易哈希、确认次数等。

另请参见[[DID-CORE]]中的DID文档元数据部分。

示例

{
	"@context": "https://w3id.org/did-resolution/v1",
	"content": {
		"@context": "https://www.w3.org/ns/did/v1",
		"id": "did:example:123456789abcdefghi",
		"authentication": [{
			"id": "did:example:123456789abcdefghi#keys-1",
			"type": "Ed25519VerificationKey2018",
			"controller": "did:example:123456789abcdefghi",
			"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
		}],
		"service": [{
			"id":"did:example:123456789abcdefghi#vcs",
			"type": "VerifiableCredentialService",
			"serviceEndpoint": "https://example.com/vc/"
		}]
	},
	"DID URLDereferencingMetadata": {
		"contentType": "application/did+ld+json",
		"retrieved": "2024-06-01T19:73:24Z",
	},
	"contentMetadata": {
		"created": "2019-03-23T06:35:22Z",
		"updated": "2023-08-10T13:40:06Z",
		"method": {
			"nymResponse": {
				"result": {
					"data": "{\"dest\":\"WRfXPg8dantKVubE3HX8pw\",\"identifier\":\"V4SGRU86Z58d6TV7PBUe6f\",\"role\":\"0\",\"seqNo\":11,\"txnTime\":1524055264,\"verkey\":\"H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV\"}",
					"type": "105",
					"txnTime": 1.524055264E9,
					"seqNo": 11.0,
					"reqId": 1.52725687080231475E18,
					"identifier": "HixkhyA4dXGz9yxmLQC4PU",
					"dest": "WRfXPg8dantKVubE3HX8pw"
				},
				"op": "REPLY"
			},
			"attrResponse": {
				"result": {
					"identifier": "HixkhyA4dXGz9yxmLQC4PU",
					"seqNo": 12.0,
					"raw": "endpoint",
					"dest": "WRfXPg8dantKVubE3HX8pw",
					"data": "{\"endpoint\":{\"xdi\":\"http://127.0.0.1:8080/xdi\"}}",
					"txnTime": 1.524055265E9,
					"type": "104",
					"reqId": 1.52725687092557056E18
				},
				"op": "REPLY"
			}
		}
	}
}

内容

与DID URL关联的任意内容。的结果。

DID URL解引用元数据

这是一个元数据结构（参见[[DID-CORE]]中的元数据结构部分），包含有关DID URL解引用过程的元数据。

此元数据通常在DID URL解引用函数的调用之间发生变化，因为它表示有关解引用过程本身的数据。

添加更多关于DID URL解引用元数据如何工作的细节。

另见[[DID-CORE]]中的DID URL解引用元数据部分。

内容元数据

这是一个元数据结构（参见[[DID-CORE]]中的元数据结构部分），包含有关内容的元数据。

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

添加更多关于内容元数据如何工作的细节。

HTTP(S) 绑定

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

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

使用此绑定，DID解析功能（参见）和/或DID URL解引用功能（参见）可以按以下方式执行：

1. 使用DID解析器 HTTP(S) 端点初始化请求HTTP(S) URL。

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

2. 对于DID解析功能：
   1. 将输入 DID附加到请求HTTP(S) URL。

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

   2. 将Accept HTTP 请求头设置为`application/ld+json;profile="https://w3id.org/did-resolution"`以请求完整的，或者
   3. 将Accept HTTP 请求头设置为解析选项中的accept值。
   4. 如果提供了其他解析选项：
      1. 输入 DID必须进行URL编码（如RFC3986 第2.1节所指定）。
      2. 将所有解析选项（除了accept）编码为请求HTTP(S) URL中的查询参数。

         https://resolver.example/1.0/identifiers/did%3Aexample%3A1234?option1=value1&option2=value2

3. 对于DID URL解引用功能：
   1. 将输入 DID URL附加到请求HTTP(S) URL。

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

   2. 将Accept HTTP 请求头设置为`application/ld+json;profile="https://w3id.org/did-url-dereferencing"`以请求完整的，或者
   3. 将Accept HTTP 请求头设置为解引用选项中的accept值。
   4. 如果提供了其他解引用选项：
      1. 输入 DID URL必须进行URL编码（如RFC3986 第2.1节所指定）。
      2. 将所有解引用选项（除了accept）编码为请求HTTP(S) URL中的查询参数。

         https://resolver.example/1.0/identifiers/did%3Aexample%3A1234%3Fservice%3Dfiles%26relativeRef%3D%2Fresume.pdf?option1=value1&option2=value2

4. 在请求HTTP(S) URL上执行HTTP GET请求。这将调用远程DID解析器上的DID解析或DID URL解引用功能。
5. 如果DID解析或DID URL解引用功能在didResolutionMetadata或dereferencingMetadata中返回error元数据属性， 则HTTP响应状态码必须对应于error元数据属性的值，根据以下表格：

   错误	HTTP 状态码
   invalidDid	400
   invalidDID URL	400
   notFound	404
   representationNotSupported	406
   methodNotSupported	501
   internalError	500
   （其他值）	500

6. 如果DID解析或DID URL解引用功能在didDocumentMetadata或contentMetadata中返回deactivated元数据属性，且其值为true：
   1. HTTP响应状态码必须为410。
7. 对于DID解析功能：
   1. 如果Content-Type HTTP 响应头的值为`application/ld+json;profile="https://w3id.org/did-resolution"`：
      1. HTTP 主体必须包含DID解析结果（参见），这是DID解析功能的结果。
   2. 如果功能成功并返回didDocument：
      1. HTTP响应状态码必须为200。
      2. HTTP响应必须包含Content-Type HTTP 响应头。其值必须为didResolutionMetadata中的contentType元数据属性的值（参见）。
      3. HTTP响应主体必须包含DID解析功能的结果didDocument，其表示形式对应于Content-Type HTTP 响应头。
8. 对于DID URL解引用功能：
   1. 如果Content-Type HTTP 响应头的值为`application/ld+json;profile="https://w3id.org/did-url-dereferencing"`：
      1. HTTP 主体必须包含DID URL解引用结果（参见），这是DID URL解引用功能的结果。
   2. 如果功能成功并返回contentStream，且contentType元数据属性的值为text/uri-list：
      1. HTTP响应状态码必须为303。
      2. HTTP响应必须包含Location头。该头的值必须为输出 服务端点 URL。
      3. HTTP响应主体必须为空。
   3. 如果功能成功并返回contentStream，且contentType为其他值：
      1. HTTP响应状态码必须为200。
      2. HTTP响应必须包含Content-Type HTTP 响应头。其值必须为dereferencingMetadata中的contentType元数据属性的值（参见）。
      3. HTTP响应主体必须包含DID URL解引用功能的结果contentStream，其表示形式对应于Content-Type HTTP 响应头。

DID解析示例

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

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

以及以下输入 DID：

did:sov:WRfXPg8dantKVubE3HX8pw

则请求HTTP(S) URL为：

https://resolver.example/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw

可以通过以下方式调用HTTP(S)绑定：

curl -X GET https://resolver.example/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw

HTTP(S)绑定的其他示例：

DID URL解引用示例

HTTP(S)绑定的其他示例：

输入

服务端点构建算法的输入是一个输入 DID URL和一个输入 服务端点 URL。

服务端点构建算法的输入要求如下：

• 输入 DID URL和输入 服务端点 URL都可以有path组件。
• 输入 DID URL和输入 服务端点 URL不能同时有query组件。
• 输入 DID URL和输入 服务端点 URL不能同时有fragment组件。
• 输入 服务端点 URL必须是HTTP(S) URL。

算法

1. 将字符串输出服务端点URL初始化为输入服务端点URL的值
2. 如果输出服务端点URL包含query组件，则移除该组件
3. 如果输出服务端点URL包含fragment组件，则移除该组件
4. 将输入DID URL的path组件追加到输出服务端点URL中
5. 如果输入服务端点URL包含query组件，则在输出服务端点URL后追加?加上query
6. 如果输入DID URL包含query组件，则在输出服务端点URL后追加?加上query
7. 如果输入服务端点URL包含fragment组件，则在输出服务端点URL后追加#加上fragment
8. 如果输入DID URL包含fragment组件，则在输出服务端点URL后追加#加上fragment
9. 返回输出服务端点URL

我们可能允许输入DID URL和输入服务端点URL同时包含query组件，前提是它们都包含可以合并的键/值参数列表。

服务端点构建算法的细节已在2019年4月的CCG邮件列表中讨论过，例如这里或这里。

我们可以考虑复用[[RFC3986]]中定义的“相对解析”算法，而不是定义自己的算法。

参见对应的开放问题。

示例

给定以下输入服务端点URL：

https://example.com/messages/8377464

以及以下输入DID URL：

did:example:123456789abcdefghi?service=messages&relativeRef=%2Fsome%2Fpath%3Fquery#frag

则输出服务端点URL为：

https://example.com/messages/8377464/some/path?query#frag

认证/授权

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

一个相关主题是DID文档（或部分）是否可以加密，例如w3c/did-core/issues/25。另见IPIDDID方法中片段的使用。

缓存

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

可以使用noCache解析选项来请求特定的缓存行为。

此解析选项是可选的。

该属性的可能值包括：

• `"false"`（默认值）：允许缓存DID文档。
• `"true"`：请求禁用缓存，并从可验证数据注册表中获取最新的DID文档。

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

参见对应的开放问题。

或许我们可以复用其他协议（如HTTP）的缓存机制。

版本控制

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

DID参数versionId 和versionTime 是互斥的。

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

DID文档元数据可能包含versionId 属性，该属性会随着每次对DID文档执行的更新操作而改变。

虽然大多数DID方法支持更新操作， 但DID方法并不需要保留所有先前的DID文档版本，因此并非所有DID方法都支持版本控制。

参见对应的开放问题。

非DID标识符

关于DID解析与非DID标识符（如域名、HTTP URI或电子邮件地址）解析之间关系的讨论正在进行中。这包括如何从非DID标识符中发现DID，以及如何使标识符之间的链接可验证。

DID方法治理

描述DID解析器应支持哪些方法，以及潜在的影响。

重定向

服务端点可能具有 一个serviceEndpoint属性，其值本身是一个DID。这被解释为从输入DID到另一个DID的“DID重定向”。在这种情况下，可以启动一个“子”DID解析过程以到达“最终”服务端点。

客户端可以提供follow-redirect解析选项作为提示，指示是否应遵循重定向。此解析选项是可选的。

参见对应的开放问题。

DID重定向不仅可以应用于单个服务端点，还可以应用于整个DID文档，从而实现可移植性用例。

{
   "id": "did:example:123456789abcdefghi#hub1",
   "type": "HubService",
   "serviceEndpoint": "did:example:xyz"
}

代理

DID文档可能包含“代理”服务类型，该类型将提供一个需要遵循的映射，以解析到最终的服务URL。

{
   "id": "did:example:123456789abcdefghi",
   "type": "ProxyService",
   "serviceEndpoint": "https://mydomain.com/proxy"
}

JSON指针