[=Decentralized identifiers=](DIDs,去中心化标识符)是一种新型标识符,能够实现可验证的去中心化数字身份。[=DID=]可以指代任何主体(例如,人、组织、事物、数据模型、抽象实体等),由[=DID=]的控制者决定。与典型的联合标识符不同,[=DIDs=]的设计使其可以与中心化注册表、身份提供商和证书颁发机构解耦。具体而言,虽然其他方可能被用来帮助发现与[=DID=]相关的信息,但该设计使[=DID=]的控制者能够在不需要任何其他方许可的情况下证明对其的控制。[=DIDs=]是将[=DID subject=]与[=DID document=]关联的[=URIs=],从而实现与该主体相关的可信交互。

每个[=DID document=]可以表达加密材料、[=verification methods=]或[=services=],这些提供了一组机制,使[=DID controller=]能够证明对[=DID=]的控制。[=Services=]使与[=DID subject=]相关的可信交互成为可能。如果[=DID subject=]是信息资源(如数据模型),[=DID=]可能提供返回[=DID subject=]本身的方式。

本文档规定了DID语法、通用数据模型、核心属性、序列化表示、DID操作,以及将DID解析为其所代表资源的过程说明。

W3C去中心化标识符工作组已将本文档发布为W3C候选推荐标准,并请求软件开发者和DID方法规范作者提供旨在测试本文档中所有功能可实现性的实验性实现。

请实现者注意,问题跟踪器中列出的任何未解决的第1、2或3类问题都可能导致规范的变更。

为退出W3C候选推荐标准阶段,W3C DID工作组要求满足以下条件:

  1. 对于可机器测试的规范性声明,每个功能至少有两个合规实现;即当一个[=conforming producer=]实现了某个功能时,至少有两个[=conforming consumers=]能够消费该功能,且对于每个被消费的功能,至少有两个[=conforming producers=]能够生产该功能。
  2. 对于不可机器测试的规范性声明,每个功能至少有两个实现演示。
  3. [[[DID-RESOLUTION]]]规范已满足其W3C候选推荐标准阶段的退出条件。

功能被定义为规范中一个或多个在功能上相关的规范性声明。对于本规范,互操作性被定义为规范性声明(例如涉及数据模型属性及其值的声明)在两个不同的DID方法之间以相同方式被解释。

特定DID方法的解析不在本规范的范围内,由[[[?DID-RESOLUTION]]]规范涵盖。

简介

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

这些全局唯一标识符中的绝大多数不在我们的控制之下。它们由外部权威机构颁发,由这些机构决定它们指代谁或什么,以及何时可以被撤销。它们仅在某些上下文中有用,且仅被我们无法选择的某些机构所认可。它们可能随着某个组织的失败而消失或失效。它们可能不必要地泄露个人信息。在许多情况下,它们可以被恶意第三方欺诈性地复制和声明,这通常被称为"身份盗窃"。

本规范中定义的去中心化标识符(DIDs)是一种新型的全局唯一标识符。它们旨在使个人和组织能够使用他们信任的系统生成自己的标识符。这些新标识符使实体能够通过使用加密证明(如数字签名)进行身份验证来证明对其的控制。

由于去中心化标识符的生成和声明由实体控制,每个实体可以拥有所需数量的DID,以维持其期望的身份、角色和交互的分离。这些标识符的使用可以适当地限定在不同的上下文中。它们支持与要求实体标识自身或其控制事物的其他人、机构或系统的交互,同时控制应该透露多少个人或私密数据,而无需依赖中央权威来保证标识符的持续存在。这些想法在DID用例文档[[DID-USE-CASES]]中进行了探讨。

本规范不预设任何特定的技术或密码学来支撑DID的生成、持久化、解析或解释。例如,实现者可以基于在联合或集中式身份管理系统中注册的标识符来创建去中心化标识符。实际上,几乎所有类型的标识符系统都可以添加对DID的支持。这在集中式、联合式和去中心化标识符的世界之间创建了一个互操作性桥梁。这也使实现者能够设计特定类型的DID以与他们信任的计算基础设施配合工作,例如分布式账本、去中心化文件系统、分布式数据库和点对点网络。

本规范适用于:

除本规范外,读者可能会发现去中心化标识符的用例和需求[[DID-USE-CASES]]文档很有用。

一个简单示例

[=DID=]是一个由三部分组成的简单文本字符串:1)`did` URI方案标识符,2)[=DID method=]的标识符,3)DID方法特定标识符。


展示DID各部分的图示。最左边的字母拼写为蓝色的'did',
上方用水平括号括起,括号上方标注'scheme'。
灰色冒号紧随'did'字母之后。中间的字母拼写为洋红色的'example',
下方用水平括号括起,括号下方标注'DID Method'。
灰色冒号紧随DID Method之后。最后,末尾的字母为绿色的'123456789abcdefghi',
下方用水平括号括起,括号下方标注'DID Method Specific String'。
去中心化标识符(DID)的一个简单示例

上面的示例[=DID=]解析为一个[=DID document=]。[=DID document=]包含与[=DID=]关联的信息,例如以加密方式[=authentication|authenticate=][=DID controller=]的方法。

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    // used to authenticate as did:...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Multikey",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }]
}
      

设计目标

[=Decentralized Identifiers=]是更大系统的组成部分,例如可验证凭证生态系统[[VC-DATA-MODEL]],它影响了本规范的设计目标。去中心化标识符的设计目标概述如下。

目标 描述
去中心化 消除标识符管理中对中心化权威机构或单点故障的需求,包括全局唯一标识符、公共验证密钥、[=services=]和其他信息的注册。
控制 赋予实体(包括人类和非人类)直接控制其数字标识符的能力,无需依赖外部权威机构。
隐私 使实体能够控制其信息的隐私,包括属性或其他数据的最小化、选择性和渐进式披露。
安全 为请求方提供足够的安全性,使其能够依赖[=DID documents=]达到所需的保证级别。
基于证明 使[=DID controllers=]在与其他实体交互时能够提供加密证明。
可发现性 使实体能够发现其他实体的[=DIDs=],以便了解更多关于这些实体的信息或与其交互。
互操作性 使用可互操作的标准,使[=DID=]基础设施能够利用为互操作性而设计的现有工具和软件库。
可移植性 与系统和网络无关,使实体能够在任何支持[=DIDs=]和[=DID methods=]的系统中使用其数字标识符。
简洁性 倾向于精简的简单功能集,使技术更易于理解、实现和部署。
可扩展性 在可能的情况下,支持可扩展性,前提是不严重妨碍互操作性、可移植性或简洁性。

架构概述

本节提供去中心化标识符架构主要组件的基本概述。


DID和DID文档记录在可验证数据注册表中;DID解析为DID文档;DID指代DID主体;DID控制者控制DID文档;DID URL包含DID;DID URL解引用为DID文档片段或外部资源。
DID架构概述及基本组件之间的关系。 另见:叙述性描述

图中出现六个内部标注的形状,它们之间有标注的箭头,如下所示。图的中心是一个标有"DID URL"的矩形,包含小号打字文本"did:example:123/path/to/rsrc"。图的中上方是一个标有"DID"的矩形,包含小号打字文本"did:example:123"。图的左上方是一个标有"DID Subject"的椭圆。图的下方中心是一个标有"DID document"的矩形。左下方是一个标有"DID Controller"的椭圆。图的右侧中间是一个二维渲染的圆柱体,标有"Verifiable Data Registry"。

从"DID URL"矩形的顶部,一个标有"contains"的箭头向上延伸,指向"DID"矩形。从"DID URL"矩形的底部,一个标有"refers, and dereferences, to"的箭头向下延伸,指向"DID document"矩形。从"DID"矩形,一个标有"resolves to"的箭头向下指向"DID document"矩形。从"DID"矩形,一个标有"refers to"的箭头向左指向"DID subject"椭圆。从"DID controller"椭圆,一个标有"controls"的箭头向右指向"DID document"矩形。从"DID"矩形,一个标有"recorded on"的箭头向右下方指向"Verifiable Data Registry"圆柱体。从"DID document"矩形,一个标有"recorded on"的箭头向右上方指向"Verifiable Data Registry"圆柱体。

DID和DID URL
去中心化标识符,即[=DID=],是由三部分组成的[=URI=]:方案`did:`、方法标识符,以及由[=DID method=]指定的唯一的方法特定标识符。[=DIDs=]可解析为[=DID documents=]。[=DID URL=]扩展了基本[=DID=]的语法,以包含其他标准[=URI=]组件,如路径、查询和片段,用于定位特定的[=resource=]—例如,[=DID document=]内的加密公钥,或[=DID document=]外部的[=resource=]。这些概念在[[[#did-syntax]]]和[[[#did-url-syntax]]]中有详细阐述。
DID主体
[=DID=]的主体,按定义,是由[=DID=]标识的实体。[=DID subject=]也可能是[=DID controller=]。任何事物都可以成为[=DID=]的主体:人、群体、组织、事物或概念。这在[[[#did-subject]]]中有进一步定义。
DID控制者
[=DID=]的[=controller=]是有能力—按照[=DID method=]的定义—对[=DID document=]进行更改的实体(人、组织或自主软件)。此能力通常通过控制一组加密密钥来声明,这些密钥由代表控制者行事的软件使用,但也可能通过其他机制来声明。请注意,一个[=DID=]可能有多个控制者,且[=DID subject=]可以是[=DID controller=]或其中之一。此概念在[[[#did-controller]]]中有文档记录。
可验证数据注册表
为了能够解析为[=DID documents=],[=DIDs=]通常记录在某种底层系统或网络上。无论使用何种具体技术,任何支持记录[=DIDs=]并返回生成[=DID documents=]所需数据的系统都称为[=verifiable data registry=]。示例包括[=distributed ledgers=]、去中心化文件系统、各种数据库、点对点网络和其他形式的可信数据存储。此概念在[[[#methods]]]中有进一步阐述。
DID文档
[=DID documents=]包含与[=DID=]关联的信息。它们通常表达[=verification methods=],例如加密公钥,以及与[=DID subject=]交互相关的[=services=]。[=DID document=]支持的通用属性在[[[#core-properties]]]中指定。[=DID document=]可以序列化为字节流(见[[[#representations]]])。[=DID document=]中存在的属性可以根据[[[#methods]]]中概述的适用操作进行更新。
DID方法
[=DID methods=]是创建、解析、更新和停用特定类型[=DID=]及其关联[=DID document=]的机制。[=DID methods=]使用单独的DID方法规范定义,如[[[#methods]]]中所述。
DID解析器和DID解析
[=DID resolver=]是一个系统组件,它以[=DID=]为输入并产生一个合规的[=DID document=]作为输出。此过程称为[=DID resolution=]。解析特定类型[=DID=]的步骤由相关的[=DID method=]规范定义。[=DID resolution=]的过程在[[?DID-RESOLUTION]]中有详细阐述。
DID URL解引用器和DID URL解引用
[=DID URL dereferencer=]是一个系统组件,它以[=DID URL=]为输入并产生一个[=resource=]作为输出。此过程称为[=DID URL dereferencing=]。[=DID URL dereferencing=]的过程在[[?DID-RESOLUTION]]中有详细阐述。

本文档包含含有JSON和JSON-LD内容的示例。其中一些示例包含无效字符,如内联注释(`//`)和使用省略号(`...`)来表示对示例贡献不大的信息。如果实现者希望将这些信息用作有效的JSON或JSON-LD,请注意移除这些内容。

一些示例包含未在本规范中定义的术语,包括属性名和值。这些用注释(`// external (property name|value)`)表示。在[=DID document=]中使用此类术语时,应在DID扩展仓库[[?DID-EXTENSIONS]]中注册,并附带正式定义和JSON-LD上下文的链接。

[=DIDs=]和[=DID documents=]实现的互操作性通过评估实现创建和解析符合本规范的[=DIDs=]和[=DID documents=]的能力来测试。[=DIDs=]和[=DID documents=]的生产者和消费者之间的互操作性通过确保[=DIDs=]和[=DID documents=]的合规性来提供。[=DID method=]规范的互操作性由每个[=DID method=]规范中的细节提供。可以理解的是,正如Web浏览器不需要实现所有已知的[=URI=]方案一样,与[=DIDs=]配合工作的合规软件也不需要实现所有已知的[=DID methods=]。但是,给定[=DID method=]的所有实现都应该对该方法具有互操作性。

conforming DID是[[[#identifier]]]中指定规则的任何具体表达,它符合该节中的相关规范性声明。

conforming DID document是本规范中描述的数据模型的任何具体表达,它符合[[[#data-model]]]和[[[#core-properties]]]中的相关规范性声明。合规文档的序列化格式是确定性的、双向的和无损的,如[[[#representations]]]中所述。

conforming producer是以软件和/或硬件实现的任何算法,它生成[=conforming DIDs=]或[=conforming DID Documents=],并符合[[[#representations]]]中的相关规范性声明。

conforming consumer是以软件和/或硬件实现的任何算法,它消费[=conforming DIDs=]或[=conforming DID documents=],并符合[[[#representations]]]中的相关规范性声明。

conforming DID method是符合[[[#methods]]]中相关规范性声明的任何规范。

目标受众

本规范有两个主要受众:合规DID方法的实现者;以及希望与DID交互和对接的系统和服务的实现者。预期受众包括但不限于软件架构师、数据建模师、应用开发者、服务开发者、测试人员、运维人员和用户体验(UX)专家。参与去中心化身份、可验证凭证和安全存储相关广泛标准工作的其他人员也可能对阅读本规范感兴趣。

术语

本节定义了本规范和[=decentralized identifier=]基础设施中使用的术语。每当这些术语出现在本规范中时,都会包含指向它们的链接。

amplification attack
一类攻击,攻击者试图通过向系统提供小而有效的输入来耗尽目标系统的CPU、存储、网络或其他资源,这些输入产生的破坏性影响的处理成本可能比输入本身高出指数级。
decentralized identifier (DID)
一种全局唯一的持久标识符,不需要中心化注册机构,通常通过加密方式生成和/或注册。DID的通用格式在中定义。特定的[=DID scheme=]在DID method规范中定义。许多(但不是全部)DID方法利用[=distributed ledger technology=](DLT)或某种其他形式的去中心化网络。
DID controller
有能力对[=DID document=]进行更改的实体。一个[=DID=]可能有多个DID控制者。DID控制者可以由[=DID document=]顶层的可选`controller`属性表示。请注意,DID控制者可能就是DID subject
DID delegate
[=DID controller=]通过DID document授予其使用与[=DID=]关联的[=verification method=]权限的实体。例如,控制孩子[=DID document=]的父母可能允许孩子使用其个人设备进行[=authentication|authenticate=]。在这种情况下,孩子是[=DID delegate=]。孩子的个人设备将包含使孩子能够使用[=DID=]进行[=authentication|authenticate=]的私有加密材料。但是,未经父母许可,孩子可能不被允许添加其他个人设备。
DID document
一组数据,能够实现与[=DID subject=]的加密可验证交互。这包括[=DID subject=]或[=DID delegate=]可用于[=authentication|authenticate=]自身并证明其与[=DID=]关联的机制,例如加密公钥。DID文档可能有一个或多个不同的[=representations=],如或W3C [[[DID-EXTENSIONS]]]中所定义。
DID fragment
DID URL中第一个 #字符 (U+0023 NUMBER SIGN之后的部分。DID片段语法与URI片段语法相同。
DID method
关于如何实现特定[=DID method scheme=]的定义。DID方法由DID方法规范定义,该规范指定了创建、解析、更新和停用[=DIDs=]和[=DID documents=]的精确操作。见
DID path
DID URL中以第一个 /字符 (U+002F SOLIDUS开始并包含该字符,到 ?字符 (U+003F QUESTION MARK#字符 (U+0023 NUMBER SIGN 或[=DID URL=]末尾之前(不包含)的部分。DID路径语法与URI路径语法相同。见
DID query
DID URL中第一个 ?字符 (U+003F QUESTION MARK之后并包含该字符的部分。DID查询语法与URI查询语法相同。见
DID resolution
以[=DID=]和一组解析选项作为输入,返回合规[=representation=]的[=DID document=]以及附加元数据的过程。此过程依赖于适用[=DID method=]的"Read"操作。此过程的输入和输出在[[?DID-RESOLUTION]]中定义。
DID resolver
[=DID resolver=]是执行[=DID resolution=]功能的软件和/或硬件组件,以[=DID=]为输入并产生合规的[=DID document=]作为输出。
DID scheme
[=decentralized identifier=]的正式语法。通用DID方案以前缀did:开头,如中所定义。每个[=DID method=]规范定义一个与该特定[=DID method=]配合使用的特定DID方法方案。在特定DID方法方案中,DID方法名称跟在第一个冒号之后并以第二个冒号终止,例如did:example:
DID subject
由[=DID=]标识并由[=DID document=]描述的实体。任何事物都可以成为DID主体:人、群体、组织、物理事物、数字事物、逻辑事物等。
DID URL
[=DID=]加上符合中定义的任何附加语法组件。这包括可选的DID path及其前导 /字符 (U+002F SOLIDUS、 可选的DID query及其前导 ?字符 (U+003F QUESTION MARK、 和可选的DID fragment及其前导 #字符 (U+0023 NUMBER SIGN
DID URL dereferencing
以[=DID URL=]和一组输入元数据为输入,返回一个[=resource=]的过程。该资源可能是DID document加上附加元数据、[=DID document=]中包含的次要资源,或完全在[=DID document=]外部的资源。该过程使用[=DID resolution=]来获取由[=DID URL=]中包含的[=DID=]指示的[=DID document=]。解引用过程然后可以对[=DID document=]执行额外处理,以返回由[=DID URL=]指示的已解引用资源。此过程的输入和输出在[[?DID-RESOLUTION]]中定义。
DID URL dereferencer
对给定[=DID URL=]或[=DID document=]执行[=DID URL dereferencing=]功能的软件和/或硬件系统。
distributed ledger (DLT)
一种非中心化的事件记录系统。这些系统建立了足够的信任,使参与者能够依赖他人记录的数据来做出运营决策。它们通常使用分布式数据库,其中不同节点使用共识协议来确认加密签名交易的排序。随时间推移将数字签名交易相互链接通常使账本的历史实际上不可变。
resource
由[=URI=]标识的事物,如[[RFC3986]]中所定义。类似地,任何资源都可以作为由[=DID=]标识的[=DID subject=]。
representation
[=resource=]的具体表达,如[[RFC9110]]所定义:"旨在反映给定资源的过去、当前或期望状态的信息,其格式可通过协议轻松传达。表示由一组表示元数据和潜在无界的表示数据流组成。"[=DID document=]是能够实现与[=DID subject=]进行加密可验证交互的信息的表示。见
representation-specific entries
[=DID document=]中其含义特定于某个[=representation=]的条目。在中定义。
service
通过一个或多个[=service endpoints=]与[=DID subject=]或关联实体进行通信或交互的方式。示例包括发现服务、代理服务、社交网络服务、文件存储服务和可验证凭证仓库服务。
did service endpoint
一个网络地址,例如HTTP URL,[=services=]在该地址代表[=DID subject=]运行。
Uniform Resource Identifier (URI)
如[[RFC3986]]所定义的万维网上所有资源的标准标识符格式。[=DID=]是一种URI方案类型。
verifiable data registry
一种促进[=decentralized identifiers=]和[=DID documents=]的创建、验证、更新和/或停用的系统。可验证数据注册表也可用于其他加密可验证的数据结构,例如[=verifiable credentials=]。更多信息请参见W3C可验证凭证规范[[VC-DATA-MODEL]]。
verifiable timestamp
可验证时间戳使第三方能够验证数据对象在特定时间点存在,且自该时间点以来未被修改或损坏。如果数据完整性在该时间点之后可能已被合理修改或损坏,则该时间戳不可验证。

除上述术语外,本规范还使用[[INFRA]]规范中的术语来正式定义数据模型。当使用[[INFRA]]术语时,例如stringsetmap,它们直接链接到该规范。

标识符

本节描述了[=DIDs=]和[=DID URLs=]的正式语法。术语"通用"用于区分此处定义的语法与特定[=DID methods=]在各自规范中定义的语法。[=DIDs=]和[=DID URLs=]的创建过程及其时序在[[[#method-operations]]]和[[[#creation-of-a-did]]]中描述。

DID语法

通用[=DID scheme=]是符合[[!RFC3986]]的[=URI=]方案。ABNF定义如下所示,使用[[!RFC5234]]中的语法以及`ALPHA`和`DIGIT`的对应定义。下面ABNF中未定义的所有其他规则名称在[[RFC3986]]中定义。所有[=DIDs=]必须(MUST)符合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 methods=]与[=DID=]语法相关的要求,请参见[[[#method-syntax]]]节。

DID URL语法

[=DID URL=]是特定[=resource=]的网络位置标识符。它可以用于检索[=DID subjects=]的表示、[=verification methods=]、[=services=]、[=DID document=]的特定部分或其他资源。

以下是使用[[!RFC5234]]中语法的ABNF定义。它建立在[[[#did-syntax]]]中定义的`did`方案之上。`path-abempty``query``fragment`组件在[[!RFC3986]]中定义。所有[=DID URLs=]必须(MUST)符合DID URL语法ABNF规则。[=DID methods=]可以进一步限制这些规则,如[[[#method-syntax]]]中所述。

DID URL语法ABNF规则
did-url = did path-abempty [ "?" query ] [ "#" fragment ]
              

虽然分号(`;`)字符可以根据[=DID URL=]语法规则使用,但本规范的未来版本可能将其用作[[?MATRIX-URIS]]中描述的参数子分隔符。为避免未来冲突,开发者应避免使用它。

路径

[=DID path=]与通用[=URI=]路径相同,符合RFC 3986第3.3节中的`path-abempty` ABNF规则。与[=URIs=]一样,路径语义可以由[=DID Methods=]指定,这些方法又可以使[=DID controllers=]进一步特化这些语义。

did:example:123456/path
        

查询

[=DID query=]与通用[=URI=]查询相同,符合RFC 3986第3.4节中的`query` ABNF规则。

did:example:123456?versionId=1
        

敦促实现者在没有专门为此目的设计的规范的情况下,避免比较具有多个查询参数的[=DID URLs=]的等价性。本规范未定义查询参数的规范化规则,且在DID方法规范或应用层定义的任何查询参数规范化规则都不是普遍认可的规则。

片段

[=DID fragment=]语法和语义与通用[=URI=]片段相同,符合RFC 3986第3.5节中的`fragment` ABNF规则。

[=DID fragment=]用作对[=DID document=]或外部[=resource=]的与方法无关的引用。下面显示了一些DID片段标识符的示例。

did:example:123#public-key-1
        
did:example:123#service-5
        

为了最大化互操作性,敦促实现者确保[=DID fragments=]在各[=representations=]之间以相同方式解释(见[[[#representations]]])。例如,虽然JSON Pointer [[?RFC6901]]可以在[=DID fragment=]中使用,但在非JSON [=representations=]中不会以相同方式解释。

片段标识符的附加语义(与本节中的语义兼容并在其基础上分层)在媒体类型描述中指定(见[[[#application-did]]]节)。有关如何解引用[=DID fragment=]的信息,请参见[[[?DID-RESOLUTION]]]规范。

相对DID URL

相对[=DID URL=]是[=DID document=]中任何不以`did:<method-name>:<method-specific-id>`开头的URL值。更具体地说,它是任何不以[[[#did-syntax]]]中定义的ABNF开头的URL值。该URL预期引用同一[=DID document=]中的[=resource=]。相对[=DID URLs=]可以(MAY)包含相对路径组件、查询参数和片段标识符。

解析相对[=DID URL=]引用时,必须(MUST)使用RFC3986第5节:引用解析中指定的算法。基础URI值是与[=DID subject=]关联的[=DID=],见[[[#did-subject]]]。方案是`did`。权限是`<method-name>:<method-specific-id>`的组合,路径查询片段值分别是[[[#path]]]、[[[#query]]]和[[[#fragment]]]中定义的值。

相对[=DID URLs=]通常用于引用[=DID Document=]中的[=verification methods=]和[=services=],而无需使用绝对URL。存储大小是考虑因素的[=DID methods=]可能使用相对URL来减少[=DID documents=]的存储大小。

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [{
    "id": "did:example:123456789abcdefghi#key-1",
    "type": "Multikey", // external (property value)
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }, ...],
  "authentication": [
    // a relative DID URL used to reference a verification method above
    "#key-1"
  ]
}
        

在上面的示例中,相对[=DID URL=]值将被转换为绝对[=DID URL=]值`did:example:123456789abcdefghi#key-1`。

数据模型

本规范定义了一个数据模型,可用于表达[=DID documents=]及其内部数据结构,然后可以将其序列化为具体表达。本节提供了数据模型的高级描述、不同类型属性在数据模型中的表达方式描述,以及扩展数据模型的说明。

[=DID document=]由一个mapentries组成,其中每个条目由一个键/值对组成。[=DID document=]数据模型包含在[[[#core-properties]]]节中指定的属性。

[=DID document=]数据模型中的所有条目键都是strings。所有条目值使用下表中的数据类型之一表达,每种[=representation=]指定每种数据类型的具体序列化格式。

数据类型 注意事项
map 如[[[INFRA]]]中所指定的,一个有限有序的键/值对序列,且没有键出现两次。map有时在[[[INFRA]]]中被称为ordered map
list 如[[[INFRA]]]中所指定的,一个有限有序的项目序列。
set 如[[[INFRA]]]中所指定的,一个不包含相同项目两次的有限有序项目序列。set有时在[[[INFRA]]]中被称为ordered set
datetime 一种日期和时间值,能够无损地表达[[XMLSCHEMA11-2]]中指定的dateTime所有可表达的值。
string 如[[[INFRA]]]中所指定的,一个通常用于表示人类可读语言的代码单元序列。
integer 如[[XMLSCHEMA11-2]]中所指定的没有小数部分的实数。为最大化互操作性,敦促实现者注意RFC8259第6节:数字中关于整数的建议。
double 如[[XMLSCHEMA11-2]]中所指定的带有小数部分的实数,通常用于近似任意实数。为最大化互操作性,敦促实现者注意RFC8259第6节:数字中关于双精度浮点数的建议。
boolean 如[[[INFRA]]]中所定义的,值为true或false。
null 如[[[INFRA]]]中所定义的,用于表示缺少值的值。

由于数据模型是使用[[[INFRA]]]中的术语定义的,可以包含多个项目的属性值,例如listsmapssets,是明确有序的。[[[INFRA]]]中的所有类似列表的值结构都是有序的,无论该顺序是否重要。对于本规范的目的,除非另有说明,mapset的排序不重要,且不期望实现产生或消费确定性排序的值。

可扩展性

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

  1. 为了最大化互操作性,建议(RECOMMENDED)扩展使用[[[?DID-EXTENSIONS]]]仓库。使用此机制用于新属性或其他扩展是唯一指定的确保两种不同[=representations=]能够协同工作的机制。
  2. [=Representations=]可以(MAY)定义其他可扩展性机制,包括不需要使用[[[?DID-EXTENSIONS]]]仓库的机制。此类扩展机制应该(SHOULD)支持无损转换为任何其他合规[=representation=]。[=representation=]的扩展机制应该(SHOULD)定义所有属性和[=representation=]语法到[=DID document=] 数据模型及其类型系统的映射。

两个特定实现总是可以带外同意使用未记录在[[[?DID-EXTENSIONS]]]仓库中的相互理解的扩展或[=representation=];此类实现与更大生态系统之间的互操作性将不太可靠。

核心属性

[=DID=]与一个[=DID document=]关联,后者是[[[CID]]]中定义的[=controlled identifier document=]的扩展。[=DID documents=]使用数据模型表达,可以序列化为表示。以下各节定义了[=DID document=]中的属性,包括这些属性是必需的还是可选的。这些属性描述了[=DID subject=]与属性值之间的关系。

下表包含本规范定义的核心属性的参考性引用,包括预期值及其是否必需。表中的属性名称链接到每个属性的规范性定义和更详细描述。

属性名称`id`、`type`和`controller`可以出现在不同类型的[=maps=]中,约束条件可能有所不同。例如,[=DID document=]顶层的`id`必须是DID,而`service` [=map=]中的`id`可以是URL。

属性 是否必需? 值约束 定义
`id` 符合[[[#did-syntax]]]节中定义规则的string [[[#did-subject]]]节。
`controller` 一个string或一个set(由符合[[[#did-syntax]]]节中定义规则的strings组成)。 [[[#did-controller]]]节。
`alsoKnownAs` 一个set(由符合URL语法或[[[#did-syntax]]]节的strings组成)。 [[[CID]]]规范的第2.1.3节:Also Known As
`service` 一个由[=service=] maps组成的set [[[CID]]]规范的第2.1.4节:Services
`verificationMethod` 一个由[=verification method=] maps组成的set [[[#verification-methods]]]节。
`authentication` 一个set,其中每个元素是符合[[[#did-syntax]]]节中定义规则的string,或符合[[[#verification-methods]]]节中[=verification methods=]规则的map [[[CID]]]规范的第2.3.1节:Authentication和[[[#verification-methods]]]节。
`assertionMethod` 一个set,其中每个元素是符合[[[#did-syntax]]]节中定义规则的string,或符合[[[#verification-methods]]]节中[=verification methods=]规则的map [[[CID]]]规范的第2.3.2节:Assertion和[[[#verification-methods]]]节。
`keyAgreement` 一个set,其中每个元素是符合[[[#did-syntax]]]节中定义规则的string,或符合[[[#verification-methods]]]节中[=verification methods=]规则的map [[[CID]]]规范的第2.3.3节:Key Agreement和[[[#verification-methods]]]节。
`capabilityInvocation` 一个set,其中每个元素是符合[[[#did-syntax]]]节中定义规则的string,或符合[[[#verification-methods]]]节中[=verification methods=]规则的map [[[CID]]]规范的第2.3.4节:Capability Invocation和[[[#verification-methods]]]节。
`capabilityDelegation` 一个set,其中每个元素是符合[[[#did-syntax]]]节中定义规则的string,或符合[[[#verification-methods]]]节中[=verification methods=]规则的map [[[CID]]]规范的第2.3.5节:Capability Delegation和[[[#verification-methods]]]节。

验证方法属性

属性 是否必需? 值约束 定义
`id` 符合[[[#did-url-syntax]]]中规则的string [[[CID]]]规范的第2.1.1节:Subjects和[[[#identifiers]]]节。
`type` 一个string [[[CID]]]规范的第2.2节:Verification Methods
`controller` 符合[[[#did-syntax]]]中规则的string [[[CID]]]规范的第2.2节:Verification Methods
`publicKeyMultibase` 符合Multibase编码公钥的string [[[CID]]]规范的第2.2.2节:Multikey
publicKeyJwk 表示JSON Web Key的map [[[CID]]]规范的第2.2.3节:JsonWebKey

服务属性

属性 是否必需? 值约束 定义
`id` 符合[[[URL]]]标准或[[[#did-syntax]]]节规则的string [[[CID]]]规范的第2.1.1节:Subjects
`type` 一个string或一个set(由strings组成)。 [[[CID]]]规范的第2.1.4节:Services
`serviceEndpoint` 单个string、单个map,或由一个或多个strings和/或maps组成的set。每个string值必须(MUST)是符合[[[URL]]]的有效URL。 [[[CID]]]规范的第2.1.4节:Services

标识符

本节描述了[=DID documents=]中包含[=DID subjects=]和[=DID controllers=]标识符的机制。

DID主体

特定[=DID subject=]的[=DID=]使用[=DID document=]中的`id`属性表达。此属性在[[[CID]]]规范的第2.1.1节:Subjects中定义,并由本规范扩展以包含[[[#did-syntax]]]节中定义的[=decentralized identifiers=]。

{
  "id": "did:example:123456789abcdefghijk"
}
        

[=DID method=]规范可以创建[=DID document=]的中间表示,例如当[=decentralized identifier=]在[=verifiable data registry=]中注册时,或当[=DID resolver=]执行[=DID resolution=]时。这些中间表示可能不包含`id`值,或可能包含某些`id`属性的临时值。一旦[=DID document=]完全解析,最终的`id`值将被确定并替换整个[=DID document=]中的临时值。

DID控制者

[=DID controller=]是被授权对[=DID document=]进行更改的实体。此属性在[[[CID]]]规范的第2.1.2节:Controllers中定义,并由本规范扩展以包含[[[#did-syntax]]]节中定义的DID。授权[=DID controller=]的过程由[=DID method=]定义。

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "controller": "did:example:bcehfew7h32f32h7af3"
}
        

标识符限制

在[=DID document=]中用于标识[=DID subject=]或[=DID Controller=]的标识符不能使用查询参数或片段标识符。敦促实现者特别注意[[[#did-syntax]]]节中的允许字符列表,该列表明确了此要求;该语法不包括`?`字符也不包括`#`字符。这与[=DID document=]中用于标识[=verification method=]或[=service=]的标识符不同,后者遵循[[[#did-url-syntax]]]节中的语法规则,允许使用查询参数和片段标识符。即便如此,在为[=DID=]生态系统制作的长期规范标识符中使用查询参数是不鼓励的,因为这可能增加[=DID resolution=]软件的复杂性,并可能导致更大的安全攻击面。片段标识符也预期在特定[=DID document=]中是唯一的,且不鼓励实现者重复使用它们来在不同时间引用不同的[=resources=],例如同一[=DID document=]中的两个不同[=verification methods=]。

验证方法

[=DID document=]可以表达[=verification methods=],如[[[CID]]]的第2.2节:Verification Methods中所定义,并附加以下限制:(a) `id`值必须(MUST)符合[[[#did-url-syntax]]]节或[[[#relative-did-urls]]]节,(b) `controller`值必须(MUST)符合[[[#did-syntax]]]节。请参见[[[CID]]]规范的第2.2节:Verification Methods以了解[=verification methods=]的描述。

验证关系

[=DID document=]可以表达[=verification relationships=],如[[[CID]]]规范的第2.3节:Verification Relationships中所定义。请参见[[[CID]]]规范的第2.3节:Verification Relationships以了解[=verification methods=]的描述。

服务

[=DID document=]可以表达[=services=],如[[[CID]]]规范的第2.1.4节:Services中所定义。[=services=]中使用的标识符可以根据[[[#did-syntax]]]节或[[[#did-url-syntax]]]节表达。请参见[[[CID]]]规范的第2.1.4节:Services以了解[=services=]的描述。

表示

本规范中[=DID document=]的具体序列化称为[=representation=]。[=representation=]通过称为production的过程将数据模型序列化而创建。[=representation=]通过称为consumption的过程转换为数据模型生产消费过程使信息能够从一种[=representation=]转换为另一种。本规范定义了一种用于JSON的[=representation=],它也兼容执行JSON-LD处理的处理器。以下各节定义了[=production=]和[=consumption=]的通用规则,以及JSON [=representation=]。

生产和消费

除本规范中定义的[=representations=]外,实现者可以使用其他[=representations=],前提是每种此类[=representation=]都被正确指定(包括可互操作处理未列在DID扩展仓库[[?DID-EXTENSIONS]]中属性的规则)。更多信息请参见[[[#extensibility]]]。

所有[=representations=]的要求如下:

  1. [=representation=]必须(MUST)为[[[#data-model]]]中指定的所有数据类型定义确定性的生产和消费规则。
  2. [=representation=]必须(MUST)与IANA注册的媒体类型唯一关联。
  3. [=representation=]必须(MUST)为其媒体类型定义符合[[[#fragment]]]中定义的片段处理规则的片段处理规则。
  4. [=representation=]应该(SHOULD)使用数据模型数据类型的词汇表示。例如,JSON和JSON-LD使用XML Schema `dateTime`词汇序列化来表示[=datetimes=]。[=representation=]可以(MAY)选择使用不同的词汇序列化来序列化数据模型数据类型,只要[=consumption=]过程返回数据模型时是无损的。例如,一些基于CBOR的[=representations=]使用整数表示自Unix纪元以来的秒数来表达[=datetime=]值。
  5. [=representation=]可以(MAY)定义[=representation-specific entries=],这些条目存储在[=representation-specific entries=] map中,用于[=production=]和[=consumption=]过程。这些条目在消费或生产时使用,以帮助确保无损转换。
  6. 为了最大化互操作性,[=representation=]规范作者应该(SHOULD)在DID扩展仓库[[?DID-EXTENSIONS]]中注册其[=representation=]。

所有[=conforming producers=]的要求如下:

  1. [=conforming producer=]必须(MUST)将[=DID document=] 数据模型和[=representation-specific entries=] map作为[=production=]过程的输入。[=conforming producer=]可以(MAY)接受额外选项作为[=production=]过程的输入。
  2. [=conforming producer=]必须(MUST)使用[=representation=]的数据类型处理规则来序列化[=DID document=] 数据模型中的所有条目,以及[=representation-specific entries=] map中没有针对正在生产的[=representation=]的显式处理规则的条目,并在[=production=]过程完成后返回序列化结果。
  3. [=conforming producer=]必须(MUST)在[=production=]过程完成后返回与[=representation=]关联的媒体类型string
  4. 合规生产者不得(MUST NOT)生产不合规的[=DIDs=]或[=DID documents=]。

所有[=conforming consumers=]的要求如下:

  1. [=conforming consumer=]必须(MUST)将[=representation=]和媒体类型string作为[=consumption=]过程的输入。[=conforming consumer=]可以(MAY)接受额外选项作为[=consumption=]过程的输入。
  2. [=conforming consumer=]必须(MUST)使用媒体类型输入string确定[=DID document=]的[=representation=]。
  3. [=conforming consumer=]必须(MUST)检测所有已知[=representations=]中的任何[=representation-specific entry=],并将该条目放入[=representation-specific entries=] map中,该map在[=consumption=]过程完成后返回。所有已知[=representation-specific entries=]的列表可在DID扩展仓库[[?DID-EXTENSIONS]]中获得。
  4. [=conforming consumer=]必须(MUST)使用[=representation=]的数据类型处理规则将所有没有针对正在消费的[=representation=]的显式处理规则的[=non-representation-specific entries=]添加到[=DID document=] 数据模型中,并在[=consumption=]过程完成后返回[=DID document=]数据模型。
  5. 合规消费者在消费不合规的[=DIDs=]或[=DID documents=]时必须(MUST)产生错误。

展示数据模型的表示如何被生产和消费的图示,包括JSON和JSON-LD。
表示的生产和消费。 另见:叙述性描述

图的左上象限包含一个灰色虚线轮廓的矩形,其中包含两个蓝色轮廓的矩形,一上一下。上面较大的矩形标注为蓝色的"Core Properties",并包含以下INFRA表示法:

«[
  "id" → "example:123",
  "verificationMethod" → « «[
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Multikey",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
    ]» »,
  "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.1" ]»
        

从灰色轮廓矩形,三对箭头延伸到三个不同的黑色轮廓矩形,一个在图的右上方,一个在右下方,一个在左下方。每对箭头由一个从灰色轮廓矩形指向相应黑色轮廓矩形的蓝色箭头(标有"produce")和一个指向相反方向的红色箭头(标有"consume")组成。右上方的黑色轮廓矩形标有"application/did+cbor",包含十六进制数据。右下方的矩形标有"application/did",包含以下JSON数据:

{
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Multikey",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }],
  "authentication": [
    "did:example:123#keys-1"
  ]
}
        

左下方的矩形标有"application/did",包含以下JSON-LD数据:

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

期望实现通过对源表示使用消费规则(生成数据模型),然后使用生产规则将数据模型序列化为目标表示,或使用产生相同目标表示的任何其他机制,来实现[=representations=]之间的转换。

JSON

本节定义JSON [=representation=]的[=production=]和[=consumption=]规则。

生产

[=DID document=]、DID文档数据结构和[=representation-specific entries=] map必须(MUST)根据以下[=production=]规则序列化为JSON [=representation=]:

数据类型 JSON表示类型
map 一个JSON Object,其中每个条目作为JSON Object的成员序列化,条目键作为JSON String成员名,条目值根据本表中定义的类型序列化。
list 一个JSON Array,列表中的每个元素按顺序根据本表中定义的类型作为数组的值序列化。
set 一个JSON Array,集合中的每个元素按顺序根据本表中定义的类型作为数组的值添加。
[=datetime=] 一个JSON String,序列化为归一化到UTC 00:00:00且没有亚秒小数精度的XML Datetime。例如:`2020-12-20T19:17:47Z`。
string 一个JSON String
[=integer=] 一个没有小数或分数部分的JSON Number
[=double=] 一个带有小数和分数部分的JSON Number
boolean 一个JSON Boolean
null 一个JSON null literal

建议所有创建生产JSON [=representations=]的[=conforming producers=]的实现者确保其算法与[[INFRA]]规范中的JSON序列化规则以及JSON [[RFC8259]]规范中的关于数字精度的建议保持一致。

[=DID document=]的所有条目必须(MUST)包含在根JSON Object中。条目可以(MAY)包含额外的数据子结构,需遵循上述列表中的值表示规则。在序列化[=DID document=]时,[=conforming producer=]必须(MUST)向下游应用程序指定`application/did`媒体类型。

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Multikey",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }]
}
      

消费

[=DID document=]和DID文档数据结构的JSON [=representation=]必须(MUST)根据以下[=consumption=]规则反序列化为数据模型

JSON表示类型 数据类型
JSON Object 一个map,其中JSON Object的每个成员作为条目添加到map中。每个条目键设置为JSON Object成员名。每个条目值通过根据本表中定义的JSON表示类型转换JSON Object成员值来设置。由于JSON Objects未指定顺序,因此不保证插入顺序。
JSON Array(当数据模型条目值为list或未知时) 一个list,其中JSON Array的每个值按顺序添加到列表中,根据本表中定义的数组值的JSON表示类型进行转换。
JSON Array(当数据模型条目值为set时) 一个set,其中JSON Array的每个值按顺序添加到集合中,根据本表中定义的数组值的JSON表示类型进行转换。
JSON String(当数据模型条目值为[=datetime=]时) 一个[=datetime=]。
JSON String(当数据模型条目值类型为[=string=]或未知时) 一个string
没有小数或分数部分的JSON Number 一个[=integer=]。
带有小数和分数部分的JSON Number,或当条目值为[=double=]时(无论是否包含分数部分) 一个[=double=]。
JSON Boolean 一个boolean
JSON null literal 一个null值。

建议所有创建[=conforming producers=]或[=conforming consumers=]的实现者确保其算法与[[INFRA]]规范中的JSON转换规则以及JSON [[RFC8259]]规范中的关于数字精度的建议保持一致。

如果媒体类型信息可供[=conforming consumer=]使用且媒体类型值为`application/did`,则正在消费的数据结构是[=DID document=],根元素必须(MUST)是JSON Object,其中对象的所有成员都是[=DID document=]的条目。消费根元素不是JSON Object的[=DID document=]的JSON [=representation=]的[=conforming consumer=]必须(MUST) report an error.

JSON-LD处理器

[[JSON-LD11|JSON-LD]]是一种基于JSON的格式,用于序列化关联数据。预期某些实现将使用标准JSON-LD处理算法处理[=DID documents=]。为了最大化互操作性,强烈建议实现者确保不阻止使用符合标准的库进行JSON-LD处理。无论是否执行使用符合标准库的JSON-LD处理,[=DID document=]的语义都是相同的。语义上的任何差异都是实现或DID方法规范中的错误。

要进行JSON-LD处理,必须(MUST)根据[[[JSON-LD11]]]规范中指定的规则指定`@context`属性。

@context
JSON-LD上下文是一个string或一个包含strings和/或ordered maps任意组合的list

[=DID document=]、DID文档数据结构和[=representation-specific entries=] map必须(MUST)根据[[[#json]]]中定义的JSON [=representation=] [=production=]规则序列化为JSON [=representation=]。

除使用JSON [=representation=] [=production=]规则外,生产必须(MUST)包含`@context`条目。`@context`的序列化值必须(MUST)是JSON String `https://www.w3.org/ns/did/v1.1`,或一个JSON Array(其中第一项是JSON String `https://www.w3.org/ns/did/v1.1`,后续项根据JSON [=production=]规则序列化)。

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  ...
}
        
{
  "@context": [
    "https://www.w3.org/ns/did/v1.1",
    "https://did-method-extension.example/v1"
  ],
  ...
}
        

建议所有创建生产或消费旨在作为JSON-LD处理的[=representations=]的[=conforming consumers=]的实现者确保其算法生成有效的[[JSON-LD11|JSON-LD]]文档。无效的JSON-LD文档将导致JSON-LD处理器停止并报告错误。

为实现跨不同[=representations=]的互操作性,所有JSON-LD上下文及其术语应该(SHOULD)在[[[?DID-EXTENSIONS]]]仓库中注册。

生成JSON-LD [=representation=]的[=conforming producer=]不应该(SHOULD NOT)生产包含未通过`@context`定义的术语的[=DID document=],因为[=conforming consumers=]预期会移除未知术语。在序列化[=DID document=]的JSON-LD [=representation=]时,[=conforming producer=]必须(MUST)向下游应用程序指定`application/did`媒体类型。

处理JSON-LD [=representation=]的[=Conforming consumers=]应该(SHOULD)从[=DID document=]中丢弃所有未通过`@context`定义的术语。

远程资源完整性

实现必须(MUST)将位于`https://www.w3.org/ns/did/v1.1`的基础上下文值视为已检索;以下值是基础上下文文件的十六进制编码SHA2-256摘要值:。可以通过在现代Unix命令行界面中运行以下命令来确认上述加密摘要:`curl -s https://www.w3.org/ns/did/v1.1 | openssl dgst -sha256`。

警告实现者,[=DID document=]中引用的其他数据(例如通过URL链接到的资源)默认不受加密保护。确保通过使用永久缓存文件和/或加密哈希为对[=DID document=]安全性至关重要的任何URL提供同类保护,被认为是最佳实践。最终,知道任何链接外部内容的加密摘要使应用程序能够确认内容与[=DID controller=]预期的相同。

本规范中具有关联加密哈希值的文件极不可能更改。但是,如果在规范中发现关键勘误且需要更正以确保生态系统稳定性,则加密哈希值可能会更改。因此,文件的HTTP缓存时间未设置为无限,且建议实现者在检测到加密哈希值更改时检查勘误表。

媒体类型

媒体类型,如[[RFC6838]]中所定义,用于标识表达[=DID document=]所使用的语法以及其他有用的处理指南。

本规范中用于表达数据模型的语法应该(SHOULD)通过媒体类型来标识,并且在定义或使用与[=DID documents=]相关的媒体类型时应该(SHOULD)遵循本节中概述的约定。

有一种与核心数据模型关联的媒体类型,列在[[[#iana-considerations]]]节中:`application/did`。

媒体类型精度

有时,开发者或系统可能使用精度较低的媒体类型来传达[=DID documents=]。使用精度较低的媒体类型的一些原因包括:

  • 当文件扩展名不可用且无法确定媒体类型时,Web服务器默认使用`text/plain`或`application/octet-stream`。
  • 开发者添加的文件扩展名导致媒体类型的精度低于文件内容。例如,`.json`可能导致`application/json`的媒体类型,而`.jsonld`可能导致`application/ld+json`的媒体类型。
  • 协议要求特定事务使用精度较低的媒体类型;例如,使用`application/json`而非`application/did`。

当可以从有效载荷中确定预期的媒体类型时,不鼓励实现者引发错误,前提是所使用的媒体类型在给定协议中是可接受的。例如,如果应用程序仅接受符合`application/did`媒体类型规则的有效载荷,但有效载荷被标记为精度较低的`application/json`或`application/ld+json`,应用程序可以执行以下步骤来确定有效载荷是否也符合精度较高的媒体类型:

  1. 将有效载荷解析为JSON文档。
  2. 确保`@context`属性的第一个元素匹配`https://www.w3.org/ns/did/v1.1`。
  3. 如果JSON文档包含顶级`id`属性,其中包含符合[[[#did-syntax]]]节中规则的标识符,则假定为`application/did`媒体类型。

尽可能建议实现者对本规范定义的所有有效载荷使用最精确的(最高精度的)媒体类型。还建议实现者认识到,标记为精度较低的媒体类型的有效载荷并不意味着该有效载荷不满足标记为精度较高类型所需的规则。同样,标记为精度较高的媒体类型的有效载荷也不意味着该有效载荷将满足与该媒体类型相关的要求。无论其关联的媒体类型如何,有效载荷的接收者都应执行适当的检查,以确保有效载荷符合其在给定系统中使用的要求。

HTTP客户端和服务器在`Accept:`头中以及指示内容类型时使用与[=DID documents=]关联的媒体类型。警告实现者,HTTP服务器可能会忽略`Accept:`头并返回其他内容类型,或返回错误代码,例如`415 Unsupported Media Type`(不支持的媒体类型)。

方法

[=conforming DID method=]定义了实现者如何实现本规范所描述的功能。[=DID methods=]通常与特定的[=verifiable data registry=]相关联。新的[=DID methods=]在其自己的规范中定义,以实现相同[=DID method=]不同实现之间的互操作性。

从概念上讲,本规范与[=DID method=]规范之间的关系类似于IETF通用[=URI=]规范[[?RFC3986]]与特定[=URI=]方案[[?IANA-URI-SCHEMES]]之间的关系,例如`http`方案[[?RFC9110]]。除了定义特定的[=DID scheme=]外,[=DID method=]规范还定义了使用特定类型的[=verifiable data registry=]创建、解析、更新和停用[=DIDs=]和[=DID documents=]的机制。它还记录了与[=DIDs=]相关的所有实现考虑因素以及安全和隐私考虑因素。

本规范规定了编写[=DID method=]规范的要求。

方法语法

所有[=DID method=]规范在定义方法特定的DID语法时的要求如下:

  1. [=DID method=]规范必须(MUST)定义恰好一种方法特定的[=DID scheme=],该方案由[[[#did-syntax]]]中`method-name`规则指定的恰好一个方法名称标识。
  2. [=DID method=]规范必须(MUST)指定如何生成[=DID=]的`method-specific-id`组件。
  3. [=DID method=]规范必须(MUST)定义`method-specific-id`值的大小写敏感性和规范化方式。
  4. `method-specific-id`值必须(MUST)在[=DID method=]内唯一。`method-specific-id`值本身可能是全局唯一的。
  5. 由[=DID method=]生成的任何[=DID=]必须(MUST)是全局唯一的。
  6. 为减少`method-name`冲突的可能性,[=DID method=]规范应该(SHOULD)在DID扩展仓库[[?DID-EXTENSIONS]]中注册。
  7. [=DID method=]可以(MAY)定义多种`method-specific-id`格式。
  8. `method-specific-id`格式可以(MAY)包含冒号。冒号的使用必须(MUST)在语法上符合`method-specific-id` ABNF规则。
  9. [=DID method=]规范可以(MAY)为[=DID paths=]指定比[[[#path]]]中通用规则更严格的ABNF规则。
  10. [=DID method=]规范可以(MAY)为[=DID queries=]指定比本节中通用规则更严格的ABNF规则。
  11. [=DID method=]规范可以(MAY)为[=DID fragments=]指定比本节中通用规则更严格的ABNF规则。

`method-specific-id`中冒号的含义完全是方法特定的。冒号可以被[=DID methods=]用于建立层次分区的命名空间、标识[=verifiable data registry=]的特定实例或部分,或用于其他目的。建议实现者避免假设与冒号相关的任何可通用于所有[=DID methods=]的含义或行为。

方法操作

所有[=DID method=]规范在定义方法操作时的要求如下:

  1. [=DID method=]规范必须(MUST)定义如何执行授权以执行所有操作,包括任何必要的加密过程。
  2. [=DID method=]规范必须(MUST)指定[=DID controller=]如何创建[=DID=]及其关联的[=DID document=]。
  3. [=DID method=]规范必须(MUST)指定[=DID resolver=]如何使用[=DID=]来解析[=DID document=],包括[=DID resolver=]如何验证响应的真实性。
  4. [=DID method=]规范必须(MUST)指定什么构成对[=DID document=]的更新,以及[=DID controller=]如何更新[=DID document=],或者声明不可能进行更新。
  5. [=DID method=]规范必须(MUST)指定[=DID controller=]如何停用[=DID=],或者声明不可能进行停用。

执行授权以进行操作的一方的权限是特定于[=DID method=]的。例如,[=DID method=]可能—

在执行方法操作时,[=DID method=]可以使用其需要的任何数据结构,包括中间的、部分的或临时的[=DID documents=],只要它们保持在DID方法内部,且方法操作返回的DID文档完全合规,如[[[#conformance]]]中所定义。

安全要求

所有[=DID method=]规范在编写安全考虑节时的要求如下:

  1. [=DID method=]规范必须(MUST)遵循RFC3552:编写安全考虑节中提供的所有指南和规范性语言,适用于[=DID method=]规范中定义的[=DID=]操作。
  2. 安全考虑节必须(MUST)记录[=DID method=]规范中定义的[=DID=]操作的以下攻击形式:窃听、重放、消息插入、删除、修改、拒绝服务、[=amplification=]和中间人攻击。其他已知的攻击形式也应该(SHOULD)记录。
  3. 安全考虑节必须(MUST)讨论残余风险,例如相关协议受损、不正确实现或部署威胁缓解后密码学方面的风险。
  4. 安全考虑节必须(MUST)为[[[#method-operations]]]节要求的所有操作提供完整性保护和更新身份验证。
  5. 如果涉及身份验证,特别是用户-主机身份验证,则必须(MUST)清楚记录身份验证方法的安全特性。
  6. 安全考虑节必须(MUST)讨论用于证明[=DIDs=]被唯一分配的策略机制。
  7. 必须(MUST)讨论方法特定的端点身份验证。当[=DID methods=]使用具有不同网络拓扑的[=DLTs=]时(有时作为轻节点瘦客户端实现以减少所需的计算资源),必须(MUST)讨论[=DID method=]实现可用的拓扑的安全假设。
  8. 如果协议包含加密保护机制,[=DID method=]规范必须(MUST)清楚指出数据的哪些部分受到保护以及受到什么保护,并且应该(SHOULD)给出加密保护易受何种攻击的指示。一些示例包括仅完整性、机密性和端点身份验证。
  9. 应保密的数据(密钥材料、随机种子等)应该(SHOULD)明确标注。
  10. [=DID method=]规范应该(SHOULD)解释并指定[=DID documents=]上签名的实现(如适用)。
  11. 当[=DID methods=]使用点对点计算资源时(如所有已知的[=DLTs=]),应该(SHOULD)讨论这些资源的预期负担与拒绝服务的关系。
  12. 引入新的身份验证[=service=]类型的[=DID methods=](如[[[#services]]]中所述)应该(SHOULD)考虑所支持的身份验证协议的安全要求。

隐私要求

所有[=DID method=]规范在编写隐私考虑节时的要求为:

  1. [=DID method=]规范的隐私考虑节必须(MUST)讨论[[?RFC6973]]第5节中可能以方法特定方式适用的任何子节。需考虑的子节包括:监视、存储数据泄露、未经请求的流量、错误归因、关联性、身份识别、二次使用、披露和排斥。

安全考虑

本节包含各种安全考虑,建议使用去中心化标识符的人在将此技术部署到生产环境之前仔细考虑这些问题。敦促读者在阅读本节之前先阅读[[[CID]]]规范的安全考虑节。[=DIDs=]设计为在许多IETF标准使用的威胁模型下运行,该模型记录在[[?RFC3552]]中。本节详细阐述了[[?RFC3552]]中的一些考虑事项,以及[=DID=]架构特有的其他考虑事项。

选择DID解析器

DID扩展仓库[[?DID-EXTENSIONS]]包含[=DID method=]名称及其对应的[=DID method=]规范的信息性列表。实现者需要注意,没有中央权威机构来指定哪个[=DID method=]规范应与特定的[=DID method=]名称一起使用。如果对特定的[=DID resolver=]是否正确实现了[=DID method=]有疑问,可以使用DID规范注册表查找注册的规范并就使用哪个[=DID resolver=]实现做出明智的决定。

不可否认性

在以下情况下支持[=DIDs=]和[=DID document=]更新的不可否认性:

无信任系统中的撤销

无信任系统是指所有信任都来源于可加密证明的断言的系统,更具体地说,是指在确定系统信任时不考虑加密系统之外的元数据的系统。要在无信任系统中验证已被撤销的[=verification method=]的签名或证明,[=DID method=]需要支持`versionId`或`versionTime`中的一个或两个,以及`updated`和`nextUpdate`这两个[=DID document=]元数据属性。当且仅当以下所有条件都为真时,验证者才能验证已撤销密钥的签名或证明:

在愿意接受构成加密输入之外的元数据的系统中,也可以实现类似的信任——但这始终需要仔细判断[=DID document=]的内容在签名事件发生时是否包含预期内容。

DID恢复

恢复是一种被动安全措施,通过该措施,由于丢失设备等原因而失去执行DID操作能力的[=controller=]能够重新获得执行DID操作的能力。

在考虑使用[=DID=]恢复时,以下考虑因素可能有用:

人类友好标识符的角色

[=DIDs=]无需中央注册机构即可实现全局唯一性。这是以人类记忆性为代价的。能够生成全局无歧义标识符的算法会产生对人类没有意义的随机字符串。这种权衡通常被称为佐科三角

在一些用例中,从人类友好标识符出发发现[=DID=]是可取的。例如,自然语言名称、域名或[=DID controller=]的常规地址,如手机号码、电子邮件地址、社交媒体用户名或博客URL。然而,将人类友好标识符映射到[=DIDs=]并以可验证和可信赖的方式进行映射的问题不在本规范的范围之内。

此问题的解决方案在引用本规范的单独规范中定义,例如[[?DNS-DID]]。强烈建议此类规范仔细考虑以下方面:

DID作为增强型URN

如果[=DID controller=]希望,[=DID=]或[=DID URL=]能够充当持久的、与位置无关的资源标识符。这类标识符被归类为统一资源名称(URN),并在[[RFC8141]]中定义。[=DIDs=]是URN的增强形式,为数字资源提供加密安全的、与位置无关的标识符,同时还提供启用检索的元数据。由于[=DID document=]和[=DID=]本身之间的间接关系,[=DID controller=]可以调整资源的实际位置—甚至直接提供资源—而无需调整[=DID=]。此类[=DIDs=]可以明确验证检索到的资源确实是所标识的资源。

打算将[=DID=]用于此目的的[=DID controller=]建议遵循[[RFC8141]]中的安全考虑。特别是:

不可变性

许多网络安全滥用行为依赖于利用现实与理性善意行为者假设之间的差距。[=DID documents=]的不可变性可以提供一些安全益处。各个[=DID methods=]应该考虑消除其不需要的行为或语义的约束。在提供相同功能集的同时,[=DID method=]越锁定,就越不容易被恶意行为者操纵。

举例来说,考虑到对[=DID document=]的单次编辑可以更改文档根`id`属性以外的任何内容。但是,[=service=]在定义后其`type`是否真的需要更改?或者密钥是否需要更改其值?还是说当对象的某些基本属性发生更改时,最好要求一个新的`id`?恶意接管网站通常的目标是使站点保持其主机名标识符,但在底层被微妙地更改。如果站点的某些属性(例如与其IP地址关联的ASN)被规范要求为不可变的,则异常检测将更容易,攻击将更加困难和昂贵。

对于与全局真相来源绑定的[=DID methods=],始终可以直接、即时查找[=DID document=]的最新版本。然而,缓存层似乎最终可能位于[=DID resolver=]和该真相来源之间。如果确实如此,当[=DID document=]中对象的属性实际上已被微妙更改时,却相信其处于给定状态,可能会招致攻击。如果某些查找是完整[=DID document=]的查找,而其他查找是部分数据(假设了更大的上下文)的查找,这一点尤其重要。

DID文档中的加密数据

由于密码学和计算能力的进步,加密算法可能会失效。建议实现者假设放置在[=DID document=]中的任何加密数据最终可能以明文形式提供给与加密数据相同的受众。如果[=DID document=]是公开的,这一点尤其重要。

加密[=DID document=]的全部或部分不是长期保护数据的适当手段。同样,在[=DID document=]中放置加密数据也不是保护个人数据的适当手段。

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

等价属性

鉴于`equivalentId`和`canonicalId`属性由[=DID methods=]自身生成,适用于[=DID document=]`id`字段中已解析[=DID=]的相同安全性和准确性保证也适用于这些属性。`alsoKnownAs`属性不保证是准确的等价声明,不应在未执行超出[=DID document=]解析范围的验证步骤的情况下予以依赖。

`equivalentId`和`canonicalId`属性表达的是由同一[=DID method=]生产的单个[=DID=]变体的等价断言,其可信度取决于请求方对[=DID method=]以及合规生产者和解析器的信任程度。

`alsoKnownAs`属性允许对不受同一[=DID method=]管理的[=URIs=]进行等价断言,在未执行管理[=DID method=]之外的验证步骤的情况下不能信任。有关其他指导,请参见[[[CID]]]规范中的第2.1.3节:Also Known As

与[=DID document=]中的任何其他安全相关属性一样,依赖[=DID document=]中任何等价声明的各方应防范在完成适当验证后攻击者替换这些属性值的情况。在验证完成后对存储在内存或磁盘中的[=DID document=]的任何写入访问都是一个攻击向量,除非重新验证[=DID document=],否则可能绕过验证。

持久性

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

但是,需要注意的是,在所有启用加密控制证明的[=DID methods=]中,证明控制权的手段始终可以通过转让秘密加密材料来转移给另一方。因此,依赖标识符持久性的系统定期检查以确保标识符实际上仍在预期方的控制之下至关重要。

不幸的是,仅从密码学无法确定与给定[=verification method=]关联的秘密加密材料是否已被泄露。可能的情况是,预期的[=controller=]仍然可以访问秘密加密材料—因此可以作为验证过程的一部分执行控制证明—同时,恶意行为者也可以访问这些相同的密钥或其副本。

因此,加密控制证明应仅作为评估高风险场景所需身份保证级别的一个因素。基于[=DID=]的身份验证比用户名和密码提供了更高的保证,这得益于能够在不在系统之间传输加密秘密的情况下确定对其的控制。但是,它并非万无一失。涉及敏感、高价值或生命攸关操作的场景应酌情使用额外因素。

除了不同[=controllers=]使用可能带来的歧义外,通常无法保证给定的[=DID=]在任何给定时间点是否指向相同的主体。从技术上讲,控制者可以为不同的主体重用[=DID=],而且更微妙的是,主体的精确定义可能会随时间变化或被误解。

例如,考虑一个用于个体经营的[=DID=],它接收用于金融交易的各种凭证。对[=controller=]来说,该标识符指的是企业。随着企业的发展,它最终注册为有限责任公司。[=controller=]继续使用同一个[=DID=],因为对他们来说,[=DID=]指的是这个企业。然而,对于州政府、税务机关和当地市政府来说,[=DID=]不再指向同一实体。含义上的微妙变化对信用提供者或供应商是否重要,必须由他们自己决定。在许多情况下,只要账单得到支付且催收可以执行,这种变化就无关紧要。

由于这些潜在的歧义,[=DIDs=]应被视为上下文相关的有效标识符,而非绝对有效。它们的持久性并不意味着它们指向完全相同的主体,也不意味着它们处于同一[=controller=]的控制之下。相反,需要理解[=DID=]创建的上下文、其使用方式,并考虑其含义可能发生的变化,并采取程序和政策来应对潜在的和不可避免的语义漂移。

评估竞争性考虑因素

本规范不要求或建议使用任何特定类型的[=verifiable data registry=]。不同的用例可能导致不同的要求。不同的要求可能建议具有不同权衡的不同考虑因素。例如,计算(能源使用)、信任(对权威的尊重)、协调(网络带宽)或内存(物理存储)之间的权衡可能对任何给定的用例合适也可能不合适。其他用例可能不会做出相同的权衡。那些需要为其用例考虑不同标准的人可以参考DID方法评估标准,该标准提供评估准则以帮助决策者确定特定[=DID Method=]是否适合其用例。

隐私考虑

由于[=DIDs=]和[=DID documents=]旨在由[=DID controller(s)=]直接管理,因此将隐私设计原则[[PRIVACY-BY-DESIGN]]应用于[=decentralized identifier=]架构的各个方面至关重要。所有七项原则都已在本规范的开发过程中得到应用。本规范中使用的设计不假设存在注册商、托管公司或其他中间服务提供商来推荐或应用额外的隐私保护措施。本规范中的隐私是预防性的,而非补救性的,是嵌入式默认。在阅读本节之前,敦促读者阅读[[[CID]]]规范的隐私考虑节,因为它包含同样适用于[=DIDs=]的更一般性的隐私考虑。本节的其余部分涵盖了特定于[=decentralized identifiers=]的隐私考虑,是[[[CID]]]规范中提供的指导之外的补充。

群体隐私

当[=DID subject=]与群体中的其他人无法区分时,隐私就可以得到保障。当与另一方进行私密互动这一行为本身就是一个可识别的标志时,隐私就大大降低了。

[=DIDs=]和[=DID methods=]需要努力改善群体隐私,特别是对于那些合法地最需要隐私的人。选择默认保留匿名性和假名性的技术和人机界面。为减少数字指纹,在请求方实现中共享通用设置,将线路协议上的协商选项保持在最低限度,使用加密传输层,并将消息填充到标准长度。

示例

DID文档

有关可选扩展和其他验证方法类型,请参见 验证方法类型 [[?DID-EXTENSIONS]]。

这些示例仅供参考,最佳实践是避免将同一[=verification method=]用于多个目的。

  {
    "@context": "https://www.w3.org/ns/did/v1.1",
    "id": "did:example:123",
    "authentication": [
      {
        "id": "did:example:123#z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
      }
    ],
    "capabilityInvocation": [
      {
        "id": "did:example:123#z6Mkvtac9bidSz9bBttzn7Yg3oCDHvMY2FtkFLs6SXRQGdQR",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6Mkvtac9bidSz9bBttzn7Yg3oCDHvMY2FtkFLs6SXRQGdQR"
      }
    ],
    "capabilityDelegation": [
      {
        "id": "did:example:123#z6MknxsdF4CGVxhRNsx6TvXPFczaHEkajKBBwu75uwBmgpom",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MknxsdF4CGVxhRNsx6TvXPFczaHEkajKBBwu75uwBmgpom"
      }
    ],
    "assertionMethod": [
      {
        "id": "did:example:123#z6MkgYhVuWq4hyc7ZKBGhsY7pb5Bc8V6VPXGPG3EPja8JBFR",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MkgYhVuWq4hyc7ZKBGhsY7pb5Bc8V6VPXGPG3EPja8JBFR"
      }
    ]
}
      
{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-0",
      "type": "JsonWebKey",
      "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": "JsonWebKey",
      "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": "JsonWebKey",
      "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": "JsonWebKey",
      "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": "JsonWebKey",
      "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": "JsonWebKey",
      "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": "JsonWebKey",
      "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": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "RSA", // external (property name)
        "e": "AQAB", // external (property name)
        "n": "UkhWaGJGOUZRMTlFVWtKSElBdENGV2hlU1F2djFNRXh1NVJMQ01UNGpWazlraEpLdjhKZU1YV2UzYldIYXRqUHNrZGYyZGxhR2tXNVFqdE9uVUtMNzQybXZyNHRDbGRLUzNVTElhVDFoSkluTUhIeGoyZ2N1Yk82ZUVlZ0FDUTRRU3U5TE8wSC1MTV9MM0RzUkFCQjdRamE4SGVjcHl1c3BXMVR1X0RicXhjU253ZW5kYW13TDUyVjE3ZUtobE80dVh3djJIRmx4dWZGSE0wS21DSnVqSUt5QXhqRF9tM3FfX0lpSFVWSEQxdERJRXZMUGhHOUF6c24zajk1ZC1zYU" // external (property name)
      }
    }
  ]
}
      
{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#key-0",
    "type": "Multikey",
    "controller": "did:example:123",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }, {
    "id": "did:example:123#key-1",
    "type": "Multikey",
    "controller": "did:example:123",
    "publicKeyMultibase": "z6MtTjFFxQ4sQKS2wmozFAn5cxukmM46WR7e2vxfqZQsv4eh"
  }, {
    "id": "did:example:123#key-2",
    "type": "EcdsaSecp256k1VerificationKey2019",
    "controller": "did:example:123",
    "publicKeyMultibase": "zns2aFDq25fEV1NUd3wZ65sgtht4j5QjFW8JCAHdUJfLwfodt"
  }, {
    "id": "did:example:123#key-3",
    "type": "JsonWebKey",
    "controller": "did:example:123",
    "publicKeyJwk": {
      "kty": "EC", // external (property name)
      "crv": "P-256", // external (property name)
      "x": "Er6KSSnAjI70ObRWhlaMgqyIOQYrDJTE94ej5hybQ2M",
      "y": "pPVzCOTJwgikPjuUE6UebfZySqEJ0ZtsWFpj7YSPGEk"
    }
  }]
}
      
        {
          "@context": "https://www.w3.org/ns/did/v1.1",
          "id": "did:example:123",
          "verificationMethod": [
            {
              // A relative DID URL, that will be transformed to the absolute DID URL value did:example:123#key-1
              "id": "#key-1",
              "type": "Ed25519VerificationKey2020",
              "controller": "did:example:123",
              "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
            }
          ],
          "authentication": [
            "#key-1"
          ],
          "capabilityInvocation": [
            "#key-1"
          ],
          "capabilityDelegation": [
            "#key-1"
          ],
          "assertionMethod": [
            // Using relative DID URL #key-1 is equivalent to using the absolute DID URL value did:example:123#key-1
            "did:example:123#key-1"
          ]
      }
      

证明

这些示例仅供参考。有关更多示例,请参见[[[VC-DATA-MODEL]]]。

{
  // external (all terms in this example)
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:key:zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz",
    "image": "data:image/png;base64,iVBORw0KGgo...5CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAA...kJggg==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": "PermanentResidentCard",
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2025-01-04T00:00:00Z",
  "validUntil": "2026-01-04T23:59:59Z",
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-01-04T15:02:36Z",
    "verificationMethod": "did:key:zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz#zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz",
    "cryptosuite": "ecdsa-rdfc-2019",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5CK4DPN7...Jpqwp"
  }
}
      
{  // external (all terms in this example)
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:example:123#key-1",
    "image": "data:image/png;base64,iVBORw0KGgo...5CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAA...kJggg==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": "PermanentResidentCard",
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2025-01-04T00:00:00Z",
  "validUntil": "2026-01-04T23:59:59Z",
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-01-04T15:02:36Z",
    "verificationMethod": "did:example:123#key-1",
    "cryptosuite": "ecdsa-jcs-2019",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5m9akGtdL...6rqBspGQP"
  }
}
      
{  // external (all terms in this example)
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:key:zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE",
    "image": "data:image/png;base64,iVBORw0KGgoAA...CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAAA...3dgg==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": "PermanentResidentCard",
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2025-01-04T00:00:00Z",
  "validUntil": "2026-01-04T23:59:59Z",
  "proof": {
    "type": "DataIntegrityProof",
    "verificationMethod": "did:key:zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE#zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE",
    "cryptosuite": "bbs-2023",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0ChVhQik2d4...pc3N1ZXI"
  }
}
      
{
  // external (all terms in this example)
  "@context": "https://www.w3.org/ns/credentials/v2",
  "type": "VerifiablePresentation",
  // holder did:key is pairwise to the domain to avoid correlation
  "holder": "did:key:z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX",
  "verifiableCredential": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v4rc1"
    ],
    "type": [
      "VerifiableCredential",
      "PermanentResidentCardCredential"
    ],
    "issuer": {
      "id": "did:web:unlinkable.example",
      "image": "data:image/png;base64,iVBORw0KGgoAA...CYII="
    },
    "credentialSubject": {
      "type": ["PermanentResident", "Person"],
      // only country is selectively disclosed
      "birthCountry": "Arcadia"
    },
    "proof": {
      "type": "DataIntegrityProof",
      "verificationMethod": "did:web:vcplayground.org#zUC7EwMqo9vCjFmj7ArU2SivcbeccAY6hd4nw5fVD6xD4W2vm9eVy6VqVnciAZRmPLXnuxuka5JTJVmgz66CxDno6eqZmvUViCckCcKg8A4s1R4i2JjyzrdTQs5zrfY4jJCHFCp",
      "cryptosuite": "bbs-2023",
      "proofPurpose": "assertionMethod",
      "proofValue": "u2V0DhV...3JnIn0"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-01-04T15:10:39Z",
    "verificationMethod": "did:key:z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX#z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX",
    "proofPurpose": "authentication",
    "challenge": "QZVVFcXlMPStFmpXTSktv",
    "domain": "https://unlinkable.example",
    "proofValue": "z5tXmHk...x2GvTt3bF"
  }
}
      
{ // external (all terms in this example)
  "protected": {
    "kid": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "alg": "EdDSA"
  },
  "payload": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v4rc1"
    ],
    "type": [
      "VerifiableCredential",
      "PermanentResidentCardCredential"
    ],
    "issuer": {
      "id": "did:key:zUC7Do...oAVE",
      "image": "data:image/png;base64,iVBORw0KGgoAA...CYII="
    },
    "name": "Permanent Resident Card",
    "description": "Government of Utopia Permanent Resident Card.",
    "credentialSubject": {
      "type": [
        "PermanentResident",
        "Person"
      ],
      "givenName": "JANE",
      "familyName": "SMITH",
      "gender": "Female",
      "image": "data:image/png;base64,iVBORw0KGgoAAA...3dgg==",
      "residentSince": "2015-01-01",
      "commuterClassification": "C1",
      "birthCountry": "Arcadia",
      "birthDate": "1978-07-17",
      "permanentResidentCard": {
        "type": "PermanentResidentCard",
        "identifier": "83627465",
        "lprCategory": "C09",
        "lprNumber": "999-999-999"
      }
    },
    "validFrom": "2025-01-04T00:00:00Z",
    "validUntil": "2026-01-04T23:59:59Z",
  },
  "signature": "qSv6d...bJRAw"
}
      

加密

这些示例仅供参考,最佳实践是避免在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"
}
      

架构考虑

详细架构图

以下是显示[[[#data-model]]]、[[[#core-properties]]]和[[[#methods]]]以及[[?DID-RESOLUTION]]之间关系的图表。


  DID和DID文档记录在可验证数据注册表上;DID解析为DID文档;DID引用DID主体;DID控制者控制DID文档;DID URL包含DID;DID URL解引用为DID文档片段或外部资源;DID解析器实现解析功能;DID URL解引用器实现解引用功能;DID方法操作可验证数据注册表;DID解析器和DID URL解引用器指示DID方法。
DID架构详细概述及基本组件之间的关系。

DID的创建

[=DID=]的创建是由每个[=DID Method=]定义的过程。一些[=DID Methods=],例如`did:key`,是纯生成性的,即通过将单个加密材料转换为合规的[=representation=]来生成[=DID=]和[=DID document=]。其他[=DID methods=]可能需要使用[=verifiable data registry=],其中[=DID=]和[=DID document=]仅在注册完成后才被第三方认可为存在(如相应的[=DID method=]所定义)。相应的[=DID method=]可能定义其他过程。

确定DID主体

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

术语"资源"以通用意义使用,指代URI可能标识的任何事物。[...] 资源不一定可以通过互联网访问。

资源可以是数字的或物理的,抽象的或具体的。任何可以分配URI的资源都可以分配[=DID=]。[=DID=]引用的资源就是[=DID subject=]。

[=DID controller=]确定[=DID subject=]。通常无法从查看[=DID=]本身来确定[=DID subject=],因为[=DIDs=]通常只对机器有意义,对人类没有意义。[=DID=]不太可能包含有关[=DID subject=]的任何信息,因此有关[=DID subject=]的更多信息只能通过将[=DID=]解析为[=DID document=]、获取有关[=DID=]的可验证凭证或通过[=DID=]的其他描述来发现。

虽然检索到的[=DID document=]中`id`属性的值必须始终与正在解析的[=DID=]匹配,但[=DID=]引用的实际资源是否可以随时间变化取决于[=DID method=]。例如,允许[=DID subject=]更改的[=DID method=]可以用来为特定角色的当前占据者生成[=DID=]—例如公司的CEO—其中占据该角色的实际人员可能因解析[=DID=]的时间不同而不同。

引用DID文档

[=DID=]引用[=DID subject=]并解析为[=DID document=](通过遵循[=DID method=]指定的协议)。[=DID document=]不是与[=DID subject=]分离的资源,也没有与[=DID=]分离的[=URI=]。相反,[=DID document=]是[=DID resolution=]的产物,由[=DID controller=]控制,目的是启用与[=DID subject=]的加密可验证交互。

下图说明了这一区别。


展示DID控制者如何分配DID以引用DID主体并解析为描述DID主体的DID文档的图形模型图。
[=DID=]是由[=DID controller=]分配的标识符,用于引用[=DID subject=]并解析为描述[=DID subject=]的[=DID document=]。[=DID document=]是[=DID resolution=]的产物,不是与[=DID subject=]不同的独立资源。另请参见:叙述性描述
图表顶部出现两个实心黑色圆圈,左侧标有"DID Controller",右侧标有"DID Subject"。下方出现一个右下角向内弯折形成小三角形的矩形,包含标签"DID Document"。这三个项目之间有箭头延伸,如下所示。一条实心红色箭头直接从DID Controller圆圈向右指向DID Subject圆圈,上方以大字体标注"DID",下方以小斜体字标注"Identifies"。其他箭头标签也是小斜体字。一条虚线红色箭头标有"Resolves to",从DID Controller延伸出来,与第一条箭头在同一条线上开始,然后向下弯曲指向DID Document矩形。一条绿色箭头标有"Controls",直接从DID Controller指向DID Document。一条标有"Controller"的绿色箭头指向相反方向,从DID Document到DID Controller,在图表左侧形成向外的弧线。一条标有"Describes"的蓝色箭头直接从DID Document指向DID Subject。

DID文档中的声明

[=DID document=]中的每个属性都是[=DID controller=]做出的声明,描述了:

[=DID document=]中唯一必需的属性是`id`,因此这是[=DID document=]中唯一保证存在的声明。该声明在[[[#did-and-did-document-graph]]]中通过[=DID=]和[=DID subject=]之间的直接链接进行了说明。

发现有关DID主体的更多信息

发现有关[=DID subject=]的更多信息的选项取决于[=DID document=]中存在的属性。如果存在`service`属性,可以从[=service endpoint=]请求更多信息。例如,通过查询支持可验证凭证的[=service endpoint=]以获取描述[=DID subject=]的一个或多个声明(属性)。

另一个选项是使用`alsoKnownAs`属性(如果它存在于[=DID document=]中)。[=DID controller=]可以使用它来提供引用同一[=DID subject=]的其他URI列表(包括其他[=DIDs=])。解析或解引用这些URI可能会产生[=DID subject=]的其他描述或表示,如下图所示。


          展示图形模型的图表,其中alsoKnownAs属性有一条弧线指向另一个节点,该节点表示解引用为DID主体的另一个描述的不同资源。
[=DID document=]可以使用alsoKnownAs属性声明另一个[=URI=](包括但不一定是另一个[=DID=])引用同一[=DID subject=]。另请参见:叙述性描述
图表包含三个小的黑色实心圆圈、两个带弯角的矩形、它们之间的箭头和标签,如下所示。左上方是一个标有"DID Controller"的圆圈。右上方是一个标有"DID Subject"的圆圈。中下偏右是一个没有标签的圆圈。右下方是一个标有"Description"的矩形。图表中央是一个标有"DID Document"的矩形。在DID Document矩形内,其标签下方是两行代码:"alsoKnownAs: ["和"URI]"。一条黑色箭头从第二行向右延伸,穿过矩形边界,指向图表右侧的无标签圆圈。此箭头上方以大字体标注"URI",下方以斜体标注"Identifies"。一条黑色箭头从无标签圆圈向下指向Description矩形,标有"Dereferences to"。一条标有"Describes"的蓝色箭头从Description延伸出来,在右侧形成弧线,向上指向DID Subject。另一条也标有"Describes"的蓝色箭头直接从图表中央标有"DID Document"的矩形向右上方指向DID Subject圆圈。一条标有"alsoKnownAs"的红色箭头从DID Subject向下指向无标签圆圈。一条红色箭头位于图像顶部,上方以大粗体标注"DID",下方以斜体标注"Identifies",从DID Controller指向DID Subject。一条虚线红色线从同一位置开始但分支出来并向下弯曲,指向图像中央的DID Document矩形。一条标有"Controls"的绿色箭头直接从DID Controller指向DID Document。另一条标有"Controller"的绿色箭头指向相反方向,在图像左侧向外弯曲,从DID Document指向DID Controller。

提供DID主体的表示

如果[=DID subject=]是可以从互联网检索的数字资源,[=DID method=]可以选择构造一个返回[=DID subject=]本身表示的[=DID URL=]。例如,需要持久的、加密可验证标识符的数据模式可以被分配一个[=DID=],并且传递指定的[[[#path]]]或[[[#query]]]可以用作检索该模式表示的标准方式。

类似地,[=DID=]可以用于引用数字资源(如图像),如果适用的[=DID method=]支持该功能,则可以直接从[=verifiable data registry=]返回该资源。

为现有Web资源分配DID

如果网页或任何其他Web资源的控制者想要为其分配一个持久的、加密可验证的标识符,控制者可以给它一个[=DID=]。例如,由博客托管公司托管的博客(在该托管公司的域名下)的作者可以为博客创建一个[=DID=]。在[=DID document=]中,作者可以包含指向博客当前URL的`alsoKnownAs`属性,例如:

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

如果作者随后将博客迁移到不同的托管公司(或作者自己的域名),作者可以更新[=DID document=]以指向博客的新URL,例如:

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

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

DID控制者与DID主体之间的关系

为避免混淆,根据[=DID subject=]与[=DID controller=]的关系,将[=DID subject=]分为两个不相交的集合是有帮助的。

集合#1:DID主体就是DID控制者

第一种情况如[[[#controller-subject-equivalence]]]所示,是[=DID subject=]也是[=DID controller=]的常见场景。这是个人或组织创建[=DID=]进行自我标识的情况。


展示从DID主体到DID控制者具有等价弧线的图形模型图。
[=DID subject=]与[=DID controller=]是同一实体。另请参见:叙述性描述
图表中出现两个小黑色圆圈,一个在左上方标有"DID Controller",一个在右上方标有"DID Subject"。一条实心红色箭头从DID Controller圆圈延伸到DID Subject圆圈,箭头上方以大粗体标注"DID",下方以小斜体标注"Identifies"。一条虚线红色双向箭头标有"Equivalence",在两个圆圈之间延伸,在它们之间和上方的空间形成弧线。图表下部是一个黑色轮廓的带弯角矩形,包含标签"DID Document"。此DID Document矩形与DID Controller和DID Subject的小黑色圆圈之间有箭头指向,带有斜体标签,如下所示。一条蓝色箭头从DID Document指向DID Subject,标有"Describes"。一条绿色箭头从DID Controller指向DID Document,标有"Controls"。一条绿色箭头从DID Document指向DID Controller,向外弯曲成弧线,标有"Controller"。一条虚线红色箭头标有"Resolves to",从DID Controller开始向右延伸,从指向DID Subject的箭头分支出来,然后向下弯曲指向DID Document。

从图形模型的角度来看,即使[[[#controller-subject-equivalence]]]中标识为[=DID controller=]和[=DID subject=]的节点是不同的,它们之间存在一条逻辑弧来表达语义等价关系。

集合#2:DID主体不是DID控制者

第二种情况是[=DID subject=]与[=DID controller=]是不同的实体。例如,父母为孩子创建并维护控制一个[=DID=];公司为子公司创建并维护控制一个[=DID=];或制造商为产品、物联网设备或数字文件创建并维护控制一个[=DID=]。

从图形模型的角度来看,与集合1的唯一区别是[=DID subject=]和[=DID controller=]节点之间没有等价弧关系。

多个DID控制者

[=DID document=]可能有多个[=DID controller=]。这可以通过以下两种方式之一发生。

独立控制

在这种情况下,每个[=DID controllers=]可以独立行事,即每个都有完全的权力独立更新[=DID document=]。从图形模型的角度来看,在此配置中:

  • 每个额外的[=DID controller=]是另一个不同的图节点(可能由其自身的[=DID=]标识)。
  • 每个[=DID controller=]和[=DID document=]之间存在相同的弧线("controls"和"controller")。

            展示三个DID控制者各自与DID文档具有独立控制关系的图表
可以各自独立行事的多个独立[=DID controllers=]。另请参见:文字描述
左侧垂直排列三个黑色圆圈,每个标有"DID Controller"。从每个圆圈延伸出一对绿色箭头指向图表中央的单个矩形,标有"DID Document"。该矩形右下角被切割并向内弯折形成一个小三角形,仿佛代表一张带卷角的纸张。每对绿色箭头由一条从黑色圆圈指向矩形的箭头(标有"Controls")和一条指向相反方向(从矩形到黑色圆圈)的箭头(标有"Controller")组成。从矩形右侧延伸出一条蓝色箭头,标有"Describes",指向一个标有"DID Subject"的黑色圆圈。

群组控制

在群组控制的情况下,[=DID controllers=]预期以某种方式共同行事,例如使用需要多个数字签名("多重签名")或阈值数量数字签名("m-of-n")的加密算法。这些用于验证证明的额外阈值可以在[=verification method=]中表达(如[[[#verification-methods]]]节所述),也可以是[=verification method=]验证材料的内在部分,其中参与生成特定数字签名的[=DID controllers=]数量出于隐私原因而被隐藏。需要由群组成员执行的加密操作组合产生证明的验证方法可用于控制DID文档的内容;具体如何实现取决于各个DID方法规范。

从功能角度来看,此选项类似于单个[=DID controller=],因为虽然[=DID controller=]组中的每个[=DID controllers=]都有其自己的图节点,但实际控制归结为表示[=DID controller=]组的单个逻辑图节点,如[[[#group-did-controllers]]]所示。


展示三个DID控制者作为单个DID控制者组共同控制DID文档的图表
预期作为[=DID controller=]组共同行事的多个[=DID controllers=]。另请参见:叙述性描述
左侧是三个黑色实心圆圈,由左侧的花括号标注为"DID Controller Group"。从这三个圆圈中的每一个都延伸出一条绿色箭头指向中右方。这三条箭头汇聚向一个单独的白色实心圆圈。一对水平绿色箭头将此白色圆圈右侧连接到一个形状像带卷角页面的矩形,标有"DID Document"。上方箭头向右指(从白色圆圈到矩形),标有"Controls"。下方箭头向左指(从矩形到白色圆圈),标有"Controller"。从矩形右侧延伸出一条蓝色箭头,标有"Describes",指向一个标有"DID Subject"的黑色圆圈。

此配置通常适用于[=DID subject=]是组织、公司、政府机构、社区或其他不受单个个人控制的团体的情况。

更改DID主体

[=DID document=]恰好有一个引用[=DID subject=]的[=DID=]。[=DID=]表示为`id`属性的值。此属性值在[=DID document=]的生命周期内是不可变的。

但是,[=DID=]标识的资源,即[=DID subject=],可能会随时间变化。这完全由[=DID controller=]决定。有关更多详细信息,请参见[[[#persistence]]]节。

更改DID控制者

[=DID document=]的[=DID controller=]可能会随时间变化。但是,根据实现方式的不同,[=DID controller=]的更改可能不会通过[=DID document=]本身的更改来体现。例如,如果更改是通过转移用于[=DID document=]中一个或多个[=verification methods=]的底层加密密钥或其他控制的所有权来实现的,则可能与标准密钥轮换无法区分。

另一方面,如果更改是通过更改[=`controller`=]属性的值来实现的,则是透明的。

如果验证[=DID controller=]的更改很重要,建议实现者根据修改后的[=DID document=]中的[=verification methods=]对新的[=DID controller=]进行[=authentication|身份验证=]。

修订历史

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

自DID v1.0 推荐标准以来的更改包括:

自DID v1.0 第二次候选推荐标准以来的更改包括:

自DID v1.0 第一次候选推荐标准以来的更改包括:

自DID v1.0 首次公开工作草案以来的更改包括:

致谢

工作组向我们的主席Brent Zundel和Dan Burnett,以及我们的W3C工作人员联系人Ivan Herman表示深切的感谢和衷心的谢意,感谢他们不懈的工作,使工作组朝着富有成效的方向前进,并引导我们通过标准化进程的深水危区。

工作组感谢那些导致本规范创建的工作,并向那些在深刻影响我们工作的技术和规范上做出贡献的个人表示真诚的感谢。这特别包括Phil Zimmerman、Jon Callas、Lutz Donnerhacke、Hal Finney、David Shaw和Rodney Thayer在1990年代和2000年代对Pretty Good Privacy (PGP)的工作。

在2010年代中期,后来成为去中心化标识符的初步实现是与Jeremie Miller的Telehash项目以及由Dave Longley和Manu Sporny领导的W3C Web支付社区组的工作协作构建的。大约一年后,XDI.org注册表工作组开始探索用去中心化技术替代其现有标识符注册表。一些探索去中心化标识符概念的最早书面论文可以追溯到由Christopher Allen召集的最初几次Rebooting the Web of Trust研讨会。该工作促成了Christopher Allen、Drummond Reed、Les Chasen、Manu Sporny和Anil John之间的关键合作。Anil看到了该技术的前景,并分配了最初的政府资金来探索该领域。如果没有Anil John多年来的支持和指导,去中心化标识符不太可能达到今天的水平。在Rebooting the Web of Trust研讨会上的进一步完善产生了第一份实现者文档,由Drummond Reed、Les Chasen、Christopher Allen和Ryan Grant编辑。贡献者包括Manu Sporny、Dave Longley、Jason Law、Daniel Hardman、Markus Sabadello、Christian Lundkvist和Jonathan Endersby。这项初始工作随后被合并到W3C凭证社区组中,进一步孵化,然后过渡到W3C去中心化标识符工作组进行全球标准化。

本规范的部分工作由美国国土安全部(US DHS)科学技术局根据合同HSHQDC-16-R00012-H-SB2016-1-002和HSHQDC-17-C-00019资助,以及US DHS硅谷创新计划根据合同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。Internet Identity Workshop的参与者(由Phil Windley、Kaliya Young、Doc Searls和Heidi Nobantu Saul推动)也通过众多旨在辩论、改进和教育参与者了解本规范的工作会议支持了这项工作。

工作组感谢以下个人对本规范的贡献(按字母顺序排列,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, and Brent Zundel.

IANA考虑事项

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

application/did

类型名称:
application
子类型名称:
did
必需参数:
可选参数:
编码考虑:
参见RFC 8259,第11节
安全考虑:
参见DID Core v1.1,安全考虑
互操作性考虑:
不适用
已发布规范:
https://www.w3.org/TR/did/
使用此媒体类型的应用程序:
任何需要去中心化、持久、加密可验证和可解析标识符的应用程序。应用程序通常包括加密身份系统、去中心化设备网络以及颁发或验证可验证凭证的网站。
附加信息:
魔术数字:
不适用
文件扩展名:
.did
Macintosh文件类型代码:
TEXT
进一步信息联系邮箱:
W3C去中心化标识符工作组 public-did-wg@w3.org
预期用途:
通用
使用限制:
作者:
Drummond Reed, Manu Sporny, Markus Sabadello, Dave Longley, Christopher Allen
变更控制者:
W3C

在JSON-LD环境中使用的片段标识符根据与JSON-LD 1.1: application/ld+json媒体类型 [[JSON-LD11]]关联的规则处理。在JSON环境中使用的片段标识符与JSON-LD环境中具有相同的语义解释。[[[?CID]]]规范的第3.4节:片段解析提供了执行片段解析的算法,该算法由[[[?DID-1.1]]]规范进行了扩展。