共计 7646 个字符，预计需要花费 20 分钟才能阅读完成。
导 读
别以为这是一个钓饵式题目，这篇文章是一篇干货文章，因而取这个题目是有深层次的技术起因的。
本题目的句式是一个疑问句，认真看，其实蕴含 2 个问题：
1. 在数字时代如何成为一个有身份的人？
第一个问题答案是「一般的数字身份」。在看文章的各位其实都有一个数字身份，要么是微信号，要么是 IP 地址。
但你是否发现一个问题：这些数字身份并不是你真正领有的，而是身份提供商分发给你的。IP 地址是运营商分发给你的，随时能够被运营商收走。微信号也是腾讯分发给你的，你晓得账户明码，然而服务器更加晓得。你抉择信赖运营商信赖服务提供商，信赖他们不会随便毁坏你的身份，但这没有技术保障。
2. 如何真正领有身份？
是否有可能真正把账户把握在本人手里？
是否有可能登录账户，但不通知服务器你的明码是多少，却还是可能让服务器验证你的确晓得明码，同时其余任何人都无奈假冒？
答案是有。
本文将会进行介绍相干技术以及基于这些技术构建的 Web3 时代的数字身份技术：分布式数字身份（Decentralized Identity，DID）。
首先咱们来回顾一下身份倒退的历程（如果想间接看技术原理的，跳到第二局部开始）。
身份倒退的趋势
在中国现代，身份最早呈现在秦朝，过后商鞅变法，防止外国特务的入侵，创造了照身帖（如图 1 - 1 所示，可看到这个照身贴和咱们古代的身份证相当靠近，有头像、姓名、户籍等根本信息）。
之后身份技术在现代一直倒退，咱们常在电视剧中看到过的虎符、免死金牌、玉玺、锦衣卫的牙牌，都是现代用于证实身份的技术。
到了古代，我国第一代身份证于 1984 年公布，尔后不断改进，一直退出防伪技术。2004 年公布了第二代身份证，并且退出了多重防伪技术。2013 年，交融了居民的生物特色。
咱们发现，身份倒退有两大的趋势：防伪和互通。
防伪这个趋势很好解释，身份原本就是为了证实“我是我”，防伪升高了“其他人假冒我”和“我假冒其他人”的概率。
而互通的起因是，人们往往同时领有多个特色及身份，指纹特色、面容特色，既有居民证实又有驾驶证实。
古代的数字身份也有相似的趋势。
随着信息技术的倒退，数字身份开始呈现，并先后涌现了中心化身份、联盟身份（Federated Identity，1999）、用户为核心的身份（User-Centric Identity，2005）、自主权身份（Self-Sovereign Identity，SSI，2016）这四个阶段的身份。
这四个阶段的倒退的趋势有 3 个：去中心化、互通、隐衷爱护。
去中心化：用户集体对本人身份的齐全掌控，只有本人晓得明码，只有本人有权限批改、读取身份信息，身份权无奈被任何其余机构剥夺。去中心化能够被了解为是一种终极意义上的防伪。防伪防到从技术上实现只有“我能力证实是我”。
互通：注册一次数字身份，能够在其余服务商的任意数字服务上登录。
隐衷爱护：用户本人保存数据，从而可能决定数字服务可能调用哪些数据。
数字身份的发展趋势比身份的发展趋势多了一个隐衷爱护。
因为数字身份比拟波及到数据，而数据、隐衷这个话题是目前十分热门的一个话题。2020 年 10 月 21 日，全国人大法工委就《个人信息保护法（草案）》公开征求意见，意味着我国首部专门爱护个人信息的法律不远了。
分布式数字身份属于第四个阶段，其心愿最终可能提供实现自主权身份 SSI 的全副技术。有机构预测分布式数字身份的市场会在 2017-2025 年增长 127 倍，从 5760 万美元达到 73 亿美元，由此可见分布式数字身份的倒退前途无量。
接下去介绍下分布式数字身份波及的技术。
非对称加密与数字签名
后面提到过“不通知服务器你的明码是多少，却还是可能让服务器验证你的确晓得明码”的技术是存在的，这种技术被称为零常识明码证实（zero knowledge password proof），IEEE P1363.2 定义了这种技术。
如果为零常识明码证实进行分类，它属于非对称加密（public-key cryptography）的一种，而且 IEEE 认为它也是零常识证实的一种。
限于篇幅和行文目标，咱们这里只简略介绍下非对称加密，而不介绍零常识明码证实的细节，二者原理是相通的。
非对称加密是古代密码学中十分重要的一个分支。个别的非对称加密中用于认证用户的不是明码，而是密钥，能够了解为了一个长度很长的明码（如 50 个字符）。
密码学次要是用于信息加密的，加密前的内容称为明文，比方“ATTACK AT 6AM”，应用某个加密密钥以及加密算法后，加密后可能变成了“NP7-UB-LDBUUB”，这个叫做密文。
要想从密文失去明文，必须应用解密密钥以及解密算法。如果加密密钥和解密密钥雷同，则为对称加密；如果不同，则为非对称加密。
非对称加密的密钥有一对 2 把，称为公钥和私钥。
公钥加密的内容，用私钥能够解密；反之用私钥加密的内容，公钥能够解密。个别私钥私藏，只有用户本人晓得；公钥须要颁布给其他人。这样他人想要给用户发送音讯时，应用公钥加密该音讯，加密后的音讯只有领有用户私钥的本人能力解密，其余领有公钥的人无奈解密。
非对称加密次要是用于信息加密的，那如何用于用户的认证呢？
数字签名。
假如用户 A 要证实本人是 A，首先，结构一条音讯“I AM A”；而后对该音讯哈希函数运算失去哈希值 H(I AM A)，而后应用私钥 Priv 对该哈希值进行加密，所失去的密文 E(H(I AM A),Priv)即为用户 A 对音讯“I AM A”的数字签名。
将音讯原文“I AM A”和签名 E(H(I AM A),Priv)发给其他人，其他人应用用户的公钥能够解密签名失去 H(I AM A)；而后也对音讯原文进行哈希计算失去 H(I AM A)’，如果 H(I AM A)’== H(I AM A)，阐明发送“I AM A”音讯的用户确实领有私钥 Priv，证实他就是用户 A。
总而言之，私钥其实就相当于是用户的明码，而公钥能够给服务器用来验证用户是否真的持有私钥，验证的形式就是验证数字签名。
有了这个根底，接下去就能够介绍分布式数字身份 DID 了。
分布式数字身份体系是基于非对称加密和数字签名建设起来的。
DID 标准
分布式数字身份 DID 倒退至今次要有 5 个技术规范：DID 标识符（Decentralized Identifier）、DID 文档（DID Document）、DID 解析器（DID resolver）、可验证申明（Verifiable Credential）、身份存储库（Identity Hub），这些技术规范的次要领导组织是 W3C（World Wide Web Consortium）和 DIF（Decentralized Identity Foundation）。
之所以有这几个标准，其实也和身份零碎自身的需要无关：
DID 标识符：身份标识符的格局；
DID 文档：身份信息的格局；
DID 解析器：身份信息的获取，为身份认证（Authentication）提供了保障；
可验证申明：隐衷数据披露的形式，为数据受权（Authorization）提供了保障；
身份存储库：隐衷数据的治理；
▲ DID 标识符
依据 Zcash 创始人提出的标识符零碎“Zooko 三角实践”，标识符无奈同时实现实现平安、去中心化、对人类有意义（易记忆）三者，W3C DID 标识符次要思考了平安、去中心化两者。
此处的 ALPHA 和 DIGIT 的在 ABNF（Augmented Backus Normal Form）中有定义，而未在此 ABNF 中定义的其余语法在 RFC3986 中有定义，值得一提的是 W3C DID 标识符是合乎 W3C URI 的标准的。
举个例子：
did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6
即为一个 DID 标识，其中 ethr 是 method-name，指明了身份所在的域（此处 ethr 所指的域就是以太坊）；0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6 是 method-specific-id，表明了这个身份在域中的地址。
▲ DID 文档
DID 标识符只是示意一个身份的标识符，不蕴含身份的信息。而 DID 文档就是用于形容身份详细信息的文档，一个 DID 标识符关联到一个 DID 文档。
DID 文档个别蕴含以下内容：
DID 标识符（必须）；
一个加密资料的汇合，比方公钥；
验证办法汇合；
一个服务端点的汇合；
工夫，包含创立工夫和更新工夫。
DID 文档的示例：
{
"@context": "https://w3id.org/did/v1",
"id": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6",
"publicKey": [
{
"id": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6#controller",
"type": "Secp256k1VerificationKey2018",
"controller": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6",
"ethereumAddress": "0xe6fe788d8ca214a080b0f6ac7f48480b2aefa9a6"
}
],
"authentication": [
{
"type": "Secp256k1SignatureAuthentication2018",
"publicKey": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6#controller"
}
]}
其中 @context 字段指明了该文档的版本；id 字段指明了该文档关联到的 DID；publicKey 字段指明了相干的公钥；authentication 字段则援用了 publicKey 字段里存储的公钥，并组成了验证该 DID 用户身份的形式。DID 文档其实和传统 PKI 零碎里的证书有点相似。
DID 文档理论格局能够是 JSON，也能够是 JSON-LD 或者 YAML、XML 等。其存储须要上链，或者至多哈希上链。
▲ DID 解析器
解析器的作用是通过 DID 标识符来获取 DID 文档，这样，当 DID 用户登录某个服务时，该服务提供商调用解析器来获取 DID 文档，从而晓得了如何来验证 DID 用户。
DID 解析器的标准次要是 DIF 主导的。
DIF Universal Resolver 的架构如下图。其先通过 DID 标识失去该 DID 标识的 method，而后去调用该 method 对应的 Driver 来实现最终的解析，这些 Driver 的具体实现不做限定，然而要遵循接口的标准。
DIF Universal Resolver 能够认为是一个 Driver 聚合器。
之所以这么设计架构，是因为不同 DID 的存储是位于不同区块链上，而且可能也是在不同的智能合约里存储的。用户要应用 DID，首先须要实现 DID 的注册，而 DID 的注册必定是和某条区块链（或者其它类型去中心化零碎）关联的，比方以太坊。
而且个别用户也是应用一些 DID Registry 服务来实现注册，比方以太坊上有 uPort，uPort 能够帮忙以太坊上的用户实现 DID 的注册，如果是在其余链上可能有其余提供 DID Registry 的服务。
因而每个提供 DID 注册的 Registry 服务可能是不同的。应用这种聚合器架构能最大限度地兼容所有的 DID Registry。
图 3 -1
▲ 可验证申明
接下去介绍 DID 的第四个技术规范可验证申明，其可能是目前 DID 生态里最重要的标准。可验证申明 Verifiable Credential，简称 VC。
VC 的目标后面说过，就是数据受权，而且是尽可能细粒度的受权，从而尽量升高隐衷数据的泄露。
图 3 -2
对某个货色的证实能够通过披露不同水平的隐衷来实现，如图 3 - 2 从左到右，隐衷泄露水平升高。来看一个例子。
假如你往年 24 岁，如何证实你大于 21 岁？如果有三种抉择：
出示身份证
出示出生年月日
开一个大于 21 岁的证实
你会抉择哪种？
很显著，这三种计划对你个人隐私的披露水平是不同的。
第一种对你隐衷信息的泄露最大，而第二种其次，而第三种简直没有泄露任何多余的信息。
图 3 -3
VC 运行须要有一套机制，须要有很多角色。能够看到图 3 - 3 里有很多角色，这些角色的性能如下：
发行者（Issuer）：能开具 VC（能拜访用户数据），如政府、银行、大学等机构和组织。
验证者（Verifier）：能验证 VC，由此能够提供给出示 VC 者某种类型的服务，如游戏网站、香烟店。
持有者（Holder）：即用户，能向 Issuer 申请 & 接管、持有 VC，向 Verifier 出示 VC，开具的 VC 能够寄存在钱包里，不便当前再次证实时应用。
标识符注册机构（Registry）：保护 DID 标识符及密钥（DID 文档）的数据库，如区块链、可信数据库、分布式账本等。
VC 的数据格式是什么样的呢？其大抵会蕴含以下字段：
VC 的 ID（必须）；
VC 的发行者；
申明的主体内容；
申明的证实。
工夫，如发行工夫。
一个实例：
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/1872",
"type": ["VerifiableCredential", "AlumniCredential"],
"issuer": {
"id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
"name": "Example University"
},
"issuanceDate": "2020-01-01T19:73:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}]}},
"proof": {
"type": "RsaSignature2018",
"created": "2017-06-18T21:19:10Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://example.edu/issuers/keys/1",“jws”: “eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5XsITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk-uQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtjPAYuNzVBAh4vGHSrQyHUdBBPM”
}}
在这个 VC 中，@context 字段指明了这个 VC 的格局；id 字段指明了 VC 的 id；type 字段指明了 VC 的类型；issuer 字段指明了 VC 的发行者；issuanceDate 字段指明了发行日期；credentialSubject 字段指明了 VC 的主体内容；proof 字段指明了 VC 的证实局部，能够被 Verfier 验证。
这里最重要的内容当然是 credentialSubject 和 proof。
▲ 身份存储库
接下去介绍 DID 的第五个技术规范，Identity Hub。
首先咱们要明确身份数据和隐衷数据是不同的。身份数据是指公钥这种只和这个账户相干的数据，而隐衷数据是和用户本人实在信息相干的数据如性别年龄等。
DID 文档里只存储和身份相干的数据；而 Identity Hub 就是用来存储用户的隐衷数据的。Identity Hub，尽管是身份的 Hub，然而存储的是数据，能够了解为数据银行。
咱们习惯将资产放到银行，为什么？因为平安，银行保障了咱们资产的平安。同样地，将来咱们将数据存储到数据银行，能够保证数据的平安。
其有如下几个特点：
Identity Hub 是去中心化的、链下的集体数据存储，可将对集体数据的控制权交给用户。它们容许用户以平安而隐衷的形式存储其敏感数据，无用户的显式受权就无奈获取用户数据。
Identity Hub 理论在哪由用户决定，能够是本地（手机、PC），也能够是云端；
在将来，用户将会把隐衷数据存储到 Identity Hub，而后当应用服务调用用户数据时必须申请用户的批准能力获取这些数据。
一个简例
来看一个简例。将下面的内容都串起来。
假如小明有一个以太坊上的账户 0x96f…3d4，小明想应用 DID 来登录反对 DID 的游戏网站 A。
- 小明找一个 DID Registry 服务（如 uPort）帮其在以太坊上注册一个 DID：did:eth: 0x96f…3d4；
- DID Registry 服务将与该 DID 相干的 DID 文档（蕴含了公钥等信息）存储到以太坊链上；
- 小明在游戏网站 A 上应用注册的 DID 登录（游戏网站 A 能够通过 DID 解析器失去 DID 文档，从而晓得该 DID 的验证形式）；
- 小明将其个人隐私数据存储在多个身份存储库（Identity Hub），其中居民身份证上的隐衷数据存在政府机构 G，政府机构 G 也须要注册好本人的 DID 身份的；
- 在游戏网站 A 上，小明想证实本人年龄 >16 岁从而取得游戏工夫；
- 小明向政府机构 G（Issuer）申请开具一个本人年龄 >16 岁的可验证申明（Verifiable Credential，VC）；
- 政府机构 G 通过查问小明的居民相干隐衷数据发现小明的确 >16 岁，因而开出了这个 VC（带着 G 的签名）给小明；
- 游戏网站 A 验证这个 VC 的签名，发现的确是政府机构 G 开具的抉择信赖，从而发放游戏工夫；
- 如果某一天，游戏网站 A 开张了。此时小明的 DID 仍旧存在，还能够用于其余利用（如游戏网站 B）的登录。
总 结
总结一下 DID。
DID 的提出是为了达到自主权身份。然而实际上是否可能实现其目标呢？
从身份上看的确 DID 的计划是不错的，将身份存储在区块链上，用非对称加密的密钥保障用户对账户的齐全管制。这部分的确 DID 做的不错。
不过咱们也很显著能发现一些问题，次要是在数据存储上。
在 VC 零碎里发放 VC 的 Issuer 其实还是把握用户数据的，因而 VC 的这个运行架构实质上还是中心化和可控的，用户必须要置信某些机构来托管隐衷数据。但这曾经比把这些隐衷数据放在服务提供商的服务器上要好太多。
而服务提供商（如 4 中的游戏网站 A）尽管没方法拿到用户的隐衷数据，然而用户在服务提供商处产生的数据，比方小明玩游戏产生的配备、皮肤、等级，这些数据仿佛还是被游戏网站 A 牢牢掌控住了。