导 读

别以为这是一个钓饵式题目，这篇文章是一篇干货文章，因而取这个题目是有深层次的技术起因的。

本题目的句式是一个疑问句，认真看，其实蕴含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。

  1. 小明找一个DID Registry服务（如uPort）帮其在以太坊上注册一个DID ：did:eth: 0x96f…3d4；
  2. DID Registry服务将与该DID相干的DID 文档（蕴含了公钥等信息）存储到以太坊链上；
  3. 小明在游戏网站A上应用注册的DID登录（游戏网站A能够通过DID解析器失去DID 文档，从而晓得该DID的验证形式）；
  4. 小明将其个人隐私数据存储在多个身份存储库（Identity Hub），其中居民身份证上的隐衷数据存在政府机构G，政府机构G也须要注册好本人的DID身份的；
  5. 在游戏网站A上，小明想证实本人年龄>16岁从而取得游戏工夫；
  6. 小明向政府机构G（Issuer）申请开具一个本人年龄>16岁的可验证申明（Verifiable Credential，VC）；
  7. 政府机构G通过查问小明的居民相干隐衷数据发现小明的确>16岁，因而开出了这个VC（带着G的签名）给小明；
  8. 游戏网站A验证这个VC的签名，发现的确是政府机构G开具的抉择信赖，从而发放游戏工夫；
  9. 如果某一天，游戏网站A开张了。此时小明的DID仍旧存在，还能够用于其余利用（如游戏网站B）的登录。

总 结
总结一下DID。

DID的提出是为了达到自主权身份。然而实际上是否可能实现其目标呢？

从身份上看的确DID的计划是不错的，将身份存储在区块链上，用非对称加密的密钥保障用户对账户的齐全管制。这部分的确DID做的不错。

不过咱们也很显著能发现一些问题，次要是在数据存储上。

在VC零碎里发放VC的Issuer其实还是把握用户数据的，因而VC的这个运行架构实质上还是中心化和可控的，用户必须要置信某些机构来托管隐衷数据。但这曾经比把这些隐衷数据放在服务提供商的服务器上要好太多。

而服务提供商（如4中的游戏网站A）尽管没方法拿到用户的隐衷数据，然而用户在服务提供商处产生的数据，比方小明玩游戏产生的配备、皮肤、等级，这些数据仿佛还是被游戏网站A牢牢掌控住了。