别以为这是一个诱饵式标题，这篇文章是一篇干货文章，因此取这个标题是有深层次的技术原因的。

本标题的句式是一个疑问句，仔细看，其实包含2个问题：

1. 在数字时代如何成为一个有身份的人？

第一个问题答案是「普通的数字身份」。在看文章的各位其实都有一个数字身份，要么是微信号，要么是IP地址。

但你是否发现一个问题：这些数字身份并不是你真正拥有的，而是身份提供商分发给你的。IP地址是运营商分发给你的，随时可以被运营商收走。微信号也是腾讯分发给你的，你知道账户密码，但是服务器更加知道。你选择信任运营商信任服务提供商，信任他们不会随意破坏你的身份，但这没有技术保障。

2. 如何真正拥有身份？

是否有可能真正把账户掌握在自己手里？

是否有可能登录账户，但不告诉服务器你的密码是多少，却还是能够让服务器验证你确实知道密码，同时其他任何人都无法冒充？

答案是有。

本文将会进行介绍相关技术以及基于这些技术构建的Web3时代的数字身份技术：分布式数字身份（Decentralized Identity，DID）。

首先我们来回顾一下身份发展的历程（如果想直接看技术原理的，跳到第二部分开始）。

身份发展的趋势

在中国古代，身份最早出现在秦朝，当时商鞅变法，避免外国间谍的入侵，发明了照身帖（如下图所示，可看到这个照身贴和我们现代的身份证相当接近，有头像、姓名、户籍等基本信息）。

之后身份技术在古代不断发展，我们常在电视剧中看到过的虎符、免死金牌、玉玺、锦衣卫的牙牌，都是古代用于证明身份的技术。

到了现代，我国第一代身份证于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。

可验证声明

接下去介绍DID的第四个技术规范可验证声明，其可能是目前DID生态里最重要的规范。可验证声明Verifiable Credential，简称VC。

VC的目的前面说过，就是数据授权，而且是尽可能细粒度的授权，从而尽量降低隐私数据的泄露。

对某个东西的证明可以通过披露不同程度的隐私来实现，如图3-2从左到右，隐私泄露程度降低。来看一个例子。

假设你今年24岁，如何证明你大于21岁？如果有三种选择：

出示身份证 出示出生年月日 开一个大于21岁的证明 你会选择哪种？

很明显，这三种方案对你个人隐私的披露程度是不同的。

第一种对你隐私信息的泄露最大，而第二种其次，而第三种几乎没有泄露任何多余的信息。

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牢牢掌控住了。