去中心化数字身份DID介绍

一、什么是 DID？

去中心化身份（DID）利用区块链技术实现让数字身份真正为用户所拥有并支配，就像我们把身份证、护照、户口本这些纸质文件放在自己家里小心保存，只有在需要的时候再拿出来一样，不再有任何中间人（即使是 DID 技术供应商）接触/拥有/控制用户的身份和数据。

实现一个用户能自主创建、完全去中心化的身份管理，是远在区块链诞生之前、坚持互联网“去中心化”初心的极客和专家一直追求的目标。然而，OpenID 等多个解决方案之所以未能奏效，是因为在技术上永远绕不开“认证中心“，一旦需要这个认证中心，就背离了初衷，而且因为涉及到中心的认证，不仅存在隐私和安全问题，多个主体间的 DID 也是互相隔断的。

区块链的出现，恰恰解决了 DID 最大的问题。区块链技术的不可篡改、哈希加密的特性，让建立标识唯一、人皆可信，去中心化运维的身份系统得以实现。

万维网联盟（W3C）正在主持开发的去中心化标识符（Decentralized Identitfiers，DID）标准正在成为去中心化身份（DID）技术实现标准，目前有微软、ArcBlock、uPort、lifeID 等企业或项目提交了各自的 DID 协议方法。

DIDs 是身份主体相关、与该主体进行可信互动的 URL。DIDs 解析为 DID 文档 ——描述如何使用该 DID 的简单文档。每个 DID 文档可能至少包含三部分：证明目的、验证方法和服务端点。证明目的与验证方法相结合，以提供证明事物的机制。例如，DID 文档可以指定特定的验证方法，例如密码公钥或化名生物特征协议，可以用于验证为目的而创建的方法。服务端点支持与 DID 控制器的可信交互。

这一可验证、“自我主权”的数字身份新型标识能够让身份数据始终置于终端用户的控制之下，并且不把个人身份信息存储在区块链上（仅将签名的哈希值作为证据），让用户成为身份的唯一所有者，从而摆脱任何中心化注册服务、身份提供商或证书颁发机构的控制。为保护隐私，DID 通常使用零知识证明方法让声明信息的披露尽可能的少：比如禁止向未成年人卖酒，有了 DID，只需要提供由相关部门签名认证的声明说你已经超过 18 岁，而不需要分享你的出生日期。

DID 技术实现的去中心化身份的体验和用途与传统的数字身份截然不同：首先，你将不只有一个 DID，而是依据身份场合需要的不同拥有无数不同的 DID，每一个 DID 都给你一个单独的终生加密的私密渠道与其他个人、组织或事物交互沟通，因此更好的选择你的身份来交流，更好的保护你的隐私，传统互联网的“人肉”现象将不会再发生；DID 将不仅用来证明的身份，而且可用来交换可验证的数字证书；最棒的是，每个 DID 直接登记在区块链或分布式网络上，无需向中心化注册机构申请。

二、为什么需要 DID？

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

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

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

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

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

综上所述，中心化身份主要的问题就是两个：

• 一是个人并不是真正意义上拥有自己的身份
• 二是身份无法互通。

三、DID 的运行原理

DID 的应用包括身份认证、身份数据授权两个方面。身份认证主要由身份提供机构和用户完成，身份数据授权主要发生在应用与用户之间。

1、身份认证

身份认证包括证书申请、证书签发和验证、证书撤销、证书更新。

证书申请是指用户通过非对称加密算法生成公私钥对，私钥自己保存，公钥和用于验证个人身份信息的数据发送给验证节点进行证书的申请。

证书签发和验证是指，根据新用户提交的信息（公钥和身份信息数据）验证其身份的真实性，验证通过后生成数字证书并上链。

证书撤销是指用户通过私钥主动提出证书撤销请求，或者由于证书到期由智能合约触发证书撤销（过期、失效等），验证节点根据信息进行审核验证，以完成撤销状态上链。

证书更新是指用户向区块链网络发起证书更新请求，提交待更新的新证书，并由验证节点验证上链。

2、身份数据授权

拥有用户数据的服务商将用户信息加密生成私钥和公钥，其中公钥生成该运营商的数字签名，私钥则保存在用户本地，如 SIM 卡或手机。

用户登录联盟链中某一应用时，该应用向有用户身份信息的服务商（身份提供方）发起请求，接收到请求后，服务商向用户发送授权申请，等待用户同意。

用户通过私钥对该申请进行授权，应用在链上对用户身份进行匹配，匹配成功后完成授权并登录该应用。

身份认证和身份数据授权相结合，基本就是 DID 系统的整体运行流程：

四、DID 基本概念

1、身份

国际电子技术委员会将“身份”定义为“一组与实体关联的属性”。这里的实体不仅仅是人，对于机器或者物体都可以是实体，甚至网络中虚拟的东西也可以是实体并拥有身份。

2、数字身份

随着互联网的出现和普及，传统的身份有了另外一种表现形式，即数字身份。一般认为，数字身份的演进经历了四个阶段，分别是：中心化身份、联盟身份、以用户为中心的身份以及自我主权身份。

• 中心化身份是由单一的权威机构进行管理和控制的，现在互联网上的大多数身份还是中心化身份。
• 联盟身份的出现解决了中心化身份中身份数据零碎混乱的弊端，此种身份是有多个机构或者联盟进行管理和控制的，用户的身份数据具备了一定程度的可移植性，例如允许用户登录某个网站时， 可以使用其他网站的账户信息，类似于 QQ、微信或者微博的跨平台登录。
• 以用户为中心的身份则将重点集中在去中心化上，通过授权和许可进行身份数据的共享，例如OpenID。
• 自我主权身份才是真正意义上的去中心化的、完全由个人所拥有和控制的身份。

3、PKI体系

Public Key Infrastructure 的缩写，翻译过来就是公钥基础设施，其主要功能是绑定证书持有者的身份和相关的密钥对（通过为公钥及相关的用户身份信息签发数字证书），为用户提供方便的证书申请、证书作废、证书获取、证书状态查询的途径，并利用数字证书及相关的各种服务（证书发布，黑名单发布，时间戳服务等）实现通信中各实体的身份认证、完整性、抗抵赖性和保密性。PKI体系的中心是CA服务器，CA服务器必须是安全的，可信任的。主要载体是X509格式的证书文件。

4、DID

Decentralized IDentity去中心化身份，简称DID，相对于传统的基于PKI的身份体系，基于区块链建立的DID数字身份系统具有保证数据真实可信、保护用户隐私安全、可移植性强等特征，其优势在于：

• 去中心化：基于区块链，避免了身份数据被单一的中心化权威机构所控制。
• 身份自主可控：基于DPKI （分布式公钥基础设施），每个用户的身份不是由可信第三方控制，而是由其所有者控制，个人能自主管理自己的身份。
• 可信的数据交换：身份相关数据锚定在区块链上，认证的过程不需要依赖于提供身份的应用方。

5、DID标识

DID标识是一个特定格式的字符串，用来代表一个实体的数字身份，这里的实体可以是人、机、物。DID标识的格式为：

前缀did：是固定的，表示这个字符串是一个did标识字符串。
中间的example：被称为DID方法，用来表示这个DID标识是用哪一套方案（方法）来进行定义和操作的。

DID方法我们可以自定义，并且注册到W3C的网站（https://w3c.github.io/did-spec-registries/#did-methods）中。

最后面部分：是在该DID方法下的唯一标识字符串。比如我们做了一个DID系统，我们把方法起名叫cid，想把中国公民的身份证信息都DID化，那么我的DID标识就是：did:cid:5111**************5，这里我们就使用身份证号码作为cid这个DID方法下的唯一标识。

6、DID文档

每一个DID标识都会对应一个DID文档（DID Document）。这个文档就是一个JSON字符串，里面一般会包含如下信息：

1. DID标识符。
2. 时间戳：如果DID文档包含已created或updated的属性，则该属性的值务必为有效的XML日期时间值。
3. Public Keys：公钥是一种验证方法。 公钥用于数字签名，加密和其他加密操作，而这些又是进行身份验证或与服务端点建立安全通信的基础。 所表达的信息通常包括全局明确的标识符和公钥材料，可用于验证数字签名。 可以表示其他信息，例如密钥的状态信息（例如，密钥是否被挂起或吊销），或者其他属性，使人们可以确定它是否是硬件支持的加密密钥。
4. Authentication ：身份验证是一种机制，通过该机制，实体可以证明自己是DID主体。即拥有哪个公钥对应私钥的用户就是此 DID 的拥有者；
5. Service Endpoints：使用服务端点来表达与DID主题或关联实体进行通信的方式。 除了发布身份验证和授权机制之外，DID文档的另一个主要目的是发布DID主题对应的服务端点 。服务端点可以表示主体希望通告的任何类型的服务，包括用于进一步发现，认证，授权或交互的分散身份管理服务。
6. Proof：用来对DID文档的完整性提供加密证明的信息。

以上信息并不是必须有，不过一般我们建议包含。我们来看一个具体的DID文档示例：

{
  // 内容所遵循的JSON-LD标准
    "@context": "https://w3id.org/did/v1",
  // 唯一标识，也就是证书ID
    "id": "did:example:123456789abcdefghi",
    "authentication": [{
        // 本DID文档对应的DID标识
        "id": "did:example:123456789abcdefghi#keys-1",
        "type": "RsaVerificationKey2018",
        "controller": "did:example:123456789abcdefghi",
        //本DID对应的公钥信息
        "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
    }],
    "service": [{
        // 获取本DID对应的VC的服务接口
        "id": "did:example:123456789abcdefghi#vcs",
        "type": "VerifiableCredentialService",
        "serviceEndpoint": "https://example.com/vc/"
    }]
}

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

我们一般是把DID标识作为Key，把DID文档作为Value存储到区块链中，利用区块链不可篡改、共享数据访问的特点，实现接下来在验证身份时能快速访问获取可信数据。

7、可验证凭证/可验证声明VC

（Verifiable Claims 或 Verifiable Credentials，本文接下去都简称VC）是一个 DID 给另一个 DID 的某些属性做背书而发出的描述性声明，并附加自己的数字签名，用以证明这些属性的真实性，可以认为是一种数字证书。
传统的PKI数字证书体系需要CA来颁发，而在DID中也是分为颁发者、持有者、验证者、DID注册系统（也就是区块链），具体关系如图：

• 颁发者Issuer就是证书的颁发机构，比如身份证就是公安机关作为颁发者，毕业证书就是大学作为颁发者。
• 持有者Holder就是证书的持有人，就是我们这些普通人。
• 验证者Verifier就是在我们使用证书时查看我们证书的人或者机构。比如我们入职新公司时需要提供大学毕业证书，新公司HR就是验证者。
• DID注册系统Verifiable Data Registry就是我们存储了DID标识和DID文档的地方，通过DID标识可以查询到对应的DID文档。

当公安机关给我颁发了身份证，在DID中，这个身份证就是VC。一个VC也是一个JSON字符串，里面包含如下信息：

• VC元数据，主要就是发行人、发行日期、声明的类型等信息。
• 声明，一个或者多个关于主体的说明。比如身份证作为公安机关颁发给我的VC，在声明中会包含：姓名、性别、出生日期、民族、住址等信息。
• 证明，通常就是颁发者的数字签名，保证了本VC能够被验证，防止VC内容被篡改以及验证VC的颁发者。

下面是官方给出的一个VC的具体样例：

{
  // VC内容所遵循的JSON-LD标准
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  // 本VC的唯一标识，也就是证书ID
  "id": "http://example.edu/credentials/1872",
  // VC内容的格式
  "type": ["VerifiableCredential", "AlumniCredential"],
  // 本VC的发行人
  "issuer": "https://example.edu/issuers/565049",
  // 本VC的发行时间
  "issuanceDate": "2010-01-01T19:73:24Z",
  // VC声明的具体内容
  "credentialSubject": {
    // 被声明的人的DID
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    // 声明的断言内容
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  // 对本VC的证明
  "proof": {
    // 签名算法
    "type": "RsaSignature2018",
    // 签名创建时间
    "created": "2017-06-18T21:19:10Z",
    // 本证明的目的
    "proofPurpose": "assertionMethod",
    // 验证本签名的公钥的ID
    "verificationMethod": "https://example.edu/issuers/keys/1",
    // 数字签名的内容
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

因为VC中具有用户的隐私信息，所以VC一般保存在私有的存储中，比如用户自己的手机中，或者需要授权的网络地址中。除了前面示例中给出的数据外，我们的VC还可以有失效日期，比如我们的身份证一般10年有效，过期后就需要重新向颁发者申请新的VC。

8、可验证表达VP

Verifiable presentation简称VP，可验证表达是VC持有者向验证者表名自己身份的数据。一般情况下，我们直接出示VC全文即可，但是在某些情况下，出于隐私保护的需要，我们并不需要出示完整的VC内容，只希望选择性披露某些属性，或者不披露任何属性，只需要证明某个断言即可。
比如一个求职者要进入某写字楼面试，写字楼的保安要求登记身份证号码和姓名，但是我们的VC中还包含了民族、住址等信息，我们的求职者不希望将自己的住址暴露给保安，所以他提供给保安的VP中应该只选择性的披露的身份证号码和姓名，其他信息都不披露。
VP的格式为：

• VP元数据，主要包含了版本，本JSON对象的类型等信息
• VC列表，要对外展示的VC的内容，如果是选择性披露或者隐私保护的情形，可能就不包含任何VC。
• 证明，主要就是持有者对本VP的签名信息

下面是官方给出的一个具体的VP的样例：

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": "VerifiablePresentation",
  // 本VP包含的VC的内容
  "verifiableCredential": [{
    "@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": "https://example.edu/issuers/565049",
    "issuanceDate": "2010-01-01T19:73:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": [{
          "value": "Example University",
          "lang": "en"
        }, {
          "value": "Exemple d'Université",
          "lang": "fr"
        }]
      }
    },
    "proof": {
      "type": "RsaSignature2018",
      "created": "2017-06-18T21:19:10Z",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "https://example.edu/issuers/keys/1",
      "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
        sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
        X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
        PAYuNzVBAh4vGHSrQyHUdBBPM"
    }
  }],
  // Holder对本VP的签名信息
  "proof": {
    "type": "RsaSignature2018",
    "created": "2018-09-14T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
    // challenge和domain是为了防止重放攻击而设计的
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
      4vGHSrQyHUGlcTwLtjPAnKb78"
  }
}

五、DID 使用流程

1. 场景描述

小明是一个刚刚从大学毕业的应届毕业生，在毕业当天学校颁发了毕业证给小明对应的数字身份，小明拿到毕业证后第二天去公司入职，其中一个环节，公司HR要求验证小明的学历信息，验证完成，小明入职成功。

2. 生成DID标识和DID文档

小明要想获得学校颁发的毕业证，那么他必须要有自己的DID，所以他先下载一个数字身份的手机APP，然后创建账号。创建账号的过程就是在手机中生成一个随机是私钥和对应的公钥。这里我们假设我们的DID标识的规则是“did:cid:身份证号”，所以小明在APP中输入自己的身份证号码，生成了一个DID标识：

did:cid:511112200001010015

同时也会生成一个DID文档，内容如下：

{
    "@context": "https://w3id.org/did/v1",
    "id": "did:cid:511112200001010015",
    "version": 1,
    "created": "2020 - 12 - 08 T16: 02: 20 Z ",
    "updated": "2020 - 12 - 08 T16: 02: 20 Z ",
    "publicKey": [{
            "id": "did:cid:511112200001010015#keys-1",
            "type": "Secp256k1",
            "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
        },
        {
            "id": "did:cid:511112200001010015#keys-2",
            "type": "Secp256k1",
            "publicKeyHex": "e3080168ee293053ba33b235d7116a3263d29f1450936b71"
        }
    ],
    "authentication": ["did:cid:511112200001010015#key-1"],
    "recovery": ["did:cid:511112200001010015#key-2"],
    "service": [{
        "id": "did:cid:511112200001010015#resolver",
        "type": "DIDResolve",
        "serviceEndpoint": "https://did.studyzydemo.com"
    }],
    "proof": {
        "type": "Secp256k1",
        "creator": "did:cid:511112200001010015#keys-1",
        "signatureValue": "QNB13Y7Q9...1tzjn4w=="
    }
}

这里我们为该DID设置了两个公钥，一个是小明自己的，用于认证签名等，Key2是系统托管的，用于手机丢失或者系统崩溃导致用户私钥丢失的情况下，帮忙小明找回自己的DID，绑定成一个新的公钥。

Proof部分是小明自己用自己APP里面的私钥对该DID文档的签名。如果我们想进一步增强安全性，可以将proof部分改为由公安机关进行签名。

DID文档生成完成后，APP会将该DID和文档上链到区块链存证，一旦上链完成，所有人都能够查询到小明的这个DID和文档。这里的区块链我们一般都是一个联盟链，并不是任意数据都可以随意写入的，所以小明必须是使用自己的身份证号经过验证确实是本人后才会上链，防止其他人冒用小明身份证号的情况。

3. 学校颁发毕业证VC

学校Issuer本身也有自己的DID，由于学校是教育系统里面颁发的DID，所以规则和小明作为中国公民的DID规则不一样，比如学校的DID标识是：did:cedu:uestc

这个DID不是学校自己签名的，而是被教育部签名的（教育部的DID是did:corg:moe），我们在区块链中可以找到该DID对应的DID文档如下：

{
    "@context": "https://w3id.org/did/v1",
    "id": "did: cedu: uestc ",
    "version": 1,
    "created": "2020 - 12 - 08 T16: 02: 20 Z ",
    "updated": "2020 - 12 - 08 T16: 02: 20 Z ",
    "publicKey": [{
        "id": "did: cedu: uestc# keys - 1 ",
        "type ": "Secp256k1 ",
        "publicKeyHex ": "3053 ba33b235d7116a3e3080168ee293053ba33b235d7116a33053ba33b235d7116a3 "
    }, {
        "id": "did: cedu: uestc# keys - 2 ",
        "type": "Secp256k1 ",
        "publicKeyHex ": "e293053ba3053ba33b235d7116a3263d29fe293053ba "
    }],
    "authentication": ["did: cedu: uestc# key - 1"],
    "recovery": ["did: cedu: uestc# key - 2 "],
    "service": [{
        "id": "did: cedu: uestc# resolver ",
        "type ": "DIDResolve ",
        "serviceEndpoint ": "https: //did.studyzydemo.com"
    }],
    "proof": {
        "type": "Secp256k1",
        "creator": "did:corg:moe#keys-1",
        "signatureValue": "QNB13Y7Q9...1tzjn4w=="
    }
}

所有认证过的高校的DID都是由did:corg:moe这个DID创建的，所以这相当于传统的根CA，我们只需要信任这个DID创建的DID，就可以认为是正规的高校。

继续说回颁发毕业证VC，学校根据小明的学习情况（入学时间、毕业时间、专业、是否结业等信息）以及小明提交的自己的DID，生成VC如下：

{
  // VC内容所遵循的JSON-LD标准
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  // 本VC的唯一标识，也就是证书ID
  "id": "uestc/alumni/12345",
  // VC内容的格式
  "type": [
    "VerifiableCredential","AlumniCredential"
  ],
  // 本VC的发行人
  "issuer": "did:cedu:uestc",
  // 本VC的发行时间
  "issuanceDate": "2010-07-01T19:73:24Z",
  // VC声明的具体内容
  "credentialSubject": {
    // 被声明的人的DID
    "id": "did:cid:511112200001010015",
    // 声明内容:毕业院校、专业、学位等
    "name": "小明",
    "alumniOf": {
      "id": "did:cedu:uestc",
      "name": [
        {
          "value": "电子科技大学",
          "lang": "cn"
        }
      ]
    },
    "degree": "硕士研究生",
    "degreeType": "工科",
    "college": "计算机学院"
  },
  // 对本VC的证明
  "proof": {
    "creator": "did:cedu:uestc#keys-1",
    "type": "Secp256k1",
    "signatureValue": "3044022051757c2de7032a0c887c3fcef02ca3812fede7ca748254771b9513d8e2bb"
  }
}

这里最主要的就是credentialSubject证书的内容和proof颁发学校给出的证明。这个VC生成后会传给小明，小明可以选择将这个内容存储到自己的手机APP中，也可以选择存储到云上，以后需要使用时再读取。

4. Holder提交VP给Verifier

接下来Holder小明来到新公司入职，入职当天需要提交学历证明给公司HR，于是小明基于上一步骤生成的VC再封装一下，生成VP，VP的内容如下：

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": "VerifiablePresentation",
  // 本VP包含的VC的内容
  "verifiableCredential": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://www.w3.org/2018/credentials/examples/v1"
      ],
      "id": "uestc/alumni/12345",
      "type": [
        "VerifiableCredential","AlumniCredential"
      ],
      "issuer": "did:cedu:uestc",
      "issuanceDate": "2010-07-01T19:73:24Z",
      "credentialSubject": {
        "id": "did:cid:511112200001010015",
        "name": "小明",
        "alumniOf": {
          "id": "did:cedu:uestc",
          "name": [
            {
              "value": "电子科技大学",
              "lang": "cn"
            }
          ]
        },
        "degree": "硕士研究生",
        "degreeType": "工科",
        "college": "计算机学院"
      },
      "proof": {
        "creator": "did:cedu:uestc#keys-1",
        "type": "Secp256k1",
        "signatureValue": "3044022051757c2de7032a0c887c3fcef02ca3812fede7ca748254771b9513d8e2bb"
      }
    }
  ],
  // Holder小明对本VP的签名信息
  "proof": {
    "type": "Secp256k1",
    "created": "2010-07-02T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:cid:511112200001010015#keys-1",
    // challenge和domain是为了防止重放攻击而设计的
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "jws": "eyJhbGciOiJSUzI1NiIsI...UGlcTwLtjPAnKb78"
  }
}

这里比较简单，只是简单的提交整个毕业证全部内容，所以VP中只需要把VC签入进去，最后proof的地方小明用自己APP里面的私钥进行签名，表名这个VP是小明自己生成的即可。这个VP生成后小明需要将整个VP的内容提交给新入职公司HR。

5. Verifier验证VP通过

公司HR作为验证者在收到小明提交的VP后首先验证Proof字段，保证VP是小明提交的，而且没有被篡改。接下来提取出其中的VC内容，对VC进行验证，验证过程如下：

1. 从proof的creator中获得颁发者的DID：did:cedu:uestc
2. 通过区块链查询到该DID的文档，在文档中有其创建人和公钥列表，其中我们取keys-1对应的公钥。
3. 创建人是did:corg:moe，是可信的DID，所以它创建的DID都是可信的。
4. 我们进一步的再用did:corg:moe去区块链读取DID文档，并获得其中的公钥，使用该公钥对did:cedu:uestc对应的文档进行签名验证，确保其没有被篡改。
5. 验证通过，我们再用did:cedu:uestc的公钥对小明提交的VC进行签名验证，验证通过，则说明这个证书确实是可信的UESTC颁发的。
6. HR检查VC中提供的内容，与小明提交的履历上是否一致，检查完成，进行下一步的入职手续。

以上验证过程中我们至少需要进行三次签名验证。验证VP是小明提交的，验证VC是UESTC颁发的，验证UESTC的DID是MOE创建的，而MOE是在验证方系统可信列表中的，所以整个就保证了小明提交的证书的可信。

5. 小结

以上只是简化版的DID从生成到申请VC再到验证VP的过程，实际生产过程中还涉及到更多的关于双方系统的校验，防止身份被冒充，系统被攻击等细节。

五、DID 的案例分析

案例 1：微软 DID

2019 年 5 月，微软将微软 DID 发布在比特币网络上运行，该技术旨在通过区块链技术更好地证明用户的身份。

DID 利用区块链技术实现让数字身份真正为用户所拥有并支配，不再有任何中间人接触拥有控制用户的身份和数据。

微软 DID 方案可以拆解为三部分：sidetree、ION、DID，分别对应协议层、网络层、应用层，三者属于逐级向上建构的关系。

协议层：Sidetree

Sidetree 是协议层，可以部署在比特币以及以太坊网络上，也可以部署于其他区块链网络上。目前，仅被部署在比特币网络上。

Sidetree 的核心功能有三项：

1、Sidetree Core （Sidetree 核心）

观测来自目标区块链（比特币区块链）的传入事务（incoming trasactions)，抓取其观测到的、所有的 DID 操作（operations），进而验证每一个 DID 的状态。

2、Content Addressable Storage Protocol （内容可寻址存储协议）

这一功能类似 IPFS，它将数据在链下存储以减少链上的负担，并允许跨节点的事务传播（transaction propagation across nodes）。

3、Blockchain/Ledger Adapter （区块链 / 账本适配器）

向底层区块链读取和写入 DID 操作的代码。

网络层：ION （Identity Overlay Network)

ION 是一个基于 Sidetree 协议的开源网络，可以通过将操作写入安全且不可变的区块链（比特币网络）来巩固和维护对 DID 的所有权。

ION 具有全球可扩展性，同时保有比特币区块链的去中心化特性。

由于 ION 是 Layer 2，所以 ION 不受限于 Layer1 的比特币区块链的吞吐量限制，其 TPS 可成千上万。

应用层：DID

DID 包括两方面内容：

1、唯一标识符（a unique identifier）

2、相关的 DID 文档（an associated DID Document）

前者是后者的标签，后者则包含诸如 DID 可以授权什么，在哪些服务中 DID 可以被使用等信息。

案例 2：eID 数字身份链

eID 是以国产自主密码技术为基础、以智能安全芯片为载体，采用空中开通或临柜面审的方式，依据对法定身份证件核验的结果，由“公民网络身份识别系统”签发给公民的网络电子身份标识，属于国家层面的数字身份。

eID 数字身份链是以 eID 数字身份为统一的个人身份标识，结合 eID 电子签名和区块链技术，链接个人各维度数据的数据流通服务平台，是在 eID 数字身份体系上发展起来的 eID 应用基础设施服务。数字身份链是以 eID 为基础的联盟链，由公安部第三研究所为指导单位，北京公易联科技有限公司投资建设及联合推广。eID 数字身份链可以提供个人身份认证、签名授权、区块链存证等平台解决方案，在保护用户数据的前提下，实现多个信息系统的数据互通。

使用体验：只要拥有 eID，就可以使用 eID 数字身份链。华为手机的卡证区可以绑定 eID，eID 数字身份 APP 可以将各种证书授权上链。

案例 3：百度智能云 CloudDID

CloudDID 是百度智能云于 2019 年 11 月推出的一款智能小程序，其核心是基于企业区块链平台天链的可信数字身份解决方案，为企业 / 用户提供数字身份服务。

CloudDID 生态有三个参与方：一是用户，即 DID 的使用者，通过小程序来创建、管理自己的 DID，并把身份相关的数据存储在组件中；二是发证方，向用户发放数字证书，比如政府机关、学校等权威机构；三是应用方，向用户提供 DID 相关的应用服务，应用方会验证用户的 DID 和数字证书。

使用体验：用户先注册百度 APP 账号，再登录 CloudDID 小程序，然后系统会自动生成 DID 和私钥（包括主私钥和备用私钥）。CloudDID 采用的是 Secp256k1 签名算法，私钥仅本地存储。目前，用户可以申请个人认证和企业认证。

主要功能：认证和授权。认证的功能是证明用户使用某产品或服务前，具有使用资质；授权的功能是用户在获取某权利或认证时，需要通过前置认证来获得授权。

用户 DID 不是由单一机构赋予，而是根据确定的算法（DID Spec）生成，同时还会生成一对密钥（公钥和私钥），其中公钥与 DID 绑定在分布式存储上，私钥则保存在用户的设备上。与 DID 相关的个人数据不上链，而是加密存储在发证方，用发证方颁发的声明来证明用户的隐私属性（比如姓名、年龄、职业、邮箱地址等），但需经用户授权才能读取。这是与中心化数字身份的区别。

案例 4：uPort

uPort 是 ConsenSys 建立在以太坊区块链上的身份管理应用，基本符合 W3C 制定的关于 DID 的标准。属于用户的代理，即 Holder 角色，会帮助用户去进行可验证声明 VC 的申请、储存和授权，以及 DID 在区块链上的注册。

使用体验：uPort App 类似于一款数字钱包，在 App 上注册一个 uPort ID，由 DID+以太坊账户组成。一个 uPort 账户关联了以下内容：1、uPort ID；2、个人基本信息：可选填姓名、邮件、国家、电话四个字段；3、Credentials：Credentials 就是在 W3C 标准里的 VC；4、其他辅助信息：如账号的二维码、账户头像等。

瑞士楚格利用 uPort 在以太坊区块链上创建了世界上第一个政府自主发行的身份项目，楚格公民可以通过 uPort 应用进行投票。

案例 5：井证 J-DID

井证是井通公链生态的一个节点，号称也拿到了公安部的个人身份代理资格。井证有两个产品：Jpassword （密码管理软件）、井证 J-DID。

Jpassword 是面向 C 端用户的密码管理软件，用于保存用户名、密码、私钥和其他个人隐私数据。

目前传统的同类软件是将这些个人隐私数据保存在中心化的服务器中，而 Jpassword 则将数据保存在去中心化的 IPFS 分布式数据库中。

J-DID 是面向 B 端和 G 端的基于区块链的可信数字身份平台，遵循 W3C DID 标准。

传统的中心化身份验证平台，各个平台之间都是数据孤岛，存在重复验证的问题，而 J-DID 则打造一个权属完全属于个人的 ID，用户是基于个人的 ID 去进行实名认证，实现数据和应用分离。

井证和中国电信、公安部第一研究所在天翼 U 盾中有合作：基于区块链的数字身份，用户的 J-DID 和私钥存储在电信 SIM 卡的安全芯片中，与 DID 相关的隐私数据保存在 IPFS 分布式存储平台，从而帮助用户管理密码及其他个人隐私数据，将 U 盾电子化、软件化、虚拟化。

除此之外，还有不少企业布局了 DID 这个赛道。比如：Paypal 投资了 Cambridge blockchain startup；Telegram 推出了 Telegram Passport，与微软 DID 类似，可以加密用户的私人信息，并使用它们在各类应用服务中安全地交互；Coinbase 则收购了 Distributed Systems，并且可能会通过数字身份在 Coinbase 旗下产品之间构建桥梁；IBM 与 HyperLedger 共同发起的 HyperLedger Indy 项目 Soverin 是企业级方案的先行者，对企业需要立刻部署基于开源技术的 DID 具有优势。

六、DID 的前景展望

区块链+数字身份这个领域，已经实现初步的应用落地，但尚未出现现象级产品。DID 项目的发展前景，主要取决于三个特性：

1、隐私保护

隐私保护是 DID 区别于传统数字身份的关键特性之一。DID 可以防止隐私数据被非授权的主体盗用，这个特性是长足优势、硬需求。

2、互操作性

DID 项目本身并不具备广泛的应用属性，DID 相当于是区块链世界的一个基础设施，DID 需要具备跨应用的互操作性以获得在商业场景中的附加价值。

跨应用互操作性可以促进应用间的互联互通，解决信息孤岛、跨应用合作困难的问题。所以，DID 项目在标准化、适用范围方面的建设非常重要。

标准化方面的建设，目前主要由国际化标准组织 W3C 牵头制定；适用范围方面的建设，主要取决于 DID 项目本身的初始设计，必须要有足够的适用广度、具备足够的跨应用互操作性，更有可能获得普遍推广应用。

3、项目信用

DID 项目信用，早期可能主要取决于建设主体的信用，后期主要取决于项目机制和项目建设成效。DID 虽然是去中心化数字身份，但是不可否认 DID 非常依赖公关事务，商业属性较弱，比较依赖公共机构牵头。以政府或者公共机构牵头建立的区块链数字身份系统，在早期更容易被广泛认可，更有希望形成社会共识。同时，政府对于身份保密性通常也有一定的要求，所以 DID 也可能成为政府政务系统中的一项基础设施。DID 这个领域本身的发展前景，随着标准化的继续拓展，相信会有越来越多的应用切换 / 加入到 DID 这个基础设施上来。

相关文章

• 去中心化身份（Decentralized ID, DID）介绍
• DID 去中心化数字身份
• 去中心化数字身份DID基本概念
• DID 起步：图说去中心化身份
• Decentralized Identifiers (DIDs) 翻译
• Azure Active Directory 可验证凭据文档
• Baidu Cloud DID Specification
• WeIdentity