【数字身份】DID：去中心化身份协议

type

status

date

slug

summary

一个DID例子

DID 包含2个部分：唯一标识符和关联的 DID 文档。

DID标识符

DID的格式定义如下：

Scheme：标识符：“did”

method：方法名。方法定义了您将如何以及在哪里找到 DID文档

方法相关的标识符

通过DID的信息，可以解析得到一个DID文档

DID文档实例

百度的DID实例

其中<method-specific-id>=base58(ripemd160(sha256(<Base DID Document>))) （参考比特币，使用双 hash）。

其中<Base DID Document>：

在<Base DID Document>中定义了两个公钥，#keys-1主私钥对应的公钥，#keys-2为备私钥对应的公钥。

生成秘钥的算法支持：

Secp256k1

RSA（TBD）

支持以下 Fragment：

#keys-<n>：指定引用哪个 publicKey

#resolver：DID解析器器

#hub：DID Identity Hub

DID文档定义

其中：

publicKey：是公钥的列表。

authentication：说明拥有哪个公钥对应的私钥的用户就是此 DID 的拥有者；通过<DID>#keys-<n>来指定。

recovery：是可用于恢复的公钥列表；通过<DID>#keys-<n>来指定哪个公钥。

service：一些能够使用此 DID 的 Endpoint，例如这里放了 DIDResolve 服务的地址。

DID Creation

创建 DID 流程如下：

生成两对公私钥，作为主和备。

生成<Base DID Document>

对<Base DID Document>做sha256

对上面的结果再做ripemd160

对上面的结果做base58

在上面的结果前添加did:ccp:作为最终的DID

创建 DID 的请求如下：

DID Read

读取DID，即DID的解析，DID Resolver会根据DID返回相应的DID Document

DID Update

目前支持：

更新主私钥对应的公钥

更新备私钥对应的公钥

更新service

更新请求举例如下： (其中signature是使用上一版本的document中的recovery key进行签名)

DID Revoke

当需要吊销一个DID时，需要发送如下请求：(其中signature是使用上一版本的document中的recovery key进行签名)

DID Authentication Workflow

用户在 App 上使用 DID 时得证明自己是 DID 的所有者，主要运用的机制是挑战-响应机制：

App 首先根据用户提供的 DID 用从 DID Resolver 查到对应的 DID Document，

然后 App 使用 DID Document 中的公钥加密自己随机生成的一串 nonce，发送给用户，

用户用自己的私钥解密后得到这串 nonce，把 nonce 发送给 App 完成挑战。

DID Login Workflow

用户操作流程：

选择使用 DID 登入/认证，显示一个二维码

用户使用移动端 DID Wallet 扫描此二维码，并在 Wallet 上确认登入

登入完成

内部挑战响应流程：

选择使用 DID 登入/认证，显示一个二维码，二维码上关键信息：loginId，loginUrl

用户使用移动端 DID Wallet 扫描此二维码，获取 loginId 和 loginUrl

用户向 loginUrl 发送 did 和 loginId

目标 App 后端收到请求后，首先根据此 DID 去 DID Resolver 获取此 DID 对应的 Document，获得 Document 中的公钥；然后使用此公钥加密一个随机生成的 nonce 得到加密结果 ciphertext 并返回给 DID Wallet

移动端 DID Wallet 使用 did 对应的私钥解密 ciphertext 得到 plainText

移动端 DID Wallet 把此 plainText 和 loginId 发送给目标 App 后端

目标 App 后端验证挑战响应结果，即 plainText=nonce

目标 App 前端轮询得知挑战成功，即登入成功

注：

黄色框内是 App 的接入成本，涉及前端和后端

Privacy considerations

与用户隐私相关的信息不上链，而是在发证方（权威机构）侧，用发证方颁发的声明来证明用户的隐私属性，从而更好的保障用户的隐私不被泄露。

能证明DID归属的私钥只存在用户的设备上，不会给任何第三方知晓。

DID Document使用签名技术来防止恶意的篡改。

Security considerations

身份恢复：权威机构的私钥丢失后，可以通过 recovery 私钥进行主私钥的 reset，但是这样的话，之前签出来的 claim 都会失效。

底层支持使用基于Quorum改造的联盟的，具备更好的节点准入、隐私交易能力。

可验证声明VC(Verifiable Claim)

可验证声明(Verifiable Claim，简称Claim)，是发证方使用自己的 DID 给用户的 DID 的某些属性做背书而签发的描述性声明，并附加自己的数字签名，可以认为是一种数字证书。

发证方的 DID 是做背书的，签发出来的Claim我们称之为：Proof Claim。

如果发证方就是用户自己，即一个 DID 对自己签发Claim，我们称之为：Profile Claim。

Proof Claim

我们设计如下Proof Claim:

其中，

id：claim 的唯一 id，要求在发证方唯一即可，用于在发证方内唯一标识此 claim

type：claim 所属大类的类型： ProofClaim, ProfileClaim

issuer：签发 Claim 的发证方的 DID

proof：签名相关内容

revocation：定义了查询 claim 吊销列表的地址

其中 credentialSubject 中的内容定义了发证方声明的内容:

id：被签发方的 DID

shortDescription：简短的描述

longDescription：详细的描述

type：claim 的类型

设计 claim 支持如下类型：

RealNameAuthentication：实名认证
FingerprintAuthentication：指纹认证
EnterpriseAuthentication：企业认证
BusinessAuthentication：商户认证
VIPAuthentication：大客户认证

Claim 设计举例：百度云企业认证 Claim

假设发证方是百度，颁发的 claim 是百度云企业认证，则设计如下 claim：

用户（DID：did:ccp:raMWmi1LEpCeoxzb7atmSNbkozc）可以通过此声明来证明自己是百度云的企业认证客户。

2.1. 用户申请 Proof Claim

用户申请 claim 是需要提供材料的，发证方的 endpoint 连同所需的材料清单一同注册在 发证方注册中心 内。

设计预定义材料：

设计自定义材料：

发证方签发 Proof Claim

Proof Claim 的吊销

对于可吊销的 claim 所保存的信息里需要包括吊销方式的字段，里面需要有查询 claim 吊销状态的 endpoint，验证 claim 时，需要通过该 endpoint 来验证 claim 是否吊销。如果需要支持 claim 的吊销，DID 账户所有者需要自己维护一个提供获取吊销列表的 endpoint。

Revocation Service 是一个提供吊销管理的服务，用户可以自己部署可以选择托管部署在百度的平台上。当部署在百度的平台上时，百度可以把这个服务设计成一个合约。

Profile Claim

Profile Claim是一个 DID 对自己的某些属性签发的可验证声明。

第三方 app 请求 claim

claim 的验证

从 Identity Hub 中获取 claim

DID + Claim Workflow

DID 可以用作统一登入，也可以用来统一认证。第三方 App 接入 DID 做统一登入时，对原有账号体系的破坏可能很大；而做统一认证时，接入成本比较低。

使用 DID 时，无论是统一登入还是统一认证，其内部的实际工作流程都是一样的：

先验证 DID

再验证 Claim

在 App 中使用 DID 做统一登入/统一认证

• Identity Hub、Claim Issuer Registry、Claim Revocation Service 都假定托管在 DID Service 这个统一平台上

DID组件及架构

DID 和 DID URLs。DID URL 扩展了基本 DID 的语法，包含一些便于定位特定资源的其他标准 URI 组件，例如路径、查询参数和片段，DID 文档内的加密公钥，或外部资源DID 文件。

DID subject。任何东西都可以是 DID 的主体：人、组、组织、事物或概念。

DID controller。DID 的控制器是具有对 DID 文档进行更改的能力（由 DID 方法定义）的实体（个人、组织或自治软件）。一个 DID 可能有多个控制器，而 DID 主题可以是 DID 控制器，也可以是其中之一。

可验证数据注册表。任何支持记录 DID 和返回生成 DID 文档所需数据的系统都称为可验证数据注册表。包括分布式账本、去中心化文件系统、任何类型的数据库、对等网络和其他形式的可信数据存储。

DID文档。DID 文档包含与 DID 相关的信息。它们通常表示验证方法，例如公钥，以及与 DID 主体交互相关的服务。

DID 方法。DID 方法是创建、解析、更新和停用特定类型的 DID 及其关联的 DID 文档的机制。

DID 解析器和 DID 解析。DID 解析器是一个系统组件，它将 DID 作为输入并生成符合要求的 DID 文档作为输出。这个过程称为 DID 解析。解析特定类型的 DID 的步骤由相关的 DID 方法规范定义。

DID URL 解引用器和 DID URL 解引用。DID URL 解引用器是一个系统组件，它将 DID URL 作为输入并生成资源作为输出。此过程称为 DID URL 取消引用。

区块链身份管理技术的独特功能，比如自主身份识别、真实性验证、KYC简化等，将成为区块链身份管理解决方案的主要优势。

目前，区块链身份管理市场的厂商类别主要分为三类：应用程序提供商，中间件提供商和基础设施提供商。这些提供商提供了基于区块链平台开发的基础设施，在这些类型中，应用程序提供商将是整个市场中增长最快的部分。技术先进的区块链解决方案，已经在各行业的垂直领域获得了一定程度的应用，从而推动了整体市场的增长。

全球区块链身份管理市场的解决方案提供商,主要包括：IBM(美国)、AWS(美国)、Civic(美国)、Bitfury(美国)、Evernym(美国)、Factom(美国)、Netki(美国)、ShoCard(美国)、UniquID(美国)、Microsoft(美国)、Oracle(美国)、Bitnation(瑞士)、Nodalblock(西班牙)、EdgeSecure(Airbitz)(美国)、Blockverify(英国)、Peer Ledger(加拿大)、Cambridge Blockchain(美国)、uPort(美国)、Originalmy(巴西)、Neuroware(马来西亚)、Tradle(美国)、Existenceid(澳大利亚)、Coinfirm(波兰)、BTL Group(加拿大)、IDHub(中国)、Ontology Network(中国)等。

身份与访问管理(IAM)

1、传统KBA身份验证已死

Equifax数据泄露之后，传统基于知识的身份验证(Knowledge Based Authentication，KBA)系统就已分崩离析。KBA是一种认证机制，它通过让用户回答至少一个“秘密问题”来进行认证。

秘密问题既可是静态也可是动态的。静态机制中，终端用户预选出几个自己希望回答的问题并同时提供正确答案。主机存储问答对，并在日后需要时用来验证终端用户身份；动态机制中，终端用户预先不清楚自己将要回答什么问题，问答对由公共记录中的采集数据确定。危险的是，这些问题攻击者也会获取并知晓，从而为用户隐私带来威胁。

2、GDPR促使身份回归个人手中

很多互联网企业越来越惯于将数据库中的东西据为己有，认为自己有权在未获用户授权的情况下可以对这些数据进行处置，几乎毫无顾忌地收集、存储、传输、买卖用户的个人可识别信息(Personally Identifiable Information，PII)。

而今年5月GDPR的正式施行改变了这一切，提高了企业对身份治理的需求。GDPR要求企业收集或共享个人信息时必须获得用户的明确许可，而且个人还应可以随时撤销该许可。个人拥有“被遗忘的权力”。另外，无论数据流向何方，身份信息的使用记录都必须留存。GDPR适用于欧盟公民的任何数据，无论该公民及其数据在哪儿，因而其影响范围是全世界，涉及公司内部和外部身份的治理与安全。

3、生物特征识别让安全变得简单易行

如今，智能手机和其他移动设备基本都默认内置了多种生物特征识别身份验证方法，加上新的WebAuthn标准，在线生物特征安全便作为强在线身份验证的低摩擦方法而变得更加实用。今年4月，WebAuthn标准由FIDO联盟和W3C联合发布，基于FIDO的生物特征识别身份验证，可以强化Web访问安全，因为它为每个站点都采用唯一的加密凭证，消除了某一站点的被盗口令可在其他站点使用的风险。用户在登录时，不用再输入一长串账号密码，而是改用生物识别（指纹、刷脸、瞳孔）技术和USB令牌来实现网站登录。

4、依托区块链的数字身份

当集中化身份系统的安全性正在遭遇挑战，区块链分布式账本技术为身份管理提供了更为安全的底层框架，并被应用于数字身份之中。

商业方面，Civic是一个基于区块链和生物识别的多因素身份认证系统，可以在移动端无需用户名和密码的情况下进行准确安全的用户身份识别；uPort是基于以太坊的自主权身份ID应用，它可以允许用户身份验证、无密登录、数字签名并和以太坊上的其它应用交互；基于IBM区块链的SecureKey是加拿大第一家专为受行业监管而设的数字身份网络；Shocard则是一家基于区块链的企业级IAM和单点登录(SSO)解决方案；Evernym没有建立在区块链基础上，而是建立在开源分布式账本平台Sovrin上的信用社数字身份平台；埃森哲和微软联手为联合国创建了基于区块链的身份基础设施，帮助联合国为全世界100多万名没有官方身份证件的人提供合法身份证明。

通过数字身份和区块链的结合，身份验证和操作授权都得到了有效解决，可信的数字身份体系也自然成为区块链系统应用场景中不可或缺的部分，可以预见，数字身份一定会成为未来区块链生态中最基础的应用之一。

5、IoT扩展机器身份边界

当身份管理遇上IoT可能会遭遇滑铁卢。物联网极大增加了需要管理的机器身份数量，并让普通消费者也有了设置、管理和保护这些机器身份，并监管机器间相互通信方式的责任。随着越来越多的设备接入互联网，以用户智能手机为中心向周边辐射，一部手机解锁所有设备的方式最终将再也无法扩展。计算机、机器人和IoT设备都需要访问计算和数据资源，这些都必须归入身份治理的范围之内。

如今，数字身份已经成为我们生活不可缺少的重要部分，并正成为未来生活的“通用基础设施”。虽然这一领域还有很多问题等待解决，比如技术标准尚未形成、市场认知有待提升、用户普及亟待加强等，但行业趋势已经显现，在不久的将来数字身份迎来全面爆发并形成各自生态也十分可期。

DID URL的格式定义如下：

DID URL举例如下：

专用的DID方法参数：

DID相对URL

上面的DID相对URL（#key-1）在解析时转换为绝对DID： did:example:123456789abcdefghi#key-1.

DID文档

DID 文档必须包含 DID。它可能包括以下内容：

创建时间的时间戳

DID 文档有效的加密证明

加密公钥列表

可以使用 DID 进行身份验证的方法列表

可以使用 DID 的服务列表

任意数量的外部定义扩展

请注意，DID 文档中没有个人身份信息：没有用户名、没有地址、没有电话号码。这来自可验证的声明。

DID 的格式是“did:” + <method> + “:” <method-specific-identifier>。上面，我的方法是“example”，我的方法特定标识符是“123456789abcdefghi”。目前有【9种注册方法】，包括比特币、以太坊、Sovrin、IPFS和Veres One——都是区块链（或“分布式账本技术”更准确）。如果您听说过“解析器”，这只是协议查找 DID 的通用术语，而“通用解析器”是可以通过任何方法查找 DID 的东西。

可验证的声明

大多数关于 DID 及其使用方式的讨论似乎都是可验证的声明。可验证声明通常包括三部分：

主题：可能是用户（如您），但也可能是公司、宠物或其他任何可以描述的事物

发行人：可能是某种组织，例如 DMV、大学、银行等。

声明：可以做出的任何陈述，通常是关于人的例子，包括“超过 21 岁”、“住在这个地址……”或“有这个名字”。可以是任何描述性陈述。

因此，可验证声明是指某个发行人对某个主题提出声明。 “可验证”的部分是它是值得信赖和防篡改的，因为它已经由发行人加密签名。

可验证声明只是一个 JSON 文档，规范仅定义数据模型。对于如何记录从一方到另一方的获取，没有指定的协议。可验证声明规范定义了另外两个角色：

持有人：接收并持有可验证声明的人，可能是从某个发行人那里获得可验证声明的用户（如您）。

Inspecter-Verifier：可能是某种服务，如 Facebook 或 BevMo，接收可验证声明并将其用作服务的一部分。

举个例子。假设我想从 BevMo 买酒，BevMo 想知道我是否年满 21 岁。我将使用来自 DMV（发行人）的可验证声明，上面写着 Adam Powers（主题）已超过 21 岁（声明）。我将从 DMV 下载该 Verifiable Claim可验证声明文件（Adam Powers 现在是持有人）并将其上传到 BevMo（颁发者-验证者）。 BevMo 将验证索赔，然后允许我购买酒类。

该示例中有一些值得强调的有趣点：

现在我正在下载一堆可验证的声明，我必须弄清楚如何管理它们。为此，有 Credential Handler API，它允许用户创建可验证声明的在线钱包并在不同的服务中轻松使用它们。

DMV 声称我“21 岁以上”不是我的生日。两者都将使 BevMo 做出相同的决定，但我的生日会给 BevMo 详细信息，这可能会让他们侵犯我的隐私。例如，我的生日（结合我的名字）可用于唯一标识我并在服务之间共享关于我的信息。

上面的示例也没有指定 BevMo 将如何验证声明。请注意，可验证声明中的“id”是一个 URI，在上面的示例中，它是一个指向“http://example.gov/credentials/3732”的 URL。获取此可验证声明的公钥是外部的Verifiable Claims 规范的范围，所以由 Inspector-Verifier 知道从哪里获取该公钥；但是需要注意的是，DID 也是 URI 的一种形式。可以想象，Verifiable 的 Issuer声明为 URI 使用了 DID，使颁发者-验证者能够将该 DID 解析为包含其公钥的 DID 文档。

我们忽略了 Verifiable Claims 中很重要的一点：发行者怎么知道持有者有权要求一个声明？以及 Inspector-Verifier 如何知道持有人与声明中的 ID 相关联？

解决办法是基于 DID 的授权，称为 DIDAuth。

DIDAuth

围绕 DIDAuth 的细节仍在不断涌现，规范仍在整理中。最近的工作来自 Markus Sabadello，他目前正在整理 [用例和架构] 列表（

blockchain-identity

peacekeeper • Updated Oct 6, 2023

）。

从本质上讲，DIDAuth 是一个质询-响应身份验证协议：您登录的服务会发送一个随机质询，您使用您的私钥对其进行签名，然后将质询、签名和 DID 发送回服务器。

DIDAuth 概述（来自 Sabadello 等人即将发表的论文）

接收 DIDAuth 响应的服务可以通过将 DID 解析为 DID 文档并使用该文档中的公钥验证质询的签名来验证用户是否与提供的 DID 相关联。

有了该技术概述，我们现在可以深入研究有关 DID 的更多令人兴奋的问题，例如：

DID 解决了哪些问题以及如何解决这些问题？

DID 需要区块链吗？现有技术能否实现相同的目标？

谁将从 DID 中受益？

当我与迪士尼、索尼影业等公司合作时，我最喜欢的一本书是《娱乐业经济学》(https://www.amazon.com/dp/B008P91ZT8)，它阐述了娱乐业是如何做出决策的。本着同样的精神，我认为从经济角度来看 DID 的生态系统是值得的。这涉及确定参与 DID 的生产、分配和消费的利益相关者以及他们做出的合理决策。请注意，我是技术人员而不是经济学家，所以希望这种分析不会冒犯任何经济学家。

请注意，这是事情可能会引起争议的地方，人们对我将要讨论的事情有非常强烈的感觉。请记住，在本文开头，我说过我会尽量保持中立和客观。如果我实际上歪曲了什么，请告诉我。

DID 生态系统中的参与者似乎是：

用户：DID 的所有者以及可验证声明的持有者和主体

服务提供商：充当声明检查员和验证员的网站、移动应用程序和平台。

Claims Issuers：就任意数量的主题提供 Claims 的政府机构、公司和组织

技术提供商：代表其他参与者构建 DID 生态系统的公司

需要明确的是，这些类别在现实世界中并没有区别：像 Google 和 Facebook 这样的公司是服务提供商、发行人和技术提供商；并且经常是政府机构（例如 DMV）既是服务提供者又是发行者。但是，这种细分仍然很有用，因为执行这些角色之一时的选择会推动共同决策。

我们可以从考虑 DID 用户的观点开始。

DID 用户

我们可以从 DID 用户的角度以及他们应该从 DID 中获得的价值入手。关于 DID 值的最常见参数是将控制权交还给用户。这可以有几个不同的品种：

标识符控制：当今常用的标识符包括电子邮件地址和域名。不幸的是，这些由第三方控制，他们的利益可能与用户不一致。例如，电子邮件提供商可能会撤销或暂停电子邮件地址；域可能会被关闭或接管。只要 DID 私钥保持私密，用户就可以控制他们的 DID。

各种权限和声明：目前很少有权威机构可以对人提出声明。示例包括驾驶执照、护照、社会安全号码、学生证、银行账户等——所有这些都可用于向第三方证明身份。然而，控制这些标识符和声明的当局并非万无一失，拥有更多可以发布声明的机构会围绕标识符和声明创建公开市场竞争，从而有望提高声明的质量和可用性。

集中式身份提供者：如今，许多人使用 Facebook、Google、Twitter、GitHub 或其他身份提供者登录第三方服务。这使这些公司对人们的生活拥有难以置信的控制力和洞察力。通过使用 DID，用户将不再依赖这些第三方帐户。

隐私控制：用户经常无法控制他们共享哪些数据或何时共享。集中式账户的一个方面是用户必须与公司共享大量私人信息，否则他们可能不会选择共享。

让我们依次考虑每一个，看看 DID 是否以及如何实现这些目标。

首先，用户确实可以控制他们的唯一标识符。通过使用区块链作为底层技术，账本算法可以防止那些有权访问和控制以进行更改的人的干扰。即使当局要求更改分类帐，负责分类帐治理的人也无法进行这些更改。

对此的后续问题是：对标识符的控制到底有多重要？丢失电子邮件地址或域名的例子并不是大多数人都能理解的；然而，在威权政权中，撤销标识符可能会使记者或寻求自由的人保持沉默，控制标识符可能会产生重大影响。

其次，DID 是否会为用户提供各种权限和声明？ DID 的一个主要论点似乎是当局脆弱且腐败，提供标识符和声明的政府机构被过度信任和过度授权。可验证声明似乎有望出现更多权威，最有可能以商业实体的形式出现（注意：这似乎与移动货币的愿景相似“[wakala](https://www.google.com/search ?q=wakala+mobile+money&tbm=isch)”，作为 Tigo Pesa、Mpesa 和其他提供商的代理）。

目前还不完全清楚这一愿景是否会实现。我想不出许多经济体系，尤其是在发达国家，它们在很长一段时间内基本上都处于分散状态。市场营销、网络外部性、收购等似乎会导致市场集中到少数几个提供声明的商业机构。如果发生这种情况，尚不清楚大型商业机构和声明提供者是否对用户更好——也许这是一个人是否更信任政府或商业实体的角度问题。

第三，用户将受益于不被锁定在充当其身份提供者的大型服务中。这似乎是一个特别有问题的论点：如今几乎任何服务都可以设置 OAuth 或 OpenID Connect 并充当身份提供者，因此这似乎不是阻止更多商业身份提供者的技术。相反，用户似乎是根据他们使用服务的频率和他们对服务提供商的信心来选择他们的身份提供商，从而将他们推向通过其他方式变大的公司。

第四也是最后一点，DID 让用户可以控制他们的隐私。 DID 是否从根本上改变了用户的隐私并不完全清楚，因为用户已经可以控制他们将哪些信息提供给哪些服务提供商。服务提供商会经常要求用户提供比必要信息更多的信息，并且 DID 不会限制用户所需信息的数量、范围或细节。

另一个隐私问题是用户信息跨服务的链接能力。如果 DID 可以阻止用户提供详细信息（如姓名和生日），那么 DID 将有望减少服务之间发生的侵犯隐私的数据共享量。此外，创建新 DID 的低成本和高可靠性使得确保不使用唯一标识符（例如电子邮件地址或社会保险号）来跨服务链接用户变得更加容易。事实上，一些 DID 实现建议为每个服务创建一个新的 DID（称为“成对 DID”）以帮助加强这种隐私。成对 DID 不是绝对的保护，但它是朝着 [隐私范围] 改善隐私的渐进步骤（https://www.w3.org/TR/verifiable-claims-data-model/#privacy-considerations） .

DID 服务提供商

当前面临的服务提供商决策是：1）他们是否应该实施基于 DID 的身份和身份验证； 2）如果他们实施基于 DID 的身份，他们将接受什么样的声明。

服务提供商采用 DID 的最佳论据可能是围绕风险转移。通过使用 DID，身份证明、声明有效性等的风险被转移回用户和声明发布者身上。因为声明是可加密验证的，所以服务提供商有一个强有力的论据，即如果声明最终是错误的，他们有理由相信声明。此外，可验证声明的使用为服务提供商提供了不保留声明数据的选项，从而减少了他们面临的 GDPR 和其他数据和隐私风险。

如果服务提供商选择与 DID 生态系统集成，最困难的挑战似乎是选择他们将接受哪些权威和声明。与大量声明提供商集成可能对用户更方便，但可能需要围绕了解声明发行者的质量、与发行者建立法律关系以及可能开发与不同提供商的技术接口进行大量工作。

声明发行人

如果用户和服务提供商选择采用 DID，声明发行人几乎没有理由不启用生态系统。通过将可加密验证的声明提供到系统中，以便于传输它们重大影响。

DID 服务提供商

当前面临的服务提供商决策是：1）他们是否应该实施基于 DID 的身份和身份验证； 2）如果他们实施基于 DID 的身份，他们将接受什么样的声明。

声明发行人

如果用户和服务提供商选择采用 DID，声明发行人几乎没有理由不启用生态系统。通过将可加密验证的声明提供到系统中，以便为任意数量的用例传输它们，声明发布者只会增加他们的影响力和他们提供的声明的价值。

DID 技术提供商

DID 生态系统的最终参与者是构建区块链、身份管理系统、身份验证系统等的技术提供商。一些技术提供商是狂热的非常支持 DID，这既是因为他们相信它为用户提供的价值，也是因为建立新市场可以获得丰厚的回报。

事实证明，其他技术提供商对 DID 生态系统持怀疑态度。乍一看，DID 似乎正在对新技术进行大量投资，现有技术可以很好地执行：区块链的功能可以由 PKI 执行；可验证声明可能只是 JSON Web 令牌 (JWT) 之上的一种新数据模型；用户信息的交换可以通过 OpenID Connect 进行，尤其是使用它的 Discovery 和 [UserInfo](http://openid. net/specs/openid-connect-core-1_0.html#UserInfo) 机制。

摆脱现有技术不仅仅是骄傲和/或浪费精力的问题。现有技术具有已知的安全和隐私模型，这些模型已经通过多年的成熟和第三方研究而得到很好的建立。放弃已知技术会带来一些市场可能难以承担的新风险。

了解现有技术是否可以实现与 DID 相同的结果是未来工作的领域之一。

人们对 DID 充满热情，技术和生态系统正在迅速发展。 W3C 凭证社区组围绕 DID、它们的用例以及已开发规范的未来进行了非常活跃的对话。大部分对话仍在进行中，尚不完全清楚 DID 的采用将如何发挥作用；然而，这是一种有趣的身份和标识符方法，值得关注。

Understanding Decentralized IDs (DIDs) - Adam Powers - Medium