Decentralized Identifiers (DIDs) v1.0

Lead Translating Organization:
CAICT, http://www.caict.ac.cn/
No.52, Hua Yuan Bei Road, Haidian District, Beijing, China
Yue Jing
Bo Zhang
​ ​
​ ​

授权中文翻译草稿

2014年12月1日

​ ​
此版本:
https://translated-did-core.github.io/
最新版本:
https://translated-did-core.github.io/
原始文档:
https://www.w3.org/TR/did-core/
勘误页:
牵头翻译组织:
中国信息通信研究院 http://www.caict.ac.cn/
牵头翻译组织联络人:
景越中国信息通信研究院
张波中国信息通信研究院
​ ​
参与翻译审阅工作的人员名单:
参与翻译审阅的单位及个人:https://lists.w3.org/Archives/Public/w3c-translators/2024OctDec/0020.html
候选授权翻译审阅内容总结:
​ ​

此版本为授权W3C文档。此翻译文档的发布遵循W3C授权翻译文档流程。如有任何争议,应以原始英文版本为权威版本。

​ ​
​ ​

分布式标识(Decentralized Identifiers,DIDs) v1.0

核心架构,数据模型和表示(Core architecture, data model, and representations)

W3C Recommendation

本文档的更多细节
此版本:
https://www.w3.org/TR/2022/REC-did-core-20220719/
最新更新版本:
https://www.w3.org/TR/did-core/
最新编辑稿:
https://w3c.github.io/did-core/
历史记录:
https://www.w3.org/standards/history/did-core
Commit history
实施报告:
https://w3c.github.io/did-test-suite/
编辑:
Manu Sporny (Digital Bazaar)
Amy Guy (Digital Bazaar)
Markus Sabadello (Danube Tech)
Drummond Reed (Evernym/Avast)
作者:
Manu Sporny (Digital Bazaar)
Dave Longley (Digital Bazaar)
Markus Sabadello (Danube Tech)
Drummond Reed (Evernym/Avast)
Orie Steele (Transmute)
Christopher Allen (Blockchain Commons)
反馈:
GitHub w3c/did-core (pull requests, new issue, open issues)
public-did-wg@w3.org with subject line [did-core] … message topic … (archives)
勘误表:
Errata exists.
相关文档
DID Use Cases and Requirements
DID Specification Registries
DID Core Implementation Report

另请参阅 翻译版本.


摘要

分布式标识(DIDs)是一种新型标识符,可以实现可验证的去中心化数字身份。一个DID 可以是该DID控制者指定的任何物体(例如:人、组织、物体、数据模型、抽象物体等)。与典型联邦式标识符不同的地方在于,DIDs从设计的源头脱离了与集中式注册表、身份提供者和证书颁发机构的关联。具体来讲,虽然可能会利用其它方来帮助发现与DID相关联的信息,但该设计使 DID的控制者可以证明其对DID的控制,而无需任何其它方的许可。 DIDs是一串将DID对象DID文档关联起来的URIs,并且允许了对象与文档之间的可信交互。 ​

每一个DID文档都可以包含加密材料、验证方法服务, 它们共同提供了一整套的机制,从而使DID控制者能够证明其对DID的控制。服务DID对象的交互提供可信支撑。如果DID对象是一个信息资源,例如数据模型,那么DID可能提供返回DID对象本身的方法。

本文档详细说明了DID涉及的语法,通用数据模型,核心属性,序列化表示,DID 操作和通过解析DID以此获得其所代表资源的过程。

文本状态

本节描述了本文档在发布时的状态。当前的W3C出版物列表和此技术报告的最新修订版可以在W3C技术报告索引技术报告索引中找到,网址是 https://www.w3.org/TR/。

在该规范发布时,已经存在103种实验性DID方法规范,32种实验性DID方法驱动程序实现,一个用于确定驱动程序实现是否符合本规范以及满足测试集中46中测试实现的测试集。建议读者注意DID 核心问题 DID 核心测试套件问题其中每个问题都包含最新的关注列表和可能导致更改本规范的提议。在发布时,将没有其他实质性问题,变化或修改。 ​

欢迎对本文件提出意见,请将问题直接存档在 GitHub,或者邮件至public-did-wg@w3.org ( subscribe, archives). ​

W3C分布式标识工作组已通过建议跟踪将此文档作为W3C的推荐标准。

W3C建议将此标准作为Web标准进行广泛部署。

W3C建议标准是一种规范,经过广泛的共识构建并得到W3C及其成员的认可,也得到工作组成员对实现的免版税许可的承诺。 ​

该文件由遵守W3C专利政策W3C Patent Policy小组制作。 W3C维护一个公开的专利列表public list of any patent disclosures,其中包含了该组织可交付成果相关的任何专利披露情况;该页面也包含披露专利的说明。拥有实际认知且认为包含基本权利Essential Claim(s)要求的专利的个人必须根据 W3C 专利政策第 6 节披露该信息section 6 of the W3C Patent Policy。 ​

本文档受2021年11月2日W3C流程文档的约束(2 November 2021 W3C Process Document).

1. 介绍

此章节是非规范性的。

作为个人和组织,我们很多人都在使用全球唯一标识符在各种各样的情况下。这些标识符作为通信地址(电话号码、电子邮件地址、社交媒体上的用户名)、身份证号码(护照、驾驶执照、税号、健康保险)和产品标识符(序列号数字、条形码、RFID)。URI(统一资源标识符)用于标记Web上的资源,此外,您在浏览器中查看的每个网页都有一个全局唯一URL(统一资源定位符)。 ​

这些全球唯一标识符中的绝大多数不受我们的控制。它们由外部的权威机构颁发,这些权威机构决定这些标识符发给谁和它们用来做什么,以及它们何时可以被撤回。它们仅在某些情况下有用,并且只被某些特定的机构所认可。它们可能会随着颁发机构的倒闭而消失或不再有效。它们可能在不经意间泄露个人信息。在许多情况下,它们可以被恶意的第三方欺诈性地复制和断言,这便是通常所说的“身份盗窃”。

本规范中定义的分布式标识 (DID) 是一种新的全球唯一标识符的类型。它们旨在使个人和组织使用其信任的系统生成属于自己的标识符。这些新的标识符使个人和组织能够通过加密证明(例如,数字签名)进行身份验证,以此来证明对该标识的掌控。 ​

由于分布式标识的生成和断言是由实体控制的,每个实体都可以拥有尽可能多的DID,以此来满足他们所需要的身份、角色和互动的独立性。这些标识符的使用可以适当地限定在不同的场景与环境中。他们支持人、机构、系统、物体间的互动与互认,同时它可以控制个人数据的泄露量,而这所有的一切都不依赖中心化的授权机构。这些想法也在DID用例文档中进行了探讨[DID-USE-CASES]。 ​

本规范不预先设定任何特定的技术或密码学以此来支持DID的产生、存在、解析或者说明。例如,部署者可以基于联邦或中心化身份管理系统生成DID。实际上,几乎所有类型的标识系统都可以添加对DID的支持。这为中心化、联邦化和分布式标识相互间的互操作搭建了桥梁。这也使得部署者能够选择他们所信任的计算基础设施,例如分布式账本、分布式文件系统、分布式数据库、点对点(P2P)网络等,开发设计特定种类的DID。 ​

本规范适用于: ​

除了此规范外,读者也可以在《对于分布式标识的应用案例和要求》 [DID-USE-CASES]找到更多有用信息。 ​

1.1 一个简单的案例

此章节是非规范性的。

DID是一个简单的文本字符串,一个DID标识包含了三部分:1)did URI 方案标识符,2) 用于标记DID方法的标识符,和3)DID方法指定的标识符。 ​


A diagram showing the parts of a DID. The left-most letters spell 'did' in blue,
are enclosed in a horizontal bracket from above and a label that reads 'scheme'
above the bracket. A gray colon follows the 'did' letters. The middle letters
spell 'example' in magenta, are enclosed in a horizontal bracket from below and
a label that reads 'DID Method' below the bracket. A gray colon follows the
DID Method. Finally, the letters at the end read '123456789abcdefghi' in
green, are enclosed in a horizontal bracket from below and a label that
reads 'DID Method Specific String' below the bracket.
1 一个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": [{
    // used to authenticate as did:...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

1.2 设计目标

此章节是非规范性的。

分布式标识 是某个大系统中的组成元素,例如可验证凭证(Verifiable Credentials ecosystem)生态系统[VC-DATA-MODEL]。该生态系统对这份规范的设计带来了影响。分布式标识这份规范的设计目的整理如下。 ​

​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​
目标 ​ 描述 ​
分布式 ​ 消除对中心化管理机构的依赖和标识管理中单点故障的出现,包括全球唯一注册标识符、公共验证密钥、服务和其它信息。 ​
可控性 ​ 赋予实体,包括人类和非人类,直接控制他们数字身份的能力,而无需依赖外部的权威机构。 ​
隐私性 ​ 赋予实体能够控制其隐私信息的能力,包括最小的、选择性的和逐渐性披露属性或其它数据的能力。 ​
安全性 ​ 为请求方提供拥有足够安全性的DID文档,以此来满足其所需的安全级别。 ​
可证明性 ​ 使得DID控制者在与其它实体交互时提供加密证明。 ​
可发现性 ​ 使得实体可以找到其它实体的DIDs,从而了解或者与其进行交互。 ​
互操作性 ​ 使用互操作标准,以便使得DID基础设施可以使用已存在的工具或软件实现互操作性。 ​
可移植性 ​ 不依赖于系统和网络,从而使得实体能够选择任何支持DIDsDID方法的系统。 ​
简易性 ​ 通过精简、简易化的特性,使得技术更易于理解、实施和部署。 ​
可扩展性 ​ 在可能且不妨碍扩展的情况下,启用可扩展性、互操作性、可移植性或简易性。 ​

1.3 体系架构概述

本章节是非规范性的。

本章节提供了对分布式标识架构中主要组件的基本概述。 ​


DIDs and DID documents are recorded on a Verifiable Data Registry; DIDs resolve
to DID documents; DIDs refer to DID subjects; a DID controller controls a DID
document; DID URLs contains a DID; DID URLs dereferenced to DID document
fragments or external resources.
2 DID架构概述及基本组件间的关系。参考: 详细说明.

图中包含了六个内部具有标记的图像,它们之间关系由箭头标记,如下图所示。在图标的中间是一个标记为“DID URL”的矩形,包含一串打印字符串"did:example:123/path/to/rsrc"。在图的中间顶部是一个标记为“DID”的矩形,包含一串打印字符串“did:example:123”。在图的左上方是一个椭圆形,标记为“DID对象(DID subject)”。在图的底部中间是一个矩形,标记为“DID文档(DID document)”。在图的左下角是一个椭圆形,标记为“DID控制者(DID controller)”。在图的右侧中间是一个圆柱体,标记为“可验证数据注册表(verifiable data registry)”。 ​

从“DID URL”矩形的顶部延伸出一个标记为"包含(contains)"的箭头,指向“DID”。从“DID URL”矩形的底部延伸出来一个标记为“参考/引用(refer)”和“解引用(dereferences)”的箭头,指向“DID文档(DID document)” 。从“DID”矩形底部延伸出来一个标记为“解析到(resolves to)”的箭头,指向DID文档(DID document)。从“DID”矩形左侧延伸出来一个标记为“参考(refers to)”的箭头,指向DID对象(DID subject)。从“DID控制者(DID controller)”右侧延伸出来一个标记为“控制(controls)”的箭头,指向右侧的“DID文档(DID document)”。从“DID”右侧延伸出来一个标记为“被记录在(recorded on)”的箭头,指向“可验证数据注册表(verifiable data registry)”。从“DID文档(DID document)”右侧延伸出来一个标记为“被记录在(recorded on)”的箭头,指向右侧的“可验证数据注册表(verifiable data registry)”。

DIDs and DID URLs
一个分布式标识DID是一串URI,其包含三部分:URI方案 did:,DID方法标识符,和一串由DID方法指定的标识符。DIDs可以被解析得到一个DID 文档。一个DID URL 拓展了基本的 DID语法使其融合了其它 URI标准内容,譬如:路径(path)、查询(query)和片段(fragment),以便定位到特定的资源,例如,定位到 DID 文档中的公钥、或者 DID 文档外部的资源等。 这些概念在 3.1 DID 语法3.2 DID URL 语法中有介绍。 ​
DID对象
根据定义,DID对象可定义为DID标记的实体。 DID 对象 也可以是 DID 控制者。任何事物都可以是DID的标记对象:人、团体、组织、事物或概念。在 5.1.1 DID 对象中有更深入的定义。 ​
DID控制者
DID控制者DID方法所规定,其是能够对DID文档进行更改的实体(人、组织或自主软件)。这种能力通常由代表控制者的软件使用的一组加密密钥的控制来声明,尽管它也可以通过其他机制来声明。请注意,一个DID可能有多个控制者,DID 对象可以是 DID 控制者,也可以是其中之一的控制者。相关的概念可以在 5.1.2 DID 控制者中找到。 ​
可验证数据注册表
为了解析后得到DID 文档DIDs 通常被记录在某种底层系统或网络上。无论使用何种具体技术,任何支持记录 DIDs并返回生成DID 文档 所需数据的系统都称为可验证数据注册表。例如有:分布式账本、去中心化文件系统、任何类型的数据库、对等网络和其他形式的可信数据存储。这些概念在8. 方法中有进一步的阐述。 ​
DID文档
DID 文档 包含与DID相关的信息。它们通常表示了 验证方法,例如加密公钥,以及与 DID 对象交互相关的服务DID 文档 细节的属性说明在5. 核心属性中。 一个 DID 文档可以被序列化为一个字节流(见 6. 表示)。DID 文档中的属性可根据适当操作进行更新,见8. 方法。 ​
DID方法
DID 方法指的是创建、解析、更新和停用特定类型的DID及其关联DID 文档的机制。DID 方法 在另外一个规范中有详细介绍,见8. 方法。 ​
DID解析器和DID解析
一个DID解析器是一个系统组件,它将一个DID 作为输入,并生成符合要求的DID 文档作为输出,这个过程称为DID解析。解析特定类型 DID 的步骤由相关的 DID 方法 规范进行定义。关于DID 解析进一步的说明参考7. 解析。 ​
DID URL解引用器和DID URL解引用 ​
一个DID URL 解引用器是一个系统组件,它将 DID URL作为输入,并生成资源作为输出。这个过程称为 DID URL 解引用,详细可见: 7.2 DID URL 解引用。 ​

1.4 合规性

除了标记为非规范性的部分外,本规范中的所有撰写指南、图表、示例和注释也是非规范性的。本规范中的其他所有内容都是规范性的。

文档中关键词可能, 必须, 必须不能, 可选择的, 建议的, 要求的, 应该, 和 不应该 仅在以全大写形式出现时按照BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。

本文包含涉及JSON和JSON-LD内容的示例。其中一些示例包含无效字符,如内联注释(//) 以及使用省略号 (...) 来表示对示例没有多大价值的信息。如果实现者希望将这些信息作为有效的JSON或JSON-LD使用,则需要注意删除这些内容。 ​

一些示例包含本规范中未定义的术语,包括属性名和值。这些用注释(// external (property name|value))来表示。当在 DID 文档中使用这些术语时,它们将在DID规范注册表[DID-SPEC-REGISTRIES] 中进行注册,并链接到正式定义和JSON-LD文档中。 ​

通过评估实现创建和解析符合本规范的DIDsDID 文档的能力,可以测试 DIDsDID 文档 实现的互操作性。通过确保 DIDsDID 文档 的合规性,为DIDsDID 文档 的生产者和消费者提供互操作性。通过各 DID 方法规范中的细节提供 DID 方法 规范的互操作性。就像web浏览器不需要实现所有已知的 URI 方案一样,与 DIDs配合使用的合规软件也不需要实现所有已知的DID 方法。然而,对于特定的 DID 方法,该方法的所有实现都应该对该方法本身具有互操作性。 ​

一个符合规范的 DID 是指,符合3. 标识部分相关规范性陈述的规则的任何具体表达。 ​

一个符合规范的 DID文档 是指,符合 4. 数据模型5. 核心属性的数据模型的任何具体表达。一致性文档的格式是确定的、双向的、无损的,如6. 表示所述。 ​

一个符合规范的创作者 是指,任何可以产生符合规范DID符合规范DID文档的软件/硬件的算法,同时符合6. 表示中的相关规范。 ​

一个符合规范的使用者 是指,任何可以读取/识别 符合规范DID符合规范DID文档的软件/硬件的算法,同时符合 6. 表示中的相关规范。 ​

一个符合规范的 DID解析器 是指,符合 7.1 DID 解析中规范的软件/硬件的算法。 ​

一个符合规范的 DID URL重新访问器 是指,符合 7.2 DID URL 解引用中规范的软件/硬件的算法。 ​

一个符合规范的 DID方法 是指,符合8. 方法中相关规范性表述的规范。 ​

2. 术语

此章节是非规范性的。

本节定义了本规范和整个分布式标识基础架构中使用的术语。本规范中出现的术语将会给出相关链接。

放大攻击
攻击者通过提供少量的有效输入试图耗尽目标系统的CPU、存储、网络或其他资源的一类攻击。该攻击造成的破坏性影响其处理成本可能比输入本身的成本要高出很多。
验证
验证是实体可以使用一个或多个 验证方法来证明其具有特定属性或控制特定秘密的过程。对于DIDs来说,一个常见的例子是证明对一个 DID 文档中与公钥关联的私钥的控制。
密码套件
一个定义特定密码原语的使用规范,以达到安全的目标。这些文档经常会来指定一些 验证方法、数字签名的类型、它们的标识符和其他关联的属性。
分布式标识
一种全球唯一的永久标识符,不依赖中心化的注册机构,通常通过密码的方式生成或注册。DID的通用格式定义在 3.1 DID 语法。一个特定的 DID方案DID 方法规范中有定义。大多数(不是全部)DID方法都用到了分布式账本(DLT),或者其他形式的去中心化网络。
分布式身份管理
身份管理 基于 DID的使用。分布式身份管理超越了传统信任根管理下标识符的生成、注册和分配权限。传统信任根例如:X.500 目录服务域名系统和大多数国家的身份标识系统。
DID控制者
有能力更改DID 文档的一个实体。一个DID可能有超过一个的DID控制者。DID控制者可以由DID 文档顶层的可选择的controller属性来表示。注意,一个DID控制者可能是DID 对象
DID代理
DID 控制者授权,可以通过DID 文档使用与DID相关联的验证方法的一个实体。例如,父母可以控制一个孩子的DID 文档,可能会允许孩子使用个人设备进行身份的验证。在这种情况下,这个孩子就是DID 代理。该孩子的个人设备将包含私人的加密材料,使得孩子可以通过DID进行身份验证。然而,未经过父母的允许,孩子不能再添加其它的个人设备。
DID文档
描述DID 对象的一组数据集合,包括 DID 对象或者DID 代理可以用于验证自身身份并证明其与DID关联的机制,例如加密公钥。一个DID文档可以有一种或多种不同的表示形式,见章节 6. 表示中的定义,或者W3C DID Specification Registries [DID-SPEC-REGISTRIES]。
DID片段
DID URL中第一个井号(#)后面的部分。DID 片段的语法与 URI 片段语法相同。
DID方法
定义了如何实现一种特定的 DID 方法 方案。一种DID 方法由 DID 方法规范定义,该规范指定了创建、解析、更新和停止使用 DIDsDID 文档的精确操作方法。详见章节 8. 方法
DID路径
DID URL 的一部分,以第一个斜杠 (/)符号开头(包含该 (/)),以问号(?) 符号,或井号 (#) 符号,或DID URL的末尾结尾。DID 路径语法与 URI 路径语法相同。参考 路径(Path)
DID查询
DID URL 的一部分,以第一个问号 (?)符号开头(包含该 (?))。DID 查询语法与 URI 查询语法相同。参考 查询(Query)
DID解析
该过程以 DID和一组解析选项作为输入,并返回符合表示形式的DID 文档以及附加的元数据。此过程依赖所使用 DID 方法中规定的“读写(read)”操作。过程中输入和输出定义在章节 7.1 DID 解析
DID解析器
一个DID 解析器是一个来实现DID 解析功能的软件或硬件组件,通常将DID作为输入并生成符合要求的 DID 文档 作为输出。
DID方案
DID的正式语法。通常以前缀did: 开头(见3.1 DID 语法)。每个 DID 方法 都规定了一个与该特定 DID 方法一起使用的特定的DID方法方案。在特定的DID方法方案中,DID方法名称在第一个冒号后面,在第二个冒号前,例如,did:example:
DID对象
DID标记并由DID 文档描述的实体。任何一个事物都可以是DID对象,人、团体、组织、物理实体、数字对象、逻辑事物等。
DID URL
一个加上任何符合 3.2 DID URL 语法 定义里附加语法的 DID。这包括可选的DID 路径(带有其前导的 /符号),可选的DID 查询(带有其前导的 ?符号),以及可选的 DID 片段(带有其前导的#符号)。
DID URL解引用
该过程以DID URL 和一组输入元数据作为输入,并且返回一个资源。这个资源可能是DID 文档加上附加元数据、DID 文档中包含的辅助资源,或者完全位于 DID 文档外部的资源。该过程使用DID 解析来获取DID URL中包含的DID 文档。重新访问过程可以对DID文档执行其他处理,并且返回DID URL指示的重新访问的资源。此过程的输入和输出定义在章节7.2 DID URL 解引用
DID URL解引用器
对给定的DID URLDID 文档执行DID URL 解引用功能的软件或硬件系统。
分布式账本
一种非中心化的事件记录系统。这些系统使得参与者们可以依赖系统中其他人记录的数据,从而使得每一个参与者都可以足够信任该系统。分布式账本通常使用分布式数据库,其中不同的节点使用共识协议来确认加密签名交易的顺序。随着时间的推移,数字签名交易的链接通常使得账本的历史记录不可篡改。
公钥描述
DID 文档中包含的数据对象,其中包含使用公钥或验证密钥所需的所有元数据。
资源
根据 [RFC3986 ] 的定义:“...‘资源(resource)’在一般意义上用于表示可以通过URI标识的任何事物。”类似地,任何资源都可以作为由 DID标记的DID 对象
表示
根据 [RFC7231 ] 对 HTTP 的定义:“旨在反映给定资源的过去、当前或期望状态的信息,其格式可以通过协议轻松传达,由一组表示元数据和可能无限的表示数据流组成。” 一个DID 文档是描述一个DID 对象信息的表示(representation)。 请参阅 6. 表示
特定条目表示
DID 文档中对特定条目的表示。定义在 4. 数据模型6. 表示。例如,JSON-LD representation中的@context就是一种特定条目的表示。
服务
通过一个或者多个服务端点DID 对象或相关实体进行通信或交互的方式。例如,发现服务、代理服务、社交网络服务、文件存储服务和可验证凭证存储库服务。
服务端点
一个网络地址,例如HTTP URL, 服务代表 DID 对象在此运行。
统一资源标识符 (URI)
在[RFC3986]中定义的万维网上所有资源的标准标识符格式。DID本身是一种URL方案。
可验证凭证
由W3C可验证凭证规范[VC-DATA-MODEL]定义的加密可验证的一种数字凭证的数据模型和表示格式的标准。
可验证数据注册表
促进创建、验证、更新和停止使用 DIDDID 文档的系统。一个可验证数据注册表还可以用于其它加密可验证的数据结构,例如 可验证凭证。有关更多信息,请参考W3C 可验证凭证规范 [VC-DATA-MODEL]。
可验证时间戳
一个可验证时间戳使得第三方能够验证数据对象在特定时刻是否真实存在,并且自该时刻以来未被修改或损坏。如果数据完整性自该时刻以来可能被修改或损坏,则该时间戳不可被验证。
可验证方法

一组可与流程一起使用以独立验证证明的参数。例如,一个加密公钥可用作数字签名的验证方法;在这种用法中,它可以验证签名者是否拥有相关的加密私钥。

本定义中的”验证(Verification)“和”证明(proof)“是广义含义上的用法。例如,在Diffie-Hellman密钥交换期间,可能会使用加密公钥来协商用于加密的共享对称密钥。这保证了密钥协商过程的完整性。因此,即使过程的描述中可能没有使用”验证“或者”证明“这两个词,这也是另外一种验证方法。

可验证关系

DID 对象与一种验证方法之间关系的表达方式。验证关系的一个例子是 5.3.1 验证。 ​

通用唯一标识符(UUID)
[RFC4122]中定义的一种全局唯一标识符。UUID与DID类似,因为他们不需要中心化的注册机构。UUID与DID的不同之处在于,UUID不可解析也无法通过加密进行验证。

除上述术语外,本规范还使用[[INFRA]]规范中的术语来正式定义 数据模型。当使用 [INFRA] 中的术语,譬如字符串集合映射时,它会直接链接到该规范。

3. 标识符

本节描述了DIDsDID URLs的语法形式。术语“通用”用于区分此处定义的语法与特定 DID 方法在各自规范中定义的语法。对DIDsDID URLs的创建过程及其创建时间,在8.2 方法操作B.2 创建一个DID 中有所描述。 ​

3.1 DID语法

通用DID 方法DID方案是符合[RFC3986]的 URI 方案。ABNF的定义如下,其使用[RFC5234]中的语法以及 ALPHADIGIT的相应定义。以下ABNF中未定义的所有其他规则名称在[RFC3986]中进行定义。所有DIDs 必须符合DID语法ABNF规则。 ​

​ ​ ​
DID语法的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 / "." / "-" / "_" / pct-encoded
pct-encoded        = "%" HEXDIG HEXDIG

对与DID语法相关的DID 方法的要求,请参考: 8.1 方法语法

3.2 DID URL语法

DID URL是特定资源的网络位置标识符。它可以用来检索DID 对象, 验证方法, 服务, DID 文档的特定部分或其他资源的具体表示。 ​

下面是使用[RFC5234]中的语法对ABNF的定义。它建立在3.1 DID Syntax did 语法基础之上。 path-abempty, query, 和 fragment 组件在[RFC3986]中进行定义。所有DID URLs必须符合DID URL语法ABNF规则。DID 方法可以进一步限制这些规则,如8.1 方法语法中所表述。 ​

​ ​ ​
DID URL语法ABNF规则
did-url = did path-abempty [ "?" query ] [ "#" fragment ]
提示:保留分号以备未来使用

尽管可以根据DID URL语法规则使用分号 (;) 字符,但该规范的后续版本可能会将其用作[MATRIX-URIS]中所述参数的子分隔符。为避免今后冲突,开发人员应避免使用它。 ​

路径

DID 路径与通用URI路径相同,并符合 RFC 3986, section 3.3中的path-abemptyABNF规则。与URIs一样,路径的语义可以通过DID 方法指定,而这反过来又可以使DID 控制者进一步专业化这些语义。 ​

did:example:123456/path

查询

DID 查询与通用的URI查询相同,并符合RFC 3986, section 3.4中的queryABNF规则。该句法的特征在3.2.1 DID 参数中有详细说明。 ​

did:example:123456?versionId=1

片段

DID 片段语法和语义与通用的URI片段相同,并符合RFC 3986, section 3.5中的fragmentABNF规则。 ​

DID 片段被用作独立于DID方法的DID 文档或外部资源的引用。以下是一些DID片段标识符的示例。 ​

例子 4: DID文档中一个特殊的验证方法
did:example:123#public-key-0
例子 5: DID文档中一个特殊的服务
did:example:123#agent
例子 6: DID文档外部的一个资源
did:example:123?service=agent&relativeRef=/credentials#degree
提示: 跨表示的片段语义

为了最大限度地提高互操作性,建议实现者以同样的方式解释DID 片段表示。 (参考 6. 表示). 例如,尽管JSON Pointer [RFC6901]可以用于 DID 片段,但在非JSON的 表示中它的解释方式并不相同。 ​

与DID片段相关的其它语义,在 E.2 应用程序/did+ld+json中有更多JSON-LD表示的描述。有关如何解除访问DID 片段的信息,请参考 7.2 DID URL 解引用。 ​

3.2.1 DID参数

基于查询中描述的query部分,DID URL 语法支持一种简单的参数格式。将一个DID参数添加到DID URL中意味着该参数成为指向 资源的标识符的一部分。 ​

例子 7: 一个拥有'versionTime'DID参数的DID URL
did:example:123?versionTime=2021-05-10T17:00:00Z
例子 8: 一个拥有'service'和'relativeRef'参数的DID URL
did:example:123?service=files&relativeRef=/resume.pdf

一些DID参数完全独立于任何特定的DID 方法,并以相同的方式对所有DIDs发挥作用。并非所有DID 方法都支持DID参数。在支持可选参数的情况下,它们应在支持它们的DID 方法中统一实现并运行。下表提供了在所有DID 方法中以相同方式发挥作用的常见DID参数。是否支持所有DID 参数可选择>的。 ​

提示

通常,DID URL重新访问器的实现将引用[DID-RESOLUTION]以获取更多实现细节。本规范的范围仅定义了最常见查询参数的合约。 ​

参数名称 描述
service 根据服务ID识别DID 文档中的服务。如果存在,关联值必须是一个ASCII字符串
relativeRef 根据RFC3986 Section 4.2,相对URI引用是指通过使用DID 文档服务端点service参数来标记/获取资源。如果存在,关联值必须是一个ASCII字符串,并且必须>使用RFC3986 Section 2.1中指定的百分比编码来表示某些字符。
versionId 标记要解析的 DID 文档的特定版本(版本ID可以是顺序的,或者是UUID,或者是用于特定方法的)。如果存在,关联值必须>是一个ASCII 字符串
versionTime 标记要解析的DID 文档的特定版本时间戳。即,在特定时间内对DID有效的一个DID 文档 。如果存在,关联值必须>是一个有效的XML日期时间值的ASCII 字符串,见W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [XMLSCHEMA11-2]。该日期时间值*必须*标准化为UTC 00:00:00,且不保留亚秒级小数精度。例如:2020-12-20T19:17:47Z
hl 在[HASHLINK]中指定的,用于添加完整性保护的DID 文档资源的哈希值。该参数是非规范性的。如果存在,关联值必须是一个ASCII 字符串。 ​

实现者以及DID 方法规范的作者可能会使用此处未列出的其他DID参数。为实现最大程度的互操作性,建议>DID参数使用DID规范注册表机制[DID-SPEC-REGISTRIES],以避免与具有不同语义的相同DID参数的其他使用发生冲突。 ​

如果存在明确的用例需要将DID参数作为URL的一部分,从而比单独使用DID可以作为更精确的方式来引用 资源,则可以使用DID参数。如果可以通过向DID解析器传递输入元数据来表示相同的功能,则不应该>使用DID参数。有关处理这些参数的其他注意事项,请参见[DID-RESOLUTION]。 ​

提示: DID参数与DID解析

通过将不属于DID URL的输入元数据传递给DID 解析器,可能影响DID 解析DID URL 解引用的过程,参考(7.1.1 DID 解析选项)。这与HTTP类似,在HTTP中,某些参数可以包含在HTTP URL中,或者在重新访问过程中作为HTTP标头传递。重要的区别在于,DID参数作为DID URL的一部分,它应用于指定所标识的资源,而不作为DID URL一部分的输入元数据应用于控制如何解析或解引用该资源。 ​

3.2.2 相对DID URL

一个相对DID URLDID 文档中不以`did::`开头的任何URL值。更具体地说,它是任何不以3.1 DID 语法中定义的ABNF开头的URL值。URL应引用同一个 DID 文档中的资源。相对 DID URLs可能包含相对路径(path)组件、查询(query)参数和片段(fragment)标识符。 ​

在解析相对DID URL引用时,必须 使用RFC3986 Section 5: Reference Resolution中指定的算法。基础 URI 的值是与DID 对象相关联的DID,参考5.1.1 DID 对象方案did授权<method-name>:<method-specific-id>的组合,此外,path, queryfragment的数值为路径, 查询片段中分别定义的值。 ​

相对DID URLs通常用于检索/引用DID 文档中的验证方法服务,而不必使用绝对URL。需要考虑存储大小的DID 方法 可以使用相对URL来减少DID 文档的存储大小。

例子 9: 一个相对DID URL的例子
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [{
    "id": "did:example:123456789abcdefghi#key-1",
    "type": "Ed25519VerificationKey2020", // external (property value)
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }, ...],
  "authentication": [
    // a relative DID URL used to reference a verification method above
    "#key-1"
  ]
}

在上面的示例中,一个相对DID URL值被转换为一个绝对 DID URLdid:example:123456789abcdefghi#key-1

4. 数据模型

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

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


Diagram illustrating the entries in the DID document, including properties
and representation-specific entries; some entries are defined by this
specification; others are defined by registered or unregistered extensions.
3 DID文档中的条目。参考: 详细描述.
这个图的标题是“DID文档中的条目”。一条灰色虚线水平穿过图的中心。虚线上方标记为“属性(properties)”,下方标记为“特定的表示条目(Representation-specific entries)”。图中出现了六个带标签的矩形,三个位于灰色虚线上方,三个位于灰色虚线下方。一个大的标有“DID Specification registres”的绿色矩形,包含了最左边的四个矩形(左上、中上、左下和中下)。最左边的两个矩形(左上和左下)以蓝色标出,并以蓝色标记,如图所示。左上角的矩形标签为“核心属性(Core Properties)”,包含”id, alsoKnownAs, controller, authentication, verificationMethod, service,serviceEndpoint……”。左下角的矩形被标记为“核心特定的表示条目(Core Representation-specific Entries)”,包含文本“@context”。最右边的四个矩形(中上、右上、中下和右下)用灰色标出,并用黑色标记,如图所示。上面的中心矩形被标记为“属性扩展(Property Extensions)”,并包含文本“以太坊地址(ethereumAddress)”。中间下方的矩形被标记为“特定于表示的条目扩展(Representation-specific Entry Extensions)”,并且不包含其他文本。右上角的矩形被标记为“未注册的属性扩展(Unregistered Property Extensions)”,并且包含文本“foo”。右下角的矩形标记为“未注册的特定于表示的条目扩展名(Unregistered Representation-specific Entry Extensions)”,并包含文本“%YAML, xmlns”。 ​

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

​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​
数据类型 注意事项
映射 键/值对的有限、有序序列,没有出现重复的键,如[INFRA]中所述。在[INFRA]中,映射有时被称为有序映射
list 项目的有限、有序序列,如[INFRA]中所述。
set 项目的有限、有序序列,不包含重复项,如[INFRA]中所述。在[INFRA]中,集合(set)有时被称为有序集合。 ​
datetime 能够无损地表示`dateTime`可表示的所有值的一个日期和时间值,如[XMLSCHEMA11-2]中所述。 ​
string 在[INFRA]中指定的通常用于表示人类可读语言的代码单元序列。 ​
integer 没有分数部分的实数,如[XMLSCHEMA11-2]中所述。为实现最大程度的互操作性,建议实现者遵守RFC8259, Section 6: Numbers中有关整数的建议。 ​
double 通常用于近似表示任意实数的一个值,如 [XMLSCHEMA11-2]中所述。为实现最大程度的互操作性,建议实现者遵守RFC8259, Section 6: Numbers中有关双精度浮点数的建议。 ​
boolean [INFRA]中所定义的true或false值。 ​
null [INFRA]中所定义的缺少值的值。 ​

由于使用[INFRA]中的术语来定义数据模型,因此包含多个项目,如: 列(lists), 映射(maps)集合(sets)的属性值均为显式排序。[INFRA]中所有类似列表的值结构都是有序的,无论该顺序是否重要。对于本规范而言,除非另有说明,否则映射集合排序并不重要,并且不期望通过实现生成或使用确定性排序的值。 ​

4.1 可扩展性(Extensibility)

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

  1. 为实现最大程度的互操作性,建议扩展使用W3C DID规范注册表机制[DID-SPEC-REGISTRIES]。将此机制用于新属性或其他扩展是确保两种不同的表示能够一起运行的唯一指定机制。
  2. 表示形式可以定义其他扩展机制,包括不需要使用DID规范注册表的机制。这种扩展机制应支持无损转换到任何其他符合规范的表示形式。一种表示的扩展机制应对所有属性和表示语法映射到数据模型及其类型系统进行定义。
注意: 未注册的扩展不太可靠

对于两种具体实现来说,始终可以在带外达成一致,使用一种彼此理解但未记录在DID规范注册表[DID-SPEC-REGISTRIES]中的扩展或表示形式。但是,这类实现与更大的生态系统之间的互操作性将不太可靠。

5. 核心属性

一个 DID 与一个DID 文档相关联。 DID 文档使用数据模型来表示,并且可以被序列化为一个表示。 以下的章节定义了DID 文档中的属性,包括这些属性是必须的还是可选的。这些属性描述了DID 对象与属性值之间的关系。 ​

下表包含本规范定义的核心属性的信息引用,包含期望值以及是否需要它们。表中的属性名称与每个属性的规范定义和更详细的描述相关联。

Note: Property names used in maps of different types

属性名称 id, type, 和 controller 可以出现在不同类型的映射中,但约束可能存在差异。

DID 文档属性

​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​
属性 必要性? 值约束
id 符合3.1 DID Syntax规则的一个字符串
alsoKnownAs 符合[RFC3986]URIs规则的一集合字符串。 ​
controller 符合3.1 DID 语法规则的一个字符串或一组字符串。 ​
verificationMethod 符合验证方法属性规则的一组验证方法的( 映射)。 ​
authentication 符合验证方法属性规则的一可验证方法映射或符合3.2 DID URL 语法规则的一串字符串。 ​
assertionMethod
keyAgreement
capabilityInvocation
capabilityDelegation
service 符合Service properties规则的一服务端点映射。 ​

验证方法属性

​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​
属性 必要性? 值约束
id 符合3.2 DID URL 语法规则的一个字符串。 ​
controller 符合3.1 DID 语法规则的一个字符串。 ​
type 一个 字符串。 ​
publicKeyJwk 符合 [RFC7517]规则的一个表示 JSON Web Key的映射。更多约束请参考definition of publicKeyJwk。 ​
publicKeyMultibase 符合[MULTIBASE]编码公钥的一个字符串。 ​

服务属性

属性 必要性? 约束值
id 符合[RFC3986]URIs规则的一个字符串
type 一个字符串 或者一 字符串
serviceEndpoint 一个或者一符合[RFC3986]URIs规则的字符串,或者一个映射

5.1 标识符

本节描述DID 文档包含DID 对象DID 控制者标识符的机制。

5.1.1 DID 对象

一个特定DID 对象DID使用DID 文档中的id属性来表示。 ​

id
id的属性值必须是一个符合 3.1 DID 语法规则的字符串,并且该值必须存在于DID 文档数据模型的根的映射中。 ​
{
  "id": "did:example:123456789abcdefghijk"
}

id属性仅仅表示该DID 对象DID当它出现在 DID 文档映射最顶端 时。 ​

Note: 中间表示

DID 方法规范可以创建不包含id属性的DID 文档,例如当DID 解析器执行DID 解析时。但是,完全解析的DID 文档始终包含一个有效的id属性。 ​

5.1.2 DID控制者

DID 控制者是被授权的可以对DID 文档进行修改的实体。DID 方法中定义了授权 DID 控制者 的过程。 ​

控制者
controller 的属性是可选择 的。如果存在,其值必须是符合 3.1 DID 语法规则的 字符串 或一组字符串的集合。相应的 DID 文档应明确包含允许使用某些 验证方法 用于对特定关系的验证 验证关系 。 ​

当某个controller 属性存在于一个 DID 文档中时,其值表示一个或多个 DIDsDID 文档中包含的任何一个验证方法 都应被视为是权威的,满足这些验证方法的证明可以被视为等同于DID 对象提供的证明。 ​

例子 11:具有controller属性的DID文档
{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "controller": "did:example:bcehfew7h32f32h7af3",
}
Note:授权和验证

注意,由controller的值提供的授权与 5.3.1 验证中描述的身份验证是不同的。这对于在加密密钥丢失的情况下进行密钥恢复尤为重要(这种情况DID 对象 不再有权访问该密钥),关于威胁模型和攻击媒介相关的信息请参考 9. 安全考虑 。 ​

5.1.3 Also Known As

一个 DID 对象 可以拥有多个标识符,用于不同的目的或不同的场合。当一个 DID 对象 拥有两个或多个DIDs(或其它形式的URI)时,可以使用alsoKnownAs 来表示。 ​

alsoKnownAs
alsoKnownAs 属性是可选择 的。如果存在,则值必须是一个集合 ,并且集合中的每个项目都是符合 [RFC3986]的一个URI。 ​
这种关系声明了这个标识符的对象也被一个或多个其它标识符所标记。 ​
提示: 等效性和also Known As

应用程序可能会选择将两个alsoKnownAs 的标识符视为等同的,如果alsoKnownAs 关系以相反的方向关联。最佳的做法是,在没有这种反向关系的情况下,不要将它们视为等同。换句话说,alsoKnownAs 断言的出现并不能完全证明该断言是真实的。因此,强烈建议请求方获得对alsoKnownAs 断言的独立验证。 ​

考虑到 DID 对象 可能会使用不同的标识符用于不同的目的,将两个标识符强行划等号或者合并两个DID 文档的信息是不一定合适的,即使标记的两者之间存在相互关系。 ​

5.2 验证方法

一个DID 文档 可以表达 验证方法,例如加密公钥,可用于验证 或者授权与 DID 对象 或相关方的交互。举例来看,一个加密公钥可用作数字签名的验证方法;在这种用法中,它验证了签名者是否可以使用关联的加密私钥。验证方法可能需要用到许多参数。一个例子就是一组有五个的加密密钥,其中三个都需要对加密阈值进行签名。 ​

verificationMethod

verificationMethod 属性是可选 的。如果存在,则其值必须是 验证方法集合 ,其中每个验证方法 都使用 映射来表示。 验证方法 映射 必须包括idtypecontroller和由type所定义的特定验证材料5.2.1 验证材料的属性。一个验证方法可以包含附加属性。验证方法应该在DID 规范注册表 [DID-SPEC-REGISTRIES]中注册。

id

验证方法id 属性的值必须 是符合 3.2 DID URL 语法规则的字符串

type
type属性的值必须 是引用一种验证方法类型的字符串。为了最大限度地提高全球互操作性,验证方法类型应该在DID 规范注册表[DID-SPEC-REGISTRIES]中注册。 ​
controller
controller属性的值必须 是符合 3.1 DID 语法规则的字符串 。 ​
Example 12: 验证方法结构的实例
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  ...
  "verificationMethod": [{
    "id": ...,
    "type": ...,
    "controller": ...,
    "publicKeyJwk": ...
  }, {
    "id": ...,
    "type": ...,
    "controller": ...,
    "publicKeyMultibase": ...
  }]
}
注意: 验证方法控制者和DID控制者

controller属性的语义在关系的主体为DID 文档时,与关系的主体为验证方法(例如加密公钥)时相同。由于密钥无法控制自身,且密钥的控制者无法从 DID 文档 中推断,因此需要明确表达密钥控制者的身份。不同之处在于,验证方法controller的值不一定是DID 控制者DID 控制者通过DID 文档最高层级(数据模型中的最顶层映射)的controller属性表示;详见 5.1.2 DID 控制者。 ​

5.2.1 验证材料

验证材料是 验证方法过程中所需要使用的任何信息。验证方法type 的预期属性将用于确定其与此类流程的兼容性。publicKeyJwkpublicKeyMultibase是常见的验证材料属性。一个密码套件 规范负责指定验证方法 type 及其相关的验证材料。例如,参考JSON Web Signature 2020Ed25519 Signature 2020。有关DIDs可用的所有已注册 验证方法 类型和相关验证材料,请参考DID规范注册表[DID-SPEC-REGISTRIES]。 ​

为了增强可互操作实现的可能性,本规范限制了在DID 文档中表达验证材料格式的数量。实施者需要实现的格式越少,他们支持所有格式的可能性就越大。这种方法试图在易于实现和支持历史上广泛部署的格式之间取得平衡。下面列出了两个受支持的验证材料属性: ​

publicKeyJwk

publicKeyJwk 属性是可选的。如果存在,则值必须是符合 [RFC7517]表示JSON Web Key的一个映射 。该映射 必须不能包含"d"或者 Registration Template中描述的任何其他私有信息类成员。建议使用JWKs[RFC7517]表示其公钥的验证方法使用 kid 值作为其 片段标识。建议将 JWKkid值设置为公钥指纹 [RFC7638]。参考例子 13 中的第一个key,作为具有复合密钥标识符的公钥示例。 ​

publicKeyMultibase

publicKeyMultibase 属性是可选的 。此功能是非规范的。如果选择使用,则值必须是符合[MULTIBASE] 编码公钥的一串 字符串

注意, [MULTIBASE]规范尚未成为标准,可能会发生变化。此数据格式可能存在一些用例,其中 publicKeyMultibase 已经被定义并且允许表达公钥,但是 privateKeyMultibase未被定义,以防止意外泄漏密钥。

一个验证方法不能包含同一材料的多个验证材料属性。例如,禁止在验证方法 中同时使用 publicKeyJwk publicKeyMultibase 来表达密钥材料。

下面的案例展示了包含上述两个属性的验证方法DID 文档

例子 13: 使用publicKeyJwk和publicKeyMultibase的验证方法
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  ...
  "verificationMethod": [{
    "id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "type": "JsonWebKey2020", // external (property value)
    "controller": "did:example:123",
    "publicKeyJwk": {
      "crv": "Ed25519", // external (property name)
      "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ", // external (property name)
      "kty": "OKP", // external (property name)
      "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A" // external (property name)
    }
  }, {
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020", // external (property value)
    "controller": "did:example:pqrstuvwxyz0987654321",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
  ...
}

5.2.2 参考验证方法

验证方法可以嵌入到,或,从与各种 验证关系 (见5.3 验证关系描述)相关的属性中引用。引用 验证方法使得这些方法可以被多个 验证关系使用。 ​

如果 验证方法 的值是一个 映射,则表示已嵌入验证方法 并且可以直接访问其属性。但是,如果值是URL 字符串,则表示已通过引用包含了 验证方法 ,并且需要从 DID 文档 的其他位置或另一个DID 文档中检索其属性。这是通过取消引用URL,并在结果资源中搜索具有ID属性(其值与URL匹配)的验证方法 映射 。 ​

例子 14:嵌入和引用验证方法
{
...
  "authentication": [
    // this key is referenced and might be used by
    // 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": "Ed25519VerificationKey2020", // external (property value)
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
...
}

5.3 验证关系

一个验证关系表达了DID 对象验证方法之间的关系。

不同的验证关系使得相关的验证方法 可以用于不同的目的。验证者可以通过检查DID 文档中相应验证关系 属性所使用的 验证方法 来确定验证尝试的有效性。

DID 对象验证方法之间的验证关系DID 文档中有明确说明。与特定验证关系无关的验证方法 不能用于该 验证关系。例如, authentication 属性值中的验证方法不能用于与DID 对象进行密钥协商协议——需要使用keyAgreement的属性值来实现这个验证过程。

DID 文档 不使用 验证关系来表示已经撤销的密钥。如果被引用的验证方法不在用于取消引用它的最新DID 文档 中,则该验证方法被视为无效或已撤销。每个 DID 方法规范都应该详细说明如何执行和跟踪撤销。 ​

以下各章节定义了几种有用的 验证关系。一个 DID 文档 可能包含其中任何一种或其它属性以用来表达特定的验证关系。为了最大限度地提高全球互操作性,所使用的任何此类属性都应该在DID规范注册表 [DID-SPEC-REGISTRIES]中注册。

5.3.1 验证

authentication验证关系用于指定如何对 DID 对象 进行验证,例如登录网站或参与任何类型的质询-响应协议。

authentication
authentication属性是可选的。如果存在,则关联值必须是一个或多个验证方法集合 。每种验证方法都可以被嵌入或被引用。
Example 15: 包含三种验证方法的验证属性
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "authentication": [
    // this method can be used to authenticate as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method is *only* approved 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": "Ed25519VerificationKey2020",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  ...
}

如果建立了身份验证,则由DID 方法 或其它应用程序来·决定如何处理该信息。可以由特定的 DID 方法 来决定 DID 控制者 是否足够来证明身份,以此执行 DID 文档的更新、删除及其他修改操作。另一种DID 方法 可能需要提供与用于验证密钥不同的密钥或者完全不同的 验证方法 来更新或删除 DID 文档 。换句话说,身份验证之后所做的事情超出了数据模型的范围;DID 方法和应用程序应该自己定义这些内容。 ​

这对于任何需要检查尝试身份验证的实体是否真实出示有效身份验证证明的身份验证者都很有用。当一个验证者收到一些数据(以某种协议特定的格式)时,其中包含为“身份验证”而制作的证明,并且表明实体由 DID标记,则该验证者会检查以确保可以使用DID 文档中列出的 验证方法 (例如公钥)来验证该证明。

注意, DID 文档 的属性指示的验证方法 只能用于验证 DID 对象。要验证不同的DID控制者,需要通过自身的DID 文档 以及相关的验证关系进行验证。

5.3.2 断言

assertionMethod 验证关系用于详细说明 DID 对象 如何表达声明,例如,声明自己颁发了可验证凭证[VC-DATA-MODEL]。 ​

assertionMethod
assertionMethod属性是可选的。如果存在,则关联值必须是一个或多个验证方法的一个集合。每种验证方法都可以被嵌入或被引用。

这种属性在验证者处理一个 可验证凭证 的过程中非常有用。在验证过程中,验证者通过检查用于 assertionMethod验证方法是否与相应 DID 文档中的属性相关联,以此来检查可验证凭证 是否包含由 DID 对象创建的证明。 ​

Example 16: 包含两种验证方法的断言方法
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "assertionMethod": [
    // this method can be used to assert statements as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method is *only* approved for assertion of statements, it is not
    // used for any other verification relationship, so its full description is
    // embedded here rather than using a reference
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2020", // external (property value)
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  ...
}

5.3.3 Key Agreement

keyAgreement 验证关系用于指定实体如何生成针对 DID 对象预期加密信息的可传输加密材料,例如,为了与接收者建立安全通信的通道。 ​

keyAgreement
keyAgreement属性是可选的。如果存在,则关联值必须是一个或多个验证方法的一个集合。每种 验证方法可以被嵌入或被引用。 ​

此属性的一个示例是对DID 对象加密一条预期消息。在这种情况下,对方在 验证方法中使用加密公钥信息来包装一个接收者的解密密钥。 ​

Example 17:包含两种验证方法的密钥协商属性
{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  ...
  "keyAgreement": [
    // this method can be used to perform key agreement as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method is *only* approved for key agreement usage, it will not
    // be used for any other verification relationship, so its full description is
    // embedded here rather than using only a reference
    {
      "id": "did:example:123#zC9ByQ8aJs8vrNXyDhPHHNNMSHPcaSgNpjjsBYpMMjsTdS",
      "type": "X25519KeyAgreementKey2019", // external (property value)
      "controller": "did:example:123",
      "publicKeyMultibase": "z9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE"
    }
  ],
  ...
}

5.3.4 能力调用

capabilityInvocation 验证关系用于指定DID 对象可能用来调用加密功能的验证方法,例如对更新 DID 文档的授权。 ​

capabilityInvocation
capabilityInvocation属性是可选的。如果存在,则关联值必须是一个或多个 验证方法的一个集合。每种验证方法可以被嵌入或被引用。 ​

此属性的一个示例是,当 DID 对象 需要访问受保护的HTTP API时(该API需要授权才能使用)。为了在使用HTTP API时获得授权, DID 对象使用与通过HTTP API公开的特定URL关联的功能。该功能的调用可以通过多种方式表达,例如,作为放置在HTTP标头中的数字签名消息。

提供HTTP API的服务器是该功能的验证者(verifier),它需要验证所调用功能所引用的验证方法是否存在于 DID 文档capabilityInvocation的属性中。验证者还会检查以确保所执行的操作有效,并且该功能适合所访问的资源。如果验证成功,则服务器已通过加密方式确定调用者有权访问受保护的资源。 ​

Example 18:包含两个验证方法的功能调用属性
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "capabilityInvocation": [
    // this method can be used to invoke capabilities as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method is *only* approved for capability invocation usage, it will not
    // be used for any other verification relationship, so its full description is
    // embedded here rather than using only a reference
    {
    "id": "did:example:123456789abcdefghi#keys-2",
    "type": "Ed25519VerificationKey2020", // external (property value)
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  ...
}

5.3.5 能力委托

capabilityDelegation验证关系用于指定DID 对象可能使用的一种机制,以将加密功能委托给另一方。例如,将访问特定HTTP API的权限委托给下属。 ​

capabilityDelegation
capabilityDelegation属性是可选的。如果存在,则关联值必须是一个或多个验证方法的一个集合。每种验证方法可以被嵌入或被引用。 ​

此功能的一个示例是,当DID 控制者选择将其访问受保护HTTP API的能力委托给自己以外的一方时。为了委托该能力, DID 对象将使用与capabilityDelegation验证关系相关联的 验证方法 将该能力以加密方式签名给另一个 DID 对象。然后,委托人将以类似于 5.3.4 能力调用中所示例的方式使用该能力。 ​

例子 19:包含两种验证方法的功能委托属性
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "capabilityDelegation": [
    // this method can be used to perform capability delegation as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method is *only* approved for granting capabilities; it will not
    // be used for any other verification relationship, so its full description is
    // embedded here rather than using only a reference
    {
    "id": "did:example:123456789abcdefghi#keys-2",
    "type": "Ed25519VerificationKey2020", // external (property value)
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  ...
}

5.4 服务

DID 文档中的服务用于表达与DID 对象或相关实体进行通信的方式。一个服务可以是 DID 对象 想要宣传的任何类型的服务,包括用于 分布式身份管理 服务的进一步挖掘、身份验证、授权或者交互。 ​

出于隐私方面的考虑,不鼓励通过社交媒体账户、个人网站和电子邮件地址等 服务泄漏公共信息。有关隐私问题的进一步探讨,请参阅 10.1 保护个人数据隐私10.6 服务隐私。与服务相关的信息通常是特定的服务。例如,与加密消息服务相关的信息可以表达在消息传递开始之前如何启动加密链接。 ​

服务使用service 属性来表达,如下所述: ​

service

service属性是可选的。如果存在,则关联值必须是服务的一个集合,其中每个服务都由一个 映射描述。每个 服务映射必须包含id, type,和serviceEndpoint属性。每个服务扩展可以包括其它属性,并且可以进一步限制与扩展相关的属性。 ​

id
id属性的值必须是符合[RFC3986]的URI。一个符合要求的生产者不得生产具有相同id的多个 service条目。一个符合要求的消费者如果检测到具有相同id的多个 service条目时,必须报错。
type
type属性的值必须是一个 字符串或一组字符串集合。为了最大限度地提高互操作性, 服务类型及其相关属性应该在DID规范注册表[DID-SPEC-REGISTRIES]中注册。
serviceEndpoint
serviceEndpoint属性的值必须是一个 字符串,一个映射或由多个 字符串 和/或 映射组成的集合。所有 字符串的值必须是符合 [RFC3986]的URIs,并根据 RFC3986 中的标准化和比较规则 和其他适用 URI规范方案中的规则进行标准化。

服务 有关的隐私和安全考虑事项,请参考10.6 服务隐私, 10.1 保持个人数据隐私, 10.3 DID文档关联风险, 和 9.3 身份验证服务端点. ​

Example 20: 服务属性的使用
{
  "service": [{
    "id":"did:example:123#linked-domain",
    "type": "LinkedDomains", // external (property value)
    "serviceEndpoint": "https://bar.example.com"
  }]
}

6. 表示

本规范中DID 文档的具体序列化称为“ 表示”。通过一个称为“生产(production)”的过程,将 数据模型 序列化,从而创建表示表示另通过一个称为“消费(consumption)”的过程转化为 数据模型生产消费 流程实现了信息从一种表示 到另一种的转换。本规范定义了 JSON 和 JSON-LD 表示 ,开发人员也可以使用能表达 数据模型的任何其他表示,如 XML 或 YAML。以下各节定义了 生产消费的一般规则以及 JSON 和 JSON-LD 表示

6.1 生产和消费

除了本规范中定义的 表示 外,执行者还可以使用其它表示,但必须对每种表示进行适当的规定(包括对 DID 规范注册表 [DID-SPEC-REGISTRIES]) 中未列出的属性进行互操作处理的规则)。更多信息,请参阅4.1 可扩展性

表示”应满足如下要求:

  1. 表示必须4. 数据模型中所述的所有数据类型来定义确定的生产和消费规则。
  2. 表示 必须 与IANA注册的媒体类型唯一关联。
  3. 表示必须 为其媒体类型定义符合片段处理规则(在“片段”中的定义)的片段处理规则。
  4. 表示应该 使用数据模型数据类型的词法表示。例如,JSON 和 JSON-LD 使用 XML Schema dateTime 词法序列化来表示日期时间。 只要返回数据模型消费 过程是无损的, 表示可以选择使用不同的词法序列化来序列化 数据模型的数据类型。例如,一些基于 CBOR 的表示使用整数来表达 日期时间值,以表示自 Unix 时间起的秒数。
  5. 一个表示 可以定义针对特定条目的表示,这些条目存储在表示特性条码目的映射中,供生产和消费过程中使用。 这些条目在生产消费时使用,有助于确保无损转换。
  6. 为了最大限度地提高互操作性,表示 规范的作者 在 DID 规范注册中心 [DID-SPEC-REGISTRIES]注册其表示。

对所有符合要求的生产者的要求如下:

  1. 符合要求的生产者 必须将 a DID 文档数据模型特定于表示的条目映射作为生产流程的输入。 符合要求的生产者可以接受其他选项作为 生产过程的输入。
  2. 符合要求的生产者 必须DID 文档数据模型中的所有条目和针对特定条目表示的条目映射进行序列化,这些条目没有明确的处理规则,只能使用表示的数据类型处理规则进行制作,并在生产过程完成后返回序列化。
  3. 符合要求的生产者 必须生产过程完成后返回与表示相关联的媒体类型字符串
  4. 符合要求的生产者不得生产不符合要求的 DIDDID 文档

对所有符合要求的消费者的要求如下:

  1. 符合要求的消费者 必须表示和媒体类型 字符串作为 消费过程的输入。 符合要求的消费者 可以接受其他选项作为消费 过程的输入。
  2. 符合要求的消费者 必须使用媒体类型输入字符串来确定 DID 文档表示形式
  3. 符合规范的消费者 必须在所有已知表示中检测到任何 表征特定条目,并将该条目放入表示特定条目映射中,该映射在 过程完成后返回。 DID 规范注册表 [DID-SPEC-REGISTRIES] 中列出了所有已知的 特定表示条目
  4. 符合要求的消费者 必须只使用表示的数据类型处理规则,将所有没有针对被消费表示的显式处理规则的非表述特定条目添加到 DID 文档 数据模型中,并在 消费过程完成后返回DID文档数据模型。
  5. 符合要求的消费者必须在消费不符合要求的 DIDDID 文档时必须产生错误。

Diagram illustrating how representations of the data model are produced
and consumed, including in JSON and JSON-LD.
4 表述的生产和消费。 另见: 叙述性描述.

The upper left quadrant of the diagram contains a rectangle with dashed grey outline, containing two blue-outlined rectangles, one above the other. The upper, larger rectangle is labeled, in blue, "Core Properties", and contains the following INFRA notation:

«[
  "id""example:123",
  "verificationMethod" → « «[
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Ed25519VerificationKey2018",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
  ]» »,
  "authentication" → «
    "did:example:123#keys-1"
  »
]»
The lower, smaller rectangle is labeled, in blue, "Core Representation-specific Entries (JSON-LD)", and contains the following monospaced INFRA notation:
«[ "@context""https://www.w3.org/ns/did/v1" ]»

From the grey-outlined rectangle, three pairs of arrows extend to three different black-outlined rectangles, one on the upper right of the diagram, one in the lower right, and one in the lower left. Each pair of arrows consists of one blue arrow pointing from the grey-outlined rectangle to the respective black-outlined rectangle, labeled "produce", and one red arrow pointing in the reverse direction, labeled "consume". The black-outlined rectangle in the upper right is labeled "application/did+cbor", and contains hexadecimal data. The rectangle in the lower right is labeled "application/did+json", and contains the following JSON data:

{
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Ed25519VerificationKey2018",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
  }],
  "authentication": [
    "did:example:123#keys-1"
  ]
}

The rectangle in the lower left is labeled "application/did+ld+json", and contains the following JSON-LD data:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Ed25519VerificationKey2018",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
  }],
  "authentication": [
    "did:example:123#keys-1"
  ]
}
提示:表述之间的转换

我们希望实施能通过在源 表示上使用消费 规则来实现数据模块 之间的转换,然后使用生产规则将 数据模型序列化到目标表示法,或任何其他能产生相同目标表示法的机制。

6.2 JSON

本节定义了JSON 表示生产消费规则。

6.2.1 生产

DID 文档、DID 文档数据结构和针对特定条目表示的条目映射必须根据以下生产规则序列化为 JSON 表示

数据 类型 JSON 表示类型
map 一个JSON 对象,其中每个条目都被序列化为 JSON 对象的一个成员,条目键为一个JSON 字符串成员名,条目值则根据其类型(如表中所定义)确定。
list 一个 JSON 数组,列表中的每个元素都会根据其类型(如表中所定义)依次序列化为数组的值。
set 一个JSON 数组,集合中的每个元素都会根据其类型(如表中所定义)依次添加为数组的值。
datetime 序列化为XML 日期事件JSON 字符串,时间归一化为 UTC 00:00:00,不含小数点后两位。例如:2020-12-20T19:17:47Z
string 一个JSON字符串.
integer 不含小数或分数成分的 JSON 数字
double 带有小数和分数成分的 JSON 数字
boolean 一个JSON布尔值.
null 一个JSON 空字面.

建议所有创建生成JSON 表示符合要求的生产者 的执行者确保其算法符合 [INFRA] 规范中的JSON 序列化规则 ,以及 JSON [RFC8259] 规范中有关数字的精度建议

所有DID文档的条目必须包含在根JSON 对象中。条目可以包含附加的数据子结构,但需遵守上述列表中的值表示规则。 当序列化一个DID文档时,一个符合规范的生产者必须 指定一个媒体类型为application/did+json,以便下游应用程序识别,如在7.1.2 DID解析元数据中所述。

例子 21: JSON表示的DID文档示例
{
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

6.2.2 消费

DID 文档 和DID文档数据结构的JSON 表示 必须 根据以下消费规则反序列化到数据模型中:

JSON 表示 类型 数据 类型
JSON 对象 一个映射,其中 JSON 对象的每个成员都作为一个条目添加到映射中。每个条目的关键字都被设置为 JSON 对象成员的名称。
数据模型条目值为列表或未知数的 JSON 数组 一个 列表,其中 JSON 数组的每个值都会按顺序添加到列表中,并根据本表中定义的数组值的 JSON 表示类型进行转换。
JSON 数组,其中数据模型条目值是一个集合 一个集合,其中 JSON 数组的每个值都会按顺序添加到集合中,并根据本表中定义的数组值的 JSON 表示类型进行转换。
数据模型 输入值为时间日期JSON 字符串 时间日期.
JSON 字符串,其中 数据模型条目值类型为字符串 或未知值 字符串.
不含小数或分数成分的JSON 数字 整数.
带有小数和分数成分的 JSON 数字,或者输入值为双精度浮点型 时,无论是否包含分数成分。 双精度浮点小数.
JSON 布尔值 布尔值.
JSON 空字面 值.

我们建议所有创建 符合要求的消费者 的执行者,在生成 JSON表示时,确保其算法符合 [INFRA] 规范中的 JSON 转换规则,以及 JSON [RFC8259] 规范中有关 数字的精度建议

如果媒体类型信息可供符合规范的消费者使用,并且媒体类型的值是application/did+json,则被消费的数据结构是一个DID文档,根元素必须是一个JSON 对象,其中对象的所有成员都是DID文档的条目。对于JSON表示符合规范的消费者,如果消费的DID文档的根元素不是一个JSON 对象,则必须报告一个错误。

6.3 JSON-LD

JSON-LD [JSON-LD 1.1] 是一种基于JSON的格式,用于序列化链接数据。本节定义了JSON-LD 表示生产消费规则。

JSON-LD 表示定义了以下特定于表示的条目

@context
JSON-LD 上下文可以是一个字符串或者一个列表,其中包含任意组合的字符串和/或有序映射

6.3.1 生产

DID 文档、DID文档数据结构和特定于表示的条目 必须根据定义在6.2 JSON中的JSON 表示生产规则序列化为JSON-LD 表示

除了使用JSON 表示生产规则外,JSON-LD生产必须 包含特定于表示的 @context条目。@context的序列化值必须JSON字符串https://www.w3.org/ns/did/v1,或者是一个JSON数组,其中第一个元素是JSON字符串https://www.w3.org/ns/did/v1,而随后的元素则根据JSON 表示生产规则进行序列化。

例子 22: 一个有效的@context条目的序列化示例
{
  "@context": "https://www.w3.org/ns/did/v1",
  ...
}
例子 23: 一个分层的@context条目的有效序列化示例
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://did-method-extension.example/v1"
  ],
  ...
}

所有创建符合规范的生产者以产生JSON-LD 表示的实现者被建议确保他们的算法产生有效的JSON-LD [JSON-LD 1.1]文档。无效的JSON-LD文档将导致JSON-LD处理器停止并报告错误。

为了实现不同表示之间的互操作性,所有JSON-LD上下文及其术语应该在DID规范注册表[DID-SPEC-REGISTRIES]中注册。

一个生成JSON-LD 表示符合规范的生产者 不应 生成一个包含未通过@context定义的术语的DID文档,因为预期符合规范的消费者会移除未知术语。当序列化一个DID文档的JSON-LD 表示时,一个符合规范的生产者 必须 指定一个媒体类型为application/did+ld+json,以便下游应用程序识别,如在7.1.2 DID解析元数据中所述。

6.3.2 消费

DID 文档以及任何通过JSON-LD 表示表达的DID文档数据结构必须根据定义在6.2 JSON中的JSON 表示消费规则反序列化到数据模型中。

对于创建消费JSON-LD 表示符合规范的消费者的所有实现者,建议确保他们的算法只接受有效的JSON-LD [JSON-LD 1.1]文档。无效的JSON-LD文档会导致JSON-LD处理器停止并报告错误。

处理JSON-LD 表示符合规范的消费者 应该DID文档中丢弃所有未通过@context定义的术语。

7. 解析

本章节定义了DID 解析的输入输出以及DID URL 解引用。其具体实现不在本规范的范围内,但在[DID-RESOLUTION]中讨论了一些实现时的注意事项。

所有符合规范的 DID 解析器 必须 实现至少一种DID 方法DID 解析函数并且必须 能够以至少一种符合规范的格式表示返回一个DID 文档

7.1 DID解析

DID 解析函数通过适用DID方法的“读”操作(详见 8.2 方法操作) 将DID 文档解析为DID 方法。 此过程的具体实现细节不在本规范的范围内,单所有符合规范的DID 解析器均应实现以下函数,这些函数应具有以下抽象形式:

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

resolve 函数以抽象数据结构(一个映射)返回 DID 文档。 resolveRepresentation 函数返回的是以相应格式表示的 DID 文档 的字节流。


Diagram illustrating how resolve() returns the DID document data model in
its abstract form and resolveRepresenation() returns it in one of the
conformant representations; conversion is possible using production and
consumption rules.
5 resolve() 函数和 resolveRepresentation()函数。 另见: 叙述性描述.

The upper middle part of the diagram contains a rectangle with dashed grey outline, containing two blue-outlined rectangles, one above the other. The upper, larger rectangle is labeled, in blue, "Core Properties", and contains the following INFRA notation:

«[
  "id""example:123",
  "verificationMethod" → « «[
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Ed25519VerificationKey2018",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
  ]» »,
  "authentication" → «
    "did:example:123#keys-1"
  »
]»

The lower, smaller rectangle is labeled, in blue, "Core Representation-specific Entries (JSON-LD)", and contains the following monospaced INFRA notation:

«[ "@context""https://www.w3.org/ns/did/v1" ]»

From the grey-outlined rectangle, three pairs of arrows extend to three different black-outlined rectangles, aligned in a horizontal row side-by-side, in the bottom half of the diagram. Each pair of arrows consists of one blue arrow pointing from the grey-outlined rectangle to the respective black-outlined rectangle, labeled "produce", and one red arrow pointing in the reverse direction, labeled "consume". The first black-outlined rectangle in the row is labeled "application/did+ld+json", and contains the following JSON-LD data:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Ed25519VerificationKey2018",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
  }],
  "authentication": [
    "did:example:123#keys-1"
  ]
}

The second rectangle in the row is labeled "application/did+json" and contains the following JSON data:

{
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Ed25519VerificationKey2018",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
  }],
  "authentication": [
    "did:example:123#keys-1"
  ]
}

The third rectangle in the row is labeled "application/did+cbor", and contains hexadecimal data.

In the left part of the diagram, in the middle, there is a box, with black outline and light gray background. This box is labeled "VERIFIABLE DATA REGISTRY" and contains a symbol representing a graph with nodes and arcs. From this box, one arrow, labeled "resolve()", extends upwards and points to the top half of the diagram where the grey-outlined rectangle is located. Another arrow, labeled "resolveRepresentation()", extends downwards and points to the bottom half of the diagram, where the row of three black-outlined rectangles is located.

resolve函数和resolveRepresentation函数的输入参数如下:

did
这是需要解析的DID。该输入是必需 的,且其值 必须 是符合 3.1 DID 语法定义的DID
resolutionOptions
一个包含 7.1.1 DID 解析选项中所定义的属性的元数据结构。该输入是必须的,但该结构可以为空。

这些函数都包括多个返回值,并没有对这些返回值如何一起返回给出限制。resolve的返回值包括didResolutionMetadatadidDocumentdidDocumentMetadataresolveRepresentation的返回值包括didResolutionMetadatadidDocumentStreamdidDocumentMetadata。这些值如下所述:

didResolutionMetadata
一个包含与DID 解析结果相关的元数据结构 ,通常在调用resolve函数和resolveRepresentation函数时会发生变化,它表达了解析过程本身的数据。该结构是必需的,并且在解析过程中发生错误时也不得为空。此元数据在7.1.2 DID 解析元数据中定义。如果调用了resolveRepresentation函数,该结构必须 包含一个contentType属性,用于表示在didDocumentStream中对应的媒体类型。如果解析未成功,则该结构必须包含一个描述错误的error属性。
didDocument
如果解析成功,且调用了 resolve函数,则该值 必须是符合4. 数据模型中描述的DID 文档的抽象数据模型(映射,映射),该模型可以使用表示形式指定的生成规则转换为符合规范的DID 文档(表示形式)。解析得到的 DID 文档中的id必须与解析的DID一致。如果解析不成功,则该值必须 为空。
didDocumentStream
如果解析成功,且调用了 resolveRepresentation 函数,则该值必须是解析得到的DID 文档的字节流,且以一种符合规范的格式来表示。该字节流随后可以通过调用 resolveRepresentation 函数解析为一个一个数据模型,进而进行验证和处理。如果解析不成功,则该值必须 为空流。
didDocumentMetadata
如果解析成功,则该值必须是一个元数据结构。该结构包含关于didDocument属性中 DID 文档的元数据。didDocumentMetadata表示的是关于DID 文档的元数据,通常在resolve 函数和resolveRepresentation函数的调用之间保持不变,除非DID 文档本身发生更改。如果解析不成功,则此输出 必须 为一个空 元数据结构。本规范定义的属性在7.1.3 DID 文档元数据中有详细说明。

符合规范的DID 解析器的实现不得以任何方式更改这些函数的型构。DID 解析器 的实现可以将resolve函数和resolveRepresentation函数映射到特定方法的内部函数,以执行实际的DID 解析过程。DID 解析器的在实现resolve函数和resolveRepresentation函数之外,可以提供其他不同签名/函数型构的其他函数实现。

7.1.1 解析选项

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

accept
调用方首选的DID 文档 表达形式的媒体类型。媒体类型必须ASCII 字符串表示。如果支持该表达形式,且该表达形式可用,DID 解析器 的实现使用此值来确定返回的didDocumentStream中的表达形式。该属性对于didDocumentStream 函数是可选的,并且不得resolve函数一起使用。

7.1.2 解析元数据

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

contentType
返回的didDocumentStream的媒体类型。如果解析成功且调用了resolveRepresentation函数,则该属性是必需的。如果调用了 resolve函数,则该属性不得存在。该属性的值必须ASCII 字符串,以符合规范的媒体类型来表示resolveRepresentation函数的调用方必须使用此值来确定如何将该函数返回的didDocumentStream解析和处理为数据模型
error
解析过程中的错误代码。当解析过程中出现错误时,此属性是必须 的。此属性的值必须是一个单一关键字 的ASCII 字符串。该字段的可能属性值 在DID规范注册表 [DID-SPEC-REGISTRIES] 中注册。本规范定义了以下通用错误值:
invalidDid
提供给DID 解析函数的DID不符合有效语法。(参见 3.1 DID 语法.)
notFound
DID 解析器 无法找到对应的DID 文档
representationNotSupported
如果通过accept输入元数据属性请求的表达形式不被DID 方法和/或DID 解析器的实现支持,则返回此错误代码。

7.1.3 DID文档元数据

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

created
DID 文档元数据包括一个created属性,以指示 创建操作的时间戳。该属性的值必须是格式化为XML Datetime格式的字符串,用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 文档版本不是DID文档的最新版本,则DID文档元数据可以包括一个nextUpdate属性。它指示下一个 更新操作的时间戳。该属性的值必须遵循与created属性相同的格式规则。
versionId
DID 文档元数据应包括一个versionId属性,以指示已解析文档版本的最后一次更新操作的版本。该属性的值必须是一个ASCII 字符串
nextVersionId
如果已解析的DID 文档 版本不是DID文档的最新版本,则DID文档元数据可以包括一个nextVersionId属性。它指示下一个 更新操作的版本。该属性的值必须是一个ASCII 字符串
equivalentId

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

DID 文档元数据可以包括一个equivalentId属性。如果存在,则其值必须是一个集合,其中每个项都是符合第3.1 DID 语法规则字符串 。这个关系表明,每个equivalentId值在逻辑上等同于id属性值,因此指向相同的DID 对象。每个equivalentId 的DID值必须 由与id属性值相同的DID 方法生成,并且是其一种形式。(例如,did:example:abc == did:example:ABC)。)

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

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

: 更强的等价性

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

如果请求方不保留idequivalentId属性中的值,并确保与它们包含的任何值的后续交互能够被正确处理为逻辑上等价的,则可能出现错误或意外情况。强烈建议实现者遵循与此元数据属性相关的指示。

canonicalId

除以下若干情况之外,canonicalId属性与equivalentId 属性相同,但是: a) canonicalId属性仅与一个值关联,而不是与一个值的集合关联; b) 该属性所给出的 DID是指包含DID 文档中的DID 对象的所对应的规范ID。

DID 文档元数据可以 包括一个canonicalId属性。如果存在,则其值必须 是一个符合第3.1 DID 语法规则字符串。这个关系表明,canonicalId值在逻辑上等同于id属性值,并且canonicalId值由 DID 方法定义为包含DID 文档范围内的 DID 对象规范ID。canonicalId 值必须由与id属性值相同的DID 方法生成,并且是其一种形式。(例如,did:example:abc == did:example:ABC

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

请求方应将canonicalId值用作DID 对象 的主要ID值,并将所有其他等效值视为次要别名(例如,在其系统中更新相应的主要引用,以反映新的规范ID)。

注意: 等价规范

canonicalIdequivalentId 的等价性声明相同,但它被限制为一个单一的值,该值被定义为在DID 文档范围内的DID 对象规范ID。与equivalentId相同,canonicalId表示完全的图形合并,因为相同的DID 文档既描述了canonicalId DID,也描述了id属性 DID

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

7.2 DID URL 解引用(DID URL Dereferencing)

DID URL 解引用函数将DID URL作为一个资源解引用,其内容取决于DID URL的组件,包括DID 方法、特定方法的标识符、路径、查询和片段。此过程依赖于对DID URL中包含的DID 解析DIDDID URL 解引用可能涉及多个步骤(例如,当要重新访问/解引用的DID URL包含一个片段时),并且该函数定义为在所有步骤完成后返回最终资源。有关此过程如何实现的详细信息不在本规范的范围之内。下图展示了上述关系。


DIDs resolve to DID documents; DID URLs contains a DID; DID URLs dereferenced to DID document fragments or
external resources.
6 DID URL 解引用概述 参见: 叙述性描述.

The top left part of the diagram contains a rectangle with black outline, labeled "DID".

The bottom left part of the diagram contains a rectangle with black outline, labeled "DID URL". This rectangle contains four smaller black-outlined rectangles, aligned in a horizontal row adjacent to each other. These smaller rectangles are labeled, in order, "DID", "path", "query", and "fragment.

The top right part of the diagram contains a rectangle with black outline, labeled "DID document". This rectangle contains three smaller black-outlined rectangles. These smaller rectangles are labeled "id", "(property X)", and "(property Y)", and are surrounded by multiple series of three dots (ellipses). A curved black arrow, labeled "DID document - relative fragment dereference", extends from the rectangle labeled "(property X)", and points to the rectangle labeled "(property Y)".

The bottom right part of the diagram contains an oval shape with black outline, labeled "Resource".

A black arrow, labeled "resolves to a DID document", extends from the rectangle in the top left part of the diagram, labeled "DID", and points to the rectangle in the top right part of diagram, labeled "DID document".

A black arrow, labeled "refers to", extends from the rectangle in the top right part of the diagram, labeled "DID document", and points to the oval shape in the bottom right part of diagram, labeled "Resource".

A black arrow, labeled "contains", extends from the small rectangle labeled "DID" inside the rectangle in the bottom left part of the diagram, labeled "DID URL", and points to the rectangle in the top left part of diagram, labeled "DID".

A black arrow, labeled "dereferences to a DID document", extends from the rectangle in the bottom left part of the diagram, labeled "DID URL", and points to the rectangle in the top right part of diagram, labeled "DID document".

A black arrow, labeled "dereferences to a resource", extends from the rectangle in the bottom left part of the diagram, labeled "DID URL", and points to the oval shape in the bottom right part of diagram, labeled "Resource".

所有符合规范的DID 解析器实现以下函数,该函数具有以下抽象形式:

dereference(didUrl, dereferenceOptions) →
   « dereferencingMetadata, contentStream, contentMetadata »

dereference函数的输入参数如下:

didUrl
作为一个单一字符串的符合规范的DID URL。这是要解引用的DID URL。要解引用一个DID 片段必须使用包含DID 片段的完整DID URL。此输入是必需的。
注意: DID URL 解引用器模式

虽然可以将任何 didUrl传递给DID URL解引用器,但实现者应参考[DID-RESOLUTION]以进一步了解如何重新访问/解引用DID URL的常见模式。

dereferencingOptions
一个元数据结构,包含除了didUrl本身之外的dereference函数的输入选项。根据本规范定义的属性见7.2.1 DID URL 解引用选项。此输入是必需的,但该结构可以为空。

该函数返回多个值,并且对这些值如何一起返回没有限制。 dereference的返回值包括dereferencingMetadatacontentStreamcontentMetadata

dereferencingMetadata
一个元数据结构 ,包含与DID URL 解引用 结果相关的值。此结构是必需的,如果重新访问/解引用过程出现错误,则必需不 为空。相关属性定义见7.2.2 DID URL 解引用元数据。如果解引用不成功,该结构必需包含一个error 属性,用于描述错误。
contentStream
如果dereferencing 函数被成功调用,此处必须包含一个与DID URL相对应的资源contentStream可以是可序列化为一种符合规范的资源表示,例如DID 文档验证方法服务或任何其他可以通过媒体类型识别,并通过解析过程获取的资源格式。如果解引用不成功,该值必须为空。
contentMetadata
如果解引用成功,此处必须是一个 元数据结构,但该结构可以为空。此结构包含有关contentStream的元数据。如果code>contentStream是DID 文档,则此处必须是一个如DID 解析中所述的DID 文档元数据结构。如果解引用不成功,该输出必须是一个空的元数据结构

符合规范的DID URL 解引用 的实现不得以任何方式更改这些函数的签名/函数型构。DID URL 解引用的实现可以将dereference函数映射到特定方法的内部函数,以执行实际的DID URL 解引用过程。此外,除了此处指定的 dereference函数之外,DID URL 解引用 可以实现并公开具有不同签名/函数型构的附加函数。

7.2.1 DID URL解引用选择

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

accept
调用者关于contentStream的首选媒体类型。媒体类型必须以一个ASCII 字符串 表示。如果支持且可用,DID URL 解引用的实现使用此值来确定返回值中所含表示contentType

7.2.2 DID URL解引用元数据

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

contentType
如果重新访问/解引用成功,返回的contentStream的媒体类型应该 使用此属性表示。媒体类型值必须 以一个ASCII 字符串表示。
error
来自解引用过程的错误代码。当解引用过程中出现错误时,此属性是必需的。该属性的值必须是一个以ASCII 字符串表示的单一关键字。此字段的可能属性值应该 在DID规范注册表中[DID-SPEC-REGISTRIES] 注册。本规范定义了以下常见错误值:
invalidDidUrl
提供给DID URL 解引用函数的DID URL不符合有效的语法。(请参见 3.2 节DID URL 语法。)
notFound
DID URL 解引用器无法找到该重解引用请求所产生的contentStream

7.3 元数据结构

DID 解析DID URL 解引用及其他与DID相关的处理过程中,通常需要设计输入和输出元数据。用于传递这些元数据的结构必须是一组属性组成的映射。每个属性的名称必须是一个字符串。每个属性值必须字符串映射列表集合布尔值或为。任何复杂数据结构(如映射和列表)中的值必须也是这些数据类型中的一种。所有在[DID-SPEC-REGISTRIES] 注册的元数据属性定义必须定义值类型,包括对该值的任何附加格式或限制(例如,格式为日期或十进制整数的字符串)。推荐 属性定义使用字符串作为值。整个元数据结构必须根据[INFRA] 规范中的JSON 序列化规则是可序列化的。在实现中可以将元数据结构序列化为其他数据格式。

所有使用元数据结构作为输入或输出的函数实现都能够以确定性的方式完全表示此处描述的所有数据类型。由于使用元数据结构的输入和输出是根据数据类型,而不是其序列化定义的,因此表示方法是函数实现内部的内容,不在本规范的范围之内。

以下示例演示了一个可用作 DID 解析输入元数据的JSON编码元数据结构。

例子 24: JSON编码的DID解析输入元数据示例
{
  "accept": "application/did+ld+json"
}

此示例对应于以下格式的元数据结构:

示例 25: DID解析输入元数据的示例
[
  "accept""application/did+ld+json"
]

以下是一个示例,展示了如果未找到DID时可能使用的JSON编码元数据结构,作为 DID 解析元数据

示例 26: JSON编码的DID解析元数据示例
{
  "error": "notFound"
}

此示例对应以下格式的元数据结构:

示例 27: 解析元数据示例
[
  "error""notFound"

下一个示例演示了一个 JSON 编码的元数据结构,该结构可用作 DID 文档元数据,以描述与 DID 文档相关的时间戳。

例子 28: JSON 编码的 DID 文档元数据示例
{
  "created": "2019-03-23T06:35:22Z",
  "updated": "2023-08-10T13:40:06Z"
}

此示例对应以下格式的元数据结构:

示例 29: DID文件元数据示例
«[
  "created""2019-03-23T06:35:22Z",
  "updated""2023-08-10T13:40:06Z"

8. 方法

DID方法 方法定义了如何按照本标准实施DID标识的具体方案和特性。DID方法通常DID方法与一个可验证的数据注册集合或机构相关联。 当定义新的 DID方法 的时候需要制定在其治下的相同DID方法不同实现之间的具体规则以实现互操作性 .

类比来说,DID方法和本标准规定的DID之间的关系类似于特定的统一资源标识符(URI)[IANA-URI-SCHEMES]和IETF的通用统一资源标识符(URI)规范[RFC3986]之间的关系,比如http 这一特定的URI格式可以类比成一个具体的DID方法。另外,当定义一个具体的DID结构的时候,需要同时制定DID方法的规范以定义如何在数据注册集合或机构治下进行DIDDID文档的创建、解析、更新和停用。并且DID方法还需要提供其之下DID具体实现的相关文档,比如关于安全性和隐私性要求和考量的文档。

本节中将提供起草和制定上述 DID 方法 的具体规范的相关要求:

8.1 方法语法

所有 DID 方法 的具体规范(以下简称 DID 方法规范)都需要按照下列规则制定该方法下的 DID 语法:

  1. DID方法 规范 必须 定义一个特定于该方法的 DID方法标识符,该标识符必须符合3.1节DID 语法 中关于 方法名称/标识符 method-name 规则的要求,且一个 DID 方法只能有一个标识符(多个标识符是不允许的)。
  2. DID 方法 规范 必须 规范如何按照该方法生成 DID method-specific-id 的规则。
  3. DID 方法 规范 必须method-specific-id 值的颗粒度和规范性进行规定。

  4. DID 方法规范必须保证method-specific-id 的标识的全局唯一性,并提供method-specific-id的方法规则。

  5. 任何DID 方法签发的DID标识必须是全球/全局唯一的。
  6. 为了避免 method-name 冲突,DID 方法需要在DID规范注册集中注册自己使用的名称和标识[DID-SPEC-REGISTRIES]。
  7. DID 方法 可以 定义多个 method-specific-id 格式,但这些格式之间不能冲突。
  8. method-specific-id 下的标识格式可以 包含冒号“:”。该 method-specific-id 下的标识格式使用冒号“:” 必须 符合方法规定的标识 ABNF(扩展巴科斯范式)语法格式描述规范。
  9. DID方法规范可以 规定自己的关于DID路径的ABNF(扩充巴科斯范式)语法格式描述规范。该DID路径规范应该是在通用的DID路径规范的基础上指定的,并且比该通用规范更为严格。
  10. DID 方法规范 可以 规定自己的 DID 查询 ABNF(扩展巴科斯范式)语法格式描述规范,该查询规范应该是在本节相关规则的基础上建立的,并比这些通用查询规范更为严格。
  11. DID 方法规范 可以 规定自己的 DID 分段 ABNF(扩展巴科斯范式)语法格式描述规范,该分段规范应该是在本节相关规则的基础上建立的,并比这些通用查询规范更为严格。
注释: 方法标识中的冒号“:”的使用

method-specific-id 下的标识中使用冒号“:”是允许的,相关规则完全取决于该DID方法的规定。 例如,冒号“:”可以用于创建在该 DID 方法 下多级命名空间之间的分层结构,也可以用于识别 可验证数据注册集合 或机构中 DID 标识的不同实体和组成部分(比如一个标识是由多个标识部分所组成的情况),或者也可以用于该 DID 方法独有的各种其他用途。 因此,使用 DID 方法 作为标识应用的开发者不应对 DID 方法下标识中的冒号“:”的作用或行为做出任何的假设,DID 规范也没有规定任何通用的 DID 方法下标识中冒号“:”使用的通用原则。

8.2 方法操作

所有 DID 方法 规范都需要按照下列原则制定该方法下的方法操作的相关规则:

  1. DID方法 规范 必须 定义如何执行所有操作的授权过程,包括任何必要的加密过程。
  2. DID方法规范必须规定DID签发或者注册表的控制者如何创建DID标识及其相关联的DID文档的过程和规则。
  3. DID方法规范必须 规定DID解析器如何使用DID标识来解析其对应的DID文档,其中应包括DID解析器如何验证响应真实性的规则和方法。
  4. DID方法规范必须 规定如何构造DID文档更新、DID签发或者注册表的控制者控制者如何更新DID文档如何就DID文档无法更新发布公告
  5. DID方法规范必须 规定DID签发或者注册表的控制者如何停用DID标识或者DID标识无法停用发表声明。

授权操作的执行方的前线是受限于特定的 DID方法。例如,DID方法 可能会 :

8.3 安全性要求

所有 DID方法 规范都需要按照下列原则制定该方法下的 安全性注意事项 的相关规则:

  1. DID方法 规范 必须 遵循 RFC3552第6节编写安全性规范 相关指南和规范性语言的方式,编写针对该DID方法中所有DID操作的安全性注意事项
  2. DID 方法规范的安全性注意事项部分 必须包含其所定义的所有DID操作遭遇下列攻击形式的考量:窃听、重放、消息插入、删除、修改、拒绝服务、 放大攻击和中间人攻击。如有其他可以预见的攻击形式也 记录在DID方法规范的安全性注意事项部分。
  3. 除了上述规定之外,安全性注意事项部分还必须讨论其余风险,例如在威胁缓解措施部署后相关协议被攻破、实施错误或加密算法失效等带来的风险。
  4. 安全性注意事项部分必须为本标准第 8.2节“方法操作”中所有操作提供完整性保护和更新认证功能。
  5. 如果涉及认证,尤其是用户与主机/服务器之间的认证,必须在本安全性注意事项部分清楚地记录认证方法的安全特性和特点。
  6. 安全性注意事项部分必须包括DID分配唯一性策略/机制的证明。
  7. 安全性注意事项部分必须包含基于特定DID方法的端点/端对端认证考量。对于使用不同网络拓扑的分布式账本技术分布式账本技术(DLT)DID方法(有时以轻节点瘦客户端的形式实现,以减少所需的计算资源),安全性注意事项部分必须包含所涉及网络拓扑在DID方法实现中的安全规则。
  8. 如果协议包含加密保护机制,DID方法规范必须清楚地指出数据的哪些部分受到保护以及采用了何种保护措施,并说明此加密保护措施可能易受的攻击类型,例如该加密保护措施是完整性保护、机密性保护还是端点/端对端认证保护。
  9. 安全性注意事项部分清楚标识哪些数据需要进行保护(如密钥材料、随机种子等)。
  10. 如果适用,DID方法规范解释并指定DID文档的签名实现方式。
  11. 对于使用点对点计算资源的DID方法(比如:当前所有分布式账本技术),安全性注意事项部分应介绍这些资源在拒绝服务攻击时预期负载和资源负担。
  12. 对于那些引入新认证服务类型的DID方法(如第5.4节 “服务”中所述),DID方法规范的安全性注意事项部分包含所支持认证协议的安全要求。

8.4 隐私性要求(Privacy Requirements)

所有DID方法规范都需要按照下列原则制定该方法下的隐私性考量的相关规则:

  1. DID方法规范中隐私性考量部分必须按照《互联网协议隐私性考量》[RFC6973]第5节中给出的各种基于不同情况下隐私性要求情况制定使用的隐私性规则,其中包括但不限于:监视、存储数据泄露、非请求流量、误归因、关联、识别、二次使用、披露和排除等情况。

9. 安全注意事项

本章节为非规范性内容

本章节介绍了将分布式标识(DIDs)技术部署到生产环境之前,应考虑的各种安全事项。DIDs的设计目的是在威胁模型中进行操作,这些模型记录在IETF(互联网工程任务组)标准和[RFC3552]中。本章节详细阐述了 [RFC3552] 中的一些注意事项,以及专属于DID架构的其他注意事项。 ​

9.1 选择DID解析器

DID规范注册表[DID-SPEC-REGISTRIES]是一个包含DID 方法名及其对应规范的信息列表。实施者需注意,没有一个中心化机构可以强制将某个DID 方法规范与特定的DID 方法名绑定。如果不确定某个特定DID 解析器是否正确执行了某个DID 方法,可以对照DID规范注册表查找已注册的规范,并据之选择合适的 DID 解析器。 ​

9.2 控制与绑定关系证明(Proving Control and Binding)

将数字世界或物理世界中的实体与特定DIDDID 文档或密钥绑定,需要使用本规范所设计的安全协议。以下部分描述了需要证明这种绑定关系的一些场景,以及相关实体在身份验证或授权中如何证明对DIDDID 文档的控制权。 ​

证明对DID和/或DID文档的控制权

在进行可验证数据注册表更新或远程系统验证时,需要证明对 DID和/或 DID 文档有控制权。数字签名算法和可验证时间戳使得与DID 文档相关的某些安全协议能够进行密码学层面的安全验证。为此,本规范在5.3.1节“身份验证”(5.3.1 验证 )和5.3.4节“能力调用”(5.3.4 能力调用)章节中定义了有效的验证关系。与验证方法相关联的密钥可用于生成数字签名,作为身份验证或授权安全协议的一部分。 ​

: 签名的DID文档

一些DID 方法允许在 DID 文档或7.3“元数据结构”章节(7.3 元数据结构)中包含数字签名和其他证明。然而,这些证明本身并不一定能证明对DID的控制权,也不一定能保证DID 文档正确对应到一个DID。为了获得正确的DID 文档并验证对DID的控制权,有必要执行DID 方法定义的DID 解析过程。 ​

与物理身份绑定

一个DIDDID 文档本身并不携带任何个人数据,强烈建议非公共实体不要在 DID 文档中发布个人数据。 ​

将一个DID与个人或组织的物理身份进行绑定时,一个有效做法是由一个受信任的权威机构进行可证明的断言,如政府机构。为此,本规范提供了5.3.2“验证关系断言”( 5.3.2 断言验证关系)。此章节特性可以实现隐私交互,并且可以在一个或多个司法管辖区内被视为具有法律效力;建立这样的绑定关系必须同时慎重的考虑隐私保护问题(见10.隐私考虑(10. 隐私考虑))。 ​

本规范考虑将DID绑定到物理世界中的某个事物(如个人或组织)——如通过使用与DID对象相同的可验证凭证,并在可验证凭证数据模型[VC-DATA-MODEL]中进一步定义。 ​

9.3 身份验证服务端点

如果一个DID 文档发布了一个用于DID对象身份验证或授权的服务(见第 5.4“服务”章节( 5.4 服务)),那么服务端点提供方、主体或请求方有责任遵守该服务端点所支持的身份验证协议的要求。 ​

如果满足以下条件,DIDsDID 文档的更新就具有不可否认性:

9.5 DID文档更改通知

针对未经授权的DID 文档更改,一个应对方法是开展实时监控并在更改发生时主动通知 DID 对象。这就类似于向已注册的电子邮件地址发送密码重置通知以防止用户名/密码账户被盗用。 ​

不同的是,在DID中没有中间注册商或账户提供商来生成此类通知。然而,如果注册DID可验证数据注册表直接支持更改通知,则可以向DID 控制者提供订阅服务。可以直接将通知发送到现有DID中列出的相关服务端点

如果DID 控制者选择依赖第三方监控服务(而非 可验证数据注册表本身),这会引入另一个攻击向量。

9.6 密钥和签名过期

DID架构中,可能没有中心化的机构来执行密钥和数字签名的过期策略。因此,请求方需要通过DID 解析器和验证库等支撑软件,来证明密钥在使用时仍在有效期内。请求方可能会在其验证过程中采用自己的过期策略。例如,一些请求方可能将过去五分钟内的验证设为有效,而具有高精度时间源的请求方可能要求将验证时间戳设为500毫秒内。 ​

有些请求方需要在密钥过期后继续使用,例如验证旧的数字签名。这种情况下,请求方可能会指示验证软件忽略密钥期限要求或判断密钥在使用时是否已过期。 ​

9.7 验证方法轮换机制

轮换机制是一种管理过程,这一过程使得新的验证方法添加到DID 文档后,采用现有验证方法的密钥将被停用或销毁。此后,控制者可应用新密钥生成证明,并且可使用新验证方法进行验证。 ​

轮换机制可以有效防止验证方法遭受攻击,因为控制器频繁地轮换验证方法可以降低单个验证方法被攻破的风险。在验证方法轮换之后立即执行撤销,对于一些用于短期验证的验证方法很有效,例如加密消息和身份验证中涉及的验证方法。 ​

在应用验证方法轮换机制时,有以下注意事项: ​

9.8 验证方法的撤销机制

撤销机制是一种管理过程,这一过程可以使现有验证方法生成的密钥失效,使其不再能验证新创建的数字签名。 ​

撤销机制是验证方法被攻破后做出的有效反应。在轮换后立即执行撤销对于控制者指定用于短期验证的验证方法很实用,例如消息加密和身份验证中的验证方法。

验证方法相关的密钥被攻破后,攻击者可以根据控制者DID 文档中表达的验证关系开展攻击,例如用于身份验证。验证方法从注册到撤销期间,攻击者和合法控制者的使用很难区分。 ​

应用验证方法撤销时,有以下注意事项: ​

撤销语义

尽管验证者可能选择不接受来自已撤销的验证方法的证明或签名,但要确切知道某个加密材料是否是由已撤销的验证方法生成的可能更困难。一些 DID 方法提供了回溯查看某一时间点时的DID状态或特定版本下的 DID 文档的能力。当这一特性与可验证声明结合时,那么密钥的撤销并不会撤销该声明。因此,这可以成为使用DIDs进行约束性承诺的基础,例如,签署抵押贷款。 ​

如果满足上述条件,撤销不具有追溯性;仅使得未来应用该方法无效。

然而,为了保证语义安全,需要在创建可验证声明时附加额外条件,即明确该声明对应的DID 文档状态。否则,可能会有人使用已撤销的密钥来创建可验证声明,日期为伪造的撤销前日期。 ​

一些DID 方法只允许检索DID的当前状态。在这种情况下,或者当无法确定可验证声明创建时的 DID状态,唯一安全的做法是不再考虑DID状态与时间的关系,除了当前DID状态为最新情况。DID生态系统实际上采取这种方法提供可验证声明,可作为短暂令牌,随时被DID 控制者撤销。

无信任系统中的撤销(Revocation in Trustless Systems)

无信任系统是指所有信任依据都来自于密码学层面的可验证声明,更确切地说,判断系统可信度的元数据全部来自加密系统。要验证已在无信任系统中撤销的 验证方法生成的签名或证明,DID 方法需要支持 versionIdversionTime或两者都支持,以及updatednextUpdateDID 文档元数据属性。验证者只有在满足以下所有条件时才能对已撤销密钥生成的签名或证明执行生效操作: ​

  • 证明或签名包含其创建时DID 文档的版本号(versionId)或版本时间(versionTime)。 ​
  • 验证者可以确定签名或证明创建的时间点;例如,相关内容存在区块链上。 ​
  • 对于解析后的DID 文档元数据,已更新时间戳(updated)在签名或证明创建的时间点之前,待更新时间戳(nextUpdate)在签名或证明创建的时间点之后。 ​

在允许加密数据之外的元数据输入的系统中,也可能实现此类的信任操作,但仍需要谨慎判断,即在签名发生时,DID 文档的内容是否包含预期内容。 ​

9.9 DID恢复

恢复是一种响应性的安全措施,通过这一措施,失去DID操作能力(例如因设备丢失)的控制者,能够重新执行DID操作。 ​

在应用DID恢复时,有以下注意事项: ​

9.10 人类友好标识符的作用

DIDs 无需中央注册机构即可实现全球唯一性。 但这样做的代价是需要人类记忆。 能够生成全局无歧义标识符的算法会随机产生一串没有人类意义的字符。 这种权衡通常被称为祖克三角(Zooko's Triangle)。 ​

在一些使用案例中,我们希望从人类友好的标识符开始查找并发现一个DID。 例如,自然语言名称、域名或DID 控制者的常规地址,如移动电话号码、电子邮件地址、社交媒体用户名或博客URL。 不过,将人类友好标识符映射到DIDs并以可验证和可信的方式进行映射的问题不属于本规范的范围。 ​

这一问题的解决方案已在引用本规范的独立规范(如 [DNS-DID])中定义。 强烈建议此类规范仔细考虑以下问题: ​

9.11 作为增强型URNs的DIDs

如果 DID 控制者需要,一个DID或一个DID URL 可以作为持久的、与位置无关的资源标识符。 这类标识符被归类为统一资源名称(URN),其定义见 [RFC8141]。 DIDs是URN的一种增强形式,它为数字资源提供了一种加密安全、与位置无关的标识符,同时还提供了可用于检索的元数据。 由于DID 文档DID本身之间的间接性,DID 控制者 可以调整资源的实际位置,甚至直接提供资源,而无需调整 DID。这种类型的DIDs可以明确验证所检索的资源,实际上就是所标识的资源。 ​

建议打算将 DID用于此目的的DID 控制者建议遵循 [RFC8141] 中的安全注意事项。 特别是: ​

​ ​
  • DID 控制者应公布其操作政策,以便请求方确定在多大程度上可以依赖该 DID 控制者控制的 DID 的持久性。 在没有此类政策的情况下,请求方不应假设某个 DID是否是同一DID 对象的持久标识符。 ​
  • ​ ​

    9.12 不可变性

    许多网络安全滥用行为都是利用了现实与理性、善意行为者的假设之间的差距。 DID 文档的不变性可以提供一些安全优势。 单个DID 方法 应考虑消除其不需要的行为或语义的约束。 在提供相同功能的同时, DID 方法 的锁定程度越高,就越不容易被恶意行为者操纵。 ​

    举例来说,对 DID 文档 进行一次编辑就可以改变除文档根 id 属性之外的任何内容。 但是,一项服务 在定义后改变其类型是否真的可取? 或者一个键改变其值是否可取? 还是在对象的某些基本属性发生变化时获取一个新的id 更好? 恶意接管网站的目的往往是让网站保留其主机名标识符,但在下面进行微妙的更改。 如果规范要求网站的某些属性(如与其 IP 地址相关的 ASN)不可更改,那么异常检测就会变得更加容易,攻击的难度和成本也会大大增加。 ​

    对于与全球真相来源绑定的DID 方法,总是可以进行直接的、即时的查询 DID 文档 的最新版本。然而,似乎很可能最终会有一些缓存层位于 DID 解析器和真相来源之间。如果是这样,如果认为DID 文档 中某个对象的属性具有给定的状态,而实际上它们有细微的差别,就可能会招致漏洞。 如果某些查找是针对完整的DID 文档,而另一些查找是针对部分数据,并假定了更大的上下文,情况就更是如此。

    9.13 DID文档中的加密数据

    众所周知,加密算法会因密码学和计算能力的进步而失效。 建议实施者放在 DID 文档的任何加密数据最终都可能以明文形式提供给加密数据的相同受众。 如果 DID 文档是公开的,这一点尤其重要。 ​

    DID 文档的全部或部分内容进行加密并不是长期保护数据的适当方法。 同样,在 DID 文档中放置加密数据也不是保护个人数据的适当手段。

    鉴于上述注意事项,如果在 DID 文档中包含加密数据,建议实施者不要关联任何可用于推断加密数据与关联方之间关系的可关联信息。 可关联信息的例子包括接收方的公开密钥、已知由接收方控制的数字资产的标识符,或接收方的人类可读描述。

    9.14 等价属性

    鉴于 equivalentIdcanonicalId属性由 DID 方法 本身生成,适用于DID 文档 id 字段中已解析 DID 的安全性和准确性保证也同样适用于这些属性。 alsoKnownAs 属性不能保证是等价性的准确声明,在未执行 DID 文档解析以外的验证步骤时,不应依赖该属性。 ​

    equivalentIdcanonicalId属性表达了对由同一 DID 方法产生的单个DID变体的等价断言,请求方可信任 DID 方法以及符合要求的生成器和解析器。

    alsoKnownAs属性允许对不受相同 DID 方法 管理的URIs进行等价断言,如果不执行管理 DID method之外的验证步骤,就无法信任这些URIs。 请参阅 5.1.3 Also Known As

    DID 文档中任何其他与安全相关的属性一样,依赖 DID 文档中任何等价声明的各方应防止攻击者在执行适当验证后替换这些属性的值。除非重新验证 DID 文档,否则对内存或磁盘中存储的DID 文档的任何写入访问都是可能规避验证的攻击向量。 ​

    9.15 内容完整性保护

    包含指向外部机器可读内容(如图像、网页或模式)链接的DID 文档很容易被篡改。 强烈建议使用哈希链接 [HASHLINK] 等解决方案保护外部链接的完整性。 如果外部链接无法得到完整性保护,而DID 文档的完整性又依赖于外部链接,则应避免使用外部链接。 ​

    DID 文档本身的完整性可能受到影响的外部链接示例之一是 JSON-LD 上下文 [JSON-LD11]。 为防止泄露,建议DID 文档使用者缓存 JSON-LD 上下文的本地静态副本,并/或根据已知与外部 JSON-LD 上下文安全版本相关联的加密哈希值验证外部上下文的完整性。

    9.16 持久性

    DIDs被设计为具有持久性,因此 控制者无需依赖单一可信第三方或管理员来维护其标识符。 在理想情况下,任何管理员都不能从控制者手中夺走控制权, 管理员也不能阻止将其标识符用于任何特定目的,如身份验证、授权和证明。 未经 控制者同意,任何第三方都不能代表控制者删除实体的标识符或使其无法使用。 ​

    不过,必须指出的是,在所有能够进行加密控制证明的DID 方法中,证明控制权的手段总是可以通过转移秘密加密材料而转移给另一方。 因此,依赖于标识符长期持久性的系统必须定期检查,以确保标识符实际上仍在预定方的控制之下。

    遗憾的是,仅从密码学角度无法确定与特定验证方法 相关的秘密加密材料是否已被泄露。 很有可能,预期的 控制者仍然可以访问秘密加密材料--因此可以作为验证过程的一部分执行控制证明--而与此同时,坏人也可以访问这些密钥或其副本。

    因此,密码学证明控制预计将仅作为评估高风险场景所需的身份保证水平的一个因素。基于 DID的认证比用户名和密码提供更高的保证,这得益于在不传输秘密本身的情况下确定对密码学秘密的控制的能力。然而,这并不是万无一失的。涉及敏感、高价值或生命关键操作的场景预计将使用适当的额外因素。

    除了不同控制者的使用可能产生的歧义外,通常无法保证在任何给定时间点,给定的 DID 正在引用相同的主体。从技术上讲,控制者有可能对不同的对象重复使用一个DID,更微妙的是,对象的准确定义有可能随着时间的推移而改变或被误解。

    例如,考虑一个用于独资企业的DID,接收用于金融交易的各种凭证。 对于控制者来说,该标识符指的是企业。 随着业务的发展,该公司最终注册为有限责任公司。 控制者继续使用同一个DID,因为对他们来说,DID指的是企业。 但是,对于国家、税务机关和地方市政当局来说,DID指的不再是同一个实体。 对于信贷提供商或供应商来说,意义上的微妙变化是否重要,必须由他们自己决定。 在许多情况下,只要账单能够支付,收款能够执行,含义的变化就无关紧要。 ​

    由于这些潜在的歧义,DIDs应被视为在上下文中有效,而不是绝对有效。它们的持久性并不意味着它们指的是完全相同的主体,也不意味着它们受到相同 控制者的控制。相反,需要了解创建DID的背景、它的使用方式,并考虑它们的含义可能发生的变化,并采取程序和政策来解决潜在的和不可避免的语义漂移问题。

    9.17 保证水平

    出于合规原因,特别是在金融和公共部门等受监管领域,通常需要有关身份验证事件安全背景的附加信息。 这些信息通常被称为 "保证级别"(LOA)。 例如,对秘密加密材料的保护、身份验证过程和验证器的形式因素。

    支付服务 (PSD 2) eIDAS将此类要求引入安全环境。 保证级别框架由 eIDAS NIST 800-63-3 ISO/IEC 29115:2013等法规和标准进行分类和定义,包括其对安全环境的要求,并就如何实现这些要求提出建议。 这可能包括FIDO2/WebAuthn可以满足要求的强用户身份验证。 ​

    某些受监管的场景要求实施特定级别的保证。 由于在某些情况下可能会使用 断言方法(assertionMethod)身份验证(authentication)验证关系,因此可能需要表达并向验证者提供有关所应用的安全上下文的信息。 是否以及如何在DID 文档数据模型中编码这些信息不属于本规范的范围。 有兴趣的读者可能会注意到:1) 可使用可验证凭证 [VC-DATA-MODEL] 传输该信息;2) 如 4.1 可拓展性 所述,可扩展DID 文档数据模型以纳入该信息,其中10. 隐私考虑 因素适用于此类扩展。 ​

    10. 隐私考虑

    此章节是非规范性的。

    由于 DIDDID 文档设计为由 DID 控制者直接管理,因此将隐私设计原则 [PRIVACY-BY-DESIGN] 应用于去中心化标识符架构的所有方面至关重要。这七个原则在本规范的制定过程中得到了全面应用。本规范中使用的设计并不假定存在注册机构、托管公司或其他中间服务提供商来推荐或应用额外的隐私保护措施。本规范中的隐私是预防性的,而不是补救性的,并且是嵌入式默认的。以下部分涵盖了实施者在构建使用去中心化标识符的系统时可能会发现有用的隐私注意事项。

    10.1 保持个人数据隐私

    如果为面向公众的可验证数据注册表编写了DID方法规范,其中相应的DIDDID文档可能会公开提供,则必须确保这些DID 文档中不包含任何个人数据。个人数据可以通过其他方式传输,例如1)可验证凭证 [VC-DATA-MODEL],或者2)由DID对象DID控制者控制的服务端点

    服务端点中使用URL时应进行尽职调查,以防止个人数据泄露或在URL内的关联。例如,包含用户名的URL包含在DID文档中是危险的,因为用户名可能具有人类可理解的意义,从而泄露DID对象未同意共享的信息。根据本规范建议的隐私架构,可以使用DID文档验证方法确定和保护的通信渠道,以私密的点对点方式交换个人数据。这也使得DID对象和请求方能够实施 GDPR被遗忘权,因为没有个人数据被写入不可变的分布式账本

    10.2 DID关联风险

    像任何类型的全球唯一标识符一样,DID可能被用于关联。DID控制者可以通过使用仅对每个关系唯一的成对DID来减轻这一隐私风险;实际上,每个DID作为化名的作用。成对的DID仅在明确需要关联时才需要与多方共享。如果成对 DID 是默认设置,那么唯一需要公开发布DID 或与多方共享的情况是,当DID控制者和/或 DID对象明确希望被公开识别和关联时。

    10.3 DID文档关联风险

    如果对应DID文档中的数据可以关联,那么成对DID的反关联保护很容易被击败。例如,在多个DID文档中使用相同的验证方法或定制的服务端点,可能会提供与使用相同DID一样多的关联信息。因此,成对DIDDID文档也需要使用成对唯一的信息,例如确保验证方法对于成对关系是唯一的。

    DID文档中为成对DID使用成对唯一的服务端点似乎是很自然的。然而,唯一的端点允许两个DID之间的所有通信完全隔离到唯一的桶中,在这些桶中时间相关分析和类似的分析很容易进行。因此,为了提高端点隐私性,更好的策略可能是让大量由不同主体控制的DID共享一个端点(参见10.5 群隐私)。

    10.4 DID对象分类

    DID文档中添加可用于明确或通过推理指示DID对象是什么类型或属性的事物的属性是危险的,特别是如果DID对象是个人的话。

    此类属性不仅可能导致个人数据(参见10.1 保持个人数据隐私)或可关联数据(参见 10.2 DID关联风险10.3 DID文档关联风险)出现在DID文档中,而且它们可以用于以特定方式对特定DID进行分组,从而使它们被包含在或排除在某些操作或功能之外。

    DID文档中包含类型信息可能会导致个人隐私损害,即使对于非个人实体的DID对象也是如此,例如物联网设备。围绕DID控制者的此类信息的聚合可能形成一种数字指纹,最好避免这种情况。

    为了尽量减少这些风险,DID文档中的所有属性都应仅用于表示加密材料、端点或与使用DID相关的验证方法

    10.5 群隐私(Herd Privacy)

    当一个DID对象在群体中无法与其他主体区分时,隐私便得以保障。当与另一方私下互动的行为本身就是一个可识别的标志时,隐私会大大减少。

    DIDDID方法需要努力提高群体隐私,特别是对于那些真正最需要它的人。选择默认保护匿名性和假名性的技术和人类界面。为了减少数字指纹,跨请求方实现共享通用设置,将协商选项在传输协议上保持最少,使用加密传输层,并将消息填充到标准长度。

    10.6 服务隐私

    控制者可选地在 DID文档中表达至少一个服务端点的能力增加了他们的控制和自主权。DID文档中的每个额外端点都会增加隐私风险,这可能是由于关联导致的,例如跨端点描述,或者因为这些服务没有受到授权机制的保护,或两者兼而有之。

    DID文档通常是公开的,并且由于它们是标准化的,因此会以其标准的本质高效地存储和索引。如果DID文档发布到不可变的可验证数据注册表中,这种风险会更严重。对由DID引用的DID文档历史记录的访问代表了一种通过使用标准变得更加高效的流量分析形式。

    使用一个DID文档中的多个服务端点所带来的额外隐私风险可能难以估计。隐私损害通常是意外后果。DID可以指代文档、服务、模式以及其他可能与个人、家庭、俱乐部和雇主相关的事物——并且它们的服务端点之间的关联可能会成为强大的监控和推断工具。这种潜在的危害的一个例子可以在多个常见的国家顶级域名(如 https://example.co.uk)被用来以更高的概率推断DID对象的大致位置时看到。

    维护群隐私

    各种可能的终点使得维护群体隐私变得特别具有挑战性,在群体隐私中,不会泄露关于DID对象的任何信息(参见10.5 群隐私)。

    首先,由于服务端点可能被指定为 URI,因此可能会因为服务架构而无意中泄露个人信息。例如,服务端点 http://example.com/MyFirstName 会将 MyFirstName 泄露给所有可以访问 DID文档的人。在链接到遗留系统时,这是不可避免的风险,并且在这种情况下应采取谨慎措施。本规范鼓励新的DID感知终端节点仅使用DID本身进行任何必要的身份识别。例如,如果服务描述包含 http://example.com/did%3Aexample%3Aabc123,则不会造成任何损害,因为 did:example:abc123 已经在 DID文档中公开了;它不会泄露更多信息。

    其次,由于DID文档可以列出多个服务端点,因此可以不可逆地关联在任何其它上下文中未关联的服务。这种关联本身可能会通过透露有关 DID对象的信息而导致隐私危害,即使使用的 URI 不包含任何敏感信息。

    第三,由于某些类型的DID对象可能或多或少地列出特定终端节点,因此给定服务的列表本身可能会泄露可用于推断有关 DID对象的信息。例如,汽车的 DID可能会包含指向机动车部门的公共所有权记录的指针,而个人的DID不会包含该信息。

    群隐私的目标是确保特定DID对象的本质被整体人群所掩盖。为了最大化群体隐私,实施者需要依赖一个——且仅一个——服务端点,该端点提供了一个代理或中介服务,控制者愿意依赖这个服务来保护这些关联,并使请求对最终服务不可见。

    服务端点替代方案

    鉴于上一节中提到的问题,强烈建议实现者考虑以下任何一种服务端点方法:

    • 协商端点 — 协商双方可接受的通信渠道的服务,最好使用私有集合交集。协商的结果是一个通信渠道以及可能需要的访问凭证。
    • Tor 终端 (Tor Onion路由) — 提供一个尊重隐私的地址以访问服务终端节点。任何可以在线提供的服务都可以通过 TOR 提供,以增加隐私保护。
    • 中介端点中介为多方提供通用终端节点,代表这些参与方接收加密消息,并将其转发给目标接收人。这样就避免了每个主题都需要有一个特定终端节点的需要,这可能会造成关联风险。这种方法也称为代理。
    • 保密存储 — 专有或保密的个人信息可能需要不存储在可验证数据注册表中,以提供额外的隐私和/或安全保证,特别是对于那些将 DID文档发布在公共分类账上的 DID方法。指向外部资源服务提供了一种授权检查和删除的手段。
    • 多态代理 — 一个可以根据调用方式充当多种服务的代理端点。例如,根据重定向机制,相同的URL可以用于协商和中介的功能。

    这些服务端点类型继续成为创新和探索的领域。

    A. 例子

    A.1 DID文档

    此章节是非规范性的。

    有关可选扩展和其它验证方法类型,请参考 验证方法类型 [DID-SPEC-REGISTRIES] 。

    提示

    这些示例仅供参考,建议不要使用相同的验证方法验证方法作为多个目的去使用。

    例子 30: 有1种验证方法类型的DID文档
      {
        "@context": [
          "https://www.w3.org/ns/did/v1",
          "https://w3id.org/security/suites/ed25519-2020/v1"
        ],
        "id": "did:example:123",
        "authentication": [
          {
            "id": "did:example:123#z6MkecaLyHuYWkayBDLw5ihndj3T1m6zKTGqau3A51G7RBf3",
            "type": "Ed25519VerificationKey2020", // external (property value)
            "controller": "did:example:123",
            "publicKeyMultibase": "zAKJP3f7BD6W4iWEQ9jwndVTCBq8ua2Utt8EEjJ6Vxsf"
          }
        ],
        "capabilityInvocation": [
          {
            "id": "did:example:123#z6MkhdmzFu659ZJ4XKj31vtEDmjvsi5yDZG5L7Caz63oP39k",
            "type": "Ed25519VerificationKey2020", // external (property value)
            "controller": "did:example:123",
            "publicKeyMultibase": "z4BWwfeqdp1obQptLLMvPNgBw48p7og1ie6Hf9p5nTpNN"
          }
        ],
        "capabilityDelegation": [
          {
            "id": "did:example:123#z6Mkw94ByR26zMSkNdCUi6FNRsWnc2DFEeDXyBGJ5KTzSWyi",
            "type": "Ed25519VerificationKey2020", // external (property value)
            "controller": "did:example:123",
            "publicKeyMultibase": "zHgo9PAmfeoxHG8Mn2XHXamxnnSwPpkyBHAMNF3VyXJCL"
          }
        ],
        "assertionMethod": [
          {
            "id": "did:example:123#z6MkiukuAuQAE8ozxvmahnQGzApvtW7KT5XXKfojjwbdEomY",
            "type": "Ed25519VerificationKey2020", // external (property value)
            "controller": "did:example:123",
            "publicKeyMultibase": "z5TVraf9itbKXrRvt2DSS95Gw4vqU3CHAdetoufdcKazA"
          }
        ]
    }
    例子 31: 有多种不同密钥类型的DID文档(DID Document with many different key types)
    {
      "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://w3id.org/security/suites/jws-2020/v1"
      ],
      "verificationMethod": [
        {
          "id": "did:example:123#key-0",
          "type": "JsonWebKey2020",
          "controller": "did:example:123",
          "publicKeyJwk": {
            "kty": "OKP", // external (property name)
            "crv": "Ed25519", // external (property name)
            "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ" // external (property name)
          }
        },
        {
          "id": "did:example:123#key-1",
          "type": "JsonWebKey2020",
          "controller": "did:example:123",
          "publicKeyJwk": {
            "kty": "OKP", // external (property name)
            "crv": "X25519", // external (property name)
            "x": "pE_mG098rdQjY3MKK2D5SUQ6ZOEW3a6Z6T7Z4SgnzCE" // external (property name)
          }
        },
        {
          "id": "did:example:123#key-2",
          "type": "JsonWebKey2020",
          "controller": "did:example:123",
          "publicKeyJwk": {
            "kty": "EC", // external (property name)
            "crv": "secp256k1", // external (property name)
            "x": "Z4Y3NNOxv0J6tCgqOBFnHnaZhJF6LdulT7z8A-2D5_8", // external (property name)
            "y": "i5a2NtJoUKXkLm6q8nOEu9WOkso1Ag6FTUT6k_LMnGk" // external (property name)
          }
        },
        {
          "id": "did:example:123#key-3",
          "type": "JsonWebKey2020",
          "controller": "did:example:123",
          "publicKeyJwk": {
            "kty": "EC", // external (property name)
            "crv": "secp256k1", // external (property name)
            "x": "U1V4TVZVMUpUa0ZVU1NBcU9CRm5IbmFaaEpGNkxkdWx", // external (property name)
            "y": "i5a2NtJoUKXkLm6q8nOEu9WOkso1Ag6FTUT6k_LMnGk" // external (property name)
          }
        },
        {
          "id": "did:example:123#key-4",
          "type": "JsonWebKey2020",
          "controller": "did:example:123",
          "publicKeyJwk": {
            "kty": "EC", // external (property name)
            "crv": "P-256", // external (property name)
            "x": "Ums5WVgwRkRTVVFnU3k5c2xvZllMbEcwM3NPRW91ZzN", // external (property name)
            "y": "nDQW6XZ7b_u2Sy9slofYLlG03sOEoug3I0aAPQ0exs4" // external (property name)
          }
        },
        {
          "id": "did:example:123#key-5",
          "type": "JsonWebKey2020",
          "controller": "did:example:123",
          "publicKeyJwk": {
            "kty": "EC", // external (property name)
            "crv": "P-384", // external (property name)
            "x": "VUZKSlUwMGdpSXplekRwODhzX2N4U1BYdHVYWUZsaXVDR25kZ1U0UXA4bDkxeHpE", // external (property name)
            "y": "jq4QoAHKiIzezDp88s_cxSPXtuXYFliuCGndgU4Qp8l91xzD1spCmFIzQgVjqvcP" // external (property name)
          }
        },
        {
          "id": "did:example:123#key-6",
          "type": "JsonWebKey2020",
          "controller": "did:example:123",
          "publicKeyJwk": {
            "kty": "EC", // external (property name)
            "crv": "P-521", // external (property name)
            "x": "VTI5c1lYSmZWMmx1WkhNZ0dQTXhaYkhtSnBEU3UtSXZwdUtpZ0VOMnB6Z1d0U28tLVJ3ZC1uNzhuclduWnplRGMx", // external (property name)
            "y": "UW5WNVgwSnBkR052YVc0Z1VqY1B6LVpoZWNaRnliT3FMSUpqVk9sTEVUSDd1UGx5RzBnRW9NV25JWlhoUVZ5cFB5" // external (property name)
          }
        },
        {
          "id": "did:example:123#key-7",
          "type": "JsonWebKey2020",
          "controller": "did:example:123",
          "publicKeyJwk": {
            "kty": "RSA", // external (property name)
            "e": "AQAB", // external (property name)
            "n": "UkhWaGJGOUZRMTlFVWtKSElBdENGV2hlU1F2djFNRXh1NVJMQ01UNGpWazlraEpLdjhKZU1YV2UzYldIYXRqUHNrZGYyZGxhR2tXNVFqdE9uVUtMNzQybXZyNHRDbGRLUzNVTElhVDFoSkluTUhIeGoyZ2N1Yk82ZUVlZ0FDUTRRU3U5TE8wSC1MTV9MM0RzUkFCQjdRamE4SGVjcHl1c3BXMVR1X0RicXhjU253ZW5kYW13TDUyVjE3ZUtobE80dVh3djJIRmx4dWZGSE0wS21DSnVqSUt5QXhqRF9tM3FfX0lpSFVWSEQxdERJRXZMUGhHOUF6c24zajk1ZC1zYU" // external (property name)
          }
        }
      ]
    }
    例子 32: 有不同验证方法类型的DID文档
    {
      "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://w3id.org/security/suites/ed25519-2018/v1",
        "https://w3id.org/security/suites/x25519-2019/v1",
        "https://w3id.org/security/suites/secp256k1-2019/v1",
        "https://w3id.org/security/suites/jws-2020/v1"
      ],
      "verificationMethod": [
        {
          "id": "did:example:123#key-0",
          "type": "Ed25519VerificationKey2018",
          "controller": "did:example:123",
          "publicKeyBase58": "3M5RCDjPTWPkKSN3sxUmmMqHbmRPegYP1tjcKyrDbt9J" // external (property name)
        },
        {
          "id": "did:example:123#key-1",
          "type": "X25519KeyAgreementKey2019",
          "controller": "did:example:123",
          "publicKeyBase58": "FbQWLPRhTH95MCkQUeFYdiSoQt8zMwetqfWoxqPgaq7x" // external (property name)
        },
        {
          "id": "did:example:123#key-2",
          "type": "EcdsaSecp256k1VerificationKey2019",
          "controller": "did:example:123",
          "publicKeyBase58": "ns2aFDq25fEV1NUd3wZ65sgj5QjFW8JCAHdUJfLwfodt" // external (property name)
        },
        {
          "id": "did:example:123#key-3",
          "type": "JsonWebKey2020",
          "controller": "did:example:123",
          "publicKeyJwk": {
            "kty": "EC", // external (property name)
            "crv": "P-256", // external (property name)
            "x": "Er6KSSnAjI70ObRWhlaMgqyIOQYrDJTE94ej5hybQ2M", // external (property name)
            "y": "pPVzCOTJwgikPjuUE6UebfZySqEJ0ZtsWFpj7YSPGEk" // external (property name)
          }
        }
      ]
    }

    A.2 证明

    此章节是非规范性的。

    提示

    这些示例仅供参考。有关其它示例,请参考W3C 可验证凭证数据模型

    例子 33:与 Ed25519VerificationKey2020 类型的验证方法关联的可验证凭证
    {  // external (all terms in this example)
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://w3id.org/citizenship/v1"
      ],
      "type": [
        "VerifiableCredential",
        "PermanentResidentCard"
      ],
      "credentialSubject": {
        "id": "did:example:123",
        "type": [
          "PermanentResident",
          "Person"
        ],
        "givenName": "JOHN",
        "familyName": "SMITH",
        "gender": "Male",
        "image": "data:image/png;base64,iVBORw0KGgo...kJggg==",
        "residentSince": "2015-01-01",
        "lprCategory": "C09",
        "lprNumber": "000-000-204",
        "commuterClassification": "C1",
        "birthCountry": "Bahamas",
        "birthDate": "1958-08-17"
      },
      "issuer": "did:example:456",
      "issuanceDate": "2020-04-22T10:37:22Z",
      "identifier": "83627465",
      "name": "Permanent Resident Card",
      "description": "Government of Example Permanent Resident Card.",
      "proof": {
        "type": "Ed25519Signature2018",
        "created": "2020-04-22T10:37:22Z",
        "proofPurpose": "assertionMethod",
        "verificationMethod": "did:example:456#key-1",
        "jws": "eyJjcml0IjpbImI2NCJdLCJiNjQiOmZhbHNlLCJhbGciOiJFZERTQSJ9..BhWew0x-txcroGjgdtK-yBCqoetg9DD9SgV4245TmXJi-PmqFzux6Cwaph0r-mbqzlE17yLebjfqbRT275U1AA"
      }
    }
    例子 34: 与 JsonWebKey2020 类型的验证方法关联的可验证凭证
    {  // external (all terms in this example)
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://www.w3.org/2018/credentials/examples/v1"
      ],
      "id": "http://example.gov/credentials/3732",
      "type": ["VerifiableCredential", "UniversityDegreeCredential"],
      "issuer": { "id": "did:example:123" },
      "issuanceDate": "2020-03-10T04:24:12.164Z",
      "credentialSubject": {
        "id": "did:example:456",
        "degree": {
          "type": "BachelorDegree",
          "name": "Bachelor of Science and Arts"
        }
      },
      "proof": {
        "type": "JsonWebSignature2020",
        "created": "2020-02-15T17:13:18Z",
        "verificationMethod": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
        "proofPurpose": "assertionMethod",
        "jws": "eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..Y0KqovWCPAeeFhkJxfQ22pbVl43Z7UI-X-1JX32CA9MkFHkmNprcNj9Da4Q4QOl0cY3obF8cdDRdnKr0IwNrAw"
      }
    }
    例子 35: 与 bls12381 验证方法关联的可验证凭证
    {  // external (all terms in this example)
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://w3id.org/security/bbs/v1",
        {
          "name": "https://schema.org/name",
          "birthDate": "https://schema.org/birthDate"
        }
      ],
      "id": "urn:uuid:c499e122-3ba9-4e95-8d4d-c0ebfcf8c51a",
      "type": ["VerifiableCredential"],
      "issuanceDate": "2021-02-07T16:02:08.571Z",
      "issuer": {
        "id": "did:example:123"
      },
      "credentialSubject": {
        "id": "did:example:456",
        "name": "John Smith",
        "birthDate": "2021-02-07"
      },
      "proof": {
        "type": "BbsBlsSignature2020",
        "created": "2021-02-07T16:02:10Z",
        "proofPurpose": "assertionMethod",
        "proofValue": "o7zD2eNTp657YzkJLub+IO4Zqy/R3Lv/AWmtSA/kUlEAOa73BNyP1vOeoow35jkABolx4kYMKkp/ZsFDweuKwe/p9vxv9wrMJ9GpiOZjHcpjelDRRJLBiccg9Yv7608mHgH0N1Qrj14PZ2saUlfhpQ==",
        "verificationMethod": "did:example:123#bls12381-g2-key"
      }
    }
    例子 36: 与 bls12381 验证方法关联的选择性披露零知识证明的可验证凭证
    {  // external (all terms in this example)
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://w3id.org/security/bbs/v1",
        {
          "name": "https://schema.org/name",
          "birthDate": "https://schema.org/birthDate"
        }
      ],
      "id": "urn:uuid:c499e122-3ba9-4e95-8d4d-c0ebfcf8c51a",
      "type": "VerifiableCredential",
      "issuanceDate": "2021-02-07T16:02:08.571Z",
      "issuer": {
        "id": "did:example:123"
      },
      "credentialSubject": {
        "id": "did:example:456",
        "birthDate": "2021-02-07"
      },
      "proof": {
        "type": "BbsBlsSignatureProof2020",
        "created": "2021-02-07T16:02:10Z",
        "nonce": "OqZHsV/aunS34BhLaSoxiHWK+SUaG4iozM3V+1jO06zRRNcDWID+I0uwtPJJ767Yo8Q=",
        "proofPurpose": "assertionMethod",
        "proofValue": "AAsH34lcKsqaqPaLQWcnLMe3mDM+K7fZM0t4Iesfj7BhD//HBtuWCmZE946BqW7OHYU106MP8mLntutqB8FyGwS7AOyK+5/7iW6JwLNVCvh4Nt3IaF3AN47fqVs2VikD9DiCsaFAUU6ISj5pbad8O+6jiT9Yw6ug8t8vJn3XHvMUhCPnDZJeBEdKD1qo4Z0LOq3L8QAAAHSEgtC9BoZL2MLjz4QuPxpwbhTTRC08MIUjdJnP4JUtz6163Lsl3rpadGu2d3Te7loAAAACZBD4YWOgV0xpPoYZ5vywNA5/NTeDHDbX36gvoV5RDJtY1SLU2LN/IDPZGrfhEiASbD1/QXqj8dod6FbjBs9m/LchBcy7z4yDBv/8DnBzDJ9dEaM4bDjpwmqtgJqha2kwtlyNog67xG9tNjnp5rrbIgAAAANMVanwWmlkg5I/f1M2QJ5GRvQiBL4lyL5sttxwIOalbTZP8VqWtFJI54xMNjTiK71aFWWN8SlNEwfVIX34HO5zBIb6fvc+Or21ubYllT9eXv1epl2o2CojuieCZyxE8/Q=",
        "verificationMethod": "did:example:123#bls12381-g2-key"
      }
    }
    例子 37: 作为已解码JWT的可验证凭证
    { // external (all terms in this example)
      "protected": {
        "kid": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
        "alg": "EdDSA"
      },
      "payload": {
        "iss": "did:example:123",
        "sub": "did:example:456",
        "vc": {
          "@context": [
            "https://www.w3.org/2018/credentials/v1",
            "https://www.w3.org/2018/credentials/examples/v1"
          ],
          "id": "http://example.gov/credentials/3732",
          "type": [
            "VerifiableCredential",
            "UniversityDegreeCredential"
          ],
          "issuer": {
            "id": "did:example:123"
          },
          "issuanceDate": "2020-03-10T04:24:12.164Z",
          "credentialSubject": {
            "id": "did:example:456",
            "degree": {
              "type": "BachelorDegree",
              "name": "Bachelor of Science and Arts"
            }
          }
        },
        "jti": "http://example.gov/credentials/3732",
        "nbf": 1583814252
      },
      "signature": "qSv6dpZJGFybtcifLwGf4ujzlEu-fam_M7HPxinCbVhz9iIJCg70UMeQbPa1ex6BmQ2tnSS7F11FHnMB2bJRAw"
    }

    A.3 加密

    此章节是非规范性的。

    提示

    这些示例仅供参考,建议避免在JWE头文件中泄露不必要的信息。

    Example 38: 通过kid与验证方法关联的JWE
    { // external (all terms in this example)
      "ciphertext": "3SHQQJajNH6q0fyAHmw...",
      "iv": "QldSPLVnFf2-VXcNLza6mbylYwphW57Q",
      "protected": "eyJlbmMiOiJYQzIwUCJ9",
      "recipients": [
        {
          "encrypted_key": "BMJ19zK12YHftJ4sr6Pz1rX1HtYni_L9DZvO1cEZfRWDN2vXeOYlwA",
          "header": {
            "alg": "ECDH-ES+A256KW",
            "apu": "Tx9qG69ZfodhRos-8qfhTPc6ZFnNUcgNDVdHqX1UR3s",
            "apv": "ZGlkOmVsZW06cm9wc3RlbjpFa...",
            "epk": {
              "crv": "X25519",
              "kty": "OKP",
              "x": "Tx9qG69ZfodhRos-8qfhTPc6ZFnNUcgNDVdHqX1UR3s"
            },
            "kid": "did:example:123#zC1Rnuvw9rVa6E5TKF4uQVRuQuaCpVgB81Um2u17Fu7UK"
          }
        }
      ],
      "tag": "xbfwwDkzOAJfSVem0jr1bA"
    }

    B. 架构考虑因素

    B.1 详细架构图

    下图显示了 4. 数据模型, 5. 核心属性, 和 8. 方法, 和 7. 解析之间的关系。 ​

    
  DIDs and DID documents are recorded on a Verifiable Data Registry; DIDs resolve
  to DID documents; DIDs refer to DID subjects; a DID controller controls a DID
  document; DID URLs contains a DID; DID URLs dereferenced to DID document
  fragments or external resources; DID resolver implements resolve function; DID
  URL dereferencer implements dereferencing function; DID method operates a
  Verfiable Data Registry; DID resolver and DID URL dereferencer instruct a DID
  method.
    7 DID 架构的详细概述和基本组件的关系。

    B.2 创建一个DID

    DID的创建过程由每个DID 方法定义。一些DID方法(例如did:key)是纯生成的,这样DIDDID 文档是通过将单个加密材料转换为符合规范的表示形式而生成的。其他 DID 方法可能需要使用可验证数据注册表,其中DIDDID 文档仅在注册完成时才被第三方识别存在,如相应的 DID 方法所定义。其他过程可能由相应的 DID 方法定义。 ​

    B.3 确定DID对象

    DID是一种特定类型的 URI(统一资源标识符),因此DID可以引用任何资源。根据 [RFC3986]: ​

    术语“资源”是泛指任何可以由 URI 标识的内容。[...] 资源不一定可以通过互联网访问。

    资源可以是数字的或物理的,抽象的或具体的。任何可以分配 URI 的资源都可以分配DIDDID引用的资源是DID 对象

    DID 控制者确定DID 对象。预计无法通过查看DID本身来确定DID 对象,因为DIDs通常只对机器有意义,而对人类没有意义。DID不太可能包含任何关于DID 对象的信息,因此关于DID 对象的更多信息只能通过将 DID解析到DID 文档、获取关于DID的可验证凭证或通过DID的其他描述来发现。

    虽然检索到的DID 文档id属性的值必须始终与正在解析的 DID 匹配,但 DID引用的实际资源是否可以随时间变化取决于 DID 方法。例如,允许DID 对象 更改的 DID 方法可用于为特定角色的当前占用者(例如公司的 CEO)生成DID,其中实际占用该角色的人可能因 DID的解析时间而异。 ​

    B.4 引用 DID 文档

    DID 引用DID 对象并解析到DID 文档(通过遵循 DID 方法指定的协议)。 DID 文档不是 DID 对象的单独资源,并且没有与DID分开的 URI。相反,DID 文档是由 DID 控制者 控制的 DID resolution的产物,目的是描述 DID 对象。 ​

    下图所示的图形模型说明了这种区别。

    
Diagram showing a graph model for how DID controllers assign DIDs to refer to
DID subjects and resolve to DID documents that describe the DID subjects.
    Figure 8 一个DID 是由DID 控制者分配的标识符,用于引用DID 对象并解析为描述DID 对象DID 文档DID 文档DID resolution的产物,而不是与 DID 对象不同的单独资源。另请参阅:叙述性描述
    Two filled black circles appear at the top of the diagram, one on the left, labeled "DID Controller", and one on the right, labeled "DID Subject". A rectangle, with lower right corner bent inwards to form a small triangle, appears below, containing the label "DID Document". Arrows extend between these three items, as follows. A solid red arrow points directly from the DID Controller circle, rightwards to the DID Subject circle, labeled "DID" above it in large font, and "Identifies" below it in small italic font. The other arrow labels are also in small italic font. A dotted red arrow, labeled "Resolves to", extends from DID Controller, starting in the same line as the first arrow, then curving downward to point to the DID Document rectangle. A green arrow, labeled "Controls", points directly from DID Controller to DID Document. A green arrow labeled "Controller" points in the opposite direction, from DID Document to DID Controller, making an arc outward to the left of the diagram. A blue arrow, labeled, "Describes" points directly from DID Document to DID Subject.

    B.5 DID文档中的声明(Statements in the DID document)

    DID 文档中的每个属性都是DID 控制者 的声明,用于描述: ​

    DID 文档中唯一必需的属性是id,因此这是保证在DID 文档中的唯一声明。 8通过DIDDID 对象之间的直接链接说明了该声明。

    B.6 发现有关DID对象的更多信息

    发现有关DID 对象 的更多信息的选项取决于DID 文档中存在的属性。如果存在服务属性,则可以从服务端点请求更多信息。例如,通过查询支持可验证凭证的服务端点 ,以获取一个或多个描述 DID 对象的声明(属性)。 ​

    另一种选择是使用 alsoKnownAs 属性(如果它存在于 DID 文档中)。DID 控制者可以使用它来提供引用相同 DID 对象的其他 URI(包括其他DIDs)的列表。解析或解引用这些 URI 可能会产生 DID 对象的其他描述或表示形式,如下图所示。 ​

    
​          Diagram showing a graph model, with an
​          alsoKnownAs property with an arc to another node representing a
​          different resource that dereferences to another description of the
​          DID subject.
​
    Figure 9 一个DID 文档可以使用 alsoKnownAs 属性来断言另一个 URI(包括但不一定是另一个DID)引用相同的DID 对象。另请参阅:叙述性描述(narrative description)
    The diagram contains three small black filled circles, two rectangles with bent corners, arrows between them, and labels, as follows. On the upper left is a circle labeled "DID Controller". On the upper right is a circle labeled "DID Subject". On the lower-middle right is a circle without a label. On the lower right is a rectangle labeled "Description". In the center of the diagram is a rectangle labeled "DID Document". Inside the DID Document rectangle, beneath its label, is two lines of code: "alsoKnownAs: [", and "URI]". A black arrow extends from the second line, to the right, crossing the rectangle border, pointing to the unlabeled circle at the right of the diagram. This arrow is labeled above it in large font, "URI", and below it in italic, "Identifies". A black arrow points from the unlabeled circle downwards to the Description rectangle, labeled "Dereferences to". A blue arrow, labeled "Describes", extends from Description, arcing on the right, pointing up to DID Subject. A blue arrow, also labeled "Describes", points directly from the rectangle, labeled "DID Document", in the center of the diagram, up and to the right to the DID Subject circle. A red arrow, labeled "alsoKnownAs", points from DID Subject down to the unlabeled circle. A red arrow, labeled "DID" above it in large font, and "Identifies" below it in italic font, lies at the top of the image, pointing from DID Controller to DID Subject. A dotted red line starts in the same place but branches off and curves downward to point to the DID Document rectangle at the center of the image. A green arrow, labeled "Controls", points directly from DID Controller to DID Document. Another green arrow points in the opposite direction, labeled "Controller", curving outwards on the left of the image, from DID Document to DID Controller. ​

    B.7 提供 DID对象的表示

    如果DID 对象是可以从互联网检索的数字资源,则DID 方法可以选择构造一个DID URL,该 URL 返回DID 对象 本身的表示形式。例如,需要持久、可加密验证的标识符的数据模式可以分配一个DID,并且传递指定的 DID 参数(请参阅3.2.1 DID 参数)可以用作检索该模式的表示形式的标准方法。 ​

    类似地,如果适用DID 方法支持该功能,则 DID可用于引用可直接从 可验证数据注册表返回的数字资源(例如图像)。 ​

    B.8 为现有Web资源分配DID

    如果网页或任何其他 Web 资源的控制者想要为其分配持久、可加密验证的标识符,则控制器可以为其提供DID。例如,博客托管公司(在其托管公司的域下)托管的博客的作者可以为该博客创建DID。在 DID 文档中,作者可以包含指向博客当前 URL 的 alsoKnownAs属性,例如: ​

    ​ "alsoKnownAs": ["https://myblog.blogging-host.example/home"] ​

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

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

    DID有效地为博客 URL 添加了一层间接寻址。此间接寻址层由作者控制,而不是由外部管理机构(例如博客托管公司)控制。这就是DID 如何有效地充当增强的URN (Uniform Resource Name)(统一资源名称)的方式——信息资源的持久标识符,其网络位置可能会随着时间的推移而发生变化。 ​

    B.9 DID控制者和DID对象之间的关系

    为避免混淆,根据DID 对象DID 控制者的关系,将DID 对象分为两个不相交的集合是有帮助的。

    B.9.1 集合#1:DID对象是DID控制者

    10中显示的第一种情况是DID 对象也是 DID controller的常见情况。这是个人或组织创建DID以进行自我识别的情况。

    
Diagram showing a graph model with an equivalence arc from the DID
subject to the DID controller.
    Figure 10  DID 对象 和 DID 控制者是同一个实体. 参考: 叙述性描述.
    Two small black circles appear in the diagram, one on the upper left, labeled, "DID Controller", and one on the upper right, labeled "DID Subject". A solid red arrow extends from the DID Controller circle to the DID Subject circle, labeled "DID" in large bold text above the arrow, and "Identifies" in small italic text beneath the arrow. A dotted red double-ended arrow, labeled "Equivalence", extends between the two circles, forming an arc in the space between and above them. In the lower part of the diagram is a rectangle with bent corner, outlined in black, containing the label "DID Document". Arrows point between this DID Document rectangle and the small black circles for DID Controller and DID Subject, with italic labels, as follows. A blue arrow points from the DID Document to the DID Subject, labeled, "Describes". A green arrow points from the DID Controller to the DID Document, labeled "Controls". A green arrow points from the DID Document to the DID Controller, in an outward arc, labeled, "Controller". A dotted red arrow, labeled "Resolves to", extends from the DID controller starting to the right, branching off from the arrow to the DID Subject, then curving downward to point to the DID Document.

    从图模型的角度来看,即使在10中标识为DID 控制者DID 对象的节点是不同的,它们之间也存在一个逻辑弧来表达语义等价关系。 ​

    B.9.2 集合#2:DID对象不是DID控制者

    第二种情况是DID 对象是与DID 控制者不同的实体。例如,父母为孩子创建和维护 DID的控制权;公司为子公司创建和维护DID的控制权;或者制造商为产品、物联网设备或数字文件创建和维护DID的控制权。 ​

    从图模型的角度来看,与集合1的唯一区别是DID 对象DID 控制者节点之间不存在等价弧关系。

    B.10 多个DID控制者

    一个 DID 文档可能有多个DID 控制者。这可以通过两种方式之一发生。 ​

    B.10.1 独立控制

    在这种情况下,每个DID 控制者都可能自行采取行动,即,每个 DID 控制者都拥有独立更新DID 文档的全部权力。从图模型的角度来看,在此配置中: ​

    • 每个额外的DID 控制者都是另一个不同的图节点(可能由其自己的 DID 标识)。
    • 每个DID 控制者DID 文档之间都存在相同的弧(“控制”和“控制者”)。
    
            Diagram showing three DID controllers each with an independent
            control relationship with the DID document
    Figure 11 可以独立行动的多个独立DID 控制者。另请参阅: 文字说明
    Three black circles appear on the left, vertically, each labeled "DID Controller". From each of these circles, a pair of green arrows extends towards the center of the diagram, to a single rectangle, labeled "DID Document". The rectangle has the lower right corner cut and bent inward to form a small triangle, as if to represent a physical piece of paper with curled corner. Each pair of green arrows consists of one arrow pointing from the black circle to the rectangle, labeled "Controls", and one pointing in the opposite direction, from the rectangle to the black circle, labeled "Controller". From the right of the rectangle extends a blue arrow, labeled, "Describes", pointing to a black circle labeled, "DID Subject".

    B.10.2 组控制

    在组控制的情况下,DID 控制者应以某种方式一起行动,例如在使用需要多个数字签名(“多重签名”)或阈值数量的数字签名(“m-of-n”)的加密算法时。从功能的角度来看,此选项类似于单个DID 控制者,因为尽管 DID 控制者组中的每个 DID 控制者都有自己的图节点,但实际控制会折叠成一个表示DID 控制者组的逻辑图节点,如12所示。 ​

    
Diagram showing three DID controllers together as a single
DID controller group to control a DID document
    Figure 12 DID 控制者组是预期一起行动的多个DID 控制者的组合。另请参阅: 叙述性描述
    On the left are three black filled circles, labeled "DID Controller Group" by a brace on the left. From each of these three circles, a green arrow extends to the center right. These three arrows converge towards a single filled white circle. A pair of horizontal green arrows connects this white circle on its right to a rectangle shaped like a page with a curled corner, labeled "DID Document". The upper arrow points right, from the white circle to the rectangle, and is labeled "Controls". The lower arrow points left, from the rectangle to the white circle, and is labeled "Controller". From the right of the rectangle extends a blue arrow, labeled "Describes", pointing to a black circle, labeled "DID Subject".

    DID 对象是组织、公司、政府机构、社区或其他不受单个人控制的团体时,此配置通常适用。

    B.11 更改DID对象

    DID 文档只有一个DID引用的 DID 对象DID表示为id属性的值。此属性值在DID 文档的生存期内是不可变的。 ​

    但是,DID标记的资源(DID 对象)可能会随着时间的推移而发生变化。这在DID 控制者的专属权限下。有关更多详细信息,请参阅9.16 持久性

    B.12 更改DID控制者

    DID 文档DID 控制者可能会随着时间的推移而发生变化。但是,根据其实现方式,DID 控制者的更改可能不会因 DID 文档本身的更改而变得明显。例如,如果更改是通过更改用于 DID 文档中一个或多个验证方法的基础加密密钥或其他控制的所有权来实现的,则它可能与标准密钥轮换无法区分。 ​

    另一方面,如果更改是通过更改controller属性的值来实现的,那它将是透明的。

    如果验证DID 控制者的更改很重要,建议实施者根据修订后的DID 文档中的验证方法对新的DID 控制者进行身份验证

    C. 修订历史记录

    本节包含自本规范作为 W3C 首次公开工作草案发布以来所做的更改。 ​

    第二次候选推荐以来的更改包括:

    第一次候选推荐以来的更改包括:

    首次公开工作草案以来的更改包括:

    D. 致谢

    工作组向主席 Brent Zundel 和 Dan Burnett 以及 W3C员工联系人 Ivan Herman 表示深切的谢意和衷心的感谢,感谢他们不懈的努力,使工作组能够朝着富有成效的方向前进,并在标准化进程的深水区和危险水域中航行。

    工作组衷心感谢促成本规范制定的各项工作,并向那些为我们的工作带来深远影响的技术和规范的制定者致以诚挚谢意。这其中尤其包括 Phil Zimmerman、Jon Callas、Lutz Donnerhacke、Hal Finney、David Shaw 和 Rodney Thayer 在 20 世纪 90 年代和 21 世纪为 Pretty Good Privacy (PGP)所做的工作。 ​

    2010 年代中期,通过与Jeremie Miller 的 Telehash 项目以及 Dave Longley 和 Manu Sporny 领导的W3C Web Payments 社区组的工作合作,建立了后来成为分布式标识(Decentralized Identifiers)的初步实现。大约一年后,XDI.org 注册工作组 开始探索用分布式技术来取代现有的标识注册(identifier registry)。一些探讨分布式标识概念的首批书面论文可以追溯到 Christopher Allen 召集的最初几次重启信任网络(Rebooting the Web of Trust)研讨会。这项工作促成了 Christopher Allen、Drummond Reed、Les Chasen、Manu Sporny 和 Anil John 之间的重要合作。Anil 看到了这项技术的前景,并拨出了最初的政府资金来探索这一领域。如果没有 Anil John 多年来的支持和指导,分布式标识不太可能取得如今的成就。在“重启信任网络”研讨会上进一步完善后,产生了第一份实施者文档,由 Drummond Reed、Les Chasen、Christopher Allen 和 Ryan Grant 共同编辑。贡献者包括 Manu Sporny、Dave Longley、Jason Law、Daniel Hardman、Markus Sabadello、Christian Lundkvist 和 Jonathan Endersby。这项初步工作随后被合并到 W3C Credentials 社区组,进一步孵化,然后移交给 W3C 分布式标识工作组进行全球标准化。 ​

    本规范的部分工作由美国国土安全部 (US DHS) 科学技术局(Science and Technology Directorate) (合同编号 HSHQDC-16-R00012-H-SB2016-1-002 和 HSHQDC-17-C-00019) 以及美国国土安全部硅谷创新计划 (Silicon Valley Innovation Program)(合同编号 70RSAT20T00000010、70RSAT20T00000029、70RSAT20T00000030、70RSAT20T00000045、70RSAT20T00000003 和 70RSAT20T00000033) 资助。本规范的内容不一定反映美国政府的立场或政策,也不应推断其已获得官方认可。 ​

    本规范的部分工作也得到了欧盟 StandICT.eu 计划的资助,资助合同编号为 CALL05/19。本规范的内容不一定反映欧盟的立场或政策,也不应推断为官方认可。 ​

    本规范的工作也得到了由 Christopher Allen、Shannon Appelcline、Kiara Robles、Brian Weller、Betty Dhamers、Kaliya Young、Kim Hamilton Duffy、Manu Sporny、Drummond Reed、Joe Andrieu 和 Heather Vescent 推动的“重启信任网络(Rebooting the Web of Trust)”社区的支持。本规范的开发也得到了 W3C可验证凭证社群小组 社区小组的支持,该小组由 Kim Hamilton Duffy、Joe Andrieu、Christopher Allen、Heather Vescent 和 Wayne Chang 担任主席。由 Phil Windley、Kaliya Young、Doc Searls 和 Heidi Nobantu Saul 推动的互联网身份研讨会(Internet Identity Workshop)的参与者也通过多次工作会议支持了这项工作,这些会议旨在讨论、改进和教育参与者有关本规范的知识。 ​

    工作组感谢以下个人对本规范做出的贡献(按字母顺序排列,Github 名称以 @ 开头,按姓氏排序):Denis Ah-Kang、Nacho Alamillo、Christopher Allen、Joe Andrieu、Antonio、Phil Archer、George Aristy、Baha、Juan Benet、BigBlueHat、Dan Bolser、Chris Boscolo、Pelle Braendgaard、Daniel Buchner、Daniel Burnett、Juan Caballero、@cabo、Tim Cappalli、Melvin Carvalho、David Chadwick、Wayne Chang、Sam Curren、Hai Dang、Tim Daubenschütz、Oskar van Deventer、Kim Hamilton Duffy、Arnaud Durand、Ken Ebert、Veikko Eeva、@ewagner70、Carson Farmer、Nikos Fotiou、Gabe、Gayan、@gimly-jack、@gjgd、Ryan Grant、Peter Grassberger、Adrian Gropper、Amy Guy、Daniel Hardman、Kyle Den Hartog、Philippe Le Hegaret、Ivan Herman、Michael Herman、Alen Horvat、Dave Huseby、Marcel Jackisch、Mike Jones、Andrew Jones、Tom Jones、jonnycrunch、Gregg Kellogg、Michael Klein、@kdenhartog-sybil1、Paul Knowles、@ktobich、David I. Lehn、Charles E. Lehner、Michael Lodder、@mooreT1881、Dave Longley、Tobias Looker、Wolf McNally、Robert Mitwicki、Mircea Nistor、Grant Noble、Mark Nottingham、@oare、Darrell O'Donnell、Vinod Panicker、Dirk Porsche、Praveen、Mike Prorock、@pukkamustard、Drummond Reed、Julian Reschke、Yancy Ribbens、Justin Richer、Rieks、@rknobloch、Mikeal Rogers、Evstifeev Roman、Troy Ronda、Leonard Rosenthol、Michael Ruminer、Markus Sabadello、Cihan Saglam、Samu、Rob Sanderson、Wendy Seltzer、Mehran Shakeri、Jaehoon (Ace) Shim、Samuel Smith、James M Snell、SondreB、Manu Sporny、@ssstolk、Orie Steele、Shigeya Suzuki、Sammotic Switchyarn、@tahpot、Oliver Terbu、Ted Thibodeau Jr.、Joel Thorstensson、Tralcan、Henry Tsai、Rod Vagg、Mike Varley、Kaliya “Identity Woman” Young、Eric Welton、Fuqiao Xue、@Yue、Dmitri Zagidulin、@zhanb 和 Brent Zundel。 ​

    E. IANA注意事项

    当本规范成为W3C 建议推荐时,本节将提交给互联网工程指导小组 (IESG) 进行审查、批准并在 IANA 注册。 ​

    E.1 应用程序/did+json(application/did+json)

    类型名称:
    application
    子类型名称:
    did+json
    必需参数:
    None
    可选参数:
    None
    编码注意事项:
    请参阅 RFC 8259, section 11.
    安全注意事项:
    请参阅 RFC 8259, section 12 [RFC8259].
    互操作性注意事项:
    不适用
    已发布的规范:
    https://www.w3.org/TR/did-core/
    使用此媒体类型的应用程序:
    任何需要分布式、持续性、加密可验证和可解析的标识符的应用程序。应用程序通常由加密身份系统、去中心化的设备网络和发布或验证W3C 可验证凭证的网站组成。 ​
    附加信息:
    魔术数字:
    不适用
    文件扩展名:
    .didjson
    Macintosh 文件类型代码:
    TEXT
    如需了解更多信息,请联系以下人员和电子邮件地址:
    Ivan Herman <ivan@w3.org>
    预期用途:
    常用
    使用限制:
    作者:
    Drummond Reed, Manu Sporny, Markus Sabadello, Dave Longley, Christopher Allen ​
    变更控制人:
    W3C

    application/did+json 一起使用的片段标识符根据“片段”章节( 片段) 中定义的规则进行处理。

    E.2 应用程序/did+ld+json

    注意: IETF 结构化媒体类型

    此规范在候选推荐(Candidate Recommendation )阶段已收到大量 application/did+ld+json 媒体类型的实现。在 IANA 注册媒体类型application/did+ld+json 时还有待解决多后缀媒体类型( Media Types with Multiple Suffixes)的问题。IETF 媒体类型维护工作组(IETF Media Type Maintenance Working Group)预计将继续开展工作,并将在发布 Media Types with Multiple Suffixes RFC 后不久由 W3C 注册application/did+ld+json 媒体类型。 ​

    类型名称:
    application
    子类型名称:
    did+ld+json
    必需参数:
    None
    可选参数:
    None
    编码注意事项:
    请参阅 RFC 8259, section 11.
    安全注意事项:
    请参阅 JSON-LD 1.1, Security Considerations [JSON-LD11].
    互操作性注意事项:
    不适用
    已发布的规范:
    https://www.w3.org/TR/did-core/
    使用此媒体类型的应用程序:
    任何需要分布式、持续性、加密可验证和可解析的标识符的应用程序。应用程序通常由加密身份系统、去中心化的设备网络和发布或验证W3C可验证凭证的网站组成。 ​
    附加信息:
    魔术数字(s):
    不适用
    文件扩展名:
    .didjsonld
    Macintosh 文件类型代码:
    TEXT
    如需了解更多信息,请联系以下人员和电子邮件地址:
    Ivan Herman <ivan@w3.org>
    预期用途:
    常用
    使用限制:
    作者
    Drummond Reed, Manu Sporny, Markus Sabadello, Dave Longley, Christopher Allen ​
    变更控制人:
    W3C

    application/did+ld+json 一起使用的片段标识符根据与JSON-LD 1.1: application/ld+json media type [JSON-LD11]相关的规则进行处理 ​

    F. 参考引用

    F.1 引用标准

    [INFRA]
    Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
    [JSON-LD11]
    JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/
    [RFC2119]
    Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
    [RFC3552]
    Guidelines for Writing RFC Text on Security Considerations. E. Rescorla; B. Korver. IETF. July 2003. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3552
    [RFC3986]
    Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
    [RFC5234]
    Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. Overell. IETF. January 2008. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
    [RFC7517]
    JSON Web Key (JWK). M. Jones. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7517
    [RFC7638]
    JSON Web Key (JWK) Thumbprint. M. Jones; N. Sakimura. IETF. September 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7638
    [RFC8174]
    Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
    [RFC8259]
    The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259
    [url]
    URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
    [XMLSCHEMA11-2]
    W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/

    F.2 参考文献

    [DID-RESOLUTION]
    Decentralized Identifier Resolution. Markus Sabadello; Dmitri Zagidulin. Credentials Community Group. Draft Community Group Report. URL: https://w3c-ccg.github.io/did-resolution/
    [DID-RUBRIC]
    Decentralized Characteristics Rubric v1.0. Joe Andrieu. Credentials Community Group. Draft Community Group Report. URL: https://w3c.github.io/did-rubric/
    [DID-SPEC-REGISTRIES]
    DID Specification Registries. Orie Steele; Manu Sporny; Michael Prorock. W3C. 28 June 2022. W3C Working Group Note. URL: https://www.w3.org/TR/did-spec-registries/
    [DID-USE-CASES]
    Use Cases and Requirements for Decentralized Identifiers. Joe Andrieu; Phil Archer; Kim Duffy; Ryan Grant; Adrian Gropper. W3C. 17 March 2021. W3C Working Group Note. URL: https://www.w3.org/TR/did-use-cases/
    [DNS-DID]
    The Decentralized Identifier (DID) in the DNS. Alexander Mayrhofer; Dimitrij Klesev; Markus Sabadello. February 2019. Internet-Draft. URL: https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/
    Cryptographic Hyperlinks. Manu Sporny. IETF. December 2018. Internet-Draft. URL: https://tools.ietf.org/html/draft-sporny-hashlink-05
    [IANA-URI-SCHEMES]
    Uniform Resource Identifier (URI) Schemes. IANA. URL: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
    [MATRIX-URIS]
    Matrix URIs - Ideas about Web Architecture. Tim Berners-Lee. December 1996. Personal View. URL: https://www.w3.org/DesignIssues/MatrixURIs.html
    [MULTIBASE]
    The Multibase Encoding Scheme. Juan Benet; Manu Sporny. IETF. February 2021. Internet-Draft. URL: https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-03
    [PRIVACY-BY-DESIGN]
    Privacy by Design. Ann Cavoukian. Information and Privacy Commissioner. 2011. URL: https://iapp.org/media/pdf/resource_center/pbd_implement_7found_principles.pdf
    [RFC4122]
    A Universally Unique IDentifier (UUID) URN Namespace. P. Leach; M. Mealling; R. Salz. IETF. July 2005. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc4122
    [RFC6901]
    JavaScript Object Notation (JSON) Pointer. P. Bryan, Ed.; K. Zyp; M. Nottingham, Ed.. IETF. April 2013. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6901
    [RFC6973]
    Privacy Considerations for Internet Protocols. A. Cooper; H. Tschofenig; B. Aboba; J. Peterson; J. Morris; M. Hansen; R. Smith. IETF. July 2013. Informational. URL: https://www.rfc-editor.org/rfc/rfc6973
    [RFC7230]
    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
    [RFC7231]
    Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
    [RFC8141]
    Uniform Resource Names (URNs). P. Saint-Andre; J. Klensin. IETF. April 2017. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8141
    [VC-DATA-MODEL]
    Verifiable Credentials Data Model v1.1. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel; Kyle Den Hartog. W3C. 3 March 2022. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model/