[=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工作组要求满足以下条件:
功能被定义为规范中一个或多个在功能上相关的规范性声明。对于本规范,互操作性被定义为规范性声明(例如涉及数据模型属性及其值的声明)在两个不同的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 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 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"圆柱体。
本文档包含含有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=]基础设施中使用的术语。每当这些术语出现在本规范中时,都会包含指向它们的链接。
U+0023 NUMBER SIGN)之后的部分。DID片段语法与URI片段语法相同。
U+002F SOLIDUS)开始并包含该字符,到
?字符
(U+003F QUESTION MARK)、
#字符
(U+0023 NUMBER SIGN)
或[=DID URL=]末尾之前(不包含)的部分。DID路径语法与URI路径语法相同。见。
U+003F QUESTION MARK)之后并包含该字符的部分。DID查询语法与URI查询语法相同。见。
did:开头,如中所定义。每个[=DID method=]规范定义一个与该特定[=DID method=]配合使用的特定DID方法方案。在特定DID方法方案中,DID方法名称跟在第一个冒号之后并以第二个冒号终止,例如did:example:
U+002F SOLIDUS)、
可选的DID query及其前导
?字符
(U+003F QUESTION MARK)、
和可选的DID fragment及其前导
#字符
(U+0023 NUMBER SIGN)。
除上述术语外,本规范还使用[[INFRA]]规范中的术语来正式定义数据模型。当使用[[INFRA]]术语时,例如string、set和map,它们直接链接到该规范。
本节描述了[=DIDs=]和[=DID URLs=]的正式语法。术语"通用"用于区分此处定义的语法与特定[=DID methods=]在各自规范中定义的语法。[=DIDs=]和[=DID URLs=]的创建过程及其时序在[[[#method-operations]]]和[[[#creation-of-a-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=]是特定[=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 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=]由一个map的entries组成,其中每个条目由一个键/值对组成。[=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]]]中的术语定义的,可以包含多个项目的属性值,例如lists、maps和sets,是明确有序的。[[[INFRA]]]中的所有类似列表的值结构都是有序的,无论该顺序是否重要。对于本规范的目的,除非另有说明,map或set的排序不重要,且不期望实现产生或消费确定性排序的值。
数据模型支持两种类型的可扩展性。
两个特定实现总是可以带外同意使用未记录在[[[?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 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 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=]的要求如下:
所有[=conforming producers=]的要求如下:
所有[=conforming consumers=]的要求如下:
图的左上象限包含一个灰色虚线轮廓的矩形,其中包含两个蓝色轮廓的矩形,一上一下。上面较大的矩形标注为蓝色的"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 [=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-LD11|JSON-LD]]是一种基于JSON的格式,用于序列化关联数据。预期某些实现将使用标准JSON-LD处理算法处理[=DID documents=]。为了最大化互操作性,强烈建议实现者确保不阻止使用符合标准的库进行JSON-LD处理。无论是否执行使用符合标准库的JSON-LD处理,[=DID document=]的语义都是相同的。语义上的任何差异都是实现或DID方法规范中的错误。
要进行JSON-LD处理,必须(MUST)根据[[[JSON-LD11]]]规范中指定的规则指定`@context`属性。
[=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=]。使用精度较低的媒体类型的一些原因包括:
当可以从有效载荷中确定预期的媒体类型时,不鼓励实现者引发错误,前提是所使用的媒体类型在给定协议中是可接受的。例如,如果应用程序仅接受符合`application/did`媒体类型规则的有效载荷,但有效载荷被标记为精度较低的`application/json`或`application/ld+json`,应用程序可以执行以下步骤来确定有效载荷是否也符合精度较高的媒体类型:
尽可能建议实现者对本规范定义的所有有效载荷使用最精确的(最高精度的)媒体类型。还建议实现者认识到,标记为精度较低的媒体类型的有效载荷并不意味着该有效载荷不满足标记为精度较高类型所需的规则。同样,标记为精度较高的媒体类型的有效载荷也不意味着该有效载荷将满足与该媒体类型相关的要求。无论其关联的媒体类型如何,有效载荷的接收者都应执行适当的检查,以确保有效载荷符合其在给定系统中使用的要求。
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语法时的要求如下:
`method-specific-id`中冒号的含义完全是方法特定的。冒号可以被[=DID methods=]用于建立层次分区的命名空间、标识[=verifiable data registry=]的特定实例或部分,或用于其他目的。建议实现者避免假设与冒号相关的任何可通用于所有[=DID methods=]的含义或行为。
所有[=DID method=]规范在定义方法操作时的要求如下:
执行授权以进行操作的一方的权限是特定于[=DID method=]的。例如,[=DID method=]可能—
在执行方法操作时,[=DID method=]可以使用其需要的任何数据结构,包括中间的、部分的或临时的[=DID documents=],只要它们保持在DID方法内部,且方法操作返回的DID文档完全合规,如[[[#conformance]]]中所定义。
所有[=DID method=]规范在编写安全考虑节时的要求如下:
所有[=DID method=]规范在编写隐私考虑节时的要求为:
本节包含各种安全考虑,建议使用去中心化标识符的人在将此技术部署到生产环境之前仔细考虑这些问题。敦促读者在阅读本节之前先阅读[[[CID]]]规范的安全考虑节。[=DIDs=]设计为在许多IETF标准使用的威胁模型下运行,该模型记录在[[?RFC3552]]中。本节详细阐述了[[?RFC3552]]中的一些考虑事项,以及[=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操作能力的[=controller=]能够重新获得执行DID操作的能力。
在考虑使用[=DID=]恢复时,以下考虑因素可能有用:
[=DIDs=]无需中央注册机构即可实现全局唯一性。这是以人类记忆性为代价的。能够生成全局无歧义标识符的算法会产生对人类没有意义的随机字符串。这种权衡通常被称为佐科三角。
在一些用例中,从人类友好标识符出发发现[=DID=]是可取的。例如,自然语言名称、域名或[=DID controller=]的常规地址,如手机号码、电子邮件地址、社交媒体用户名或博客URL。然而,将人类友好标识符映射到[=DIDs=]并以可验证和可信赖的方式进行映射的问题不在本规范的范围之内。
此问题的解决方案在引用本规范的单独规范中定义,例如[[?DNS-DID]]。强烈建议此类规范仔细考虑以下方面:
如果[=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 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-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 Method=]定义的过程。一些[=DID Methods=],例如`did:key`,是纯生成性的,即通过将单个加密材料转换为合规的[=representation=]来生成[=DID=]和[=DID document=]。其他[=DID methods=]可能需要使用[=verifiable data registry=],其中[=DID=]和[=DID document=]仅在注册完成后才被第三方认可为存在(如相应的[=DID method=]所定义)。相应的[=DID method=]可能定义其他过程。
[=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 subject=]并解析为[=DID document=](通过遵循[=DID method=]指定的协议)。[=DID document=]不是与[=DID subject=]分离的资源,也没有与[=DID=]分离的[=URI=]。相反,[=DID document=]是[=DID resolution=]的产物,由[=DID controller=]控制,目的是启用与[=DID subject=]的加密可验证交互。
下图说明了这一区别。
[=DID document=]中的每个属性都是[=DID controller=]做出的声明,描述了:
[=DID document=]中唯一必需的属性是`id`,因此这是[=DID document=]中唯一保证存在的声明。该声明在[[[#did-and-did-document-graph]]]中通过[=DID=]和[=DID subject=]之间的直接链接进行了说明。
发现有关[=DID subject=]的更多信息的选项取决于[=DID document=]中存在的属性。如果存在`service`属性,可以从[=service endpoint=]请求更多信息。例如,通过查询支持可验证凭证的[=service endpoint=]以获取描述[=DID subject=]的一个或多个声明(属性)。
另一个选项是使用`alsoKnownAs`属性(如果它存在于[=DID document=]中)。[=DID controller=]可以使用它来提供引用同一[=DID subject=]的其他URI列表(包括其他[=DIDs=])。解析或解引用这些URI可能会产生[=DID subject=]的其他描述或表示,如下图所示。
如果[=DID subject=]是可以从互联网检索的数字资源,[=DID method=]可以选择构造一个返回[=DID subject=]本身表示的[=DID URL=]。例如,需要持久的、加密可验证标识符的数据模式可以被分配一个[=DID=],并且传递指定的[[[#path]]]或[[[#query]]]可以用作检索该模式表示的标准方式。
类似地,[=DID=]可以用于引用数字资源(如图像),如果适用的[=DID method=]支持该功能,则可以直接从[=verifiable data registry=]返回该资源。
如果网页或任何其他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 subject=]与[=DID controller=]的关系,将[=DID subject=]分为两个不相交的集合是有帮助的。
第一种情况如[[[#controller-subject-equivalence]]]所示,是[=DID subject=]也是[=DID controller=]的常见场景。这是个人或组织创建[=DID=]进行自我标识的情况。
从图形模型的角度来看,即使[[[#controller-subject-equivalence]]]中标识为[=DID controller=]和[=DID subject=]的节点是不同的,它们之间存在一条逻辑弧来表达语义等价关系。
第二种情况是[=DID subject=]与[=DID controller=]是不同的实体。例如,父母为孩子创建并维护控制一个[=DID=];公司为子公司创建并维护控制一个[=DID=];或制造商为产品、物联网设备或数字文件创建并维护控制一个[=DID=]。
从图形模型的角度来看,与集合1的唯一区别是[=DID subject=]和[=DID controller=]节点之间没有等价弧关系。
[=DID document=]可能有多个[=DID controller=]。这可以通过以下两种方式之一发生。
在这种情况下,每个[=DID controllers=]可以独立行事,即每个都有完全的权力独立更新[=DID document=]。从图形模型的角度来看,在此配置中:
在群组控制的情况下,[=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 subject=]是组织、公司、政府机构、社区或其他不受单个个人控制的团体的情况。
[=DID document=]恰好有一个引用[=DID subject=]的[=DID=]。[=DID=]表示为`id`属性的值。此属性值在[=DID document=]的生命周期内是不可变的。
但是,[=DID=]标识的资源,即[=DID subject=],可能会随时间变化。这完全由[=DID controller=]决定。有关更多详细信息,请参见[[[#persistence]]]节。
[=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.
当本规范成为W3C提案推荐标准时,本节将提交给互联网工程指导组(IESG)进行审查、批准并在IANA注册。
在JSON-LD环境中使用的片段标识符根据与JSON-LD 1.1: application/ld+json媒体类型 [[JSON-LD11]]关联的规则处理。在JSON环境中使用的片段标识符与JSON-LD环境中具有相同的语义解释。[[[?CID]]]规范的第3.4节:片段解析提供了执行片段解析的算法,该算法由[[[?DID-1.1]]]规范进行了扩展。