去中心化身份（Decentralized ID, DID）介绍

去中心化身份（Decentralized ID, DID）介绍

DID可以说是区块链领域一个偏冷门的方向，但是其实它看上去有不小的价值的。

1 背景与现状

1.1 数字身份认证背景

中心化身份 => 联盟身份 => 中心化身份（DID）

一开始的数字认证始是中心化的，比如ICANN管理的域名与IP地址分配，以及PKI（Public Key Infrastructure）系统中的CA（Certificate Authority）证书机构管理的数字证书。

中心化身份系统的本质就是，中央集权化的权威机构掌握着身份数据，因为围绕数据进行的认证、授权等也都由中心化的机构来决定。身份不是由用户自己控制的。

而且不同的中心化网站（比如淘宝、知乎、豆瓣等等）上有一套自己的身份系统，所以都需要你重新注册一个账户。而不同网站自己用的身份系统（及账户对应的数据）之间是不互通的。

为了解决这个问题，不同的网站自己联合起来推出了联盟身份（这个概念是首先由微软在1999年提出的）。在联盟身份体系下，用户的在线身份有了一定的可移植性。如今的不少网站注册都可以支持第三方登录，比如微信、QQ、新浪微博等。

在联盟身份提出后，身份系统就开始走向去中心化了。期间也有很多去中心化的标准、方案出现，比如OpenID。其实就算是一些网站支持的微信、QQ第三方登录，其用户体验也不是很好，而且往往还是需要你用手机号 + 验证码进行注册的。

综上所述，中心化身份主要的问题就是两个，一是个人并不是真正意义上拥有自己的身份，二是身份无法互通。

1.2 Decentralized IDentity（DID）现状

发展前景、已经提出的标准、已经出现的项目

DID可以说是区块链领域一个偏冷门的方向。目前只有很少的团队在研究DID，开发的项目也不多，屈指可数，而关于DID行业的研究报告也几乎没有（只找到一份）。DID的热度和扩容、跨链、DeFi这些热门概念是无法相比的。但是其实它看上去有不小的价值的，微软布局DID或许就是从侧面说明了这点。

基于区块链或者说是分布式账本（DLT）技术的DID有望解决前面提到的问题（但是也会引进新的问题，新的问题会在3 uPort项目部分提到）。

（1）标准

目前（2019年）已经提出的标准主要有：

• W3C的DID标准：A Primer for Decentralized Identifiers
• DIF（Decentralized Identity Foundation）的DID Auth：DIF官网

接下去以W3C的DID标准以及以太坊ETH上的实际项目uPort进行简要分析。

（2）项目

目前已经有的比较知名的DID项目有：MicrosoftDID、Sovrin、uPort、Evernym、Civic、ShoCard。

项目名称	大致内容
MicrosoftDID	微软的DID
Sovrin	位于HyperLedger
uPort	位于ETH
Evernym	用于交易
Civic	使生物识别的多因素身份认证、移动身份平台
ShoCard	移动身份平台、保护隐私

2 W3C DID 标准

去中心化身份标识(Decentralized Identifier，DID)是一种新类型的标识符，具有全局唯一性、高可用性可解析性和加密可验证性。DIDs通常与加密材料(如公钥)和服务端点相关联，以建立安全的通信信道。DIDs对于任何受益于自管理、加密可验证的标识符(如个人标识符、组织标识符和物联网场景标识符)的应用程序都很有用。例如，当前W3C可验证凭据的商业部署大量使用DIDs来标识人员、组织和事物，并实现许多安全和隐私保护保证。
——W3C 文档

W3C的DID标准下的DID系统主要包括以下层次要素：

1. 基础层：DID规范
   • DID标识符（Identifier）
   • DID文档（Document）
2. 应用层：可验证声明
   • 可验证声明（Verifiable Claims 或 Verifiable Credentials，本文接下去都简称VC）

2.1 DID 规范

DID标识符，是一个全局唯一的表示你身份的东西，就像你的身份证号码一样。其形式大致如下：

DID示例：did:eth:123456789abcdefg

DID标识符不容易记忆。根据Zooko三角形理论，没有任何标识符能够同时实现易记忆、安全、去中心化。在这里，W3C的DID取了后两者。

DID Infrastructure是一个全局键值对数据库，这个数据库要么是某个DID兼容的区块链，要么是某个DID兼容的分布式账本，或者是某个DID兼容的去中心化网络（其实这个数据库的位置就是DID标识符中的example字段，目前已经有非常多的合法地址）。在这个数据库中，DID标识符是键，而DID文档是值。

DID文档是一个JSON-LD Object，包括6个部分（都是optional的）：

1. DID标识符。
2. 一个加密材料的集合。比如公钥。
3. 一个加密协议的集合。
4. 一个服务端点的集合。
5. 时间戳。
6. 一个可选的JSON-LD签名。用来证明这个DID文档是合法的。

文档内容示例：

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    // used to authenticate as did:...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "service": [{
    // used to retrieve Verifiable Credentials associated with the DID
    "id":"did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

这里需要注意的是，DID文档中没有任何和你个人真实信息相关的内容，比如你的真实姓名、地址、手机号等。因此光靠DID规范是无法验证一个人的身份的，必须要靠DID应用层中的VC。

2.2 可验证声明

W3C认为前面的DID规范是基础，而把可验证声明视作是next higher layer，并认为这一层才是建立DID整个体系的价值所在。因为在这个应用层中，DID既可以用来标识个体的身份、也可以用来标识组织的身份，甚至标识物品的身份（言外之意是不仅可以改变当前的互联网，还可以改变物联网？）。

接下去我将可验证声明简称之VC。VC有点类似于数字签名，要是实现数字签名，需要有PKI体系。这里要实现VC也是一样，需要用一套系统来支持它。在VC的这套系统中，有以下几种参与者（列出了其功能）：

• 发行者（Issuer）：拥有用户数据并能开具VC的实体，如政府、银行、大学等机构和组织。
• 验证者（Inspector-Verifier，IV）：接受VC并进行验证，由此可以提供给出示VC者某种类型的服务。
• 持有者（Holder）：向Issuer请求、收到、持有VC的实体。向IV出示VC。开具的VC可以放在VC钱包里，方便以后再次使用。
• 标识符注册机构（Identifier Registry）：维护DIDs的数据库，如某条区块链、分布式账本（差不多就是前面提到的DID里的example字段）。

之所以需有Identifier Registry，是因为IV要验证VC，也要验证用户。验证VC用VC和发VC的Issuer，验证用户用DID和存DID的数据库。

因为DID对应的DID文档里没有用户的真实信息，所以当用户进行某个操作时，网站需要用户出示证明。比如，要求你证明“我XXX年龄已经大于18周岁”。这个时候你就需要Issuer帮你发出（并签名）这样一个VC给网站，网站做作为Inspector就可以进行验证。验证之后你可以进行操作了。

这里有一点要注意，那就是Issuer只需要给出你是超过18岁的VC，而不需要给出你的生日是多少的的VC，前者泄露你更少的信息。最理想的VC应该是一个回答是否的回复，而不是回答多少和什么的回复。这样能泄露最少的信息给IV。

VC的格式也是JSON的。示例如下：

{
  // set the context, which establishes the special terms we will be using
  // such as 'issuer' and 'alumniOf'.
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  // specify the identifier for the credential
  "id": "http://example.edu/credentials/1872",
  // the credential types, which declare what data to expect in the credential
  "type": ["VerifiableCredential", "AlumniCredential"],
  // the entity that issued the credential
  "issuer": "https://example.edu/issuers/565049",
  // when the credential was issued
  "issuanceDate": "2010-01-01T19:73:24Z",
  // claims about the subjects of the credential
  "credentialSubject": {
    // identifier for the only subject of the credential
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    // assertion about the only subject of the credential
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  // digital proof that makes the credential tamper-evident
  // see the NOTE at end of this section for more detail
  "proof": {
    // the cryptographic signature suite that was used to generate the signature
    "type": "RsaSignature2018",
    // the date the signature was created
    "created": "2017-06-18T21:19:10Z",
    // purpose of this proof
    "proofPurpose": "assertionMethod",
    // the identifier of the public key that can verify the signature
    "verificationMethod": "https://example.edu/issuers/keys/1",
    // the digital signature value
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

这里讲讲IV该如何来验证VC。因为VC中是没有Issuer的公钥的（也不应该有，因为就算有了，IV还是得亲自验证公钥是否是真的）。这里VC的id是一个URI，而VC中的Issuer字段也是一个URI。而Issuer也可能是使用DID来作为其身份的。因此通过VC中的Issuer字段——URI地址得到其DID，然后从DID对应的DID文档里就可以得到其公钥了。用公钥验证对VC的签名就能验证VC是否Issuer发的。

当然IV验证用户的方法也是如此：用Holder（即用户）的DID对应的DID文档里的公钥来验证其数字签名的合法性。

3 uPort项目

uPort是用于构建以用户为中心的去中心化应用的工具和协议的集合。它建立在开放标准和开放源代码库之上。 ——uPort官网

uPort项目方认为，一般的DApp用起来有诸多局限，用户的使用门槛较高：

1. 你必须下载一个钱包
2. 理解和钱包、密钥有关的各种概念
3. 你必须申请一个对应的区块链上的账号
4. 你必须购买一些平台币，比如ETH上必须买ETH来支付交易gas、EOS上必须买EOS来抵押CPU、RAM、NET资源。购买平台币至少意味着两件提高用户使用成本的事情：
   • 需要一个交易所来买入加密货币，因此需要注册一个交易所账户，还需要弄懂加密货币的交易所其实和证券交易所是有所不同的
   • 需要付费购买。不像其他互联网服务一样是免费的
5. 理解区块链、P2P网络的各种概念

其实以上就是去中心化身份相比于中心化身份的缺点（优点在前面早就讲过了哈）。因此uPort的目标就是解决这些问题，解决这些问题，去中心化身份才会真正便利于用户。

值得一提的是，uPort是尽可能符合W3C制定的关于DID的标准的。这里需要说明的是DID完全还是区块链行业中，或者说是Web3生态中处于萌芽状态的事物，W3C的标准也只是v0.13，标准还处于完善之中。因此，作为已经在开发产品的uPort其实在使用DID的一些情况下，W3C DID标准可能是还没有相应的Spec，或者是和实际情况不符的。因此uPort此时必须自己想出解决方案。

3.1 uPort App

uPort现在已经有一款移动端的产品了，名字也叫uPort。如下图片所示。

uPort App类似于一款加密货币的钱包，你需要现在这个App上注册一下，注册完了之后你会有一个uPort ID，这个uPort ID（上图最左）其实就是由DID + 以太坊账户组成的。而且看山去骨DID后面的几位是和你你以太坊账户的数字一样的（我无法看到我DID标识符的全部内容，不知道是不是App的bug… ）。

一个uPort账户关联了以下内容，这些内容都在uPort App中显示出来了：

• 一个uPort ID：包括一个DID和一个ETH Mainnet Address
• 个人基本信息：可选填Name、Email、Country、Phone四个字段，其中Name是你在申请账号时必填的，自己任取
• Credentials：Credentials就是在W3C标准里提到的Claims，就是VC。前面说了VC被Issuer发了以后，Holder可以存在自己的钱包里，等下次用的时候直接出示，而可以省去让Issuer重开的成本。uPort App自然可以帮你存储VC。
• 其他辅助信息：如账号的二维码、账户头像等等

3.2 uPort是如何运转的

当你开始使用uPort App后（也就是你已经有一个uPort账户了），当你使用某个支持uPort的DApp时，你就可以使用uPort账户来登录。如果这个DApp需要你出示一些证明，你就可以用uPort来帮你把存在uPort账户里对应的VC发给DApp。这和你要进行加密货币交易是，拉起钱包来帮你进行交易签名类似。一个VC就像一个对交易的数字签名。

当然，VC需要事先备在你的uPort账户。获取VC到uPort账户的流程是：用户上传证明材料到uPort账户，比如证明驾驶证的照片。然后uPort作为代理去Issuer出示证明材料，获取VC到你的uPort账户进行关联。

因此uPort运行起来最重要的当然是要有Issuer的支持。Issuer必须支持和uPort的合作。试想某个网站要求Holder出示驾驶证的证明。就算用户真的把驾驶证拍照作为VC上传到uPort账户上，作为IV也无法通过照片来验证，VC是Issuer发的，因此必须由Issuer来告诉IV如何正确验证VC。

3.3 关于uPort App的疑问

1）uPort账户数据是存在uPort的中心化服务器上的还是存在区块链上的?

• 说实话，相关文件里似乎没有写明。但是，可以肯定的是有部分数据上链了，而其他数据没上链。
• uPort ID中的DID和ETH账号肯定是上链的，上的是ETH主网。但是用户头像、二维码这些辅助数据应该是存在服务器了吧（个人推测，这种无关紧要的数据没必要上链）。
• 而最关键的VC是否上链了呢？应该没上链。VC是不能上链的，作为用户的隐私，如果上链了那就相当于公开了。VC其实和加密货币钱包里的私钥一样，应该都是存在本地的，也就是只存在你手机上的。而从使用uPort App的实际来看，应该也是存在本地的。因为uPort App里有一个选项是帮你备份VC，备份方案只有一个，那就是备份到uPort的服务器上的（如下图所示）。默认情况下VC是不备份的，由此看来是VC就是存在本地的（当然我并未看过uPort App的源码）。

2）IV（Inspector-Verifier）是uPort还是需要VC的DApp？

• uPort App这个App帮你从Issuer那儿拿到了VC，它自然有能力帮你验证（如何验证VC在W3C体系下的DID中讲过了嗷，不过有文章声称uPort是靠取出电子档案数据库里的数据来进行比对的…这个待查证，暂时认为uPort验证VC就是和W3C DID标准里是一样的）。其实我也不清楚到底是uPort验证的还是DApp验证的。这个问题也留给我自己，以后去搞清楚。

3.4 DApp如何使用uPort

首先说一下DApp对uPort支持的现状，uPort作为ETH上的DID服务提供者之一，一般肯定是服务于ETH上的DApp的。而使用DID的DApp非常少，并且DID也不是ETH上热门之物 —— 在2018年以太坊的全年总结之中也没有提到DID的任何内容。所以实际是支持uPort的DApp应该是很少了。

在uPort App里关于VC有一个Demo —— 通过uPort官网上的一个应用：uPortlandia来获取VC。但是其在和uPort App交互时似乎也有bug导致VC出示没有反应，这应该是个bug。

因此现在应该是没有什么DApp使用uPort来着，而且感觉uPort本身的软件也并不是非常成熟。

其开发文档在这里。

4 疑问

1. 区块链上的账户，比如ETH、EOS上的主网账号是否是DID？

   • 首先，DID和区块链中的账户有不少类似的地方：账号的数据都存在区块链上、都通过公私钥对进行控制。
   • 但是也有不同的地方：DID都有一个全局唯一的标识符，符合一定的标准，本文讲的是W3C的标准。而且上链的账户数据是JSON格式的某种文件。
   • 只能说因为区块链主网的账户有DID的思想在里面，但是不能说它是DID。因为区块链主网上的原生账户都不是互通的。

2. 使用了DID，用户自己掌控账号的问题是否解决？

   • 首先，自己的信息还是存在中心化机构，如政府、银行、教育机构上的。这似乎是没办法改变的。
   • 其次，如果你在某个中心化网站注册了一个账户，那你使用这个账号在这个网站上产的数据自然还是全部被这个网站所拥有的。
   • 但是，你的最关键的信息——存在政府的那些信息，只要你不想透露，就不会透露给中心化网站，你可以使用VC的方式来出示证明。
   • 因此，总的看来，DID确实有保护个人隐私的作用。而且DID是由公私钥控制的，和区块链上的账户体系类似。你的私钥只有你一个人知道。所以用户对于DID是掌控住的。但是前面也说了，DID里不包含真实的个人信息。你掌控的只是这个DID而已。

3. 最重要的一个疑问：DID会流行吗？

   • 如果DID无法流行起来，那如何谈论它都是空谈。DID能否推行起来，
   • 一就要看DID体系下的参与者们——Issuer、Holder、IV、IR（这里可以视为区块链服务提供者）是否愿意使用了。毫无疑问，Holder肯定想要DID，如此一来Issuer和IR应该也不会不愿意。但是希望能多获取用户信息的IV估计就不愿意了。
   • 二要看是否有公司愿意开发DID的技术。一般来说客户有需求，肯定会有人愿意开发。不过也有一些技术公司觉得，是否需要用 Blockchain + VC 来实现DID？使用已经成熟的技术比如 PKI + JWTs(JSON Web Tokens) + OpenID 好像也不赖。

5 结语

在多数用到了区块链的解决方案上，往往都能用目前比较成熟的技术的另一个方案（除了数字货币本身）。而且区块链往往确实没有特别的优势。只要是这样，由于惰性的存在，区块链的落地就很难进行。

其实我觉得可能区块链的应用确实是比较小众的，它就是一个分布式账簿数据库，并不是所有应用都要使用这种数据库的。区块链之所以热门起来也是因为比特币大涨，而似乎不是技术本身。那些本身需要用到分布式系统的应用，因为区块链热门而使用区块链，其实他们直接使用分布式系统就可以了。不应该是世界适应区块链，而应该是区块链适应世界。

我个人目前最看好的还是DeFi。在区块链向各个领域扩张尝试后，也是时候收敛回最有可能落地的某几个场景了，反正目前业界普遍认为最有可能落地的是金融和游戏。

参考文献:

[1]Decentralized Identifiers (DIDs) v0.13——Data Model and Syntaxes
[2]Understanding Decentralized IDs (DIDs). Adam Powers.
[3]去中心化身份研究报告.时戳资本.
[4]uPort概述.uPort官网
[5]uPort解读1.简书
[5]uPort解读2.medium