1 行业现状

分布式数字身份诞生之前，人们的身份信息其实或多或少已经数字化，但数字化不意味着网络化、可信任，以及可以便捷且合法合规的互联互通。

1.1 现有数字身份的痛点

互联网应用的数字身份以用户名密码为主，并结合KYC完成实名认证。用户要重复注册账号密码。
互联网业务在应用层面并不互联互通，用户跨应用的确权操作需要更改整个业务架构。
互联网巨头依靠垄断市场，利用用户数据产生了大量价值，但用户无法掌控利用自己的价值数据。

综上所述，归结为三个问题：

重复认证的问题
多身份体系在浪费资源的同时，也存在诸多数据共享和使用上的障碍，不同企业主体间的数据信息分别存储，无法综合利用。
身份数据隐私与安全问题
用户身份信息散落在各个企业级的身份认证者手中，多方认证难免会引起用户的数据泄漏，产生木桶短板效应问题。
中心化认证效率和容错性问题
传统的 PKI 系统中数字证书是认证的核心，由权威的 CA 机构签发的中心结构可能存在性能问题，另一方面，单中心的结构容易使其成为攻击的目标，一旦上级CA机构被攻破，则与之相关联的下级CA 也会受到牵连。

1.2 分布式数字身份整体架构

分布式数字身份，它用分布式基础设施改变应用厂商控制数字身份的模式，让用户控制和管理数字身份，通过将数据所有权归还用户从根本上解决隐私问题。区块链技术用哈希链的数据结构改变了电子数据易被篡改的属性，用“区块+共识算法” 解决分布式系统的数据一致性问题，拜占庭容错能力保证跨实体运行的系统不受少数节点恶意行为的影响。

分布式数字身份一般采用多层框架，如下图是一种典型的分布式数字身份三层架构。

分布式账本层
分布式账本层是整个方案的基础设施，提供了对 DID 文档（DID Document）以及其他需要分布式存储内容的数据存储锚定。 DID 文档内最关键的是DID 与公钥的对应关系。

DPKI网络层
DPKI 网络层对上层提供了统一的 DID 解析服务，即DID Resolver，此服务可以同时对接不同的DID生态，保证DID生态间的互认。
DPKI节点会把上层的DID相关的操作打包，创建一个链上交易，并在交易中嵌入该操作批次的哈希，从而提高系统的整理处理性能。使用DPKI节点也可以隔离上层业务对底层区块链存储的差异性，对业务层和存储层进行解耦。

可信交换层
可信交换层是 DID 系统中各个生态参与方互相建立安全身份认证与数据交换层，从角色上一般会分为用户、发证方、验证方等。用户通过用户代理)注册链上身份获得 DID，并依托 DID 向发证方申请各类可验证凭证，最终向验证方提供 DID和可验证凭证完成验证流程。

2 W3C DID协议与规范

万维网联盟（W3C）推动中的分布式标识符（DID）和可验证凭（Verifiable Credential）规范， DID 规范和可验证凭证规范分别定义了代表实体的身份标识符及与之关联的属性声明，其共同支撑了分布式数字身份基础模型，可验证凭证流转模型的有效运转。

2.1 DID（Decentralized ID）

分布式标识符（DID）的两个用途，

用标识符来标识 DID主体（人员，组织，设备，密钥，服务和一般事物）的特定实例。
促进实体之间创建持久加密的专用通道,而无需任何中心化注册机制。它们可以用于诸如凭证交换和认证。

DID 的定义具有以下形式： “did:” + <did – method> + “:” + <method 特定的标识符>

did – method：通常是实现并注册了特定DID操作方法的厂商名称的缩写
method特定的标识符：通常是 URL 或 URI 标识符。

DID 解析器允许将 DID 作为输入，并返回 DID Doc 的相关元数据，该元数据遵循诸如 JavaScript Object Notation（JSON）

DID Doc是一个通用数据结构，它包含与 DID 验证相关的密钥信息和验证方法，提供了一组使 DID 控制者能够证明其对 DID 控制的机制。根据 W3C 的规范定义。
Doc 由以下标准元素组成：

统一资源标识符（URI），用于标识允许各方阅读 DID 文档的术语和协议
标识 DID 文档身份主体的 DID
用于认证，授权和通信机制的一组公共密钥
用于 DID 的一组身份验证方法，以向其他实体证明 DID 的所有权
针对 DID 的一组授权和委派方法，以允许另一个实体代表他们进行操作
服务端点集，以描述在何处以及如何与 DID 身份主体进行交互
创建文档的时间戳记[可选]
文档上次更新的时间戳[可选]
完整性的密码证明（例如，数字签名） [可选]

2.2 Verifiable Credential

分布式数字身份标识符（DID）并未附加与该数字身份实体相关的现实世界属性，因此不是一个完整的数字身份表达。可验证凭证（verifiable credential）规范定义了可在实体之间交换的凭证格式，用以提供对于实体的属性说明。
可验证凭证是由发行人签名加密的防篡改凭证，凭证通常由至少两组信息组成。

可验证的凭证本身，包含凭证元数据和声明。
数字签名。

为了增强隐私保护，规范还定义了可验证表述（verifiable presentation），用于证明实体在特定场景下的身份角色属性。可验证表述是一种防篡改的描述，它来自一个或多个可验证凭证，并由披露这些凭证的主体用密码签名。无论是直接使用可验证凭证，还是从可验证凭证中获得的数据构造身份证明， DID 身份证明都将以可验证表述（verifiable Presentation）的方式进行出示。可验证的描述通常由以下内容组成：

唯一标识描述（presentation）的 URI
标识对象类型的 URI
从中推出（描述）的一个或多个可验证凭证（credential）或数据
可验证表述（presentation）的创建者 URI（例如 DID）
身份主体的密码证明（例如，数字签名）

可验证表述的数据格式可以进行密码验证，但其本身并不包含可验证凭证。

可验证凭证支持与身份持有者所关联的属性信息基于密码学方式进行签发与验证，从而确保凭证的权威性、和隐私保护性。可验证凭证同时支持可撤销能力，凭证的创建者负责通过撤销机制撤销已经发出的凭证，验证方则相应需要具有灵活高效地验证凭证是否已处于被撤销状态的能力。

3 分布式数字身份的支撑体系

分布式数字身份凭证的发行,呈现和验证是在一系列协议和技术中进行的。相关栈包括四层：分布式账本层、代理层、凭证交换层、治理层。对用户来说，自底层向上分别需要分布式账本提供身份注册，代理软件（服务）提供所有者身份管理和实现与他人通信，凭证工具提供凭证流转和验证功能。

3.1 分布式账本

分布式身份基础设施需置于分布式信任的环境中，而不属于任何单一组织所控制的环境中，主权身份 DID 锚定于分布式账本，以避免被特定中心化服务所掌控。考虑分布式账本专门用于支持身份交易，应具有以下几个重要属性：

可公开访问，尽可能广泛的范围里部署分散节点网络
可信验证，分布式账本能够生成状态证明，客户端不必下载和访问整个分类账
操作成本低廉，账本访问应尽可能便宜，以覆盖更广泛的网络受众
不可重新分配，DID 是永久性，持久性和不可重新分配的
可解析，DID 解析是指在 DID 账本中查找特定 DID Doc 的操作

3.2 身份代理

分布式数字身份系统中代表身份所有者执行自主权身份相关的数字权益的“数字代表” 软件被称为代理组件。代理基于 DKMS 标准存储、管理、以及使用密钥和凭证。

代理软件通常包括客户端代理和服务器端代理。

客户端代理主要加载在用户的智能手机、汽车、笔记本电脑等终端设备上，终端设备具有私有属性，终端代理主要用来管理用户身份私钥，个人秘密，以及本人身份凭证等；
服务器端代理实现了可寻址的网络端，主要用来为其客户端代理提供以下服务：持久的 P2P 消息服务；协调身份所有者的多个客户端代理；加密数据存储与共享；身份所有者密钥的加密备份等。
所有密钥和凭证存储在钱包中。代理可以关联钱包。
代理与代理之间实现交互连接、凭证请求，以及凭证验证等交易，不需要第三方。

3.3 凭证交换

凭证交换主要解决以下问题：

确定发行方的代理如何向凭证持有者发布凭证
凭证验证者如何向凭证持有者请求信息
凭证持有者如何从其凭证中提取证明使验证者信任

凭证交换的核心是密码学技术,主要用于证明可验证凭证或可验证表述中的信息完整性与真实性。凭证持有人可以使用零知识证明（ZKP）以最少的披露共享来自多个凭证的信息。

3.4 身份数据中心

身份数据中心是连接在一起并链接到给定实体的链外加密个人数据存储。它们可以用于安全地存储身份数据（直接在用户设备上或在用户指定的云存储服务上），并在所有者批准此类共享时进行细粒度分享。
用户的个人设备，特别是移动端设备在数据存储方面有容量限制，可能导致用户的客户端代理在进行本地凭证存储时无法保存全部的个人凭证记录，这种情况下，可以考虑使用分布式存储对用户凭证进行云端托管。
DIF 发起 ID-hub 协议和开源软件工程支持在云服务上提供安全的身份隐私数据存储。

4 领域应用场景和案例

WeIdendity + FISCO BCOS联盟链的应用，澳门政府基于 WeIdentity 方案推出了证书电子化项目,实现安全高效的跨机构身份标识和数据合作,提升澳门居民的服务体验。

澳门居民通过进行实名认证后，用户代理会为其生成独一无二的 WeID，并由用户身份验证服务提供方为用户基于此 WeID 生成用户的 KYC Credential。用户访问接入证书电子化项目的联盟链上的其他机构时，只需出示自己的 WeID 及 KYC Credential，便可认证身份并执行业务。若出现用户丢失了本地存储的电子凭证，证书验证方可以通过机构后台，在获取用户链上授权的基础上，通过区块链连接证书发行方后台并拉取Credential 原文。