此版本为授权W3C文档。此翻译文档的发布遵循W3C授权翻译文档流程。如有任何争议,应以原始英文版本为权威版本。
另请参阅 翻译版本.
Copyright © 2022 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
分布式标识(DIDs)是一种新型标识符,可以实现可验证的去中心化数字身份。一个DID 可以是该DID控制者指定的任何物体(例如:人、组织、物体、数据模型、抽象物体等)。与典型联邦式标识符不同的地方在于,DIDs从设计的源头脱离了与集中式注册表、身份提供者和证书颁发机构的关联。具体来讲,虽然可能会利用其它方来帮助发现与DID相关联的信息,但该设计使 DID的控制者可以证明其对DID的控制,而无需任何其它方的许可。 DIDs是一串将DID对象 和DID文档关联起来的URIs,并且允许了对象与文档之间的可信交互。
每一个DID文档都可以包含加密材料、验证方法或服务, 它们共同提供了一整套的机制,从而使DID控制者能够证明其对DID的控制。服务为DID对象的交互提供可信支撑。如果DID对象是一个信息资源,例如数据模型,那么DID可能提供返回DID对象本身的方法。
本文档详细说明了DID涉及的语法,通用数据模型,核心属性,序列化表示,DID 操作和通过解析DID以此获得其所代表资源的过程。
本节描述了本文档在发布时的状态。当前的W3C出版物列表和此技术报告的最新修订版可以在W3C技术报告索引技术报告索引中找到,网址是 https://www.w3.org/TR/。
在该规范发布时,已经存在103种实验性DID方法规范,32种实验性DID方法驱动程序实现,一个用于确定驱动程序实现是否符合本规范以及满足测试集中46中测试实现的测试集。建议读者注意DID 核心问题和 DID 核心测试套件问题其中每个问题都包含最新的关注列表和可能导致更改本规范的提议。在发布时,将没有其他实质性问题,变化或修改。
欢迎对本文件提出意见,请将问题直接存档在 GitHub,或者邮件至public-did-wg@w3.org ( subscribe, archives).
W3C分布式标识工作组已通过建议跟踪将此文档作为W3C的推荐标准。
W3C建议将此标准作为Web标准进行广泛部署。
W3C建议标准是一种规范,经过广泛的共识构建并得到W3C及其成员的认可,也得到工作组成员对实现的免版税许可的承诺。
该文件由遵守W3C专利政策W3C Patent Policy小组制作。 W3C维护一个公开的专利列表public list of any patent disclosures,其中包含了该组织可交付成果相关的任何专利披露情况;该页面也包含披露专利的说明。拥有实际认知且认为包含基本权利Essential Claim(s)要求的专利的个人必须根据 W3C 专利政策第 6 节披露该信息section 6 of the W3C Patent Policy。
本文档受2021年11月2日W3C流程文档的约束(2 November 2021 W3C Process Document).
此章节是非规范性的。
作为个人和组织,我们很多人都在使用全球唯一标识符在各种各样的情况下。这些标识符作为通信地址(电话号码、电子邮件地址、社交媒体上的用户名)、身份证号码(护照、驾驶执照、税号、健康保险)和产品标识符(序列号数字、条形码、RFID)。URI(统一资源标识符)用于标记Web上的资源,此外,您在浏览器中查看的每个网页都有一个全局唯一URL(统一资源定位符)。
这些全球唯一标识符中的绝大多数不受我们的控制。它们由外部的权威机构颁发,这些权威机构决定这些标识符发给谁和它们用来做什么,以及它们何时可以被撤回。它们仅在某些情况下有用,并且只被某些特定的机构所认可。它们可能会随着颁发机构的倒闭而消失或不再有效。它们可能在不经意间泄露个人信息。在许多情况下,它们可以被恶意的第三方欺诈性地复制和断言,这便是通常所说的“身份盗窃”。
本规范中定义的分布式标识 (DID) 是一种新的全球唯一标识符的类型。它们旨在使个人和组织使用其信任的系统生成属于自己的标识符。这些新的标识符使个人和组织能够通过加密证明(例如,数字签名)进行身份验证,以此来证明对该标识的掌控。
由于分布式标识的生成和断言是由实体控制的,每个实体都可以拥有尽可能多的DID,以此来满足他们所需要的身份、角色和互动的独立性。这些标识符的使用可以适当地限定在不同的场景与环境中。他们支持人、机构、系统、物体间的互动与互认,同时它可以控制个人数据的泄露量,而这所有的一切都不依赖中心化的授权机构。这些想法也在DID用例文档中进行了探讨[DID-USE-CASES]。
本规范不预先设定任何特定的技术或密码学以此来支持DID的产生、存在、解析或者说明。例如,部署者可以基于联邦或中心化身份管理系统生成DID。实际上,几乎所有类型的标识系统都可以添加对DID的支持。这为中心化、联邦化和分布式标识相互间的互操作搭建了桥梁。这也使得部署者能够选择他们所信任的计算基础设施,例如分布式账本、分布式文件系统、分布式数据库、点对点(P2P)网络等,开发设计特定种类的DID。
本规范适用于:
除了此规范外,读者也可以在《对于分布式标识的应用案例和要求》 [DID-USE-CASES]找到更多有用信息。
此章节是非规范性的。
DID是一个简单的文本字符串,一个DID标识包含了三部分:1)did
URI 方案标识符,2) 用于标记DID方法的标识符,和3)DID方法指定的标识符。
上面示例的 DID可以解析为 DID文档。一个DID文档包含了与该 DID相关联的信息,例如使用密码对DID控制者进行身份验证。
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
]
"id": "did:example:123456789abcdefghi",
"authentication": [{
// used to authenticate as did:...fghi
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}]
}
此章节是非规范性的。
分布式标识 是某个大系统中的组成元素,例如可验证凭证(Verifiable Credentials ecosystem)生态系统[VC-DATA-MODEL]。该生态系统对这份规范的设计带来了影响。分布式标识这份规范的设计目的整理如下。
目标 | 描述 |
---|---|
分布式 | 消除对中心化管理机构的依赖和标识管理中单点故障的出现,包括全球唯一注册标识符、公共验证密钥、服务和其它信息。 |
可控性 | 赋予实体,包括人类和非人类,直接控制他们数字身份的能力,而无需依赖外部的权威机构。 |
隐私性 | 赋予实体能够控制其隐私信息的能力,包括最小的、选择性的和逐渐性披露属性或其它数据的能力。 |
安全性 | 为请求方提供拥有足够安全性的DID文档,以此来满足其所需的安全级别。 |
可证明性 | 使得DID控制者在与其它实体交互时提供加密证明。 |
可发现性 | 使得实体可以找到其它实体的DIDs,从而了解或者与其进行交互。 |
互操作性 | 使用互操作标准,以便使得DID基础设施可以使用已存在的工具或软件实现互操作性。 |
可移植性 | 不依赖于系统和网络,从而使得实体能够选择任何支持DIDs和DID方法的系统。 |
简易性 | 通过精简、简易化的特性,使得技术更易于理解、实施和部署。 |
可扩展性 | 在可能且不妨碍扩展的情况下,启用可扩展性、互操作性、可移植性或简易性。 |
本章节是非规范性的。
本章节提供了对分布式标识架构中主要组件的基本概述。
图中包含了六个内部具有标记的图像,它们之间关系由箭头标记,如下图所示。在图标的中间是一个标记为“DID URL”的矩形,包含一串打印字符串"did:example:123/path/to/rsrc"。在图的中间顶部是一个标记为“DID”的矩形,包含一串打印字符串“did:example:123”。在图的左上方是一个椭圆形,标记为“DID对象(DID subject)”。在图的底部中间是一个矩形,标记为“DID文档(DID document)”。在图的左下角是一个椭圆形,标记为“DID控制者(DID controller)”。在图的右侧中间是一个圆柱体,标记为“可验证数据注册表(verifiable data registry)”。
从“DID URL”矩形的顶部延伸出一个标记为"包含(contains)"的箭头,指向“DID”。从“DID URL”矩形的底部延伸出来一个标记为“参考/引用(refer)”和“解引用(dereferences)”的箭头,指向“DID文档(DID document)” 。从“DID”矩形底部延伸出来一个标记为“解析到(resolves to)”的箭头,指向DID文档(DID document)。从“DID”矩形左侧延伸出来一个标记为“参考(refers to)”的箭头,指向DID对象(DID subject)。从“DID控制者(DID controller)”右侧延伸出来一个标记为“控制(controls)”的箭头,指向右侧的“DID文档(DID document)”。从“DID”右侧延伸出来一个标记为“被记录在(recorded on)”的箭头,指向“可验证数据注册表(verifiable data registry)”。从“DID文档(DID document)”右侧延伸出来一个标记为“被记录在(recorded on)”的箭头,指向右侧的“可验证数据注册表(verifiable data registry)”。
did:
,DID方法标识符,和一串由DID方法指定的标识符。DIDs可以被解析得到一个DID 文档。一个DID URL 拓展了基本的 DID语法使其融合了其它 URI标准内容,譬如:路径(path)、查询(query)和片段(fragment),以便定位到特定的资源,例如,定位到 DID 文档中的公钥、或者 DID 文档外部的资源等。
这些概念在 3.1 DID 语法和 3.2 DID URL 语法中有介绍。
除了标记为非规范性的部分外,本规范中的所有撰写指南、图表、示例和注释也是非规范性的。本规范中的其他所有内容都是规范性的。
文档中关键词可能, 必须, 必须不能, 可选择的, 建议的, 要求的, 应该, 和 不应该 仅在以全大写形式出现时按照BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。
本文包含涉及JSON和JSON-LD内容的示例。其中一些示例包含无效字符,如内联注释(//
) 以及使用省略号 (...
) 来表示对示例没有多大价值的信息。如果实现者希望将这些信息作为有效的JSON或JSON-LD使用,则需要注意删除这些内容。
一些示例包含本规范中未定义的术语,包括属性名和值。这些用注释(//
external (property name|value)
)来表示。当在 DID 文档中使用这些术语时,它们将在DID规范注册表[DID-SPEC-REGISTRIES] 中进行注册,并链接到正式定义和JSON-LD文档中。
通过评估实现创建和解析符合本规范的DIDs和 DID 文档的能力,可以测试 DIDs和 DID 文档 实现的互操作性。通过确保 DIDs 和 DID 文档 的合规性,为DIDs 和 DID 文档 的生产者和消费者提供互操作性。通过各 DID 方法规范中的细节提供 DID 方法 规范的互操作性。就像web浏览器不需要实现所有已知的 URI 方案一样,与 DIDs配合使用的合规软件也不需要实现所有已知的DID 方法。然而,对于特定的 DID 方法,该方法的所有实现都应该对该方法本身具有互操作性。
一个符合规范的 DID 是指,符合3. 标识部分相关规范性陈述的规则的任何具体表达。
一个符合规范的 DID文档 是指,符合 4. 数据模型 和5. 核心属性的数据模型的任何具体表达。一致性文档的格式是确定的、双向的、无损的,如6. 表示所述。
一个符合规范的创作者 是指,任何可以产生符合规范DID或符合规范DID文档的软件/硬件的算法,同时符合6. 表示中的相关规范。
一个符合规范的使用者 是指,任何可以读取/识别 符合规范DID或 符合规范DID文档的软件/硬件的算法,同时符合 6. 表示中的相关规范。
一个符合规范的 DID解析器 是指,符合 7.1 DID 解析中规范的软件/硬件的算法。
一个符合规范的 DID URL重新访问器 是指,符合 7.2 DID URL 解引用中规范的软件/硬件的算法。
一个符合规范的 DID方法 是指,符合8. 方法中相关规范性表述的规范。
此章节是非规范性的。
本节定义了本规范和整个分布式标识基础架构中使用的术语。本规范中出现的术语将会给出相关链接。
controller
属性来表示。注意,一个DID控制者可能是DID 对象。
#
)后面的部分。DID 片段的语法与 URI 片段语法相同。
/
)符号开头(包含该 (/
)),以问号(?
) 符号,或井号 (#
) 符号,或DID URL的末尾结尾。DID 路径语法与 URI 路径语法相同。参考 路径(Path)。
?
)符号开头(包含该 (?
))。DID 查询语法与 URI 查询语法相同。参考 查询(Query)。
did:
开头(见3.1 DID 语法)。每个 DID 方法 都规定了一个与该特定 DID 方法一起使用的特定的DID方法方案。在特定的DID方法方案中,DID方法名称在第一个冒号后面,在第二个冒号前,例如,did:example:
/
符号),可选的DID 查询(带有其前导的 ?
符号),以及可选的 DID 片段(带有其前导的#
符号)。
@context
就是一种特定条目的表示。
一组可与流程一起使用以独立验证证明的参数。例如,一个加密公钥可用作数字签名的验证方法;在这种用法中,它可以验证签名者是否拥有相关的加密私钥。
本定义中的”验证(Verification)“和”证明(proof)“是广义含义上的用法。例如,在Diffie-Hellman密钥交换期间,可能会使用加密公钥来协商用于加密的共享对称密钥。这保证了密钥协商过程的完整性。因此,即使过程的描述中可能没有使用”验证“或者”证明“这两个词,这也是另外一种验证方法。
除上述术语外,本规范还使用[[INFRA]]规范中的术语来正式定义 数据模型。当使用 [INFRA] 中的术语,譬如字符串,集合和映射时,它会直接链接到该规范。
本节描述了DIDs和 DID URLs的语法形式。术语“通用”用于区分此处定义的语法与特定 DID 方法在各自规范中定义的语法。对DIDs和 DID URLs的创建过程及其创建时间,在8.2 方法操作和B.2 创建一个DID 中有所描述。
通用DID 方法DID方案是符合[RFC3986]的 URI 方案。ABNF的定义如下,其使用[RFC5234]中的语法以及 ALPHA
和DIGIT
的相应定义。以下ABNF中未定义的所有其他规则名称在[RFC3986]中进行定义。所有DIDs 必须符合DID语法ABNF规则。
DID语法的ABNF规则 |
---|
did = "did:" method-name ":" method-specific-id method-name = 1*method-char method-char = %x61-7A / DIGIT method-specific-id = *( *idchar ":" ) 1*idchar idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded pct-encoded = "%" HEXDIG HEXDIG |
DID URL是特定资源的网络位置标识符。它可以用来检索DID 对象, 验证方法, 服务, DID 文档的特定部分或其他资源的具体表示。
下面是使用[RFC5234]中的语法对ABNF的定义。它建立在3.1 DID Syntax did
语法基础之上。 path-abempty
, query
, 和 fragment
组件在[RFC3986]中进行定义。所有DID URLs必须符合DID URL语法ABNF规则。DID 方法可以进一步限制这些规则,如8.1 方法语法中所表述。
DID URL语法ABNF规则 |
---|
did-url = did path-abempty [ "?" query ] [ "#" fragment ] |
尽管可以根据DID URL语法规则使用分号 (;
) 字符,但该规范的后续版本可能会将其用作[MATRIX-URIS]中所述参数的子分隔符。为避免今后冲突,开发人员应避免使用它。
DID 路径与通用URI路径相同,并符合 RFC 3986, section 3.3中的path-abempty
ABNF规则。与URIs一样,路径的语义可以通过DID 方法指定,而这反过来又可以使DID 控制者进一步专业化这些语义。
did:example:123456/path
DID 查询与通用的URI查询相同,并符合RFC 3986, section 3.4中的query
ABNF规则。该句法的特征在3.2.1 DID 参数中有详细说明。
did:example:123456?versionId=1
DID 片段语法和语义与通用的URI片段相同,并符合RFC 3986, section 3.5中的fragment
ABNF规则。
DID 片段被用作独立于DID方法的DID 文档或外部资源的引用。以下是一些DID片段标识符的示例。
did:example:123#public-key-0
did:example:123#agent
did:example:123?service=agent&relativeRef=/credentials#degree
为了最大限度地提高互操作性,建议实现者以同样的方式解释DID 片段 和表示。 (参考 6. 表示). 例如,尽管JSON Pointer [RFC6901]可以用于 DID 片段,但在非JSON的 表示中它的解释方式并不相同。
与DID片段相关的其它语义,在 E.2 应用程序/did+ld+json中有更多JSON-LD表示的描述。有关如何解除访问DID 片段的信息,请参考 7.2 DID URL 解引用。
基于查询中描述的query
部分,DID URL 语法支持一种简单的参数格式。将一个DID参数添加到DID URL中意味着该参数成为指向 资源的标识符的一部分。
did:example:123?versionTime=2021-05-10T17:00:00Z
did:example:123?service=files&relativeRef=/resume.pdf
一些DID参数完全独立于任何特定的DID 方法,并以相同的方式对所有DIDs发挥作用。并非所有DID 方法都支持DID参数。在支持可选参数的情况下,它们应在支持它们的DID 方法中统一实现并运行。下表提供了在所有DID 方法中以相同方式发挥作用的常见DID参数。是否支持所有DID 参数是可选择>的。
通常,DID URL重新访问器的实现将引用[DID-RESOLUTION]以获取更多实现细节。本规范的范围仅定义了最常见查询参数的合约。
参数名称 | 描述 |
---|---|
service
|
根据服务ID识别DID 文档中的服务。如果存在,关联值必须是一个ASCII字符串。 |
relativeRef
|
根据RFC3986 Section 4.2,相对URI引用是指通过使用DID 文档中服务端点的service 参数来标记/获取资源。如果存在,关联值必须是一个ASCII字符串,并且必须>使用RFC3986
Section 2.1中指定的百分比编码来表示某些字符。
|
versionId
|
标记要解析的 DID 文档的特定版本(版本ID可以是顺序的,或者是UUID,或者是用于特定方法的)。如果存在,关联值必须>是一个ASCII 字符串。 |
versionTime
|
标记要解析的DID 文档的特定版本时间戳。即,在特定时间内对DID有效的一个DID 文档 。如果存在,关联值必须>是一个有效的XML日期时间值的ASCII 字符串,见W3C XML Schema Definition Language
(XSD) 1.1 Part 2: Datatypes [XMLSCHEMA11-2]。该日期时间值*必须*标准化为UTC 00:00:00,且不保留亚秒级小数精度。例如:2020-12-20T19:17:47Z 。
|
hl
|
在[HASHLINK]中指定的,用于添加完整性保护的DID 文档资源的哈希值。该参数是非规范性的。如果存在,关联值必须是一个ASCII 字符串。 |
实现者以及DID 方法规范的作者可能会使用此处未列出的其他DID参数。为实现最大程度的互操作性,建议>DID参数使用DID规范注册表机制[DID-SPEC-REGISTRIES],以避免与具有不同语义的相同DID参数的其他使用发生冲突。
如果存在明确的用例需要将DID参数作为URL的一部分,从而比单独使用DID可以作为更精确的方式来引用 资源,则可以使用DID参数。如果可以通过向DID解析器传递输入元数据来表示相同的功能,则不应该>使用DID参数。有关处理这些参数的其他注意事项,请参见[DID-RESOLUTION]。
通过将不属于DID URL的输入元数据传递给DID 解析器,可能影响DID 解析和DID URL 解引用的过程,参考(7.1.1 DID 解析选项)。这与HTTP类似,在HTTP中,某些参数可以包含在HTTP URL中,或者在重新访问过程中作为HTTP标头传递。重要的区别在于,DID参数作为DID URL的一部分,它应用于指定所标识的资源,而不作为DID URL一部分的输入元数据应用于控制如何解析或解引用该资源。
一个相对DID URL是DID 文档中不以`did:
在解析相对DID URL引用时,必须 使用RFC3986 Section 5: Reference Resolution中指定的算法。基础 URI 的值是与DID 对象相关联的DID,参考5.1.1 DID 对象。方案是did
。授权是<method-name>:<method-specific-id>
的组合,此外,path, query和fragment的数值为路径, 查询和片段中分别定义的值。
相对DID URLs通常用于检索/引用DID 文档中的验证方法和服务,而不必使用绝对URL。需要考虑存储大小的DID 方法 可以使用相对URL来减少DID 文档的存储大小。
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ] "id": "did:example:123456789abcdefghi", "verificationMethod": [{ "id": "did:example:123456789abcdefghi#key-1", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }, ...], "authentication": [ // a relative DID URL used to reference a verification method above "#key-1" ] }
在上面的示例中,一个相对DID URL值被转换为一个绝对 DID URL:did:example:123456789abcdefghi#key-1
该规范定义了一种数据模型,该模型可用于表示DID 文档和DID文档的数据结构,然后将其序列化为多个具体表示。本节提供了数据模型的高级描述,不同类型属性在数据模型中的表达方式的描述,以及扩展数据模型的指令。
一个DID 文档由条目的映射组成,其中每个条目由键/值(key/value)对组成。DID 文档数据模型至少包含两种不同类别的条目。第一类条目称为属性(properties),并在5. 核心属性中指定。第二类是特定条目表示,并在6. 表示中指定。
DID 文档数据模型中的所有条目键都是字符串。所有条目值都使用下表中的一种抽象数据类型来表示,每种表示都指定了每种数据类型的具体序列化格式。
数据类型 |
注意事项 |
---|---|
映射 | 键/值对的有限、有序序列,没有出现重复的键,如[INFRA]中所述。在[INFRA]中,映射有时被称为有序映射 。 |
list | 项目的有限、有序序列,如[INFRA]中所述。 |
set | 项目的有限、有序序列,不包含重复项,如[INFRA]中所述。在[INFRA]中,集合(set)有时被称为有序集合。 |
datetime | 能够无损地表示`dateTime`可表示的所有值的一个日期和时间值,如[XMLSCHEMA11-2]中所述。 |
string | 在[INFRA]中指定的通常用于表示人类可读语言的代码单元序列。 |
integer | 没有分数部分的实数,如[XMLSCHEMA11-2]中所述。为实现最大程度的互操作性,建议实现者遵守RFC8259, Section 6: Numbers中有关整数的建议。 |
double | 通常用于近似表示任意实数的一个值,如 [XMLSCHEMA11-2]中所述。为实现最大程度的互操作性,建议实现者遵守RFC8259, Section 6: Numbers中有关双精度浮点数的建议。 |
boolean | [INFRA]中所定义的true或false值。 |
null | [INFRA]中所定义的缺少值的值。 |
由于使用[INFRA]中的术语来定义数据模型,因此包含多个项目,如: 列(lists), 映射(maps) 和 集合(sets)的属性值均为显式排序。[INFRA]中所有类似列表的值结构都是有序的,无论该顺序是否重要。对于本规范而言,除非另有说明,否则映射和集合排序并不重要,并且不期望通过实现生成或使用确定性排序的值。
数据模型支持两种类型的可扩展性。
对于两种具体实现来说,始终可以在带外达成一致,使用一种彼此理解但未记录在DID规范注册表[DID-SPEC-REGISTRIES]中的扩展或表示形式。但是,这类实现与更大的生态系统之间的互操作性将不太可靠。
一个 DID 与一个DID 文档相关联。 DID 文档使用数据模型来表示,并且可以被序列化为一个表示。 以下的章节定义了DID 文档中的属性,包括这些属性是必须的还是可选的。这些属性描述了DID 对象与属性值之间的关系。
下表包含本规范定义的核心属性的信息引用,包含期望值以及是否需要它们。表中的属性名称与每个属性的规范定义和更详细的描述相关联。
属性名称 id
, type
, 和
controller
可以出现在不同类型的映射中,但约束可能存在差异。
属性 | 必要性? | 值约束 |
---|---|---|
id |
是 | 符合3.1 DID Syntax规则的一个字符串。 |
alsoKnownAs |
否 | 符合[RFC3986]URIs规则的一集合字符串。 |
controller |
否 | 符合3.1 DID 语法规则的一个字符串或一组字符串。 |
verificationMethod |
否 | 符合验证方法属性规则的一组验证方法的( 映射)。 |
authentication |
否 | 符合验证方法属性规则的一组可验证方法的映射或符合3.2 DID URL 语法规则的一串字符串。 |
assertionMethod |
否 | |
keyAgreement |
否 | |
capabilityInvocation |
否 | |
capabilityDelegation |
否 | |
service |
否 | 符合Service properties规则的一组服务端点的映射。 |
属性 | 必要性? | 值约束 |
---|---|---|
id |
是 | 符合3.2 DID URL 语法规则的一个字符串。 |
controller |
是 | 符合3.1 DID 语法规则的一个字符串。 |
type |
是 | 一个 字符串。 |
publicKeyJwk |
否 | 符合 [RFC7517]规则的一个表示 JSON Web Key的映射。更多约束请参考definition of publicKeyJwk。 |
publicKeyMultibase |
否 | 符合[MULTIBASE]编码公钥的一个字符串。 |
属性 | 必要性? | 约束值 |
---|---|---|
id |
是 | 符合[RFC3986]URIs规则的一个字符串 。 |
type |
是 | 一个字符串 或者一 组字符串。 |
serviceEndpoint |
是 | 一个或者一组符合[RFC3986]URIs规则的字符串,或者一个映射。 |
本节描述DID 文档包含DID 对象 和DID 控制者标识符的机制。
一个特定DID 对象的DID使用DID 文档中的id
属性来表示。
id
的属性值必须是一个符合 3.1 DID 语法规则的字符串,并且该值必须存在于DID 文档的数据模型的根的映射中。
{ "id": "did:example:123456789abcdefghijk" }
DID 控制者是被授权的可以对DID 文档进行修改的实体。DID 方法中定义了授权 DID 控制者 的过程。
controller
的属性是可选择 的。如果存在,其值必须是符合 3.1 DID 语法规则的 字符串 或一组字符串的集合。相应的 DID 文档应明确包含允许使用某些 验证方法 用于对特定关系的验证 验证关系 。
当某个controller
属性存在于一个 DID 文档中时,其值表示一个或多个 DIDs。DID 文档中包含的任何一个验证方法 都应被视为是权威的,满足这些验证方法的证明可以被视为等同于DID 对象提供的证明。
{ "@context": "https://www.w3.org/ns/did/v1", "id": "did:example:123456789abcdefghi", "controller": "did:example:bcehfew7h32f32h7af3", }
一个 DID 对象 可以拥有多个标识符,用于不同的目的或不同的场合。当一个 DID 对象 拥有两个或多个DIDs(或其它形式的URI)时,可以使用alsoKnownAs
来表示。
alsoKnownAs
属性是可选择 的。如果存在,则值必须是一个集合 ,并且集合中的每个项目都是符合 [RFC3986]的一个URI。
应用程序可能会选择将两个alsoKnownAs
的标识符视为等同的,如果alsoKnownAs
关系以相反的方向关联。最佳的做法是,在没有这种反向关系的情况下,不要将它们视为等同。换句话说,alsoKnownAs
断言的出现并不能完全证明该断言是真实的。因此,强烈建议请求方获得对alsoKnownAs
断言的独立验证。
考虑到 DID 对象 可能会使用不同的标识符用于不同的目的,将两个标识符强行划等号或者合并两个DID 文档的信息是不一定合适的,即使标记的两者之间存在相互关系。
一个DID 文档 可以表达 验证方法,例如加密公钥,可用于验证 或者授权与 DID 对象 或相关方的交互。举例来看,一个加密公钥可用作数字签名的验证方法;在这种用法中,它验证了签名者是否可以使用关联的加密私钥。验证方法可能需要用到许多参数。一个例子就是一组有五个的加密密钥,其中三个都需要对加密阈值进行签名。
此verificationMethod
属性是可选 的。如果存在,则其值必须是 验证方法的 集合 ,其中每个验证方法 都使用 映射来表示。 验证方法 映射 必须包括id
,type
,controller
和由type
所定义的特定验证材料5.2.1 验证材料的属性。一个验证方法可以包含附加属性。验证方法应该在DID 规范注册表 [DID-SPEC-REGISTRIES]中注册。
验证方法 中 id
属性的值必须 是符合 3.2 DID URL 语法规则的字符串 。
type
属性的值必须 是引用一种验证方法类型的字符串。为了最大限度地提高全球互操作性,验证方法类型应该在DID 规范注册表[DID-SPEC-REGISTRIES]中注册。
controller
属性的值必须 是符合 3.1 DID 语法规则的字符串 。
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1"
"https://w3id.org/security/suites/ed25519-2020/v1"
]
"id": "did:example:123456789abcdefghi",
...
"verificationMethod": [{
"id": ...,
"type": ...,
"controller": ...,
"publicKeyJwk": ...
}, {
"id": ...,
"type": ...,
"controller": ...,
"publicKeyMultibase": ...
}]
}
controller
属性的语义在关系的主体为DID 文档时,与关系的主体为验证方法(例如加密公钥)时相同。由于密钥无法控制自身,且密钥的控制者无法从 DID 文档 中推断,因此需要明确表达密钥控制者的身份。不同之处在于,验证方法的controller
的值不一定是DID 控制者。DID 控制者通过DID 文档最高层级(数据模型中的最顶层映射)的controller
属性表示;详见 5.1.2 DID 控制者。
验证材料是 验证方法过程中所需要使用的任何信息。验证方法type
的预期属性将用于确定其与此类流程的兼容性。publicKeyJwk
和publicKeyMultibase
是常见的验证材料属性。一个密码套件 规范负责指定验证方法 type
及其相关的验证材料。例如,参考JSON
Web Signature 2020 和 Ed25519 Signature 2020。有关DIDs可用的所有已注册 验证方法 类型和相关验证材料,请参考DID规范注册表[DID-SPEC-REGISTRIES]。
为了增强可互操作实现的可能性,本规范限制了在DID 文档中表达验证材料格式的数量。实施者需要实现的格式越少,他们支持所有格式的可能性就越大。这种方法试图在易于实现和支持历史上广泛部署的格式之间取得平衡。下面列出了两个受支持的验证材料属性:
此 publicKeyJwk
属性是可选的。如果存在,则值必须是符合 [RFC7517]表示JSON Web Key的一个映射 。该映射 必须不能包含"d"或者 Registration
Template中描述的任何其他私有信息类成员。建议使用JWKs[RFC7517]表示其公钥的验证方法使用 kid
值作为其 片段标识。建议将 JWKkid
值设置为公钥指纹 [RFC7638]。参考例子 13 中的第一个key,作为具有复合密钥标识符的公钥示例。
publicKeyMultibase
属性是可选的 。此功能是非规范的。如果选择使用,则值必须是符合[MULTIBASE] 编码公钥的一串 字符串
注意, [MULTIBASE]规范尚未成为标准,可能会发生变化。此数据格式可能存在一些用例,其中 publicKeyMultibase
已经被定义并且允许表达公钥,但是 privateKeyMultibase
未被定义,以防止意外泄漏密钥。
一个验证方法不能包含同一材料的多个验证材料属性。例如,禁止在验证方法 中同时使用
和publicKeyJwk
publicKeyMultibase
来表达密钥材料。
下面的案例展示了包含上述两个属性的验证方法 的 DID 文档
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/jws-2020/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ] "id": "did:example:123456789abcdefghi", ... "verificationMethod": [{ "id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A", "type": "JsonWebKey2020", // external (property value) "controller": "did:example:123", "publicKeyJwk": { "crv": "Ed25519", // external (property name) "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ", // external (property name) "kty": "OKP", // external (property name) "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A" // external (property name) } }, { "id": "did:example:123456789abcdefghi#keys-1", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:pqrstuvwxyz0987654321", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }], ... }
验证方法可以嵌入到,或,从与各种 验证关系 (见5.3 验证关系描述)相关的属性中引用。引用 验证方法使得这些方法可以被多个 验证关系使用。
如果 验证方法 的值是一个 映射,则表示已嵌入验证方法 并且可以直接访问其属性。但是,如果值是URL 字符串,则表示已通过引用包含了 验证方法 ,并且需要从 DID 文档 的其他位置或另一个DID 文档中检索其属性。这是通过取消引用URL,并在结果资源中搜索具有ID属性(其值与URL匹配)的验证方法 映射 。
{ ... "authentication": [ // this key is referenced and might be used by // more than one verification relationship "did:example:123456789abcdefghi#keys-1", // this key is embedded and may *only* be used for authentication { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], ... }
DID 对象和验证方法之间的验证关系在 DID 文档中有明确说明。与特定验证关系无关的验证方法 不能用于该 验证关系。例如, authentication
属性值中的验证方法不能用于与DID 对象进行密钥协商协议——需要使用
的属性值来实现这个验证过程。
keyAgreement
DID 文档 不使用 验证关系来表示已经撤销的密钥。如果被引用的验证方法不在用于取消引用它的最新DID 文档 中,则该验证方法被视为无效或已撤销。每个 DID 方法规范都应该详细说明如何执行和跟踪撤销。
以下各章节定义了几种有用的 验证关系。一个 DID 文档 可能包含其中任何一种或其它属性以用来表达特定的验证关系。为了最大限度地提高全球互操作性,所使用的任何此类属性都应该在DID规范注册表 [DID-SPEC-REGISTRIES]中注册。
验证关系用于指定如何对 DID 对象 进行验证,例如登录网站或参与任何类型的质询-响应协议。
authentication
authentication
属性是可选的。如果存在,则关联值必须是一个或多个验证方法的集合 。每种验证方法都可以被嵌入或被引用。
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:example:123456789abcdefghi", ... "authentication": [ // this method can be used to authenticate as did:...fghi "did:example:123456789abcdefghi#keys-1", // this method is *only* approved for authentication, it may not // be used for any other proof purpose, so its full description is // embedded here rather than using only a reference { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2020", "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], ... }
如果建立了身份验证,则由DID 方法 或其它应用程序来·决定如何处理该信息。可以由特定的 DID 方法 来决定 DID 控制者 是否足够来证明身份,以此执行 DID 文档的更新、删除及其他修改操作。另一种DID 方法 可能需要提供与用于验证密钥不同的密钥或者完全不同的 验证方法 来更新或删除 DID 文档 。换句话说,身份验证之后所做的事情超出了数据模型的范围;DID 方法和应用程序应该自己定义这些内容。
这对于任何需要检查尝试身份验证的实体是否真实出示有效身份验证证明的身份验证者都很有用。当一个验证者收到一些数据(以某种协议特定的格式)时,其中包含为“身份验证”而制作的证明,并且表明实体由 DID标记,则该验证者会检查以确保可以使用DID 文档中列出的 验证方法 (例如公钥)来验证该证明。
注意, DID 文档 的属性指示的验证方法 只能用于验证 DID 对象。要验证不同的DID控制者,需要通过自身的DID 文档 以及相关的验证关系进行验证。
assertionMethod
验证关系用于详细说明 DID 对象 如何表达声明,例如,声明自己颁发了可验证凭证[VC-DATA-MODEL]。
assertionMethod
属性是可选的。如果存在,则关联值必须是一个或多个验证方法的一个集合。每种验证方法都可以被嵌入或被引用。
这种属性在验证者处理一个 可验证凭证 的过程中非常有用。在验证过程中,验证者通过检查用于 assertionMethod
的验证方法是否与相应 DID 文档中的属性相关联,以此来检查可验证凭证 是否包含由 DID 对象创建的证明。
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:example:123456789abcdefghi", ... "assertionMethod": [ // this method can be used to assert statements as did:...fghi "did:example:123456789abcdefghi#keys-1", // this method is *only* approved for assertion of statements, it is not // used for any other verification relationship, so its full description is // embedded here rather than using a reference { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], ... }
keyAgreement
验证关系用于指定实体如何生成针对 DID 对象预期加密信息的可传输加密材料,例如,为了与接收者建立安全通信的通道。
keyAgreement
属性是可选的。如果存在,则关联值必须是一个或多个验证方法的一个集合。每种 验证方法可以被嵌入或被引用。
此属性的一个示例是对DID 对象加密一条预期消息。在这种情况下,对方在 验证方法中使用加密公钥信息来包装一个接收者的解密密钥。
{ "@context": "https://www.w3.org/ns/did/v1", "id": "did:example:123456789abcdefghi", ... "keyAgreement": [ // this method can be used to perform key agreement as did:...fghi "did:example:123456789abcdefghi#keys-1", // this method is *only* approved for key agreement usage, it will not // be used for any other verification relationship, so its full description is // embedded here rather than using only a reference { "id": "did:example:123#zC9ByQ8aJs8vrNXyDhPHHNNMSHPcaSgNpjjsBYpMMjsTdS", "type": "X25519KeyAgreementKey2019", // external (property value) "controller": "did:example:123", "publicKeyMultibase": "z9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE" } ], ... }
capabilityInvocation
验证关系用于指定DID 对象可能用来调用加密功能的验证方法,例如对更新 DID 文档的授权。
capabilityInvocation
属性是可选的。如果存在,则关联值必须是一个或多个 验证方法的一个集合。每种验证方法可以被嵌入或被引用。
此属性的一个示例是,当 DID 对象 需要访问受保护的HTTP API时(该API需要授权才能使用)。为了在使用HTTP API时获得授权, DID 对象使用与通过HTTP API公开的特定URL关联的功能。该功能的调用可以通过多种方式表达,例如,作为放置在HTTP标头中的数字签名消息。
提供HTTP API的服务器是该功能的验证者(verifier),它需要验证所调用功能所引用的验证方法是否存在于 DID 文档capabilityInvocation
的属性中。验证者还会检查以确保所执行的操作有效,并且该功能适合所访问的资源。如果验证成功,则服务器已通过加密方式确定调用者有权访问受保护的资源。
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:example:123456789abcdefghi", ... "capabilityInvocation": [ // this method can be used to invoke capabilities as did:...fghi "did:example:123456789abcdefghi#keys-1", // this method is *only* approved for capability invocation usage, it will not // be used for any other verification relationship, so its full description is // embedded here rather than using only a reference { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], ... }
capabilityDelegation
验证关系用于指定DID 对象可能使用的一种机制,以将加密功能委托给另一方。例如,将访问特定HTTP API的权限委托给下属。
capabilityDelegation
属性是可选的。如果存在,则关联值必须是一个或多个验证方法的一个集合。每种验证方法可以被嵌入或被引用。
此功能的一个示例是,当DID 控制者选择将其访问受保护HTTP API的能力委托给自己以外的一方时。为了委托该能力, DID 对象将使用与capabilityDelegation
验证关系相关联的 验证方法 将该能力以加密方式签名给另一个 DID 对象。然后,委托人将以类似于 5.3.4 能力调用中所示例的方式使用该能力。
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:example:123456789abcdefghi", ... "capabilityDelegation": [ // this method can be used to perform capability delegation as did:...fghi "did:example:123456789abcdefghi#keys-1", // this method is *only* approved for granting capabilities; it will not // be used for any other verification relationship, so its full description is // embedded here rather than using only a reference { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], ... }
DID 文档中的服务用于表达与DID 对象或相关实体进行通信的方式。一个服务可以是 DID 对象 想要宣传的任何类型的服务,包括用于 分布式身份管理 服务的进一步挖掘、身份验证、授权或者交互。
出于隐私方面的考虑,不鼓励通过社交媒体账户、个人网站和电子邮件地址等 服务泄漏公共信息。有关隐私问题的进一步探讨,请参阅 10.1 保护个人数据隐私和10.6 服务隐私。与服务相关的信息通常是特定的服务。例如,与加密消息服务相关的信息可以表达在消息传递开始之前如何启动加密链接。
service
属性是可选的。如果存在,则关联值必须是服务的一个集合,其中每个服务都由一个 映射描述。每个 服务的映射必须包含id
, type
,和serviceEndpoint
属性。每个服务扩展可以包括其它属性,并且可以进一步限制与扩展相关的属性。
id
属性的值必须是符合[RFC3986]的URI。一个符合要求的生产者不得生产具有相同id
的多个 service
条目。一个符合要求的消费者如果检测到具有相同id
的多个 service
条目时,必须报错。
type
属性的值必须是一个 字符串或一组字符串的集合。为了最大限度地提高互操作性, 服务类型及其相关属性应该在DID规范注册表[DID-SPEC-REGISTRIES]中注册。
serviceEndpoint
属性的值必须是一个 字符串,一个映射或由多个 字符串 和/或 映射组成的集合。所有 字符串的值必须是符合 [RFC3986]的URIs,并根据 RFC3986 中的标准化和比较规则 和其他适用 URI规范方案中的规则进行标准化。
与 服务 有关的隐私和安全考虑事项,请参考10.6 服务隐私, 10.1 保持个人数据隐私, 10.3 DID文档关联风险, 和 9.3 身份验证服务端点.
{
"service": [{
"id":"did:example:123#linked-domain",
"type": "LinkedDomains", // external (property value)
"serviceEndpoint": "https://bar.example.com"
}]
}
本规范中DID 文档的具体序列化称为“ 表示”。通过一个称为“生产(production)”的过程,将 数据模型 序列化,从而创建表示。表示另通过一个称为“消费(consumption)”的过程转化为 数据模型。生产 和消费 流程实现了信息从一种表示 到另一种的转换。本规范定义了 JSON 和 JSON-LD 表示 ,开发人员也可以使用能表达 数据模型的任何其他表示,如 XML 或 YAML。以下各节定义了 生产和消费的一般规则以及 JSON 和 JSON-LD 表示。
除了本规范中定义的 表示 外,执行者还可以使用其它表示,但必须对每种表示进行适当的规定(包括对 DID 规范注册表 [DID-SPEC-REGISTRIES]) 中未列出的属性进行互操作处理的规则)。更多信息,请参阅4.1 可扩展性 。
“ 表示”应满足如下要求:
dateTime
词法序列化来表示日期时间。
只要返回数据模型的消费 过程是无损的, 表示可以选择使用不同的词法序列化来序列化 数据模型的数据类型。例如,一些基于 CBOR 的表示使用整数来表达 日期时间值,以表示自 Unix 时间起的秒数。
对所有符合要求的生产者的要求如下:
对所有符合要求的消费者的要求如下:
The upper left quadrant of the diagram contains a rectangle with dashed grey outline, containing two blue-outlined rectangles, one above the other. The upper, larger rectangle is labeled, in blue, "Core Properties", and contains the following INFRA notation:
«[
"id" → "example:123",
"verificationMethod" → « «[
"id": "did:example:123#keys-1",
"controller": "did:example:123",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
]» »,
"authentication" → «
"did:example:123#keys-1"
»
]»
The lower, smaller rectangle is labeled, in blue, "Core Representation-specific
Entries (JSON-LD)", and contains the following monospaced INFRA notation:
«[ "@context" → "https://www.w3.org/ns/did/v1" ]»
From the grey-outlined rectangle, three pairs of arrows extend to three different black-outlined rectangles, one on the upper right of the diagram, one in the lower right, and one in the lower left. Each pair of arrows consists of one blue arrow pointing from the grey-outlined rectangle to the respective black-outlined rectangle, labeled "produce", and one red arrow pointing in the reverse direction, labeled "consume". The black-outlined rectangle in the upper right is labeled "application/did+cbor", and contains hexadecimal data. The rectangle in the lower right is labeled "application/did+json", and contains the following JSON data:
{
"id": "did:example:123",
"verificationMethod": [{
"id": "did:example:123#keys-1",
"controller": "did:example:123",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
}],
"authentication": [
"did:example:123#keys-1"
]
}
The rectangle in the lower left is labeled "application/did+ld+json", and contains the following JSON-LD data:
{
"@context": ["https://www.w3.org/ns/did/v1"],
"id": "did:example:123",
"verificationMethod": [{
"id": "did:example:123#keys-1",
"controller": "did:example:123",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
}],
"authentication": [
"did:example:123#keys-1"
]
}
DID 文档、DID 文档数据结构和针对特定条目表示的条目映射必须根据以下生产规则序列化为 JSON 表示:
数据 类型 | JSON 表示类型 |
---|---|
map | 一个JSON 对象,其中每个条目都被序列化为 JSON 对象的一个成员,条目键为一个JSON 字符串成员名,条目值则根据其类型(如表中所定义)确定。 |
list | 一个 JSON 数组,列表中的每个元素都会根据其类型(如表中所定义)依次序列化为数组的值。 |
set | 一个JSON 数组,集合中的每个元素都会根据其类型(如表中所定义)依次添加为数组的值。 |
datetime |
序列化为XML 日期事件的 JSON 字符串,时间归一化为 UTC 00:00:00,不含小数点后两位。例如:2020-12-20T19:17:47Z 。
|
string | 一个JSON字符串. |
integer | 不含小数或分数成分的 JSON 数字 。 |
double | 带有小数和分数成分的 JSON 数字。 |
boolean | 一个JSON布尔值. |
null | 一个JSON 空字面. |
建议所有创建生成JSON 表示 的符合要求的生产者 的执行者确保其算法符合 [INFRA] 规范中的JSON 序列化规则 ,以及 JSON [RFC8259] 规范中有关数字的精度建议。
所有DID文档的条目必须包含在根JSON 对象中。条目可以包含附加的数据子结构,但需遵守上述列表中的值表示规则。
当序列化一个DID文档时,一个符合规范的生产者必须
指定一个媒体类型为application/did+json
,以便下游应用程序识别,如在7.1.2 DID解析元数据中所述。
{ "id": "did:example:123456789abcdefghi", "authentication": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "Ed25519VerificationKey2018", "controller": "did:example:123456789abcdefghi", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }] }
DID 文档 和DID文档数据结构的JSON 表示 必须 根据以下消费规则反序列化到数据模型中:
JSON 表示 类型 | 数据 类型 |
---|---|
JSON 对象 | 一个映射,其中 JSON 对象的每个成员都作为一个条目添加到映射中。每个条目的关键字都被设置为 JSON 对象成员的名称。 |
数据模型条目值为列表或未知数的 JSON 数组 | 一个 列表,其中 JSON 数组的每个值都会按顺序添加到列表中,并根据本表中定义的数组值的 JSON 表示类型进行转换。 |
JSON 数组,其中数据模型条目值是一个集合 | 一个集合,其中 JSON 数组的每个值都会按顺序添加到集合中,并根据本表中定义的数组值的 JSON 表示类型进行转换。 |
数据模型 输入值为时间日期的 JSON 字符串 | 时间日期. |
JSON 字符串,其中 数据模型条目值类型为字符串 或未知值 | 字符串. |
不含小数或分数成分的JSON 数字 | 整数. |
带有小数和分数成分的 JSON 数字,或者输入值为双精度浮点型 时,无论是否包含分数成分。 | 双精度浮点小数. |
JSON 布尔值 | 布尔值. |
JSON 空字面 | 空 值. |
我们建议所有创建 符合要求的消费者 的执行者,在生成 JSON表示时,确保其算法符合 [INFRA] 规范中的 JSON 转换规则,以及 JSON [RFC8259] 规范中有关 数字的精度建议。
如果媒体类型信息可供符合规范的消费者使用,并且媒体类型的值是application/did+json
,则被消费的数据结构是一个DID文档,根元素必须是一个JSON 对象,其中对象的所有成员都是DID文档的条目。对于JSON表示的符合规范的消费者,如果消费的DID文档的根元素不是一个JSON 对象,则必须报告一个错误。
JSON-LD [JSON-LD 1.1] 是一种基于JSON的格式,用于序列化链接数据。本节定义了JSON-LD 表示的生产和消费规则。
DID 文档、DID文档数据结构和特定于表示的条目 必须根据定义在6.2 JSON中的JSON 表示的生产规则序列化为JSON-LD 表示。
除了使用JSON 表示的生产规则外,JSON-LD生产必须 包含特定于表示的 @context
条目。@context
的序列化值必须是JSON字符串https://www.w3.org/ns/did/v1
,或者是一个JSON数组,其中第一个元素是JSON字符串https://www.w3.org/ns/did/v1
,而随后的元素则根据JSON 表示的生产规则进行序列化。
{
"@context": "https://www.w3.org/ns/did/v1",
...
}
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://did-method-extension.example/v1"
],
...
}
所有创建符合规范的生产者以产生JSON-LD 表示的实现者被建议确保他们的算法产生有效的JSON-LD [JSON-LD 1.1]文档。无效的JSON-LD文档将导致JSON-LD处理器停止并报告错误。
为了实现不同表示之间的互操作性,所有JSON-LD上下文及其术语应该在DID规范注册表[DID-SPEC-REGISTRIES]中注册。
一个生成JSON-LD 表示的符合规范的生产者 不应 生成一个包含未通过@context
定义的术语的DID文档,因为预期符合规范的消费者会移除未知术语。当序列化一个DID文档的JSON-LD 表示时,一个符合规范的生产者 必须 指定一个媒体类型为application/did+ld+json
,以便下游应用程序识别,如在7.1.2 DID解析元数据中所述。
DID 文档以及任何通过JSON-LD 表示表达的DID文档数据结构必须根据定义在6.2 JSON中的JSON 表示的消费规则反序列化到数据模型中。
对于创建消费JSON-LD 表示的符合规范的消费者的所有实现者,建议确保他们的算法只接受有效的JSON-LD [JSON-LD 1.1]文档。无效的JSON-LD文档会导致JSON-LD处理器停止并报告错误。
本章节定义了DID 解析的输入输出以及DID URL 解引用。其具体实现不在本规范的范围内,但在[DID-RESOLUTION]中讨论了一些实现时的注意事项。
所有符合规范的 DID 解析器 必须 实现至少一种DID 方法的DID 解析函数并且必须 能够以至少一种符合规范的格式表示返回一个DID 文档。
DID 解析函数通过适用DID方法的“读”操作(详见 8.2 方法操作) 将DID 文档解析为DID 方法。 此过程的具体实现细节不在本规范的范围内,单所有符合规范的DID 解析器均应实现以下函数,这些函数应具有以下抽象形式:
resolve(did, resolutionOptions) →
« didResolutionMetadata, didDocument, didDocumentMetadata »
resolveRepresentation(did, resolutionOptions) →
« didResolutionMetadata, didDocumentStream, didDocumentMetadata »
resolve
函数以抽象数据结构(一个映射)返回 DID 文档。
resolveRepresentation
函数返回的是以相应格式表示的 DID
文档 的字节流。
The upper middle part of the diagram contains a rectangle with dashed grey outline, containing two blue-outlined rectangles, one above the other. The upper, larger rectangle is labeled, in blue, "Core Properties", and contains the following INFRA notation:
«[
"id" → "example:123",
"verificationMethod" → « «[
"id": "did:example:123#keys-1",
"controller": "did:example:123",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
]» »,
"authentication" → «
"did:example:123#keys-1"
»
]»
The lower, smaller rectangle is labeled, in blue, "Core Representation-specific Entries (JSON-LD)", and contains the following monospaced INFRA notation:
«[ "@context" → "https://www.w3.org/ns/did/v1" ]»
From the grey-outlined rectangle, three pairs of arrows extend to three different black-outlined rectangles, aligned in a horizontal row side-by-side, in the bottom half of the diagram. Each pair of arrows consists of one blue arrow pointing from the grey-outlined rectangle to the respective black-outlined rectangle, labeled "produce", and one red arrow pointing in the reverse direction, labeled "consume". The first black-outlined rectangle in the row is labeled "application/did+ld+json", and contains the following JSON-LD data:
{
"@context": ["https://www.w3.org/ns/did/v1"],
"id": "did:example:123",
"verificationMethod": [{
"id": "did:example:123#keys-1",
"controller": "did:example:123",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
}],
"authentication": [
"did:example:123#keys-1"
]
}
The second rectangle in the row is labeled "application/did+json" and contains the following JSON data:
{
"id": "did:example:123",
"verificationMethod": [{
"id": "did:example:123#keys-1",
"controller": "did:example:123",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA"
}],
"authentication": [
"did:example:123#keys-1"
]
}
The third rectangle in the row is labeled "application/did+cbor", and contains hexadecimal data.
In the left part of the diagram, in the middle, there is a box, with black outline and light gray background. This box is labeled "VERIFIABLE DATA REGISTRY" and contains a symbol representing a graph with nodes and arcs. From this box, one arrow, labeled "resolve()", extends upwards and points to the top half of the diagram where the grey-outlined rectangle is located. Another arrow, labeled "resolveRepresentation()", extends downwards and points to the bottom half of the diagram, where the row of three black-outlined rectangles is located.
resolve
函数和resolveRepresentation
函数的输入参数如下:
这些函数都包括多个返回值,并没有对这些返回值如何一起返回给出限制。resolve
的返回值包括didResolutionMetadata、didDocument和didDocumentMetadata。resolveRepresentation
的返回值包括didResolutionMetadata、didDocumentStream和didDocumentMetadata。这些值如下所述:
resolve
函数和resolveRepresentation
函数时会发生变化,它表达了解析过程本身的数据。该结构是必需的,并且在解析过程中发生错误时也不得为空。此元数据在7.1.2 DID 解析元数据中定义。如果调用了resolveRepresentation
函数,该结构必须 包含一个contentType
属性,用于表示在didDocumentStream
中对应的媒体类型。如果解析未成功,则该结构必须包含一个描述错误的error
属性。
resolve
函数,则该值 必须是符合4. 数据模型中描述的DID 文档的抽象数据模型(映射,映射),该模型可以使用表示形式指定的生成规则转换为符合规范的DID 文档(表示形式)。解析得到的 DID 文档中的id
值必须与解析的DID一致。如果解析不成功,则该值必须 为空。
resolveRepresentation
函数,则该值必须是解析得到的DID
文档的字节流,且以一种符合规范的格式来表示。该字节流随后可以通过调用 resolveRepresentation
函数解析为一个一个数据模型,进而进行验证和处理。如果解析不成功,则该值必须 为空流。
didDocument
属性中 DID 文档的元数据。didDocumentMetadata表示的是关于DID
文档的元数据,通常在resolve
函数和resolveRepresentation
函数的调用之间保持不变,除非DID 文档本身发生更改。如果解析不成功,则此输出 必须 为一个空 元数据结构。本规范定义的属性在7.1.3 DID 文档元数据中有详细说明。
符合规范的DID 解析器的实现不得以任何方式更改这些函数的型构。DID 解析器 的实现可以将resolve
函数和resolveRepresentation
函数映射到特定方法的内部函数,以执行实际的DID 解析过程。DID 解析器的在实现resolve
函数和resolveRepresentation
函数之外,可以提供其他不同签名/函数型构的其他函数实现。
该结构中的可能属性及其可能值已在DID规范注册表 [DID-SPEC-REGISTRIES] 中注册。本规范定义了以下通用属性。
didDocumentStream
中的表达形式。该属性对于didDocumentStream
函数是可选的,并且不得与resolve
函数一起使用。
该结构中的可能属性及其可能值已在DID规范注册表 [DID-SPEC-REGISTRIES] 中注册。本规范定义了以下DID解析元数据属性:
didDocumentStream
的媒体类型。如果解析成功且调用了resolveRepresentation
函数,则该属性是必需的。如果调用了 resolve
函数,则该属性不得存在。该属性的值必须是ASCII 字符串,以符合规范的媒体类型来表示。resolveRepresentation
函数的调用方必须使用此值来确定如何将该函数返回的didDocumentStream
解析和处理为数据模型。
accept
输入元数据属性请求的表达形式不被DID 方法和/或DID 解析器的实现支持,则返回此错误代码。
该结构中的可能属性及其可能值应该在DID规范注册表 [DID-SPEC-REGISTRIES] 中注册。本规范定义了以下通用属性。
created
属性,以指示 创建操作的时间戳。该属性的值必须是格式化为XML Datetime格式的字符串,用UTC 00:00:00的标准化时间表达,并且不带亚秒小数精度。例如:2020-12-20T19:17:47Z
。
updated
属性,以指示已解析文档版本的最后更新操作的时间戳。该属性的值必须遵循与created
属性相同的格式规则。如果从未对DID 文档执行过更新操作,则将省略updated
属性。如果存在updated
属性,当两个时间戳之间的差异少于一秒时,它的值可以与created
属性相同。
true
。如果DID未被停用,则该属性是可选的,但如果包含,则必须具有布尔值false
。
nextUpdate
属性。它指示下一个 更新操作的时间戳。该属性的值必须遵循与created
属性相同的格式规则。
versionId
属性,以指示已解析文档版本的最后一次更新操作的版本。该属性的值必须是一个ASCII 字符串。
nextVersionId
属性。它指示下一个 更新操作的版本。该属性的值必须是一个ASCII 字符串。
一个DID 方法可以定义逻辑上等价的不同形式的DID。例如,当DID在 可验证数据注册表注册之前采用一种形式,而在注册之后采用另一种形式,在这种情况下,DID 方法可能需要将一个或多个与已解析DID逻辑上等价的DID作为DID 文档的属性进行表达。这就是equivalentId
属性的目的。
DID 文档元数据可以包括一个equivalentId
属性。如果存在,则其值必须是一个集合,其中每个项都是符合第3.1 DID 语法规则的字符串 。这个关系表明,每个equivalentId
值在逻辑上等同于id
属性值,因此指向相同的DID 对象。每个equivalentId
的DID值必须 由与id属性值相同的DID 方法生成,并且是其一种形式。(例如,did:example:abc
== did:example:ABC
)。)
符合规范的DID 方法规范必须保证每个equivalentId
值在逻辑上等同于id
属性值。
请求方应保留id
属性和equivalentId
属性中的值,以确保与它们包含的任何值的后续交互能够被正确处理为逻辑上等价的(例如,在数据库中保留所有变体,以便与任何一个变体的交互映射到相同的底层数据库账户)。
equivalentId
是一种比alsoKnownAs
更强的等价形式,因为这种等价性必须由管理的DID 方法保证。equivalentId
表示完全的图形合并,因为相同的DID 文档描述了equivalentId属性和id
属性中描述的DID。
如果请求方不保留id
和equivalentId
属性中的值,并确保与它们包含的任何值的后续交互能够被正确处理为逻辑上等价的,则可能出现错误或意外情况。强烈建议实现者遵循与此元数据属性相关的指示。
除以下若干情况之外,canonicalId
属性与equivalentId
属性相同,但是:
a) canonicalId属性仅与一个值关联,而不是与一个值的集合关联;
b) 该属性所给出的 DID是指包含DID 文档中的DID 对象的所对应的规范ID。
DID 文档元数据可以 包括一个canonicalId
属性。如果存在,则其值必须 是一个符合第3.1 DID 语法规则的字符串。这个关系表明,canonicalId
值在逻辑上等同于id
属性值,并且canonicalId
值由 DID 方法定义为包含DID 文档范围内的 DID
对象规范ID。canonicalId
值必须由与id
属性值相同的DID 方法生成,并且是其一种形式。(例如,did:example:abc
== did:example:ABC
)
符合规范的DID 方法必须保证canonicalId
值在逻辑上等同于id
属性值。
请求方应将canonicalId
值用作DID 对象 的主要ID值,并将所有其他等效值视为次要别名(例如,在其系统中更新相应的主要引用,以反映新的规范ID)。
canonicalId
与equivalentId
的等价性声明相同,但它被限制为一个单一的值,该值被定义为在DID
文档范围内的DID 对象规范ID。与equivalentId
相同,canonicalId
表示完全的图形合并,因为相同的DID 文档既描述了canonicalId
DID,也描述了id
属性 DID。
如果解析方不将canonicalId
值用作DID对象的主要ID值,并将所有其他等效值视为次要别名,则可能会出现与用户体验相关的错误或意外问题。强烈建议实现者遵循与此元数据属性相关的指示。
DID URL 解引用函数将DID URL作为一个资源解引用,其内容取决于DID URL的组件,包括DID 方法、特定方法的标识符、路径、查询和片段。此过程依赖于对DID URL中包含的DID 解析的DID。DID URL 解引用可能涉及多个步骤(例如,当要重新访问/解引用的DID URL包含一个片段时),并且该函数定义为在所有步骤完成后返回最终资源。有关此过程如何实现的详细信息不在本规范的范围之内。下图展示了上述关系。
The top left part of the diagram contains a rectangle with black outline, labeled "DID".
The bottom left part of the diagram contains a rectangle with black outline, labeled "DID URL". This rectangle contains four smaller black-outlined rectangles, aligned in a horizontal row adjacent to each other. These smaller rectangles are labeled, in order, "DID", "path", "query", and "fragment.
The top right part of the diagram contains a rectangle with black outline, labeled "DID document". This rectangle contains three smaller black-outlined rectangles. These smaller rectangles are labeled "id", "(property X)", and "(property Y)", and are surrounded by multiple series of three dots (ellipses). A curved black arrow, labeled "DID document - relative fragment dereference", extends from the rectangle labeled "(property X)", and points to the rectangle labeled "(property Y)".
The bottom right part of the diagram contains an oval shape with black outline, labeled "Resource".
A black arrow, labeled "resolves to a DID document", extends from the rectangle in the top left part of the diagram, labeled "DID", and points to the rectangle in the top right part of diagram, labeled "DID document".
A black arrow, labeled "refers to", extends from the rectangle in the top right part of the diagram, labeled "DID document", and points to the oval shape in the bottom right part of diagram, labeled "Resource".
A black arrow, labeled "contains", extends from the small rectangle labeled "DID" inside the rectangle in the bottom left part of the diagram, labeled "DID URL", and points to the rectangle in the top left part of diagram, labeled "DID".
A black arrow, labeled "dereferences to a DID document", extends from the rectangle in the bottom left part of the diagram, labeled "DID URL", and points to the rectangle in the top right part of diagram, labeled "DID document".
A black arrow, labeled "dereferences to a resource", extends from the rectangle in the bottom left part of the diagram, labeled "DID URL", and points to the oval shape in the bottom right part of diagram, labeled "Resource".
所有符合规范的DID 解析器实现以下函数,该函数具有以下抽象形式:
dereference(didUrl, dereferenceOptions) →
« dereferencingMetadata, contentStream, contentMetadata »
dereference
函数的输入参数如下:
虽然可以将任何 didUrl
传递给DID URL解引用器,但实现者应参考[DID-RESOLUTION]以进一步了解如何重新访问/解引用DID URL的常见模式。
didUrl
本身之外的dereference
函数的输入选项。根据本规范定义的属性见7.2.1 DID URL 解引用选项。此输入是必需的,但该结构可以为空。
该函数返回多个值,并且对这些值如何一起返回没有限制。 dereference
的返回值包括dereferencingMetadata
、contentStream
和contentMetadata
:
error
属性,用于描述错误。
dereferencing
函数被成功调用,此处必须包含一个与DID URL相对应的资源。contentStream
可以是可序列化为一种符合规范的资源表示,例如DID
文档 、验证方法、服务或任何其他可以通过媒体类型识别,并通过解析过程获取的资源格式。如果解引用不成功,该值必须为空。
contentStream
的元数据。如果code>contentStream是DID 文档,则此处必须是一个如DID 解析中所述的DID 文档元数据结构。如果解引用不成功,该输出必须是一个空的元数据结构。
符合规范的DID URL 解引用 的实现不得以任何方式更改这些函数的签名/函数型构。DID URL 解引用的实现可以将dereference
函数映射到特定方法的内部函数,以执行实际的DID URL
解引用过程。此外,除了此处指定的 dereference
函数之外,DID URL 解引用 可以实现并公开具有不同签名/函数型构的附加函数。
此结构中的可能属性及其可能值应在DID规范注册表中[DID-SPEC-REGISTRIES]注册。本规范定义了以下解引用选项的常见属性:
contentStream
的首选媒体类型。媒体类型必须以一个ASCII 字符串 表示。如果支持且可用,DID URL 解引用的实现应使用此值来确定返回值中所含表示的contentType
。
此结构中的可能属性及其可能值已在DID规范注册表中 [DID-SPEC-REGISTRIES] 注册。本规范定义了以下常见属性。
contentStream
的媒体类型应该 使用此属性表示。媒体类型值必须 以一个ASCII 字符串表示。
contentStream
。
在DID 解析、DID URL 解引用及其他与DID相关的处理过程中,通常需要设计输入和输出元数据。用于传递这些元数据的结构必须是一组属性组成的映射。每个属性的名称必须是一个字符串。每个属性值必须 是字符串、映射、列表、集合、布尔值或为空。任何复杂数据结构(如映射和列表)中的值必须也是这些数据类型中的一种。所有在[DID-SPEC-REGISTRIES] 注册的元数据属性定义必须定义值类型,包括对该值的任何附加格式或限制(例如,格式为日期或十进制整数的字符串)。推荐 属性定义使用字符串作为值。整个元数据结构必须根据[INFRA] 规范中的JSON 序列化规则是可序列化的。在实现中可以将元数据结构序列化为其他数据格式。
所有使用元数据结构作为输入或输出的函数实现都能够以确定性的方式完全表示此处描述的所有数据类型。由于使用元数据结构的输入和输出是根据数据类型,而不是其序列化定义的,因此表示方法是函数实现内部的内容,不在本规范的范围之内。
以下示例演示了一个可用作 DID 解析输入元数据的JSON编码元数据结构。
{
"accept": "application/did+ld+json"
}
此示例对应于以下格式的元数据结构:
[
"accept" → "application/did+ld+json"
]
以下是一个示例,展示了如果未找到DID时可能使用的JSON编码元数据结构,作为 DID 解析元数据:
{
"error": "notFound"
}
此示例对应以下格式的元数据结构:
[
"error" → "notFound"
]»
下一个示例演示了一个 JSON 编码的元数据结构,该结构可用作 DID 文档元数据,以描述与 DID 文档相关的时间戳。
{
"created": "2019-03-23T06:35:22Z",
"updated": "2023-08-10T13:40:06Z"
}
此示例对应以下格式的元数据结构:
«[
"created" → "2019-03-23T06:35:22Z",
"updated" → "2023-08-10T13:40:06Z"
]»
DID方法 方法定义了如何按照本标准实施DID标识的具体方案和特性。DID方法通常DID方法与一个可验证的数据注册集合或机构相关联。 当定义新的 DID方法 的时候需要制定在其治下的相同DID方法不同实现之间的具体规则以实现互操作性 .
类比来说,DID方法和本标准规定的DID之间的关系类似于特定的统一资源标识符(URI)[IANA-URI-SCHEMES]和IETF的通用统一资源标识符(URI)规范[RFC3986]之间的关系,比如http
这一特定的URI格式可以类比成一个具体的DID方法。另外,当定义一个具体的DID结构的时候,需要同时制定DID方法的规范以定义如何在数据注册集合或机构治下进行DID 和 DID文档的创建、解析、更新和停用。并且DID方法还需要提供其之下DID具体实现的相关文档,比如关于安全性和隐私性要求和考量的文档。
本节中将提供起草和制定上述 DID 方法 的具体规范的相关要求:
所有 DID 方法 的具体规范(以下简称 DID 方法规范)都需要按照下列规则制定该方法下的 DID 语法:
method-name
规则的要求,且一个 DID
方法只能有一个标识符(多个标识符是不允许的)。
method-specific-id
的规则。
DID
方法 规范 必须 对 method-specific-id
值的颗粒度和规范性进行规定。
DID
方法规范必须保证method-specific-id
的标识的全局唯一性,并提供method-specific-id
的方法规则。
method-name
冲突,DID 方法需要在DID规范注册集中注册自己使用的名称和标识[DID-SPEC-REGISTRIES]。
method-specific-id
格式,但这些格式之间不能冲突。
method-specific-id
下的标识格式可以 包含冒号“:”。该 method-specific-id
下的标识格式使用冒号“:” 必须 符合方法规定的标识 ABNF(扩展巴科斯范式)语法格式描述规范。
在 method-specific-id
下的标识中使用冒号“:”是允许的,相关规则完全取决于该DID方法的规定。
例如,冒号“:”可以用于创建在该 DID 方法 下多级命名空间之间的分层结构,也可以用于识别 可验证数据注册集合 或机构中 DID
标识的不同实体和组成部分(比如一个标识是由多个标识部分所组成的情况),或者也可以用于该 DID 方法独有的各种其他用途。
因此,使用 DID
方法 作为标识应用的开发者不应对 DID 方法下标识中的冒号“:”的作用或行为做出任何的假设,DID 规范也没有规定任何通用的 DID 方法下标识中冒号“:”使用的通用原则。
所有 DID 方法 规范都需要按照下列原则制定该方法下的方法操作的相关规则:
授权操作的执行方的前线是受限于特定的 DID方法。例如,DID方法 可能会 :
控制者
属性来进行授权操作。
授权
.
capabilityInvocation
验证关系 指定的 验证方法进行授权。
所有 DID方法 规范都需要按照下列原则制定该方法下的 安全性注意事项 的相关规则:
所有DID方法规范都需要按照下列原则制定该方法下的隐私性考量的相关规则:
本章节为非规范性内容
本章节介绍了将分布式标识(DIDs)技术部署到生产环境之前,应考虑的各种安全事项。DIDs的设计目的是在威胁模型中进行操作,这些模型记录在IETF(互联网工程任务组)标准和[RFC3552]中。本章节详细阐述了 [RFC3552] 中的一些注意事项,以及专属于DID架构的其他注意事项。
DID规范注册表[DID-SPEC-REGISTRIES]是一个包含DID 方法名及其对应规范的信息列表。实施者需注意,没有一个中心化机构可以强制将某个DID 方法规范与特定的DID 方法名绑定。如果不确定某个特定DID 解析器是否正确执行了某个DID 方法,可以对照DID规范注册表查找已注册的规范,并据之选择合适的 DID 解析器。
将数字世界或物理世界中的实体与特定DID、DID 文档或密钥绑定,需要使用本规范所设计的安全协议。以下部分描述了需要证明这种绑定关系的一些场景,以及相关实体在身份验证或授权中如何证明对DID或DID 文档的控制权。
在进行可验证数据注册表更新或远程系统验证时,需要证明对 DID和/或 DID 文档有控制权。数字签名算法和可验证时间戳使得与DID 文档相关的某些安全协议能够进行密码学层面的安全验证。为此,本规范在5.3.1节“身份验证”(5.3.1 验证 )和5.3.4节“能力调用”(5.3.4 能力调用)章节中定义了有效的验证关系。与验证方法相关联的密钥可用于生成数字签名,作为身份验证或授权安全协议的一部分。
一个DID和 DID 文档本身并不携带任何个人数据,强烈建议非公共实体不要在 DID 文档中发布个人数据。
将一个DID与个人或组织的物理身份进行绑定时,一个有效做法是由一个受信任的权威机构进行可证明的断言,如政府机构。为此,本规范提供了5.3.2“验证关系断言”( 5.3.2 断言验证关系)。此章节特性可以实现隐私交互,并且可以在一个或多个司法管辖区内被视为具有法律效力;建立这样的绑定关系必须同时慎重的考虑隐私保护问题(见10.隐私考虑(10. 隐私考虑))。
本规范考虑将DID绑定到物理世界中的某个事物(如个人或组织)——如通过使用与DID对象相同的可验证凭证,并在可验证凭证数据模型[VC-DATA-MODEL]中进一步定义。
如果一个DID 文档发布了一个用于DID对象身份验证或授权的服务(见第 5.4“服务”章节( 5.4 服务)),那么服务端点提供方、主体或请求方有责任遵守该服务端点所支持的身份验证协议的要求。
如果满足以下条件,DIDs和DID 文档的更新就具有不可否认性:
针对未经授权的DID 文档更改,一个应对方法是开展实时监控并在更改发生时主动通知 DID 对象。这就类似于向已注册的电子邮件地址发送密码重置通知以防止用户名/密码账户被盗用。
不同的是,在DID中没有中间注册商或账户提供商来生成此类通知。然而,如果注册DID的 可验证数据注册表直接支持更改通知,则可以向DID 控制者提供订阅服务。可以直接将通知发送到现有DID中列出的相关服务端点。
如果DID 控制者选择依赖第三方监控服务(而非 可验证数据注册表本身),这会引入另一个攻击向量。 在DID架构中,可能没有中心化的机构来执行密钥和数字签名的过期策略。因此,请求方需要通过DID 解析器和验证库等支撑软件,来证明密钥在使用时仍在有效期内。请求方可能会在其验证过程中采用自己的过期策略。例如,一些请求方可能将过去五分钟内的验证设为有效,而具有高精度时间源的请求方可能要求将验证时间戳设为500毫秒内。
有些请求方需要在密钥过期后继续使用,例如验证旧的数字签名。这种情况下,请求方可能会指示验证软件忽略密钥期限要求或判断密钥在使用时是否已过期。
轮换机制是一种管理过程,这一过程使得新的验证方法添加到DID 文档后,采用现有验证方法的密钥将被停用或销毁。此后,控制者可应用新密钥生成证明,并且可使用新验证方法进行验证。
轮换机制可以有效防止验证方法遭受攻击,因为控制器频繁地轮换验证方法可以降低单个验证方法被攻破的风险。在验证方法轮换之后立即执行撤销,对于一些用于短期验证的验证方法很有效,例如加密消息和身份验证中涉及的验证方法。
在应用验证方法轮换机制时,有以下注意事项:
撤销机制是一种管理过程,这一过程可以使现有验证方法生成的密钥失效,使其不再能验证新创建的数字签名。
撤销机制是验证方法被攻破后做出的有效反应。在轮换后立即执行撤销对于控制者指定用于短期验证的验证方法很实用,例如消息加密和身份验证中的验证方法。
与验证方法相关的密钥被攻破后,攻击者可以根据控制者在DID 文档中表达的验证关系开展攻击,例如用于身份验证。验证方法从注册到撤销期间,攻击者和合法控制者的使用很难区分。
应用验证方法撤销时,有以下注意事项:
尽管验证者可能选择不接受来自已撤销的验证方法的证明或签名,但要确切知道某个加密材料是否是由已撤销的验证方法生成的可能更困难。一些 DID 方法提供了回溯查看某一时间点时的DID状态或特定版本下的 DID 文档的能力。当这一特性与可验证声明结合时,那么密钥的撤销并不会撤销该声明。因此,这可以成为使用DIDs进行约束性承诺的基础,例如,签署抵押贷款。
如果满足上述条件,撤销不具有追溯性;仅使得未来应用该方法无效。
然而,为了保证语义安全,需要在创建可验证声明时附加额外条件,即明确该声明对应的DID 文档状态。否则,可能会有人使用已撤销的密钥来创建可验证声明,日期为伪造的撤销前日期。 一些DID 方法只允许检索DID的当前状态。在这种情况下,或者当无法确定可验证声明创建时的 DID状态,唯一安全的做法是不再考虑DID状态与时间的关系,除了当前DID状态为最新情况。DID生态系统实际上采取这种方法提供可验证声明,可作为短暂令牌,随时被DID 控制者撤销。
无信任系统是指所有信任依据都来自于密码学层面的可验证声明,更确切地说,判断系统可信度的元数据全部来自加密系统。要验证已在无信任系统中撤销的 验证方法生成的签名或证明,DID 方法需要支持 versionId
或versionTime
或两者都支持,以及updated
和nextUpdate
,DID 文档元数据属性。验证者只有在满足以下所有条件时才能对已撤销密钥生成的签名或证明执行生效操作:
versionId
)或版本时间(versionTime
)。
updated
)在签名或证明创建的时间点之前,待更新时间戳(nextUpdate
)在签名或证明创建的时间点之后。
在允许加密数据之外的元数据输入的系统中,也可能实现此类的信任操作,但仍需要谨慎判断,即在签名发生时,DID 文档的内容是否包含预期内容。
恢复是一种响应性的安全措施,通过这一措施,失去DID操作能力(例如因设备丢失)的控制者,能够重新执行DID操作。
在应用DID恢复时,有以下注意事项:
DIDs 无需中央注册机构即可实现全球唯一性。 但这样做的代价是需要人类记忆。 能够生成全局无歧义标识符的算法会随机产生一串没有人类意义的字符。 这种权衡通常被称为祖克三角(Zooko's Triangle)。
在一些使用案例中,我们希望从人类友好的标识符开始查找并发现一个DID。 例如,自然语言名称、域名或DID 控制者的常规地址,如移动电话号码、电子邮件地址、社交媒体用户名或博客URL。 不过,将人类友好标识符映射到DIDs并以可验证和可信的方式进行映射的问题不属于本规范的范围。
这一问题的解决方案已在引用本规范的独立规范(如 [DNS-DID])中定义。 强烈建议此类规范仔细考虑以下问题:
如果 DID 控制者需要,一个DID或一个DID URL 可以作为持久的、与位置无关的资源标识符。 这类标识符被归类为统一资源名称(URN),其定义见 [RFC8141]。 DIDs是URN的一种增强形式,它为数字资源提供了一种加密安全、与位置无关的标识符,同时还提供了可用于检索的元数据。 由于DID 文档和 DID本身之间的间接性,DID 控制者 可以调整资源的实际位置,甚至直接提供资源,而无需调整 DID。这种类型的DIDs可以明确验证所检索的资源,实际上就是所标识的资源。
建议打算将 DID用于此目的的DID 控制者建议遵循 [RFC8141] 中的安全注意事项。 特别是:
许多网络安全滥用行为都是利用了现实与理性、善意行为者的假设之间的差距。 DID 文档的不变性可以提供一些安全优势。 单个DID 方法 应考虑消除其不需要的行为或语义的约束。 在提供相同功能的同时, DID 方法 的锁定程度越高,就越不容易被恶意行为者操纵。
举例来说,对 DID 文档 进行一次编辑就可以改变除文档根 id
属性之外的任何内容。 但是,一项服务 在定义后改变其类型是否真的可取? 或者一个键改变其值是否可取? 还是在对象的某些基本属性发生变化时获取一个新的id
更好? 恶意接管网站的目的往往是让网站保留其主机名标识符,但在下面进行微妙的更改。 如果规范要求网站的某些属性(如与其 IP 地址相关的 ASN)不可更改,那么异常检测就会变得更加容易,攻击的难度和成本也会大大增加。
对于与全球真相来源绑定的DID 方法,总是可以进行直接的、即时的查询 DID 文档 的最新版本。然而,似乎很可能最终会有一些缓存层位于 DID 解析器和真相来源之间。如果是这样,如果认为DID 文档 中某个对象的属性具有给定的状态,而实际上它们有细微的差别,就可能会招致漏洞。 如果某些查找是针对完整的DID 文档,而另一些查找是针对部分数据,并假定了更大的上下文,情况就更是如此。
众所周知,加密算法会因密码学和计算能力的进步而失效。 建议实施者放在 DID 文档的任何加密数据最终都可能以明文形式提供给加密数据的相同受众。 如果 DID 文档是公开的,这一点尤其重要。
对 DID 文档的全部或部分内容进行加密并不是长期保护数据的适当方法。 同样,在 DID 文档中放置加密数据也不是保护个人数据的适当手段。
鉴于上述注意事项,如果在 DID 文档中包含加密数据,建议实施者不要关联任何可用于推断加密数据与关联方之间关系的可关联信息。 可关联信息的例子包括接收方的公开密钥、已知由接收方控制的数字资产的标识符,或接收方的人类可读描述。
鉴于 equivalentId
和 canonicalId
属性由 DID 方法 本身生成,适用于DID 文档 id
字段中已解析 DID 的安全性和准确性保证也同样适用于这些属性。 alsoKnownAs
属性不能保证是等价性的准确声明,在未执行 DID 文档解析以外的验证步骤时,不应依赖该属性。
equivalentId
和canonicalId
属性表达了对由同一 DID 方法产生的单个DID变体的等价断言,请求方可信任 DID 方法以及符合要求的生成器和解析器。
alsoKnownAs
属性允许对不受相同 DID 方法 管理的URIs进行等价断言,如果不执行管理 DID
method之外的验证步骤,就无法信任这些URIs。 请参阅 5.1.3 Also Known As。
包含指向外部机器可读内容(如图像、网页或模式)链接的DID 文档很容易被篡改。 强烈建议使用哈希链接 [HASHLINK] 等解决方案保护外部链接的完整性。 如果外部链接无法得到完整性保护,而DID 文档的完整性又依赖于外部链接,则应避免使用外部链接。
DID 文档本身的完整性可能受到影响的外部链接示例之一是 JSON-LD 上下文 [JSON-LD11]。 为防止泄露,建议DID 文档使用者缓存 JSON-LD 上下文的本地静态副本,并/或根据已知与外部 JSON-LD 上下文安全版本相关联的加密哈希值验证外部上下文的完整性。
DIDs被设计为具有持久性,因此 控制者无需依赖单一可信第三方或管理员来维护其标识符。 在理想情况下,任何管理员都不能从控制者手中夺走控制权, 管理员也不能阻止将其标识符用于任何特定目的,如身份验证、授权和证明。 未经 控制者同意,任何第三方都不能代表控制者删除实体的标识符或使其无法使用。
不过,必须指出的是,在所有能够进行加密控制证明的DID 方法中,证明控制权的手段总是可以通过转移秘密加密材料而转移给另一方。 因此,依赖于标识符长期持久性的系统必须定期检查,以确保标识符实际上仍在预定方的控制之下。
遗憾的是,仅从密码学角度无法确定与特定验证方法 相关的秘密加密材料是否已被泄露。 很有可能,预期的 控制者仍然可以访问秘密加密材料--因此可以作为验证过程的一部分执行控制证明--而与此同时,坏人也可以访问这些密钥或其副本。因此,密码学证明控制预计将仅作为评估高风险场景所需的身份保证水平的一个因素。基于 DID的认证比用户名和密码提供更高的保证,这得益于在不传输秘密本身的情况下确定对密码学秘密的控制的能力。然而,这并不是万无一失的。涉及敏感、高价值或生命关键操作的场景预计将使用适当的额外因素。
除了不同控制者的使用可能产生的歧义外,通常无法保证在任何给定时间点,给定的 DID 正在引用相同的主体。从技术上讲,控制者有可能对不同的对象重复使用一个DID,更微妙的是,对象的准确定义有可能随着时间的推移而改变或被误解。
例如,考虑一个用于独资企业的DID,接收用于金融交易的各种凭证。 对于控制者来说,该标识符指的是企业。 随着业务的发展,该公司最终注册为有限责任公司。 控制者继续使用同一个DID,因为对他们来说,DID指的是企业。 但是,对于国家、税务机关和地方市政当局来说,DID指的不再是同一个实体。 对于信贷提供商或供应商来说,意义上的微妙变化是否重要,必须由他们自己决定。 在许多情况下,只要账单能够支付,收款能够执行,含义的变化就无关紧要。
由于这些潜在的歧义,DIDs应被视为在上下文中有效,而不是绝对有效。它们的持久性并不意味着它们指的是完全相同的主体,也不意味着它们受到相同 控制者的控制。相反,需要了解创建DID的背景、它的使用方式,并考虑它们的含义可能发生的变化,并采取程序和政策来解决潜在的和不可避免的语义漂移问题。
出于合规原因,特别是在金融和公共部门等受监管领域,通常需要有关身份验证事件安全背景的附加信息。 这些信息通常被称为 "保证级别"(LOA)。 例如,对秘密加密材料的保护、身份验证过程和验证器的形式因素。
支付服务 (PSD 2) 和 eIDAS将此类要求引入安全环境。 保证级别框架由 eIDAS, NIST 800-63-3和 ISO/IEC 29115:2013等法规和标准进行分类和定义,包括其对安全环境的要求,并就如何实现这些要求提出建议。 这可能包括FIDO2/WebAuthn可以满足要求的强用户身份验证。
某些受监管的场景要求实施特定级别的保证。 由于在某些情况下可能会使用
断言方法(assertionMethod)
和身份验证(authentication)
等 验证关系,因此可能需要表达并向验证者提供有关所应用的安全上下文的信息。 是否以及如何在DID 文档数据模型中编码这些信息不属于本规范的范围。 有兴趣的读者可能会注意到:1) 可使用可验证凭证 [VC-DATA-MODEL] 传输该信息;2) 如 4.1 可拓展性 所述,可扩展DID 文档数据模型以纳入该信息,其中10. 隐私考虑 因素适用于此类扩展。
此章节是非规范性的。
由于 DID 和 DID 文档设计为由 DID 控制者直接管理,因此将隐私设计原则 [PRIVACY-BY-DESIGN] 应用于去中心化标识符架构的所有方面至关重要。这七个原则在本规范的制定过程中得到了全面应用。本规范中使用的设计并不假定存在注册机构、托管公司或其他中间服务提供商来推荐或应用额外的隐私保护措施。本规范中的隐私是预防性的,而不是补救性的,并且是嵌入式默认的。以下部分涵盖了实施者在构建使用去中心化标识符的系统时可能会发现有用的隐私注意事项。
如果为面向公众的可验证数据注册表编写了DID方法规范,其中相应的DID和 DID文档可能会公开提供,则必须确保这些DID 文档中不包含任何个人数据。个人数据可以通过其他方式传输,例如1)可验证凭证 [VC-DATA-MODEL],或者2)由DID对象或DID控制者控制的服务端点。
在服务端点中使用URL时应进行尽职调查,以防止个人数据泄露或在URL内的关联。例如,包含用户名的URL包含在DID文档中是危险的,因为用户名可能具有人类可理解的意义,从而泄露DID对象未同意共享的信息。根据本规范建议的隐私架构,可以使用DID文档中验证方法确定和保护的通信渠道,以私密的点对点方式交换个人数据。这也使得DID对象和请求方能够实施 GDPR的被遗忘权,因为没有个人数据被写入不可变的分布式账本。
像任何类型的全球唯一标识符一样,DID可能被用于关联。DID控制者可以通过使用仅对每个关系唯一的成对DID来减轻这一隐私风险;实际上,每个DID作为化名的作用。成对的DID仅在明确需要关联时才需要与多方共享。如果成对 DID 是默认设置,那么唯一需要公开发布DID 或与多方共享的情况是,当DID控制者和/或 DID对象明确希望被公开识别和关联时。
如果对应DID文档中的数据可以关联,那么成对DID的反关联保护很容易被击败。例如,在多个DID文档中使用相同的验证方法或定制的服务端点,可能会提供与使用相同DID一样多的关联信息。因此,成对DID的DID文档也需要使用成对唯一的信息,例如确保验证方法对于成对关系是唯一的。
在DID文档中为成对DID使用成对唯一的服务端点似乎是很自然的。然而,唯一的端点允许两个DID之间的所有通信完全隔离到唯一的桶中,在这些桶中时间相关分析和类似的分析很容易进行。因此,为了提高端点隐私性,更好的策略可能是让大量由不同主体控制的DID共享一个端点(参见10.5 群隐私)。
在DID文档中添加可用于明确或通过推理指示DID对象是什么类型或属性的事物的属性是危险的,特别是如果DID对象是个人的话。
此类属性不仅可能导致个人数据(参见10.1 保持个人数据隐私)或可关联数据(参见 10.2 DID关联风险和10.3 DID文档关联风险)出现在DID文档中,而且它们可以用于以特定方式对特定DID进行分组,从而使它们被包含在或排除在某些操作或功能之外。
在 DID文档中包含类型信息可能会导致个人隐私损害,即使对于非个人实体的DID对象也是如此,例如物联网设备。围绕DID控制者的此类信息的聚合可能形成一种数字指纹,最好避免这种情况。
当一个DID对象在群体中无法与其他主体区分时,隐私便得以保障。当与另一方私下互动的行为本身就是一个可识别的标志时,隐私会大大减少。
DID 和 DID方法需要努力提高群体隐私,特别是对于那些真正最需要它的人。选择默认保护匿名性和假名性的技术和人类界面。为了减少数字指纹,跨请求方实现共享通用设置,将协商选项在传输协议上保持最少,使用加密传输层,并将消息填充到标准长度。
控制者可选地在 DID文档中表达至少一个服务端点的能力增加了他们的控制和自主权。DID文档中的每个额外端点都会增加隐私风险,这可能是由于关联导致的,例如跨端点描述,或者因为这些服务没有受到授权机制的保护,或两者兼而有之。
DID文档通常是公开的,并且由于它们是标准化的,因此会以其标准的本质高效地存储和索引。如果DID文档发布到不可变的可验证数据注册表中,这种风险会更严重。对由DID引用的DID文档历史记录的访问代表了一种通过使用标准变得更加高效的流量分析形式。
使用一个DID文档中的多个服务端点所带来的额外隐私风险可能难以估计。隐私损害通常是意外后果。DID可以指代文档、服务、模式以及其他可能与个人、家庭、俱乐部和雇主相关的事物——并且它们的服务端点之间的关联可能会成为强大的监控和推断工具。这种潜在的危害的一个例子可以在多个常见的国家顶级域名(如
https://example.co.uk
)被用来以更高的概率推断DID对象的大致位置时看到。
各种可能的终点使得维护群体隐私变得特别具有挑战性,在群体隐私中,不会泄露关于DID对象的任何信息(参见10.5 群隐私)。
首先,由于服务端点可能被指定为 URI,因此可能会因为服务架构而无意中泄露个人信息。例如,服务端点 http://example.com/MyFirstName
会将
MyFirstName
泄露给所有可以访问 DID文档的人。在链接到遗留系统时,这是不可避免的风险,并且在这种情况下应采取谨慎措施。本规范鼓励新的DID感知终端节点仅使用DID本身进行任何必要的身份识别。例如,如果服务描述包含
http://example.com/did%3Aexample%3Aabc123
,则不会造成任何损害,因为 did:example:abc123
已经在
DID文档中公开了;它不会泄露更多信息。
其次,由于DID文档可以列出多个服务端点,因此可以不可逆地关联在任何其它上下文中未关联的服务。这种关联本身可能会通过透露有关 DID对象的信息而导致隐私危害,即使使用的 URI 不包含任何敏感信息。
第三,由于某些类型的DID对象可能或多或少地列出特定终端节点,因此给定服务的列表本身可能会泄露可用于推断有关 DID对象的信息。例如,汽车的 DID可能会包含指向机动车部门的公共所有权记录的指针,而个人的DID不会包含该信息。
群隐私的目标是确保特定DID对象的本质被整体人群所掩盖。为了最大化群体隐私,实施者需要依赖一个——且仅一个——服务端点,该端点提供了一个代理或中介服务,控制者愿意依赖这个服务来保护这些关联,并使请求对最终服务不可见。
鉴于上一节中提到的问题,强烈建议实现者考虑以下任何一种服务端点方法:
这些服务端点类型继续成为创新和探索的领域。
此章节是非规范性的。
有关可选扩展和其它验证方法类型,请参考 验证方法类型 [DID-SPEC-REGISTRIES] 。
这些示例仅供参考,建议不要使用相同的验证方法验证方法作为多个目的去使用。
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
],
"id": "did:example:123",
"authentication": [
{
"id": "did:example:123#z6MkecaLyHuYWkayBDLw5ihndj3T1m6zKTGqau3A51G7RBf3",
"type": "Ed25519VerificationKey2020", // external (property value)
"controller": "did:example:123",
"publicKeyMultibase": "zAKJP3f7BD6W4iWEQ9jwndVTCBq8ua2Utt8EEjJ6Vxsf"
}
],
"capabilityInvocation": [
{
"id": "did:example:123#z6MkhdmzFu659ZJ4XKj31vtEDmjvsi5yDZG5L7Caz63oP39k",
"type": "Ed25519VerificationKey2020", // external (property value)
"controller": "did:example:123",
"publicKeyMultibase": "z4BWwfeqdp1obQptLLMvPNgBw48p7og1ie6Hf9p5nTpNN"
}
],
"capabilityDelegation": [
{
"id": "did:example:123#z6Mkw94ByR26zMSkNdCUi6FNRsWnc2DFEeDXyBGJ5KTzSWyi",
"type": "Ed25519VerificationKey2020", // external (property value)
"controller": "did:example:123",
"publicKeyMultibase": "zHgo9PAmfeoxHG8Mn2XHXamxnnSwPpkyBHAMNF3VyXJCL"
}
],
"assertionMethod": [
{
"id": "did:example:123#z6MkiukuAuQAE8ozxvmahnQGzApvtW7KT5XXKfojjwbdEomY",
"type": "Ed25519VerificationKey2020", // external (property value)
"controller": "did:example:123",
"publicKeyMultibase": "z5TVraf9itbKXrRvt2DSS95Gw4vqU3CHAdetoufdcKazA"
}
]
}
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1"
],
"verificationMethod": [
{
"id": "did:example:123#key-0",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"kty": "OKP", // external (property name)
"crv": "Ed25519", // external (property name)
"x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ" // external (property name)
}
},
{
"id": "did:example:123#key-1",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"kty": "OKP", // external (property name)
"crv": "X25519", // external (property name)
"x": "pE_mG098rdQjY3MKK2D5SUQ6ZOEW3a6Z6T7Z4SgnzCE" // external (property name)
}
},
{
"id": "did:example:123#key-2",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"kty": "EC", // external (property name)
"crv": "secp256k1", // external (property name)
"x": "Z4Y3NNOxv0J6tCgqOBFnHnaZhJF6LdulT7z8A-2D5_8", // external (property name)
"y": "i5a2NtJoUKXkLm6q8nOEu9WOkso1Ag6FTUT6k_LMnGk" // external (property name)
}
},
{
"id": "did:example:123#key-3",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"kty": "EC", // external (property name)
"crv": "secp256k1", // external (property name)
"x": "U1V4TVZVMUpUa0ZVU1NBcU9CRm5IbmFaaEpGNkxkdWx", // external (property name)
"y": "i5a2NtJoUKXkLm6q8nOEu9WOkso1Ag6FTUT6k_LMnGk" // external (property name)
}
},
{
"id": "did:example:123#key-4",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"kty": "EC", // external (property name)
"crv": "P-256", // external (property name)
"x": "Ums5WVgwRkRTVVFnU3k5c2xvZllMbEcwM3NPRW91ZzN", // external (property name)
"y": "nDQW6XZ7b_u2Sy9slofYLlG03sOEoug3I0aAPQ0exs4" // external (property name)
}
},
{
"id": "did:example:123#key-5",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"kty": "EC", // external (property name)
"crv": "P-384", // external (property name)
"x": "VUZKSlUwMGdpSXplekRwODhzX2N4U1BYdHVYWUZsaXVDR25kZ1U0UXA4bDkxeHpE", // external (property name)
"y": "jq4QoAHKiIzezDp88s_cxSPXtuXYFliuCGndgU4Qp8l91xzD1spCmFIzQgVjqvcP" // external (property name)
}
},
{
"id": "did:example:123#key-6",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"kty": "EC", // external (property name)
"crv": "P-521", // external (property name)
"x": "VTI5c1lYSmZWMmx1WkhNZ0dQTXhaYkhtSnBEU3UtSXZwdUtpZ0VOMnB6Z1d0U28tLVJ3ZC1uNzhuclduWnplRGMx", // external (property name)
"y": "UW5WNVgwSnBkR052YVc0Z1VqY1B6LVpoZWNaRnliT3FMSUpqVk9sTEVUSDd1UGx5RzBnRW9NV25JWlhoUVZ5cFB5" // external (property name)
}
},
{
"id": "did:example:123#key-7",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"kty": "RSA", // external (property name)
"e": "AQAB", // external (property name)
"n": "UkhWaGJGOUZRMTlFVWtKSElBdENGV2hlU1F2djFNRXh1NVJMQ01UNGpWazlraEpLdjhKZU1YV2UzYldIYXRqUHNrZGYyZGxhR2tXNVFqdE9uVUtMNzQybXZyNHRDbGRLUzNVTElhVDFoSkluTUhIeGoyZ2N1Yk82ZUVlZ0FDUTRRU3U5TE8wSC1MTV9MM0RzUkFCQjdRamE4SGVjcHl1c3BXMVR1X0RicXhjU253ZW5kYW13TDUyVjE3ZUtobE80dVh3djJIRmx4dWZGSE0wS21DSnVqSUt5QXhqRF9tM3FfX0lpSFVWSEQxdERJRXZMUGhHOUF6c24zajk1ZC1zYU" // external (property name)
}
}
]
}
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2018/v1",
"https://w3id.org/security/suites/x25519-2019/v1",
"https://w3id.org/security/suites/secp256k1-2019/v1",
"https://w3id.org/security/suites/jws-2020/v1"
],
"verificationMethod": [
{
"id": "did:example:123#key-0",
"type": "Ed25519VerificationKey2018",
"controller": "did:example:123",
"publicKeyBase58": "3M5RCDjPTWPkKSN3sxUmmMqHbmRPegYP1tjcKyrDbt9J" // external (property name)
},
{
"id": "did:example:123#key-1",
"type": "X25519KeyAgreementKey2019",
"controller": "did:example:123",
"publicKeyBase58": "FbQWLPRhTH95MCkQUeFYdiSoQt8zMwetqfWoxqPgaq7x" // external (property name)
},
{
"id": "did:example:123#key-2",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:example:123",
"publicKeyBase58": "ns2aFDq25fEV1NUd3wZ65sgj5QjFW8JCAHdUJfLwfodt" // external (property name)
},
{
"id": "did:example:123#key-3",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"kty": "EC", // external (property name)
"crv": "P-256", // external (property name)
"x": "Er6KSSnAjI70ObRWhlaMgqyIOQYrDJTE94ej5hybQ2M", // external (property name)
"y": "pPVzCOTJwgikPjuUE6UebfZySqEJ0ZtsWFpj7YSPGEk" // external (property name)
}
}
]
}
此章节是非规范性的。
这些示例仅供参考。有关其它示例,请参考W3C 可验证凭证数据模型。
{ // external (all terms in this example)
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/citizenship/v1"
],
"type": [
"VerifiableCredential",
"PermanentResidentCard"
],
"credentialSubject": {
"id": "did:example:123",
"type": [
"PermanentResident",
"Person"
],
"givenName": "JOHN",
"familyName": "SMITH",
"gender": "Male",
"image": "data:image/png;base64,iVBORw0KGgo...kJggg==",
"residentSince": "2015-01-01",
"lprCategory": "C09",
"lprNumber": "000-000-204",
"commuterClassification": "C1",
"birthCountry": "Bahamas",
"birthDate": "1958-08-17"
},
"issuer": "did:example:456",
"issuanceDate": "2020-04-22T10:37:22Z",
"identifier": "83627465",
"name": "Permanent Resident Card",
"description": "Government of Example Permanent Resident Card.",
"proof": {
"type": "Ed25519Signature2018",
"created": "2020-04-22T10:37:22Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "did:example:456#key-1",
"jws": "eyJjcml0IjpbImI2NCJdLCJiNjQiOmZhbHNlLCJhbGciOiJFZERTQSJ9..BhWew0x-txcroGjgdtK-yBCqoetg9DD9SgV4245TmXJi-PmqFzux6Cwaph0r-mbqzlE17yLebjfqbRT275U1AA"
}
}
{ // external (all terms in this example)
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.gov/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": { "id": "did:example:123" },
"issuanceDate": "2020-03-10T04:24:12.164Z",
"credentialSubject": {
"id": "did:example:456",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": {
"type": "JsonWebSignature2020",
"created": "2020-02-15T17:13:18Z",
"verificationMethod": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
"proofPurpose": "assertionMethod",
"jws": "eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..Y0KqovWCPAeeFhkJxfQ22pbVl43Z7UI-X-1JX32CA9MkFHkmNprcNj9Da4Q4QOl0cY3obF8cdDRdnKr0IwNrAw"
}
}
{ // external (all terms in this example)
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/security/bbs/v1",
{
"name": "https://schema.org/name",
"birthDate": "https://schema.org/birthDate"
}
],
"id": "urn:uuid:c499e122-3ba9-4e95-8d4d-c0ebfcf8c51a",
"type": ["VerifiableCredential"],
"issuanceDate": "2021-02-07T16:02:08.571Z",
"issuer": {
"id": "did:example:123"
},
"credentialSubject": {
"id": "did:example:456",
"name": "John Smith",
"birthDate": "2021-02-07"
},
"proof": {
"type": "BbsBlsSignature2020",
"created": "2021-02-07T16:02:10Z",
"proofPurpose": "assertionMethod",
"proofValue": "o7zD2eNTp657YzkJLub+IO4Zqy/R3Lv/AWmtSA/kUlEAOa73BNyP1vOeoow35jkABolx4kYMKkp/ZsFDweuKwe/p9vxv9wrMJ9GpiOZjHcpjelDRRJLBiccg9Yv7608mHgH0N1Qrj14PZ2saUlfhpQ==",
"verificationMethod": "did:example:123#bls12381-g2-key"
}
}
{ // external (all terms in this example)
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/security/bbs/v1",
{
"name": "https://schema.org/name",
"birthDate": "https://schema.org/birthDate"
}
],
"id": "urn:uuid:c499e122-3ba9-4e95-8d4d-c0ebfcf8c51a",
"type": "VerifiableCredential",
"issuanceDate": "2021-02-07T16:02:08.571Z",
"issuer": {
"id": "did:example:123"
},
"credentialSubject": {
"id": "did:example:456",
"birthDate": "2021-02-07"
},
"proof": {
"type": "BbsBlsSignatureProof2020",
"created": "2021-02-07T16:02:10Z",
"nonce": "OqZHsV/aunS34BhLaSoxiHWK+SUaG4iozM3V+1jO06zRRNcDWID+I0uwtPJJ767Yo8Q=",
"proofPurpose": "assertionMethod",
"proofValue": "AAsH34lcKsqaqPaLQWcnLMe3mDM+K7fZM0t4Iesfj7BhD//HBtuWCmZE946BqW7OHYU106MP8mLntutqB8FyGwS7AOyK+5/7iW6JwLNVCvh4Nt3IaF3AN47fqVs2VikD9DiCsaFAUU6ISj5pbad8O+6jiT9Yw6ug8t8vJn3XHvMUhCPnDZJeBEdKD1qo4Z0LOq3L8QAAAHSEgtC9BoZL2MLjz4QuPxpwbhTTRC08MIUjdJnP4JUtz6163Lsl3rpadGu2d3Te7loAAAACZBD4YWOgV0xpPoYZ5vywNA5/NTeDHDbX36gvoV5RDJtY1SLU2LN/IDPZGrfhEiASbD1/QXqj8dod6FbjBs9m/LchBcy7z4yDBv/8DnBzDJ9dEaM4bDjpwmqtgJqha2kwtlyNog67xG9tNjnp5rrbIgAAAANMVanwWmlkg5I/f1M2QJ5GRvQiBL4lyL5sttxwIOalbTZP8VqWtFJI54xMNjTiK71aFWWN8SlNEwfVIX34HO5zBIb6fvc+Or21ubYllT9eXv1epl2o2CojuieCZyxE8/Q=",
"verificationMethod": "did:example:123#bls12381-g2-key"
}
}
{ // external (all terms in this example)
"protected": {
"kid": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
"alg": "EdDSA"
},
"payload": {
"iss": "did:example:123",
"sub": "did:example:456",
"vc": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.gov/credentials/3732",
"type": [
"VerifiableCredential",
"UniversityDegreeCredential"
],
"issuer": {
"id": "did:example:123"
},
"issuanceDate": "2020-03-10T04:24:12.164Z",
"credentialSubject": {
"id": "did:example:456",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
},
"jti": "http://example.gov/credentials/3732",
"nbf": 1583814252
},
"signature": "qSv6dpZJGFybtcifLwGf4ujzlEu-fam_M7HPxinCbVhz9iIJCg70UMeQbPa1ex6BmQ2tnSS7F11FHnMB2bJRAw"
}
此章节是非规范性的。
这些示例仅供参考,建议避免在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"
}
DID的创建过程由每个DID 方法定义。一些DID方法(例如did:key
)是纯生成的,这样DID和DID 文档是通过将单个加密材料转换为符合规范的表示形式而生成的。其他 DID 方法可能需要使用可验证数据注册表,其中DID和DID 文档仅在注册完成时才被第三方识别存在,如相应的 DID 方法所定义。其他过程可能由相应的 DID 方法定义。
DID是一种特定类型的 URI(统一资源标识符),因此DID可以引用任何资源。根据 [RFC3986]:
术语“资源”是泛指任何可以由 URI 标识的内容。[...] 资源不一定可以通过互联网访问。
资源可以是数字的或物理的,抽象的或具体的。任何可以分配 URI 的资源都可以分配DID。DID引用的资源是DID 对象。
DID 控制者确定DID 对象。预计无法通过查看DID本身来确定DID 对象,因为DIDs通常只对机器有意义,而对人类没有意义。DID不太可能包含任何关于DID 对象的信息,因此关于DID 对象的更多信息只能通过将 DID解析到DID 文档、获取关于DID的可验证凭证或通过DID的其他描述来发现。
虽然检索到的DID 文档中 id
属性的值必须始终与正在解析的 DID 匹配,但 DID引用的实际资源是否可以随时间变化取决于 DID 方法。例如,允许DID 对象 更改的 DID 方法可用于为特定角色的当前占用者(例如公司的 CEO)生成DID,其中实际占用该角色的人可能因 DID的解析时间而异。
DID 引用DID 对象并解析到DID 文档(通过遵循 DID 方法指定的协议)。 DID 文档不是 DID 对象的单独资源,并且没有与DID分开的 URI。相反,DID 文档是由 DID 控制者 控制的 DID resolution的产物,目的是描述 DID 对象。
下图所示的图形模型说明了这种区别。
DID 文档中的每个属性都是DID 控制者 的声明,用于描述:
id
和 alsoKnownAs
属性)。
verificationMethod
和服务
属性)。
@context
属性)。
DID 文档中唯一必需的属性是id
,因此这是保证在DID 文档中的唯一声明。
图 8通过DID和DID 对象之间的直接链接说明了该声明。
发现有关DID 对象 的更多信息的选项取决于DID 文档中存在的属性。如果存在服务
属性,则可以从服务端点请求更多信息。例如,通过查询支持可验证凭证的服务端点 ,以获取一个或多个描述 DID 对象的声明(属性)。
另一种选择是使用 alsoKnownAs
属性(如果它存在于 DID 文档中)。DID 控制者可以使用它来提供引用相同 DID 对象的其他 URI(包括其他DIDs)的列表。解析或解引用这些 URI 可能会产生 DID 对象的其他描述或表示形式,如下图所示。
如果DID 对象是可以从互联网检索的数字资源,则DID 方法可以选择构造一个DID URL,该 URL 返回DID 对象 本身的表示形式。例如,需要持久、可加密验证的标识符的数据模式可以分配一个DID,并且传递指定的 DID 参数(请参阅3.2.1 DID 参数)可以用作检索该模式的表示形式的标准方法。
如果网页或任何其他 Web 资源的控制者想要为其分配持久、可加密验证的标识符,则控制器可以为其提供DID。例如,博客托管公司(在其托管公司的域下)托管的博客的作者可以为该博客创建DID。在 DID 文档中,作者可以包含指向博客当前 URL 的 alsoKnownAs
属性,例如:
"alsoKnownAs": ["https://myblog.blogging-host.example/home"]
如果作者随后将博客移动到不同的托管公司(或作者自己的域名),则作者可以更新DID 文档以指向博客的新 URL,例如:
"alsoKnownAs": ["https://myblog.example/"]
DID有效地为博客 URL 添加了一层间接寻址。此间接寻址层由作者控制,而不是由外部管理机构(例如博客托管公司)控制。这就是DID 如何有效地充当增强的URN (Uniform Resource Name)(统一资源名称)的方式——信息资源的持久标识符,其网络位置可能会随着时间的推移而发生变化。
为避免混淆,根据DID 对象与 DID 控制者的关系,将DID 对象分为两个不相交的集合是有帮助的。
图 10中显示的第一种情况是DID 对象也是 DID controller的常见情况。这是个人或组织创建DID以进行自我识别的情况。
从图模型的角度来看,即使在图 10中标识为DID 控制者和DID 对象的节点是不同的,它们之间也存在一个逻辑弧来表达语义等价关系。
第二种情况是DID 对象是与DID 控制者不同的实体。例如,父母为孩子创建和维护 DID的控制权;公司为子公司创建和维护DID的控制权;或者制造商为产品、物联网设备或数字文件创建和维护DID的控制权。
一个 DID 文档可能有多个DID 控制者。这可以通过两种方式之一发生。
在这种情况下,每个DID 控制者都可能自行采取行动,即,每个 DID 控制者都拥有独立更新DID 文档的全部权力。从图模型的角度来看,在此配置中:
在组控制的情况下,DID 控制者应以某种方式一起行动,例如在使用需要多个数字签名(“多重签名”)或阈值数量的数字签名(“m-of-n”)的加密算法时。从功能的角度来看,此选项类似于单个DID 控制者,因为尽管 DID 控制者组中的每个 DID 控制者都有自己的图节点,但实际控制会折叠成一个表示DID 控制者组的逻辑图节点,如图12所示。
当 DID 对象是组织、公司、政府机构、社区或其他不受单个人控制的团体时,此配置通常适用。
DID 文档只有一个DID引用的 DID 对象。 DID表示为id
属性的值。此属性值在DID 文档的生存期内是不可变的。
但是,DID标记的资源(DID 对象)可能会随着时间的推移而发生变化。这在DID 控制者的专属权限下。有关更多详细信息,请参阅9.16 持久性。
DID 文档的DID 控制者可能会随着时间的推移而发生变化。但是,根据其实现方式,DID 控制者的更改可能不会因 DID 文档本身的更改而变得明显。例如,如果更改是通过更改用于 DID 文档中一个或多个验证方法的基础加密密钥或其他控制的所有权来实现的,则它可能与标准密钥轮换无法区分。
另一方面,如果更改是通过更改controller
属性的值来实现的,那它将是透明的。
本节包含自本规范作为 W3C 首次公开工作草案发布以来所做的更改。
自第二次候选推荐以来的更改包括:
publicKeyMultibase
相关的警告。
自 第一次候选推荐以来的更改包括:
method-specific-id
ABNF 规则以及nextUpdate
和 nextVersionId
的风险问题标记。
equivalentId
和 canonicalId
是可选的。
publicKeyBase58
替换为 publicKeyMultibase
。
自 首次公开工作草案以来的更改包括:
工作组向主席 Brent Zundel 和 Dan Burnett 以及 W3C员工联系人 Ivan Herman 表示深切的谢意和衷心的感谢,感谢他们不懈的努力,使工作组能够朝着富有成效的方向前进,并在标准化进程的深水区和危险水域中航行。
工作组衷心感谢促成本规范制定的各项工作,并向那些为我们的工作带来深远影响的技术和规范的制定者致以诚挚谢意。这其中尤其包括 Phil Zimmerman、Jon Callas、Lutz Donnerhacke、Hal Finney、David Shaw 和 Rodney Thayer 在 20 世纪 90 年代和 21 世纪为 Pretty Good Privacy (PGP)所做的工作。
2010 年代中期,通过与Jeremie Miller 的 Telehash 项目以及 Dave Longley 和 Manu Sporny 领导的W3C Web Payments 社区组的工作合作,建立了后来成为分布式标识(Decentralized Identifiers)的初步实现。大约一年后,XDI.org 注册工作组 开始探索用分布式技术来取代现有的标识注册(identifier registry)。一些探讨分布式标识概念的首批书面论文可以追溯到 Christopher Allen 召集的最初几次重启信任网络(Rebooting the Web of Trust)研讨会。这项工作促成了 Christopher Allen、Drummond Reed、Les Chasen、Manu Sporny 和 Anil John 之间的重要合作。Anil 看到了这项技术的前景,并拨出了最初的政府资金来探索这一领域。如果没有 Anil John 多年来的支持和指导,分布式标识不太可能取得如今的成就。在“重启信任网络”研讨会上进一步完善后,产生了第一份实施者文档,由 Drummond Reed、Les Chasen、Christopher Allen 和 Ryan Grant 共同编辑。贡献者包括 Manu Sporny、Dave Longley、Jason Law、Daniel Hardman、Markus Sabadello、Christian Lundkvist 和 Jonathan Endersby。这项初步工作随后被合并到 W3C Credentials 社区组,进一步孵化,然后移交给 W3C 分布式标识工作组进行全球标准化。
本规范的部分工作由美国国土安全部 (US DHS) 科学技术局(Science and Technology Directorate) (合同编号 HSHQDC-16-R00012-H-SB2016-1-002 和 HSHQDC-17-C-00019) 以及美国国土安全部硅谷创新计划 (Silicon Valley Innovation Program)(合同编号 70RSAT20T00000010、70RSAT20T00000029、70RSAT20T00000030、70RSAT20T00000045、70RSAT20T00000003 和 70RSAT20T00000033) 资助。本规范的内容不一定反映美国政府的立场或政策,也不应推断其已获得官方认可。
本规范的部分工作也得到了欧盟 StandICT.eu 计划的资助,资助合同编号为 CALL05/19。本规范的内容不一定反映欧盟的立场或政策,也不应推断为官方认可。
本规范的工作也得到了由 Christopher Allen、Shannon Appelcline、Kiara Robles、Brian Weller、Betty Dhamers、Kaliya Young、Kim Hamilton Duffy、Manu Sporny、Drummond Reed、Joe Andrieu 和 Heather Vescent 推动的“重启信任网络(Rebooting the Web of Trust)”社区的支持。本规范的开发也得到了 W3C可验证凭证社群小组 社区小组的支持,该小组由 Kim Hamilton Duffy、Joe Andrieu、Christopher Allen、Heather Vescent 和 Wayne Chang 担任主席。由 Phil Windley、Kaliya Young、Doc Searls 和 Heidi Nobantu Saul 推动的互联网身份研讨会(Internet Identity Workshop)的参与者也通过多次工作会议支持了这项工作,这些会议旨在讨论、改进和教育参与者有关本规范的知识。
工作组感谢以下个人对本规范做出的贡献(按字母顺序排列,Github 名称以 @ 开头,按姓氏排序):Denis Ah-Kang、Nacho Alamillo、Christopher Allen、Joe Andrieu、Antonio、Phil Archer、George Aristy、Baha、Juan Benet、BigBlueHat、Dan Bolser、Chris Boscolo、Pelle Braendgaard、Daniel Buchner、Daniel Burnett、Juan Caballero、@cabo、Tim Cappalli、Melvin Carvalho、David Chadwick、Wayne Chang、Sam Curren、Hai Dang、Tim Daubenschütz、Oskar van Deventer、Kim Hamilton Duffy、Arnaud Durand、Ken Ebert、Veikko Eeva、@ewagner70、Carson Farmer、Nikos Fotiou、Gabe、Gayan、@gimly-jack、@gjgd、Ryan Grant、Peter Grassberger、Adrian Gropper、Amy Guy、Daniel Hardman、Kyle Den Hartog、Philippe Le Hegaret、Ivan Herman、Michael Herman、Alen Horvat、Dave Huseby、Marcel Jackisch、Mike Jones、Andrew Jones、Tom Jones、jonnycrunch、Gregg Kellogg、Michael Klein、@kdenhartog-sybil1、Paul Knowles、@ktobich、David I. Lehn、Charles E. Lehner、Michael Lodder、@mooreT1881、Dave Longley、Tobias Looker、Wolf McNally、Robert Mitwicki、Mircea Nistor、Grant Noble、Mark Nottingham、@oare、Darrell O'Donnell、Vinod Panicker、Dirk Porsche、Praveen、Mike Prorock、@pukkamustard、Drummond Reed、Julian Reschke、Yancy Ribbens、Justin Richer、Rieks、@rknobloch、Mikeal Rogers、Evstifeev Roman、Troy Ronda、Leonard Rosenthol、Michael Ruminer、Markus Sabadello、Cihan Saglam、Samu、Rob Sanderson、Wendy Seltzer、Mehran Shakeri、Jaehoon (Ace) Shim、Samuel Smith、James M Snell、SondreB、Manu Sporny、@ssstolk、Orie Steele、Shigeya Suzuki、Sammotic Switchyarn、@tahpot、Oliver Terbu、Ted Thibodeau Jr.、Joel Thorstensson、Tralcan、Henry Tsai、Rod Vagg、Mike Varley、Kaliya “Identity Woman” Young、Eric Welton、Fuqiao Xue、@Yue、Dmitri Zagidulin、@zhanb 和 Brent Zundel。
当本规范成为W3C 建议推荐时,本节将提交给互联网工程指导小组 (IESG) 进行审查、批准并在 IANA 注册。
与 application/did+json 一起使用的片段标识符根据“片段”章节( 片段) 中定义的规则进行处理。
此规范在候选推荐(Candidate Recommendation )阶段已收到大量 application/did+ld+json
媒体类型的实现。在 IANA 注册媒体类型application/did+ld+json
时还有待解决多后缀媒体类型(
Media Types with Multiple Suffixes)的问题。IETF 媒体类型维护工作组(IETF Media Type
Maintenance Working Group)预计将继续开展工作,并将在发布
Media Types with Multiple Suffixes RFC 后不久由 W3C 注册application/did+ld+json
媒体类型。
与application/did+ld+json 一起使用的片段标识符根据与JSON-LD 1.1: application/ld+json media type [JSON-LD11]相关的规则进行处理
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: