Decentralized Identifiers (DIDs) v1.0 机翻中文

Decentralized Identifiers (DIDs) v1.0

Core architecture, data model, and representations

W3C Working Draft 03 April 2020

Abstract

分布式标识符（DID）是一种可验证的分布式数字身份新型标识符。 DID标识DID的控制者可以决定标识任何主题（例如，人，组织，事物，数据模型，抽象实体等）。这些新的标识符旨在使DID的控制者能够证明对它的控制，并且可以独立于任何集中式注册机构、身份提供者或证书颁发机构而实施。 DID是将DID主题与DID文档相关联的URL，并且可与其进行可信交互。每个DID文档都可以表达密码材料，验证方法或服务端点，这些密码材料、服务端点提供了一组机制，这些机制使DID控制者能够证明对DID的控制。服务端点启用与DID主题关联的可信交互。 DID文档可能包含有关它标识的主题的语义。 DID文档可能包含DID主题本身（例如，数据模型）。

本文档为DID，DID文档和DID方法指定了通用数据模型，URL格式和一组操作。

1. Introduction

传统的身份管理系统基于集中式机构，例如公司目录服务，证书机构或域名注册机构。从加密信任验证的角度来看，这些集中管理机构中的每一个都充当其自己的信任根。为了使身份管理跨这些系统工作，需要实施联合身份管理。

分布式账本技术（DLT）和区块链技术的出现为完全分散的身份管理提供了机会。在去中心化身份系统中，实体（即，但不限于个人，组织和事物等离散的可识别单元）可以自由使用任何共享的信任根。全球分布的分类帐，分布式的P2P网络或其他具有类似功能的系统提供了一种管理信任根的方法，而无需引入集中式授权或单点故障。结合使用DLT和分布式身份管理系统，任何实体都可以在任意数量的分布式独立信任根上创建和管理自己的标识符。

实体由分布式标识符（DID）标识，并可以使用证明（例如，数字签名，隐私保护生物特征协议等）进行身份验证。 DID指向DID文档。 DID文档包含一组服务端点，用于与DID标识的实体（即DID主题）进行交互。按照设计中的隐私权准则，任何实体都可以具有必要的DID（以及相应的DID文档和服务端点），以尊重实体所需的身份，角色和上下文的分隔（从日常意义上讲）。

DID方法是在特定的分布式分类帐或网络上创建，读取，更新和停用DID及其关联的DID文档的机制。 DID方法是使用单独的DID方法规范定义的。

这种设计消除了对标识符的集中注册机构以及对密钥管理的集中证书颁发机构的依赖，密钥管理是分层PKI（公钥基础结构）中的标准。如果DID注册中心是分布式分类帐，则每个实体都可以充当其自己的根权限。该体系结构称为DPKI（分布式PKI）。

NOTE

还可以为在联合或集中身份管理系统中注册的标识符开发DID方法。 实际上，所有类型的标识符系统都可以添加对DID的支持。 这在集中标识符，联合标识符和分散标识符之间建立了互操作性桥梁。

本规范的第一个目的是定义可以对任何DID注册表实现的通用DID方案和对DID文档的通用操作集。 该规范的第二个目的是为DID方法规范定义一致性要求。 DID方法规范是一个单独的文档，为特定的DID注册机构定义了特定的DID方案和一组特定的DID文档操作。

具有特定DID方法规范的通用DID规范的分层设计引入了一些与URI规范相同的概念：

  • 来自不同DID方法的DID可能无法互操作，就像来自不同URI方案的URI可能不可互操作一样。
  • 实体可能需要多个DID来支持不同的关系，因为另一方可能仅支持某些DID方法，就像某些浏览器可能仅支持某些URI方案一样。
  • 实体可能需要多个DID以支持不同DID方法的不同加密方案，因为并非所有参与方都将以相同的方式（并非所有浏览器都支持相同的URI方案）来支持相同的加密方案。
  • 管理多个DID并跟踪哪个DID属于哪个关系，在哪种加密方案下，引入了类似的logistical challenges，例如管理多个Web地址并跟踪哪个地址属于哪个网站，或者跟踪哪个电子邮件地址属于哪个关系。

For a list of DID methods and their corresponding specifications, see the DID Method Registry [DID-METHOD-REGISTRY].

1.1 A Simple Example

DID是一个简单的文本字符串，由三部分组成：

  • URL scheme identifier (did)
  • Identifier for the DID method
  • DID method-specific identifier.

EXAMPLE 1: A simple example of a decentralized identifier (DID)

did:example:123456789abcdefghi

上面的示例DID解析为DID文档。 DID文档包含与DID相关的信息，例如在DID的控制下以密码学方式对实体进行身份验证的方式，以及可用于与实体进行交互的服务。

EXAMPLE 2: Minimal self-managed DID document

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    // used to authenticate as did:...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "service": [{
    // used to retrieve Verifiable Credentials associated with the DID
    "id":"did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

1.2 Design Goals

分布式标识符是大型系统的组成部分，例如可验证凭证生态系统[VC-DATA-MODEL]，该系统推动了此规范的设计目标。 本节总结了此规范的主要设计目标。

Goal Description
Decentralization 消除了对标识符管理中的集中管理机构或单点故障的要求，包括全局唯一标识符，公共验证密钥，服务端点和其他元数据的注册。
Control 赋予实体人类和非人类实体直接控制其数字标识符的权力，而无需依赖外部权威。
Privacy 使实体能够控制其信息的隐私，包括对属性或其他数据的最小，选择性和逐步公开。
Security 为依赖方提供足够的安全性，以使其依赖DID文档获得所需的保证级别。
Proof-based 与其他实体进行交互时，使DID主题能够提供加密证明。
Discoverability 使实体可以发现其他实体的DID，以了解更多有关这些实体或与这些实体进行交互的信息。
Interoperability 使用可互操作的标准，以便DID基础结构可以利用为互操作性而设计的现有工具和软件库。
Portability 不受系统和网络的影响，并使实体能够在支持DID和DID方法的任何系统上使用其数字标识符。
Simplicity 支持减少的一组简单功能，以使该技术更易于理解，实施和部署。
Extensibility 在可能的情况下，启用可扩展性，前提是它不会极大地妨碍互操作性，可移植性或简单性。

1.3 Interoperability

  • DID方法名称是唯一的，未被现有的、不兼容的DID方法使用。
  • 支持所需的操作。
  • 描述了需要描述的操作。
  • 规范足够具体，详细且完整，足以独立实施。
  • 规范包含描述安全和隐私注意事项的部分。

DID和DID文档的生产者和消费者的互操作性通过确保DID和DID文档相符来实现。 每个DID方法规范中的详细信息都提供了DID方法规范的互操作性。 可以理解，以与不需要Web浏览器来实现所有已知URI方案相同的方式，不需要与DID兼容的兼容软件来实现所有已知的DID方法。 但是，给定DID方法的所有实现必须对该方法可互操作。

2. Terminology

本文档试图通过使用专门术语讨论特定概念来传达在分布式标识符空间中概述的概念。 该术语包含在下面，并链接到整个文档中以帮助读者：

  • blockchain
    • 一种特定类型的[分布式分类帐技术]（DLT），它将分类帐条目存储在事务块中，这些事务块被分组在一起并哈希成一个加密链。 由于这种类型的[DLT]由[Bitcoin]引入，因此有时使用术语blockchain专门指代比特币分类帐。
  • decentralized identifier (DID)
    • 全局唯一的标识符，因为它已通过分布式分类帐技术（DLT）或其他形式的分散式网络进行注册，因此不需要集中式注册机构。 DID的通用格式在本规范中定义。 在DID方法规范中定义了特定的DID方案。
  • decentralized identity management
    • 基于分布式标识符的身份管理。 分布式身份管理将标识符创建权限扩展到X.500目录服务，域名系统和大多数国家标识系统所需的传统信任根之外。
  • DID controller
    • 能够更改DID文档的实体。 一个DID可以有多个控制器。 DID控制器由DID文档顶层的controller属性表示。 请注意，DID控制器可能包括DID主题。
  • DID document
    • 描述DID主题的一组数据，包括DID主题可以用来认证自己并证明其与DID关联的机制，例如公钥和匿名生物测定。 DID文档可能还包含描述主题的其他属性或声明。 这些文档是基于图形的数据结构，通常使用[JSON-LD]表示，但是可以使用其他兼容的基于图形的数据格式表示。
  • DID fragment
    • DID URL中位于第一个哈希符号字符（＃）之后的部分。 DID片段语法与URI片段语法相同。
  • DID method
    • 有关如何在特定的分布式分类帐或网络上实施特定DID方案的定义，包括解析和停用DID以及编写和更新DID文档的精确方法。
  • DID path
    • DID URL的开头并包括第一个正斜杠字符（/）的部分。 DID路径语法与URI路径语法相同。
  • DID query
    • DID URL中第一个问号字符（？）之后的部分。 DID查询语法与URI查询语法相同。
  • DID registry
    • 系统执行的角色是调解分散标识符的创建，验证，更新和停用。 DID注册表是一种可验证的数据注册表。 有关更多信息，请参见[VC-DATA-MODEL]。
  • DID resolver
    • 能够检索给定DID的DID文档的系统。 这些系统在DID解析规范[DID-RESOLUTION]中指定。
  • DID scheme
    • 分布式标识符的形式语法。 在本规范中定义了通用DID方案。 单独的DID方法规范定义了与该特定DID方法一起使用的特定DID方案。
  • DID subject
    • DID文档所涉及的实体。 即，由DID标识并由DID文档描述的实体。
  • DID URL
    • DID加上可选的DID路径，可选的？ 字符后跟DID查询，以及可选的＃字符后跟DID片段。
  • distributed ledger (DLT)
    • 一个分布式数据库，其中的各个节点使用共识协议来维护共享分类帐，在该分类帐中，每个交易都经过密码签名并链接到先前的交易。
  • extensible data interchange (XDI)
    • OASIS XDI技术委员会定义的语义图格式和语义数据交换协议。
  • JSON Pointer
    • 根据[RFC6901]的定义，定义用于标识JavaScript对象表示法（JSON）文档中特定值的字符串语法。
  • public key description
    • DID文档中包含的JSON对象，其中包含使用公共密钥或验证密钥所需的所有元数据。
  • service endpoint
    • 服务代表DID主题运行的网络地址。 特定服务的示例包括发现服务，社交网络，文件存储服务和可验证的声明存储库服务。 服务端点也可以由通用数据交换协议（例如可扩展数据交换）提供。
  • Uniform Resource Identifier (URI)
    • 标识符，由[RFC3986]定义。
  • verification method
    • 独立验证证明所需的一组参数，例如将在证明中使用的公/私钥对的标识符。
  • Universally Unique Identifier (UUID)
    • 标识符，由[RFC4122]定义。

3. Overall Architecture

3.1 DIDs

3.2 DID Registries

3.3 DID Documents

DID文档是与分布式标识符（DID）关联的资源。 DID文档通常表示可用于与DID控制器进行交互的验证方法（例如公用密钥）和服务。

如第8节中所述，DID文档将根据特定语法进行序列化。 DID本身包含在id属性中。

§3.3 DID文档中概述了DID文档中可能存在的属性。

DID文档中存在的属性可以根据第9节中的方法概述的适用操作进行更新。

3.4 DID Resolvers and DID Resolution

3.5 Security and Privacy

4. Conformance

除了标记为非规范性的部分，本规范中的所有创作指南、图表、示例和注释都是非规范性的。本规范中的其他所有内容都是标准化的。

本文档中的关键词MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD和SHOULD NOT应按BCP 14 [RFC2119] [RFC8174]中的描述，当且仅当它们出现在所有大写字母中时， 如此处所示。

本文档包含包含JSON，CBOR和JSON-LD内容的示例。 其中一些示例包含无效字符，例如内联注释（//）以及使用省略号（...）表示对示例几乎没有价值的信息。 如果实现者希望将信息用作有效的JSON，CBOR或JSON-LD，则应警告他们删除此内容。

conforming DID是第5节中指定的规则的任何具体表达。标识符和务必遵守该节中的相关规范性声明。

conforming DID Document 是本规范中描述的数据模型的任何具体表达，并且必须遵守第§6.数据模型和第7.节“核心属性”中的相关规范性声明。 符合文件的序列化格式必须是确定的，双向的且无损的，如第8节中所述。核心表示。 合格的DID文档可以任何序列化格式传输或存储。

conforming DID Method是符合第§9节“方法”中有关规范性声明的任何规范。

producer是实现为软件和/或硬件的任何算法，并且如果生成符合要求的DID或符合要求的DID文档，则符合该规范。 符合本规范的生产者不得生产不合格的DID或DID文档。

consumer是实现为软件和/或硬件的任何算法，如果它使用符合要求的DID或符合要求的DID文档，则符合该规范。 符合此规范的使用者在使用不合格的DID或DID文档时必须产生错误。

5. Identifier

全局唯一的分散标识符的概念并不新鲜。 通用唯一标识符（UUID）最早是在1980年代开发的，后来成为开放软件基金会的分布式计算环境的标准功能。 UUID通过使用一种算法来生成全局唯一性，而无需使用集中式注册表服务，该算法可生成具有足够熵的128位值，从而使碰撞的机会极小。 UUID在[RFC4122]中正式指定为统一资源名称（URN）的特定类型。

DID与UUID相似，不同之处在于：

  • 像URL一样，它可以解析或取消引用描述主题的标准资源。 也就是DID文档。 有关更多信息，请参见第3.3节DID文档。
  • 与取消引用URL时返回的大多数资源不同，DID文档通常包含用于对DID主题进行身份验证的加密材料。

5.1 DID Syntax

5.1.1 Generic DID Syntax

通用DID方案是符合[RFC3986]的URI方案。

NOTE

DID始终标识DID主题。

以下是使用[RFC5234]中的语法的ABNF定义，该语法定义了ALPHA和DIGIT。 [RFC3986]中定义了该ABNF中未定义的所有其他规则名称。

did                = "did:" method-name ":" method-specific-id
method-name        = 1*method-char
method-char        = %x61-7A / DIGIT
method-specific-id = *( ":" *idchar ) 1*idchar
idchar             = ALPHA / DIGIT / "." / "-" / "_"

5.1.2 Method-Specific Syntax

DID方法规范必须通过定义自己的方法名称和方法特定的ID语法来进一步限制通用DID语法。 有关更多信息，请参见第9节“方法”。

5.1.3 Normalization

为了实现最广泛的互操作性，请使DID标准化尽可能简单和通用：

  • DID方案名称必须(MUST)为小写。
  • DID方法名称必须(MUST)为小写。
  • 第5.1.1节“通用DID语法”中的区分大小写和方法特定ID规则的值的规范化必须由控制性DID方法规范来定义。

5.1.4 Persistence

预期DID将是持久性的并且是不变的。 也就是说，DID唯一且永久地与其唯一主题绑定。 即使禁用了DID，也希望永远不要重新使用它。

理想情况下，DID应该是一个完全抽象的分布式标识符（如UUID），可以随时间绑定到多个基础DID注册表，从而保持其持久性独立于任何特定系统。 但是，在多个DID注册表上注册相同的标识符会带来非常困难的实体关系和start-of-authority （SOA）问题。 这也大大增加了开发人员的实现复杂性。

NOTE

为了避免这些问题，开发人员应参考f分布式特征规范[DID-RUBRIC]来确定哪种DID方法最能满足用例的需求。

NOTE

尽管未包含在此版本中，但此规范的将来版本可能支持DID文档equivID属性，以在表示多个DID注册管理机构上相同主题的DID之间建立可验证的等效关系。 这种等价关系可以产生单个持久性抽象DID的实际等价关系。 有关更多信息，请参见§D未来工作。

5.2 DID URL Syntax

5.2.1 Generic DID URL Syntax

DID URL始终标识要定位的资源。 例如，它可用于标识DID文档的特定部分。

以下是使用[RFC5324]中的语法的ABNF定义。 它建立在第5.1.1节“通用DID语法”中定义的did方案的基础上。 path-abempty, query和fragment组件与[RFC3986]中定义的ABNF规则相同。

did-url            = did *( ";" param ) path-abempty [ "?" query ]
                     [ "#" fragment ]
param              = param-name [ "=" param-value ]
param-name         = 1*param-char
param-value        = *param-char
param-char         = ALPHA / DIGIT / "." / "-" / "_" / ":" /
                     pct-encoded

5.2.2 Generic DID URL Parameters

DID URL语法基于矩阵参数语法（[MATRIX-URIS]）支持简单，通用的参数格式。 上面的ABNF指定了基本语法（param-name规则），但是没有指定任何具体的参数名称。

一些通用的DID参数名称（例如，用于服务选择）完全独立于任何特定的DID方法，并且对于所有DID务必(MUST)始终以相同的方式起作用。 某些DID方法可能(MAY)支持其他DID参数名称（例如，用于版本控制），但必须(MUST)在确实支持它们的DID方法之间统一操作。

第5.1.2节“特定于方法的语法”中描述了完全特定于方法的参数名称。

下表定义了一组通用DID参数名称。

Generic DID Parameter Name Description
hl DID文档的资源哈希，以添加完整性保护，如[HASHLINK]中所指定。
service 通过服务ID从DID文档中识别服务。
version-id 标识要解析的DID文档的特定版本（版本ID可以是顺序的，或者是UUID，或者是特定于方法的）。 请注意，并非所有DID方法都支持此参数。
version-time 标识要解析的DID文档的特定版本时间戳。 即，在特定时间对DID有效的DID文档。 请注意，并非所有DID方法都支持此参数。

这些参数的确切处理规则在[DID-RESOLUTION]中指定。

在DID URL中添加DID参数意味着该参数成为资源（DID文档或其他）标识符的一部分。 或者，也可以通过将不属于DID URL的选项传递给DID解析器来影响DID解析和DID URL解引用过程。 Such options could for example control caching or the desired encoding of a resolution result。 这与HTTP相当，在HTTP中，某些参数可以包含在HTTP URL中，也可以在取消引用过程中作为HTTP标头传递。 重要区别在于，应使用属于DID URL的DID参数指定要标识的资源，而应使用不属于DID URL的DID解析器选项来控制对该资源的取消引用。

如果(MAY)有明确的用例，则该参数必须是URI的一部分，并且可以用作链接或RDF / JSON-LD文档中的资源，则可以使用DID参数。

如果已经存在其他实现相同目的的URI等效方法（例如，使用其他语法结构，例如URI查询字符串或URI片段），则不应(SHUOULD NOT)使用DID参数。

如果可以通过将选项传递给DID解析器来表示相同的功能，并且不需要构造URI用作链接或RDF / JSON-LD文档中的资源，则不应(SHUOULD NOT)使用DID参数。

5.2.3 Method-Specific DID URL Parameters

DID方法规范可以(MAY)指定其他方法特定的参数名称。 特定于方法的参数名称必须(MSUT)以方法名称为前缀，如method-name规则所定义。

例如，如果方法did：foo：定义了参数bar，则参数名称必须为foo：bar。 使用此方法和此方法特定参数的示例DID URL如下所示。

EXAMPLE 3

did:foo:21tDAKCERh95uGgKbJNHYp;foo:bar=high

由一个DID方法定义的方法特定的参数名可以被其他DID方法使用。

EXAMPLE 4

did:example:21tDAKCERh95uGgKbJNHYp;foo:bar=low

特定于方法的参数名称可以按任何顺序与通用参数名称组合。

EXAMPLE 5

did:example:21tDAKCERh95uGgKbJNHYp;service=agent;foo:bar=high

DID方法名称空间和方法特定的参数名称空间都可以(MAY)包含冒号，因此它们可以按照DID方法规范的定义进行分层划分。 以下示例DID URL对此进行了说明。

EXAMPLE 6

did:foo:baz:21tDAKCERh95uGgKbJNHYp;foo:baz:hex=b612

5.2.4 Path

通用DID路径与URI路径相同，并且必须(MUST)符合[RFC3986]中的path-abempty ABNF规则。 DID路径应(SHOULD)用于寻址通过服务端点可用的资源。 有关更多信息，请参见第7.6节服务端点。

特定的DID方案可以(MAY)为DID路径指定ABNF规则，该规则比本节中的通用规则更具限制性。

EXAMPLE 7

did:example:123456/path

5.2.5 Query

通用DID查询与URI查询相同，并且必须(MUST)符合[RFC3986]中的查询ABNF规则。 DID查询应该(SHOULD)用于解决通过服务端点可用的资源。 有关更多信息，请参见第7.6节服务端点。

特定的DID方案可以(MAY)为DID查询指定ABNF规则，该规则比本节中的通用规则更具限制性。

EXAMPLE 8

did:example:123456?query=true

5.2.6 Fragment

DID片段用作DID文档中与方法无关的引用，以标识文档的组件（例如，唯一的公共密钥描述或服务端点）。 DID片段的语法和语义与通用URI片段相同，并且必须(MUST)符合RFC 3986第3.5节。 为了解析DID片段引用，必须(MUST)将包括DID片段在内的完整DID URL用作DID文档对象中目标组件的DID URL解引用算法的输入。 有关更多信息，请参见[DID-RESOLUTION]。

特定的DID方案可以(MAY)为DID片段指定ABNF规则，该规则比本节中的通用规则更具限制性。

当DID包含DID片段时，实现无需依赖于基于图形的DID文档处理来定位DID文档中包含的元数据。 可以改用基于树的处理。

实现不应(SHOULD NOT)阻止使用JSON指针（[RFC6901]）。

EXAMPLE 9

did:example:123456#public-key-1

§F.2 application / did + ld + json中针对JSON-LD表示描述了与本节中的语义兼容并分层的片段标识符的其他语义。

5.2.7 Relative DID URLs

相对DID URL是DID文档中不以did::开头的任何URL值。 更具体地说，它是任何以第5.1.1节“通用DID语法”中定义的ABNF开头的URL值。 URL的内容通常引用同一DID文档中的资源。 相对DID URL可以(MAY)包含相对路径成分，查询参数和片段标识符。

当解析相对的DID URL引用时，必须(MSUT)使用RFC3986第5节：引用解析中指定的算法。 基本URI值是与DID主题关联的DID，请参阅第7.2节“ DID主题”。 该计划已完成。 权限是：的组合，并且path, query和fragment值分别在§5.2.4节路径、§5.2.5节查询和§5.2.6节片段中定义。

相对DID URL通常用于标识DID文档中的验证方法和服务，而不必使用绝对URL，而绝对URL往往比必需的更为冗长。

EXAMPLE 10: An example of a relative DID URL

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "publicKey": [{
    "id": "did:example:123456789abcdefghi#key-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }, ...],
  "authentication": [
    // a relative DID URL used to reference a verification method above
    "#key-1"
  ]
}

在上面的示例中，相对DID URL值将转换为did:example:123456789abcdefghi#key-1

6. Data Model

6.1 Definition

6.2 Extensibility

6.3 Representation Requirements

7. Core Properties

DID指向DID文档。 DID文档是第6节“数据模型”中概述的数据模型的序列化。 以下各节定义了DID文档中的属性，包括这些属性是必需的还是可选的。

7.1 Identifiers

数据模型中使用标识符来识别人员，组织，设备，键，服务和一般事物的特定实例。 标识符通常是URL，或更普遍的是URI。 不建议使用非基于URI的标识符，因为尽管数据模型支持它们，但它们不易与其他基于Internet的标识符一起使用。

7.2 DID Subject

DID主题用id属性表示。 DID主题是DID文档所涉及的实体。 即，它是由DID标识并由DID文档描述的实体。

DID文件必须(MUST)包含id属性。

  • id
    • id的值必须(MUST)是一个有效的DID。

EXAMPLE 11

{
  "id": "did:example:21tDAKCERh95uGgKbJNHYp"
}

NOTE

DID方法规范可以创建不包含id密钥的DID文档的中间表示形式，例如在DID解析器执行解析时。 但是，完全解析的DID文档始终包含有效的id属性。 解析的DID文档中的id值应与解析的DID匹配。

7.3 Public Keys

DID文档可以表达加密密钥和其他验证方法，这些方法可以用于验证或授权与DID主题或关联方的交互。 所表达的信息通常包括全局明确的标识符和公钥材料，可用于验证数字签名。 可以表示其他信息，例如密钥的状态信息（例如，密钥是否被挂起或吊销），或者其他属性，使人们可以确定它是否是硬件支持的加密密钥。

关于加密密钥材料，可以根据其用途将公共密钥包含在DID文档中，例如，使用publicKey或身份验证属性。 每个公共密钥都有其自己的标识符（id），类型和控制器，以及取决于其类型的其他属性。

该规范致力于将用于在DID文档中表达公钥材料的格式的数量限制到最小，以增加互操作性的可能性。 实现者必须实现的格式越少，他们将支持所有这些格式的可能性就越大。 这种方法试图在易于实现和历来广泛部署的支持格式之间取得微妙的平衡。 下面列出了此规范中支持的密钥格式的特定类型。

公钥是一种验证方法。 公钥用于数字签名，加密和其他加密操作，而这些又是进行身份验证（请参阅第7.4节）或与服务端点建立安全通信（请参阅第7.6节服务端点）之间的安全通信的基础。 同样，公钥可以在DID方法操作的授权机制中起作用（请参见第9.2节“方法操作”），该机制可以由DID方法规范定义。

NOTE: Verification methods

公钥只是一种验证方法。 DID文档使用验证关系来表达DID主题和验证方法之间的关系。 验证关系的示例包括：身份验证，authentication, capabilityInvocation, capabilityDelegation, keyAgreement和assertionMethod。 DID控制器必须(MUST)明确说明DID主体与验证方法之间的验证关系。 与特定验证关系不相关的验证方法不得(MUST NOT)用于该验证关系。 有关验证关系的更多详细示例，请参见第7.4节“身份验证”。

DID文档可以(MAY)包含publicKey属性。

  • publicKey
    • 如果DID文档包含publicKey属性，则该属性的值必须(MUST)是公共密钥对象的数组。 每个公共密钥对象必须(MUST)具有类型，控制器和特定的公共密钥属性，并且必须(MUST)具有id属性。 公钥对象可以包含附加属性。

id属性的值必须(MUST)是URI。 公钥数组不得(MUST NOT)包含具有相同ID的多个条目。 在这种情况下，DID文档处理器必须(MUST)产生一个错误。

type属性的值必须(MUST)恰好是一种公钥类型。 有关可用密钥类型和格式的注册表，请参阅附录§A.互操作性注册表。

标识相应私钥的控制器的controller属性的值必须(MUST)是有效的DID。

NOTE: Key controller(s) and DID controller(s)

当关系的主题是DID文档时，和关系的主题是键时，控制器属性的语义是相同的。 由于密钥本身无法控制，并且不能从DID文档中推断出密钥控制器，因此有必要明确表示密钥控制器的身份（可以是DID控制器或DID主题）。 区别在于，键上控制器的值不一定是DID控制器。 DID控制器是使用DID文档顶层的controller属性来表示的； 参见第7.5节“授权和委派”。

id属性的值可以构造为复合键。 这对于与现有的密钥管理系统和密钥格式（例如JWK）集成特别有用。 建议(RECOMMENDED)将JWK kid值设置为公用密钥指纹。 建议使用JWK表示其公共密钥的验证方法将kid的值用作其片段标识符。 有关带有复合密钥标识符的公共密钥的示例，请参见示例11中的第一个密钥。

所有公钥属性都必须(MUST)来自链接数据加密套件注册表。 有关密钥类型和格式的注册表，请参阅附录§A.互操作性注册表。

如果DID文档中不存在公共密钥，则必须(MUST)假定该密钥已被撤销或无效。 DID文件可以(MAY)包含撤销的密钥。 包含撤销密钥的DID文档还必须(MUST)包含或引用密钥的撤销信息（例如，撤销列表）。 每个DID方法规范都应详细说明如何执行和跟踪吊销。

所有类型的公钥都必须使用publicKeyJwk属性以JSON Web密钥（JWK）格式或下表中列出的格式之一表示。 公钥表达式不得使用任何其他密钥格式。

Key Type Support
RSA RSA公钥值必须(MUST)使用publicKeyPem属性编码为JWK或以增强隐私邮件（PEM）格式编码。
ed25519 Ed25519公共密钥值必须(MUST)使用publicKeyBase58属性以Base58比特币格式编码为JWK或编码为原始的32字节公共密钥值。
secp256k1-koblitz Secp256k1 Koblitz公钥值必须(MUST)使用publicKeyBase58属性以Base58比特币格式编码为JWK或编码为原始的33字节公钥值。
secp256r1 Secp256r1公共密钥值必须(MUST)使用publicKeyBase58属性编码为JWK或编码为以Base58比特币格式编码的原始32字节公共密钥值。
Curve25519 Curve25519（也称为X25519）公钥值必须(MUST)使用publicKeyBase58属性以Base58 Bitcoin格式编码为JWK或编码为原始的32字节公钥值。

Example:

EXAMPLE 12: Various public keys

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/v1"],
  "id": "did:example:123456789abcdefghi",
  ...
  "publicKey": [{
    "id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "type": "JwsVerificationKey2020",
    "controller": "did:example:123",
    "publicKeyJwk": {
      "crv": "Ed25519",
      "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
      "kty": "OKP",
      "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
    }
  }, {
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }, {
    "id": "did:example:123456789abcdefghi#keys-2",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:example:pqrstuvwxyz0987654321",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }, {
    "id": "did:example:123456789abcdefghi#keys-3",
    "type": "Secp256k1VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
  }],
  ...
}

密钥可以嵌入或引用在DID文档中。 例如，authentication属性可能以两种方式引用密钥，如下面的示例所示。

EXAMPLE 13: Various public keys

{
...

  "authentication": [
    // this key is referenced, it may be used with more than one verification relationship
    "did:example:123456789abcdefghi#keys-1",
    // this key is embedded and may *only* be used for authentication
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],

...
}

处理DID文档中的publicKey属性时使用的步骤为：

  1. 让value为与public Key属性关联的数据，并将结果初始化为NULL。
  2. 如果值是对象，则嵌入关键材料。 将结果设置为值。
  3. 如果value是字符串，则该键包含在引用中。 假设值是一个URL。
    1. 取消引用URL并检索与URL关联的publicKey属性。 例如，在取消引用的文档的顶层处理publicKey属性。
    2. 遍历每个公钥对象，如果对象的id属性与value匹配，则将结果设置为该对象。
  4. 如果result至少不包含id，type和controller属性以及由result的type属性确定的任何强制性公共加密材料，则将引发错误。

NOTE

DID文档中密钥的缓存和过期完全由DID解析器和其他客户端负责。 有关更多信息，请参见第10节。

7.4 Authentication

身份验证是一种机制，通过该机制，实体可以证明自己是DID主体。 身份验证尝试的验证者可以检查身份验证方是否正在提供有效的身份验证证明，即他们是他们所说的身份。 请注意，成功的认证本身可能会或可能不会赋予授权； 这取决于验证应用程序。

NOTE: Uses of authentication

如果建立了身份验证，则由DID方法或其他应用程序决定如何处理该信息。 特定的DID方法可以确定作为DID控制器进行身份验证足以例如更新或删除DID文档。 为了更新或删除DID文档而不是用于身份验证的文档，另一种DID方法可能需要提供不同的密钥或完全不同的验证方法。 换句话说，在进行身份验证检查之后执行的操作超出了DID数据模型的范围，但是DID方法和应用程序需要自行定义此内容。

DID文档可以(MAY)包含一个认证属性。

  • authentication
    • authentication属性是DID主题和一组验证方法（例如但不限于公钥）之间的关系。 这意味着DID主题已出于身份验证目的（根据authentication属性的值）授权了一些验证方法集。 authentication属性的值应该是一组验证方法。 每种验证方法都可以嵌入或引用。 验证方法的一个示例是公钥（请参阅第7.3节“公钥”）。

该语句对于需要检查看看是否试图进行身份验证的实体是否实际上在提供有效的身份验证证明的任何“authentication verifier”很有用。 当verifier收到某些数据（采用某种特定于协议的格式），该数据包含为“身份验证”目的而做出的证明，并说该实体由DID标识时，该验证者将进行检查以确保证明 可以使用DID文档中authentication下列出的验证方法（例如，公钥）来验证。

由DID文档的authentication属性指示的验证方法只能用于认证DID主体。为了认证DID控制器(在DID控制器不是DID主体的情况下)，与控制器的值相关联的实体(参见§7.5授权和委托)需要使用自己的DID文档和所附的authentication验证方法关系来认证自己。

Example:

EXAMPLE 14: Authentication field containing three verification methods

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  ...
  "authentication": [
    // this method can be used to authenticate as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method can be used to authenticate as did:...fghi
    "did:example:123456789abcdefghi#biometric-1",
    // this method is *only* authorized for authentication, it may not
    // be used for any other proof purpose, so its full description is
    // embedded here rather than using only a reference
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  ...
}

7.5 Authorization and Delegation

授权是一种机制，用于声明如何代表DID主题执行操作。 委托是主体用来授权他人代表他人行事的机制。

NOTE: Authorization vs authentication

请注意，授权与§7.4认证是分开的。 这对于在密钥丢失的情况下对于密钥恢复尤为重要，当主体无法再访问其密钥或密钥泄露时，DID控制器的受信任第三方需要覆盖攻击者的恶意活动。 参见第11节。

DID文档可以(MAY)包括一个控制器属性，以指示除DID主题外还有其他DID控制器。 如果是这样：

  • controller
    • controller属性的值必须(MUST)是有效的DID或有效的DID数组。 相应的DID文档应(SHOULD)包含授权关系，该授权关系明确允许出于特定目的使用某些验证方法。

每个DID方法必须(MUST)定义授权和委派的实现方式，包括任何必要的加密操作。

至少有两种建议的实现授权和委托的方法，可以分层：

  • DID registry可以通过启用DID文档来表达控制它的另一个 DID controller的DID来实现粗粒度的controller模式，或者另外，
  • DID registry可以实施基于功能的方法，从而可以对授权和委派进行进一步的细粒度控制。

EXAMPLE 15: DID document with a controller property

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "controller": "did:example:bcehfew7h32f32h7af3",
  "service": [{
    // used to retrieve Verifiable Credentials associated with the DID
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

7.6 Service Endpoints

在DID文档中使用服务端点来表达与DID主题或关联实体进行通信的方式。 DID文档中列出的服务可以包含有关保护隐私的邮件服务(privacy preserving messaging)的信息，或者包含更多公共信息，例如社交媒体帐户，个人网站和电子邮件地址。 与服务关联的元数据通常是特定于服务的。 例如，与加密的消息传递服务关联的元数据可以表示在消息传递开始之前如何启动加密的链接。

使用service属性表示服务的指针。 每个服务都有自己的id和type，以及带有URI或其他描述服务的属性的serviceEndpoint。

DID文档的主要目的之一是启用服务端点的发现。 服务端点可以是DID主体想要通告(advertise)的任何类型的服务，包括用于进一步发现，认证，授权或交互的分布式身份管理服务。

DID文档可以(MAY)包含服务属性。

  • service
    • 如果DID文档包含service属性，则该属性的值应(SHOULD)为服务端点对象的数组。 每个服务端点必须(MUST)具有id，type和serviceEndpoint属性，并且可以(MAY)包含其他属性。

id属性的值必须(MUST)是URI。 服务端点数组不得(MUST NOT)包含多个具有相同id的条目。 在这种情况下，DID文档处理器必须(MUST)产生一个错误。

serviceEndpoint属性的值务必(MUST)是JSON-LD对象或符合[RFC3986]的有效URI，并根据[RFC3986]第6节中的规则以及其适用的URI方案规范中的任何规范化规则进行规范化。

期望服务端点协议以开放标准规范发布。

EXAMPLE 16: Various service endpoints

{
 "service": [{
   "id": "did:example:123456789abcdefghi#openid",
   "type": "OpenIdConnectVersion1.0Service",
   "serviceEndpoint": "https://openid.example.com/"
 }, {
   "id": "did:example:123456789abcdefghi#vcr",
   "type": "CredentialRepositoryService",
   "serviceEndpoint": "https://repository.example.com/service/8377464"
 }, {
   "id": "did:example:123456789abcdefghi#xdi",
   "type": "XdiService",
   "serviceEndpoint": "https://xdi.example.com/8377464"
 }, {
   "id": "did:example:123456789abcdefghi#agent",
   "type": "AgentService",
   "serviceEndpoint": "https://agent.example.com/8377464"
 }, {
   "id": "did:example:123456789abcdefghi#hub",
   "type": "IdentityHub",
   "publicKey": "did:example:123456789abcdefghi#key-1",
   "serviceEndpoint": {
     "@context": "https://schema.identity.foundation/hub",
     "type": "UserHubEndpoint",
     "instances": ["did:example:456", "did:example:789"]
   }
 }, {
   "id": "did:example:123456789abcdefghi#messages",
   "type": "MessagingService",
   "serviceEndpoint": "https://example.com/messages/8377464"
 }, {
   "id": "did:example:123456789abcdefghi#inbox",
   "type": "SocialWebInboxService",
   "serviceEndpoint": "https://social.example.com/83hfh37dj",
   "description": "My public social inbox",
   "spamCost": {
     "amount": "0.50",
     "currency": "USD"
   }
 }, {
   "id": "did:example:123456789abcdefghi#authpush",
   "type": "DidAuthPushModeVersion1",
   "serviceEndpoint": "http://auth.example.com/did:example:123456789abcdefg"
 }]
}

有关身份验证服务端点的安全注意事项的更多信息，请参见§9.1方法方案和§7.4身份验证。

7.7 Created

一个DID文档应该(SHOULD)包括一个created的属性。

  • created
    • 如果DID文档包含已created的属性，则该属性的值务必(MUST)为有效的XML日期时间值，如W3C XML模式定义语言（XSD）1.1第2部分：数据类型[XMLSCHEMA11-2]的3.3.7节所定义。 该日期时间值必须标准化为UTC 00:00，如尾随的“ Z”所示。

EXAMPLE 17

{
  "created": "2002-10-10T17:00:00Z"
}

7.8 Updated

标识符记录的标准元数据包括最新更改的时间戳。

DID文档应(SHOULD)包含updated的属性。

  • updated
    • 如果DID文档包含updated属性，则该属性的值必须(MUST)遵循与created属性相同的格式规则，如7.7节“创建的”中所述。

EXAMPLE 18

{
  "updated": "2016-10-17T02:41:00Z"
}

7.9 Proof

DID文档上的proof是根据以下方式之一的DID文档完整性的加密证明：

  • DID主题，如第7.2节DID主题中所定义
  • DID控制器，如第7.5节“授权和委托”中所定义。

此证明不是(NOT)DID和DID文档之间绑定的证明。 有关更多信息，请参见第11.2节“身份绑定”。

DID文档可以(MAY)包含proof属性。

  • proof
    • 如果DID文档包含proof属性，则该属性的值务必(MUST)是有效的JSON-LD证明，如链接数据证明所定义。

EXAMPLE 19: A signature-based proof

{
  "proof": {
    "type": "LinkedDataSignature2015",
    "created": "2016-02-08T16:02:20Z",
    "creator": "did:example:8uQhQMGzWxR8vw5P3UWH1ja#keys-1",
    "signatureValue": "QNB13Y7Q9...1tzjn4w=="
  }
}

8. Core Representations

DID文档的所有具体表示都必须(MUST)使用确定性映射进行序列化，该确定性映射能够明确地解析为本规范中定义的数据模型。 所有序列化方法必须(MUST)定义用于将DID文档双向转换为相关表示形式的规则。 结果，必须(MUST)通过将源格式解析为DID文档模型（在第6节，数据模型和第3.3节DID文档中进行描述），然后将DID文档模型序列化为目标表示，才能完成任何两种表示形式之间的转换。 在未先解析为DID文档模型的情况下，实现不得(MUST NOT)在表示之间进行转换。

尽管这里为JSON，JSON-LD和CBOR提供了语法映射，但是应用程序和服务可以(MAY)使用能够表达数据模型的任何其他数据表示语法，例如XML或YAML。

生产者必须(MUST)通过文档的元数据中的媒体类型指示使用了哪种文档表示形式。 消费者必须(MUST)通过文档元数据中的媒体类型确定文档所处的表示形式。 消费者不得(MUST NOT)仅通过其内容确定文档的表示形式。

本节中的生产和消费规则适用于所有寻求与规范的独立实现完全兼容的实现。 本规范的部署可以(MAY)使用定制的约定表示，包括用于处理注册表中未列出的属性的本地化规则。 见?? 有关扩展性的更多信息。

8.1 JSON

当生成和使用纯JSON（如文档元数据所指出）的DID文档时，必须遵循以下规则。

8.1.1 Production

DID文档必须(MUST)是符合[RFC8259]的单个JSON对象。 DID文档的所有顶级属性都必须(MUST)通过使用属性名称作为JSON对象成员的名称来表示。 §6中描述的数据模型的属性值。数据模型，包括所有扩展，必须通过将属性值映射到JSON类型，以JSON [RFC8259]进行编码，如下所示：

  • 可表示为IEEE754的数值必须(MUST)表示为数字类型。
  • 布尔值必须(MUST)表示为Boolean literal。
  • 序列值必须(MUST)表示为数组类型。
  • 无序值集必须(MUST)表示为数组类型。
  • 属性集必须(MUST)表示为对象类型。
  • 空值必须表示为null literal。
  • 其他值必须(MUST)表示为字符串类型。

DID文档的所有属性必须(MUST)包含在根对象中。 属性可以(MAY)根据上面列表中的值表示规则定义其他数据子结构。

成员名称@context绝不能(MUST NOT)使用，因为此属性保留给JSON-LD生产者使用。

8.1.2 Consumption

顶级元素必须(MUST)是JSON对象。 顶层的任何其他数据类型都是错误，必须(MUST)被拒绝。 顶级JSON对象代表DID文档，并且该对象的所有成员都是DID文档的属性。 对象成员名称是属性名称，成员值解释如下：

  • 数字类型必须(MUST)解释为可表示为IEEE754的数值。
  • Boolean literals 必须(MUST)被解释为布尔值。
  • 数组类型必须(MUST)解释为序列或无序集合，具体取决于该值的属性定义。
  • 一个对象类型必须(MUST)被解释为一组属性。
  • null literal必须(MUST)被解释为空值。
  • 字符串类型必须(MUST)解释为字符串，根据此值的属性定义，可以将其进一步解析为更具体的数据类型，例如URI，日期戳或其他值。

@context对象成员的值必须(MUST)被忽略，因为它是为JSON-LD使用者保留的。

未知对象成员名称必须(MUST)作为未知属性而忽略。

8.2 JSON-LD

[JSON-LD]是用于序列化链接数据的基于JSON的格式。

当生成和使用JSON-LD中的DID文档时（如文档元数据所示），必须(MUST)遵循以下规则。

  • @id和@type关键字分别别名为id和type，使开发人员能够将此规范用作惯用JSON。
  • 数据类型（例如整数，日期，度量单位和URL）会自动键入，以为需要它们的用例提供更强的类型保证。

8.2.1 Production

DID文档遵循JSON处理程序中的规则进行序列化，并附加以下内容：DID文档必须包含@context属性。

  • @context
    • @context属性的值必须(MUST)是一个或多个URI，其中第一个URI的值为https://www.w3.org/ns/did/v1。 @context属性的所有成员必须存在于DID属性扩展注册表中。

8.2.2 Consumption

顶级元素必须是JSON对象。 顶层的任何其他数据类型都是错误，必须(MUST)被拒绝。 在定义的@context字段的规则下，使用JSON-LD处理来解释此顶级JSON对象。

  • @context
    • @context属性的值必须是一个或多个URI，其中第一个URI的值为https://www.w3.org/ns/did/v1。 如果提供了多个URI，则URI必须(MUST)被解释为有序集合。 建议(RECOMMENDED)取消对每个URI的引用会导致文档包含有关上下文的机器可读信息。

未知对象成员名称必须(MUST)作为未知属性而忽略。

8.3 CBOR

8.3.1 Production

8.3.2 Consumption

9. Methods

9.1 Method Schemes

DID方法规范必须(MUST)准确定义一个方法特定的DID方案，并由一个方法名称来标识。 有关更多信息，请参见第5.1.1节“通用DID语法”中的method-name规则。

因为方法名称是DID的一部分，所以最好使用简短的方法名称。 方法名称应(SHOULD)不超过5个字符。 方法名称可能反映了DID方法规范所适用的DID注册表的名称。 有关更多信息，请参见第9.1节“方法方案”。

用于方法专用DID scheme的DID方法规范必须(MUST)规定如何生成DID的method-specific-id组件。 无需使用集中式注册表服务，就必须能够生成method-specific-id值。 method-specific-id值本身应(SHOULD)全局唯一。 根据第5.1.1节“通用DID语法”中的did规则定义，DID必须(MUST)是全局唯一的。

如果需要，一个特定于方法的DID scheme可以(MAY)定义多种method-specific-id格式。 建议(RECOMMENDED)特定于方法的DID scheme定义尽可能少的method-specific-id格式。

method-specific-id格式可以(MAY)包含冒号，DID方法可将其用于各种目的，例如建立按层次划分的命名空间，或标识DID注册表的特定实例或部分。 冒号的使用必须(MUST)在语法上符合method-specific-id ABNF规则，并且它们的使用完全是方法特定的。 建议实现者避免假定与冒号相关的任何含义或行为，这些含义或行为通常适用于所有DID方法。

新的DID方法规范的作者应(SHOULD)使用在发布时已知的所有DID方法名称中唯一的方法名称。

因为没有中央机构来分配或批准DID方法名称，所以无法确定特定的DID方法名称是否唯一。 为了应对这一挑战，W3C凭据社区组维护了一个非权威的已知DID方法名称及其关联规范的列表。 有关更多信息，请参见附录§A.互操作性注册表。

[DID-METHOD-REGISTRY]是实现者在就新方法名称达成共识时可以使用的工具，并且是为使用不同DID方法实现DID解析器的软件开发人员提供的信息性参考。 有关DID解析器的更多信息，请参见第10节。 [DID-METHOD-REGISTRY]不是DID方法的权威列表。 尽管如此，还是鼓励在[DID-METHOD-REGISTRY]中添加DID方法名称，以便其他实现者和社区成员都可以看到现有DID方法的概述。 包含的轻量级标准记录在[DID-METHOD-REGISTRY]中。

9.2 Method Operations

为了在特定的DID注册表上启用DID和DID文档的全部功能，DID方法规范必须(MUST)指定如何使用客户端执行创建，读取，更新和停用操作。 应该将每个操作指定为构建和测试可互操作的客户端实现所必需的详细程度。 如果不支持某个操作（例如更新或停用），则建议(RECOMMENDED)DID方法规范声明不支持该操作。 这些操作可用于执行加密密钥管理系统（CKMS）所需的所有操作，例如：密钥注册，密钥替换，密钥轮换，密钥恢复和密钥到期。

确定当事方执行操作的权限是特定于方法的。 例如，DID方法可以：

  • 使用认证下列出的验证方法来决定是否允许更新/停用操作；或者
  • 使用DID文档中的其他构造来决定这一点，例如，可以使用capabilityInvocation下指定的验证方法来验证对更新DID Document的功能的调用。 或者
  • 完全不使用DID文档来决定这一点，而是具有“内置于”该方法的规则。

9.2.1 Create

DID方法规范必须(MUST)规定客户端如何在DID注册表上创建DID及其相关的DID文档，包括建立控制证明所需的所有密码操作。

9.2.2 Read/Verify

DID方法规范必须(MUST)指定客户端如何使用DID向DID注册中心请求DID文档，包括客户端如何验证响应的真实性。

9.2.3 Update

DID方法规范必须(MUST)指定客户端如何更新DID注册表上的DID文档，包括建立控制证据所需的所有加密操作，或声明不能进行更新。

DID的更新是创建后用于生成DID文档的数据中的任何更改。 DID方法实现者负责定义什么构成更新，以及给定DID方法支持DID文档的哪些属性。 例如，在不更改密钥材料的情况下对其进行替换的更新操作可能是有效的更新，不会导致DID文档的更改。

9.2.4 Deactivate

DID方法规范必须(MUST)规定客户端如何在DID注册表上停用DID，包括建立停用证明所需的所有加密操作，或声明无法停用。

9.3 Extensibility

9.4 Security Requirements

DID方法规范必须(MUST)包括其自己的“安全注意事项”部分。 本节必须(MUST)考虑[RFC3552]（第27页）的第5节中对规范中定义的DID操作的所有要求。

至少必须(MUST)考虑以下攻击形式：窃听，重放，消息插入，删除，修改和中间人。 还必须(MUST)确定潜在的拒绝服务攻击。

如果协议包含了密码保护机制，则DID方法规范必须(MUST)清楚地指出数据的哪些部分受到保护以及哪些保护是受保护的，并且应该(SHOULD)指出密码保护容易受到哪些攻击。 例如，仅完整性，机密性，端点身份验证等。

应当保密的数据（密钥材料，随机种子等）应该(SHOULD)清楚地标记。

如果该技术涉及身份验证，尤其是用户主机身份验证，则必须(MUST)明确指定身份验证方法的安全性。

本节必须(MUST)根据[RFC3552]的第5节，讨论部署威胁缓解措施后的剩余风险（例如，相关协议中的漏洞，错误的实现或密码带来的风险）。

本节必须(MUST)为第9.2节“方法操作”所要求的所有操作提供完整性保护和更新身份验证。

在DID方法利用对等计算资源的情况下，例如与所有已知DLT一起使用时，应(SHOULD)与拒绝服务相关地讨论这些资源的预期负担。

必须(MUST)讨论特定于方法的端点认证。 如果DID方法使用具有变化的网络拓扑的DLT，有时以light node或thin client实现的形式提供DLT，以减少所需的计算资源，则必须(MUST)讨论可用于DID方法实现的拓扑的安全性假设。

DID方法必须(MUST)讨论证明DID被唯一分配的策略机制。 DID符合[RFC8141]中定义的URN的功能定义。 也就是说，DID是一个持久标识符，它一次分配给一个资源，而从不重新分配给另一个资源。 这在安全上下文中尤其重要，因为DID可能用于标识受特定授权权限约束的特定方。

引入新认证服务端点类型的DID方法（请参阅第7.6节“服务端点”）应考虑支持的认证协议的安全要求。

9.5 Privacy Requirements

DID方法规范必须(MUST)仅包含其自己的“隐私注意事项”部分（如果仅指向§12）。

DID方法规范的“隐私注意事项”部分必须(MUST)讨论[RFC6973]第5节的任何小节，这些小节可以以方法特定的方式应用。 要考虑的小节是：监视，存储数据泄露，未经请求的流量，错误归因，关联，标识，二次使用，披露，排除。

10. Resolution

DID解析器是具有API的软件或硬件组件，用于解析至少一种DID方法的DID。 它执行与解析的DID对应的DID方法的读取操作，以获得权威的DID文档。 有关更多信息，请参见第9.2.2节“读取/验证”。

在[DID-RESOLUTION]中指定了用于解析DID和取消引用DID URL的接口和算法。

11. Security Considerations

This section is non-normative.

NOTE: Note to implementers

在“工作草案”阶段，本节重点介绍在早期实现中应该很重要的安全性主题。 编辑人员正在寻求有关威胁和缓解威胁的反馈，这些反馈应在本节或本规范的其他部分中得到反映。 DID设计为在许多IETF标准使用的通用Internet威胁模型下运行。 我们假设端点不受影响，但是预计消息可能会在网络上被读取或损坏。 当系统受到威胁时，防范攻击需要外部密钥签名硬件（请参阅第11.7节“密钥撤销和恢复”）。

11.1 Choosing DID Resolvers

[DID-METHOD-REGISTRY]是DID方法名称及其对应的DID方法规范的信息性列表。实现者需要记住，没有中央权威机构强制要求将哪个DID方法规范与任何特定的DID方法名称一起使用，但在选择使用哪个DID解析器实现时，可以使用[DID-METHOD-REGISTRY]做出明智的决定。

11.2 Binding of Identity

以下各节描述与DID和DID文档的绑定标识。

11.2.1 Proving Control of a DID and DID Document

签名是允许DID文档经过密码学验证的一种方法。

就其本身而言，在自签名DID文档上的已验证签名不能证明对DID的控制。 它仅证明：

  • 自注册以来，DID文档未被篡改。
  • DID控制器在生成签名时控制用于签名的私钥。

证明对DID的控制（即DID和描述它的DID文档之间的绑定）需要两步过程：

  1. 根据DID方法规范将DID解析为DID文档。
  2. 验证生成的DID文档的id属性是否与解析的DID相匹配。

应该注意的是，该过程证明了对DID和DID文档的控制，而不管DID文档是否已签名。

DID文档上的签名是可选的。 DID方法规范应解释并指定其实现（如果适用）。

最好将时间戳和签名结合在一起。

11.2.2 Proving Control of a Public Key

有两种方法可以证明对与DID文档中的公共密钥描述相对应的私有密钥的控制：静态和动态。

静态方法是使用私钥对DID文档进行签名。 这证明了在不晚于注册DID文档的时间对私钥的控制。 如果未对DID文档进行签名，则仍可以动态证明DID文档中描述的公钥控制，如下所示：

  1. 向DID文档中描述的适当服务端点发送包含DID文档中的公钥描述和现时信息的质询消息。
  2. 根据公钥描述验证响应消息的签名。

11.2.3 Authentication and Verifiable Claims

DID和DID文档固有地不带有任何PII（个人身份信息）。 将DID绑定到现实世界中的某物（例如某个人或公司）的过程（例如具有与该DID相同主题的凭据）不在本规范范围内。 有关更多信息，请参见[VC-DATA-MODEL]。

11.3 Authentication Service Endpoints

如果DID文档发布了旨在对DID主题进行身份验证或授权的服务端点（请参阅第7.6节，服务端点），则服务端点提供者，主体或依赖方有责任遵守身份验证协议的要求 该服务端点支持。

11.4 Non-Repudiation

在以下主题的假设下，支持DID和DID文档更新的不可否认性：

  • 正在监视未经授权的更新（请参阅第11.5节“ DID文档更改的通知”）。
  • 根据DID方法的访问控制机制，已经有足够的机会还原恶意更新（请参阅第7.4节“身份验证”）。

如果包含时间戳，则进一步支持不可否认性（请参阅第7.7节“创建”和第7.8节“更新”），并且目标DLT系统支持时间戳。

11.5 Notification of DID Document Changes

防止对DID文档进行未经授权的更改的一种缓解措施是，在发生更改时监视并主动通知DID主题。 这类似于通过向文件中的电子邮件地址发送密码重置通知来帮助防止在常规用户名/密码帐户上进行帐户接管。 对于DID，没有中间注册商或帐户提供者来生成通知，建议采用以下方法：

  • Subscriptions. 如果直接在其上注册了DID的DID注册表支持更改通知，则可以将该服务提供给DID控制器。 通知可以直接发送到现有DID中列出的相关服务端点。
  • Self-monitoring. DID主题可以雇用他们自己的本地或在线代理来定期监视DID文档的更改。
  • Third-party monitoring.DID主体可能依赖第三方监视服务，但这引入了另一种攻击媒介。

11.6 Key and Signature Expiration

在分布式标识符体系结构中，没有集中的机构来强制执行密钥或签名到期策略。 因此，DID解析器和其他客户端应用程序需要验证密钥在使用时没有过期。 由于某些用例可能有合理的理由可以扩展已经过期的密钥，因此请确保密钥过期不会阻止对该密钥的任何进一步使用，并且解析程序的实现应与此类扩展行为兼容。

11.7 Key Revocation and Recovery

第9.2节的“方法操作”指定了DID方法规范所支持的DID操作，包括通过用更新的DID文档替换DID文档来使其停用。 DID方法还可以定义如何撤销加密密钥。此外，还希望DID方法规范能够支持一定数量的受信方，以实现密钥恢复。 §7.5授权和委派中建议了一些这样做的工具。并非所有DID方法规范都可以识别使用其他DID方法注册的DID的控制，并且它们可能会将第三方控制限制为使用相同方法的DID。 DID方法规范中的访问控制和密钥恢复还可以包括时间锁定功能，以通过维护恢复的第二控制轨道来防止密钥泄露。此类控制的进一步规范是将来的工作（请参见第D.4节“时间锁定和DID文档恢复”）。

11.8 The Role of Human-Friendly Identifiers

DID无需全局注册机构即可实现全局唯一性。 然而，这是以牺牲人类记忆为代价的。 能够生成全局唯一标识符的算法会自动生成没有人类意义的随机字符串。 这证明了Zooko三角中描述的关于标识符的公理：“human-meaningful，decentralized，secure——任意选择两个”。

当然，在许多用例中，从人类友好的标识符开始时，希望发现DID。 例如，DID控制器的自然语言名称，域名或常规地址，例如移动电话号码，电子邮件地址，Twitter句柄或博客URL。 但是，将人类友好的标识符映射到DID（并以一种可以被验证和信任的方式进行）的问题不在本规范的范围之内。

应该在引用此规范的单独规范中定义该问题（并且有很多）的解决方案。 强烈建议此类规范仔细考虑以下内容：

  • 基于欺骗用户有关目标实体的真实人类友好标识符的众多安全攻击。
  • 使用固有相关的人类友好标识符的隐私后果，尤其是在全球范围内唯一的情况下。

NOTE

[DNS-DID]上提供了用于使用DNS查找从域名和电子邮件地址中查找DID的规范草案。

11.9 Immutability

许多网络安全滥用取决于利用现实与理性，善意参与者的假设之间的差距。 像任何生态系统一样，DID生态系统也有可能发生这种情况。 由于此规范的重点是数据模型而不是协议，因此对于如何使用该模型的许多方面都没有意见。 但是，各个DID方法可能需要考虑可以消除它们不需要的行为或语义的约束。 在提供相同功能集的同时，DID方法的锁定越多，恶意行为者对其进行操纵的可能性就越小。

例如，考虑数据模型在更新方面提供的灵活性。 对DID文档的单次编辑可以更改文档的root id属性以外的所有内容。 数据模型中的任何单个JSON对象都可以更改其id以外的所有属性。 但是，服务端点在定义后实际上是否需要更改其type？ 或者用于密钥更改其值？ 还是在对象的某些基本属性发生变化时要求使用新的id更好？ 对网站的恶意收购通常旨在使网站保留其标识符（主机名），但在其下进行微妙的危险更改。 如果规范要求站点的某些属性是不可变的（例如，与其IP地址相关联的ASN），则实施此类攻击可能会更加困难且成本更高，并且异常检测将更加容易。

由于缓存，不变性提供了一些网络安全优势的概念特别重要。 对于与全局真相相关的DID方法，始终可以直接，及时地查找DID文档的最新版本。 但是，高速缓存层似乎最终可能位于客户端和该事实来源之间。 如果确实如此，则认为DID文档中对象的属性确实具有给定的状态（实际上它们实际上是微妙的不同）可能会引起漏洞利用。 如果某些查找属于完整的DID文档，而其他查找属于部分数据（假定使用较大的上下文），则尤其如此。

11.10 Encrypted Data in DID Documents

DID文档通常是公开可用的。 由于加密和计算能力的提高，已知加密算法会失败。 建议实施者假定放置在DID文档中的所有加密数据最终都可以以明文形式提供给可使用该加密数据的同一受众。

从长远来看，对DID文档的全部或部分进行加密不是一种适当的方法来保护数据。 同样，将加密数据放置在DID文档中也不是包含个人可识别信息的适当方法。

鉴于上述注意事项，如果DID文档中包含加密数据，则建议实施者不要使用不希望与DID相关联的实体的公钥进行加密。

12. Privacy Considerations

This section is non-normative.

将设计隐私原则应用于分布式标识符体系结构的所有方面至关重要，因为DID和DID文档在设计上直接由DID控制器管理。 没有注册商，托管公司或其他中间服务提供商来推荐或应用其他隐私保护措施。 本规范的作者已在其整个开发过程中应用了全部七个“按设计保密”原则。 例如，本规范中的隐私是预防性的而不是补救性的，而隐私是嵌入式默认值。 此外，分布式的标识符体系结构本身体现了原则7：“尊重用户隐私-以用户为中心”。

本节列出了实现者，委托人和DID主题应记住的其他隐私注意事项。

12.1 Keep Personally-Identifiable Information (PII) Private

如果DID方法规范是为公共DID注册表编写的，其中所有DID和DID文档都是公开可用的，则DID文档不包含PII是至关重要的。所有PII应保持在服务端点之后，由DID主体控制。利用该隐私体系结构，可以使用由DID文档中的公钥描述标识和保护的通信信道在私有的、对等的基础上交换PII。这也使得DID主体和依赖方能够实现GDPR权利而被遗忘，因为没有任何PII被写入到不可变的分布式分类帐中。

12.2 DID Correlation Risks and Pseudonymous DIDs

像任何类型的全局唯一标识符一样，DID可以用于关联。 DID控制器可以通过使用成对的唯一DID（即为每个关系共享不同的私有DID）来减轻这种隐私风险。 实际上，每个DID都充当假名。 仅当DID主题明确授权这些方之间的关联时，才需要与多个方共享假名DID。 如果默认使用匿名DID，则唯一的公共DID（公开发布或与大量各方共享的DID）是DID主题明确要求公开身份的时候。

12.3 DID Document Correlation Risks

如果可以将相应DID文档中的数据进行关联，则容易破坏假名DID的反相关保护。 例如，在多个DID文档中使用相同的公钥描述或定制服务端点可以提供与使用相同的DID一样多的关联信息。 因此，用于匿名DID的DID文档还需要使用成对的唯一公共密钥。 在DID文档中也使用成对的唯一服务端点作为匿名DID似乎很自然。 但是，唯一的端点可以将两个DID之间的所有流量完美地隔离到唯一的存储桶中，在这些存储桶中，时序相关性和类似分析很容易。 因此，一种更好的端点隐私策略可能是在由许多不同主体控制的数千个或数百万个DID之间共享一个端点。

12.4 Herd Privacy

当DID主题与群体中的其他主题无法区分时，隐私是可用的。当与另一方私下接触的行为本身就是一面可识别的旗帜时，隐私就会大大减少。DIDs和DID方法需要努力改善群体隐私，特别是对于那些合法最需要隐私的人。选择默认保留匿名和假名的技术和人机界面。要减少数字指纹，请在客户端实施之间共享公共设置，将协商的选项保持在最小的有线协议上，使用加密的传输层，并将消息填充为标准长度。

A. Interoperability Registries

有多个注册表定义了该规范的DID方法和扩展。 这些注册表是：

Registry Purpose
DID Method Registry 列出所有已知的DID方法，并包含其规范的链接。
Linked Data Cryptography Suite Registry 定义所有已知的链接数据密码套件和密钥格式。

B. Real World Example

下面提供了面向未来的现实环境：

EXAMPLE 20: Advanced DID document example

{
  "@context": "https://w3id.org/future-method/v1",
  "id": "did:example:123456789abcdefghi",

  "publicKey": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }, {
    "id": "did:example:123456789abcdefghi#keys-3",
    "type": "Ieee2410VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],

  "authentication": [
    // this mechanism can be used to authenticate as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this mechanism can be used to biometrically authenticate as did:...fghi
    "did:example:123456789abcdefghi#keys-3",
    // this mechanism is *only* authorized for authentication, it may not
    // be used for any other proof purpose, so its full description is
    // embedded here rather than using only a reference
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],

  "service": [{
    "id": "did:example:123456789abcdefghi#oidc",
    "type": "OpenIdConnectVersion1.0Service",
    "serviceEndpoint": "https://openid.example.com/"
  }, {
    "id": "did:example:123456789abcdefghi#vcStore",
    "type": "CredentialRepositoryService",
    "serviceEndpoint": "https://repository.example.com/service/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#xdi",
    "type": "XdiService",
    "serviceEndpoint": "https://xdi.example.com/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#hub",
    "type": "HubService",
    "serviceEndpoint": "https://hub.example.com/.identity/did:example:0123456789abcdef/"
  }, {
    "id": "did:example:123456789abcdefghi#messaging",
    "type": "MessagingService",
    "serviceEndpoint": "https://example.com/messages/8377464"
  }, {
    "type": "SocialWebInboxService",
    "id": "did:example:123456789abcdefghi#inbox",
    "serviceEndpoint": "https://social.example.com/83hfh37dj",
    "description": "My public social inbox",
    "spamCost": {
      "amount": "0.50",
      "currency": "USD"
    }
  }, {
    "type": "DidAuthPushModeVersion1",
    "id": "did:example:123456789abcdefghi#push",
    "serviceEndpoint": "http://auth.example.com/did:example:123456789abcdefghi"
  }, {
    "id": "did:example:123456789abcdefghi#bops",
    "type": "BopsService",
    "serviceEndpoint": "https://bops.example.com/enterprise/"
  }]
}

C. Current Issues

D. Future Work

D.1 Upper Limits on DID Character Length

当前规范在DID的最大长度上没有位置。 目前，最大可互操作的URL长度约为2K个字符。 QR码可以处理大约4K个字符。 使用DID的客户将负责存储许多DID，并且某些方法将能够通过依赖更复杂的签名方案或通过将状态添加到临时使用的DID中来将其部分成本外在化。 本规范的未来版本应在DID字符长度上设置合理的限制，以最大程度地减少外部性。

D.2 Equivalence

在值是DID数组的DID文档中包括等价属性，例如equivID，将允许主题声明两个或多个表示同一主题的DID。 此功能具有多种用途，包括支持DID注册表之间的迁移，并提供现有DID与将来的DID注册表的前向兼容性。 从理论上讲，等效的DID应该具有相同的标识符权限，从而允许对一个DID提出的可验证声明适用于等效的DID。 由于验证不同DLT和不同DID方法之间的等效性以及汇总等效DID文档的属性的复杂性，当前规范中不包括等效性。 但是，此规范的将来版本应支持等效性。

D.3 Timestamps

可验证的时间戳对于标识符记录具有重要的用途。 这非常适合DLT，因为大多数DLT提供某种类型的时间戳机制。 尽管有一些交易成本，它们还是世界上最不受审查审查的交易订购系统，因此它们几乎是DID文档时间戳的理想选择。 在某些情况下，DLT的即时计时是近似的，但是可以精确定义其“过去的中间时间”（参见比特币BIP 113）的含义。 通用的DID文档时间戳机制可以在所有DLT中使用，并且可以通过包括单个交易或交易批处理的机制进行操作。 尽管通用机制可能会包含在本规范的将来版本中，但它仍被认为超出了此版本的范围。

D.4 Time Locks and DID Document Recovery

第11.7节“密钥撤销和恢复”中提到了一种可能的巧妙利用时间锁来在密钥泄露后恢复对DID的控制的情况。 该技术依赖于能够利用DID文档的较早版本应用的Authorization覆盖对DID文档的最新更新的能力，以便击败攻击者。 这种保护取决于添加时间锁（请参阅比特币BIP 65）以保护部分交易链，从而使授权块可用于恢复控制。 我们计划在此规范的将来版本中增加对时间锁定的支持。

D.5 Smart Signatures

并非所有DLT都可以支持第7.5节“授权和委托”中的授权逻辑。 因此，在此版本的规范中，所有授权逻辑均委托给DID方法规范。 未来的潜在解决方案是智能签名规范，该规范指定了任何符合DLT要求的可实现以处理签名控制逻辑的代码。

D.6 Verifiable Credentials

尽管DID和DID文档构成了去中心化身份的基础，但它们只是描述其主题的第一步。 其余的描述能力来自收集和有选择地使用可验证凭证[VC-DATA-MODEL]。 规范的未来版本将更详细地描述DID和DID文档如何与“可验证凭据”生态系统集成在一起并帮助启用。

D.7 Alternate Serializations and Graph Models

该规范的版本依赖于JSON-LD和RDF图形模型来表达DID文档。 本规范的未来版本可能会为DID文档指定其他语义图格式。

E. JSON LD Description and Extension

[JSON-LD]是用于序列化链接数据的基于JSON的格式。 该语法旨在轻松集成到已经使用JSON的已部署系统中，并提供从JSON到JSON-LD的平滑升级路径。 它主要旨在成为一种在基于Web的编程环境中使用链接数据，构建可互操作的Web服务以及将链接数据存储在基于JSON的存储引擎中的方法。

扩展本规范中描述的数据模型时，JSON-LD很有用。 数据模型的实例以与JSON编码相同的方式在JSON-LD中进行编码（请参阅第8.1节JSON），并添加了@context属性。 JSON-LD上下文在[JSON-LD]规范中进行了详细说明，其用法在第6.2节“可扩展性”中进行了详细说明。

通常，设计本文档中描述的数据模型和语法，以便开发人员可以将示例复制并粘贴到其软件系统中。 这种方法的设计目标是提供较低的进入门槛，同时仍可确保一组异构软件系统之间的全局互操作性。 本节描述了其中一些方法，大多数开发人员可能不会注意到这些方法，但是其详细信息将对实现者感兴趣。 JSON-LD提供的值得注意的功能是：

  • @id和@type关键字分别别名为id和type，使开发人员能够将此规范用作惯用JSON。
  • 数据类型（例如整数，日期，度量单位和URL）会自动键入，以为需要它们的用例提供更强的类型保证。
  • JSON-LD 1.1的@protected属性功能用于确保此规范定义的术语不会被覆盖。 这意味着，只要在DID文档的顶部进行相同的@context声明，就可以保证使用JSON-LD处理器的实现与不使用JSON-LD处理器的实现之间的互操作性。

E.1 Contexts

当两个软件系统需要交换数据时，它们需要使用两个系统都理解的术语和协议。 @context属性可确保在同一DID文档上运行的两个系统使用相互同意的术语。

DID文档必须包含@context属性

NOTE: The JSON-LD Context

通常，可以在[JSON-LD]规范中找到有关JSON-LD上下文的更多信息。

  • @context
    • @context属性的值必须(MUST)是一个或多个URI，其中第一个URI的值为https://www.w3.org/ns/did/v1。 如果提供了多个URI，则URI必须(MUST)被解释为有序集合。 建议(RECOMMENDED)取消对每个URI的引用会导致文档包含有关上下文的机器可读信息。

EXAMPLE 21

{
    "@context": "https://www.w3.org/ns/did/v1"
}

DID方法规范可以(MAY)定义自己的JSON-LD上下文。 但是，建议不要(NOT RECOMMENDED)定义新的上下文，除非该上下文是正确实现该方法所必需的。 特定于方法的上下文不得(MUST NOT)覆盖通用DID上下文中定义的术语。

E.2 JSON-LD Extensibility

分布式标识符数据模型的目标之一是实现无许可的创新。 数据模型需要以多种不同方式扩展，包括：

  • 通过使用基于图的数据模型，可以对复杂的多实体关系进行建模。
  • 通过使用[LINKED-DATA]可以扩展用于描述数据模型中信息的机器可读词汇，而无需依赖集中式系统。
  • 通过使用链接数据证明[LD-PROOFS]，链接数据签名[LD-SIGNATURES]和各种签名套件，可以实现对多种类型的密码证明格式的支持。
  • 上面概述的所有可扩展性机制都以一种数据格式提供，该格式在软件开发人员和网页作者中很流行，并且可以通过使用[JSON-LD]启用。

这种数据建模方法通常称为开放世界假设，这意味着任何人都可以对其他事情发表任何言论。 这种方法通常似乎与构建简单且可预测的软件系统相冲突。 在开放世界的假设下，平衡可扩展性与程序正确性总是比封闭软件系统更具挑战性。

本节的其余部分将通过一系列示例描述如何实现可扩展性和程序正确性。

让我们假设我们从以下DID文档开始。

EXAMPLE 22: A simple DID document

{
    "@context": "https://example.org/example-method/v1",
    "id": "did:example:123456789abcdefghi",
    "publicKey": [{ ... }],
    "authentication": [{ ... }],
    "service": [{ ... }]
}

对于本节而言，publicKey，authentication和service属性的内容并不重要。 重要的是，上面的对象是有效的DID文档。 现在假设开发人员想要扩展DID文档以表达附加信息，即主题的公共照片流。

开发人员要做的第一件事是创建一个包含新术语的JSON-LD上下文。

EXAMPLE 23: An example JSON-LD Context

{
    "@context": {
        "PhotoStreamService": "https://example.com/vocab#PhotoStreamService"
    }
}

现在，已经创建了JSON-LD上下文，开发人员必须(MUST)将其发布到任何DID文档处理器都可以访问的位置。 对于此示例，假设上面的JSON-LD上下文发布在did：example：contexts：987654321上。 至此，扩展本节中的第一个示例仅需包括上面的上下文并将新属性添加到DID文档中。

EXAMPLE 24: A DID document with a custom extension

{
    "@context": "https://example.org/example-method/v1",
    "id": "did:example:123456789abcdefghi",
    "authentication": [ ... ],
    "service": [{
        "@context": "did:example:contexts:987654321",
        "id": "did:example:123456789abcdefghi#photos",
        "type": "PhotoStreamService",
        "serviceEndpoint": "https://example.org/photos/379283"
    }]
}

到目前为止的示例表明，很容易以无许可和分布式的方式扩展分布式标识符数据模型。 该机制还确保以这种方式创建的分布式标识符可防止名称空间冲突和语义歧义。

这种动态的可扩展性模型确实增加了实施负担。 为此系统编写的软件需要根据应用程序的风险状况确定是否接受带有扩展名的DID文档。 一些应用程序可能选择接受但忽略扩展，另一些应用程序可能选择仅接受某些扩展，而高度安全的环境则可能不允许扩展。 这些决定取决于应用程序开发人员，尤其不是本规范的范围。

当扩展JSON-LD上下文覆盖此规范中指定的术语的扩展URL时，实现必须(MUST)产生错误。 为了避免意外覆盖术语的可能性，开发人员应该扩展其扩展范围。 例如，以下扩展将新的PhotoStreamService术语限定为作用域，以便只能在service属性中使用它：

EXAMPLE 25: Scoping terms in a JSON-LD Context

{
    "@context": {
        "service": {
            "@id": "https://w3id.org/did#service",
            "@context": {
                "PhotoStreamService": "https://example.com/vocab#PhotoStreamService"
            }
        }
    }
}

强烈建议开发人员确保扩展JSON-LD上下文高度可用。 无法获取上下文的实现将产生错误。 确保扩展JSON-LD上下文始终可用的策略包括为上下文使用内容寻址的URL，将上下文文档与实现捆绑在一起或启用积极的上下文缓存。

F. IANA Considerations

当本规范成为W3C提议的建议书时，本节将提交给Internet工程指导小组（IESG）进行审查，批准和向IANA进行注册。

F.1 application/did+json

  • Type name:

    application

  • Subtype name:

    did+json

  • Required parameters:

    None

  • Optional parameters:

    None

  • Encoding considerations:

    See RFC 8259, section 11.

  • Security considerations:

    See RFC 8259, section 12 [RFC8259].

  • Interoperability considerations:

    Not Applicable

  • Published specification:

    http://www.w3.org/TR/did-core/

  • Applications that use this media type:

    Any application that requires an identifier that is decentralized, persistent, cryptographically verifiable, and resolvable. Applications typically consist of cryptographic identity systems, decentralized networks of devices, and websites that issue or verify W3C Verifiable Credentials.

  • Additional information:

    Magic number(s):Not ApplicableFile extension(s):.didMacintosh file type code(s):TEXT

  • Person & email address to contact for further information:

    Ivan Herman ivan@w3.org

  • Intended usage:

    Common

  • Restrictions on usage:

    None

  • Author(s):

    Drummond Reed, Manu Sporny, Markus Sabadello, Dave Longley, Christopher Allen

  • Change controller:

    W3C

Fragment identifiers used with application/did+json are treated according to the rules defined in DID Core v1.0, Fragment [DID-CORE].

F.2 application/did+ld+json

  • Type name:

    application

  • Subtype name:

    did+ld+json

  • Required parameters:

    None

  • Optional parameters:

    None

  • Encoding considerations:

    See RFC 8259, section 11.

  • Security considerations:

    See JSON-LD 1.1, Security Considerations [JSON-LD11].

  • Interoperability considerations:

    Not Applicable

  • Published specification:

    http://www.w3.org/TR/did-core/

  • Applications that use this media type:

    Any application that requires an identifier that is decentralized, persistent, cryptographically verifiable, and resolvable. Applications typically consist of cryptographic identity systems, decentralized networks of devices, and websites that issue or verify W3C Verifiable Credentials.

  • Additional information:

    Magic number(s):Not ApplicableFile extension(s):.didMacintosh file type code(s):TEXT

  • Person & email address to contact for further information:

    Ivan Herman ivan@w3.org

  • Intended usage:

    Common

  • Restrictions on usage:

    None

  • Author(s):

    Drummond Reed, Manu Sporny, Markus Sabadello, Dave Longley, Christopher Allen

  • Change controller:

    W3C

Fragment identifiers used with application/did+ld+json are treated according to the rules associated with the JSON-LD 1.1: application/ld+json media type [JSON-LD11].

G. References

G.1 Normative references

G.2 Informative references

posted @ 2020-04-08 21:11  NykuvL  阅读(1910)  评论(0)  编辑  收藏  举报