数字身份DID(1)--- 去中心化DID身份认证的技术解析

[winterpi]

    去中心化数字身份(Decentralized Identity，DID)是基于区块链技术建立起来的一种数字身份系统。它可以保证身份数据真实可信，同时也能保护身份用户相关的隐私，确保跟个人身份相关的数据归属于个人所有。很吻合2021年11月开始实施的《中国个人信息保护法》，有没有？

身份认证的演进过程

V1.0 传统的身份认证：用户在每个网站上都重复注册账号，使用账号+密码的方式登录，每个网站各自掌握着用户的身份信息，如图1(a)所示。
缺点：重复注册账号，用户会时常不记得账号密码；而且多个网站都有用户的信息，也导致信息泄露。

V2.0 以单点登录代表的身份认证：用户在一个网站上注册的账号，可以授权登录到其他网站，比如在支付宝、微信、facebook、google等网站注册号账号后，授权登录到其他网站，如图1(b)所示。
缺点：用户的信息都掌握在几个大网站内，会有”店大欺客“的成分存在，也容易出现信息泄露的情况，如facebook的用户信息泄露问题。

V3.0 去中心化的身份认证：用户保管自己的身份信息，在必要的时候，以最小化的方式出示给各个网站确认即可，如图1(c)所示。
**算缺点么？**需要区块链作为底层技术支撑，将区块链作为一个可信任的第三方，来保证身份信息的完整性和正确性。

DID 身份认证的原理

1. DID长什么样？

前缀did: 固定的，表示它是一个did标识。
中间的example：被称为DID方法，用来表示是用哪一套方案（方法）来进行定义和操作的。可以自定义，比如腾讯旗下FISCO BCOS的DID标识为 tdid，Hyperledger Indy的标识为 indy，更多的请参考W3C的网站（https://w3c.github.io/did-spec-registries/#did-methods）。
后面的字符串：是在该DID方法下的唯一标识字符串。

2. DID document --> DID的详细说明

    DID 文档是对DID的详细说明，是一对一的关系，可以看作由两部分组成：DID metadata，以及 DID public key，如图4(a)，其中public key是关键，用于数字签名或加密操作等。
    一般 DID 由用户自己保存，而将DID document 保存在区块链上(可以DID为 key 做索引)，以保证DID document 的正确性。
    当用户在区块链上注册 DID 时，可以根据智能合约生成DID 及相关的document，并由智能合约负责 DID在链上的读取和更新等。

3. DID的认证流程

    DID的认证过程涉及四方的交互：证书颁发者，证书持有者(可以拥有一个app保存多张证书凭据VC)，验证方，以及DID注册系统(比如区块链)。
    证书颁发者是一个权威机构，比如某大学、公安机关等；持有者会保存权威机构发布的凭据VC(比如从大学拿到的毕业证，公安机关拿到的身份证等)；验证者会对这些凭据的表示(VP)，并结合区块链上的信息进行验证。
    DID认证的前提是权威机构、VC持有者、验证者都已经在区块链上注册了各自的ID。

VC(Verifiable Credential): 可验证的凭据，这相当于大学颁发的毕业证，或是公安机构颁发的身份证等。其格式如图4(b)所示，包括：
(1) VC metadata，比如发行人、发行日期、声明(claim)的类型等；
(2) claim: 是一个或者多个关于主体的说明，比如身份证凭据的声明包含：姓名、性别、出生日期、民族、住址等；
(3) proof证明：保存了颁发者的数字签名，用于验证该VC的正确性及来源等。
有些实现方案中使用app或是钱包存储VC，持有者自己保管，也可以将VC存在区块链中，作为私密数据保存。

VP(Verifiable Presentation): 可验证的凭据表示，或者说是可验证的凭据的展示方式，有些场景下持有者不便于将VC直接给验证者看，或者一次验证中会涉及多个VC，所以就将一个或多个VC包装成VP，其格式如图4(c):
(1) VP元数据，包含了版本等信息；
(2) VC列表，要对外展示的VC的内容，如果是选择性披露或者隐私保护的情形，就需要对原始的VC做一些变动并加上对变动的证明。
(3) proof证明，主要就是持有者对本VP的签名信息。

4. 如何支持多种类型的claim

    VC中的claim五花八门，可能是大学毕业证书、身份证、驾驶证、结婚证等，为了能正确地解析，就需要提前在区块链中注册其解析方式。
    这种事情一般由Authority来完成，按照业务场景分类，定义不同类型数据结构的Claim结构，并注册在区块链上，以保证全网通用。

5. 如何支持选择性披露

     以身份证为例，其完整的VC凭据包括姓名、性别、出生日期、民族、住址、照片等。在买火车票时，可能只需要姓名和身份证号码；上学报名时，可能仅需要姓名、出生日期等；确认少数民族身份时，必须要明确民族信息。所以很多场景下，不是全部选项都需要，可能只需要其中的一两项，可以仅仅披露必须项。
    但如何确认披露的这几项是正确的，没有被修改过呢？这里用到了经典的Merkle Tree结构，如图5所示。比如在只需要披露生日的场景下，就可以借用”生日“的兄弟选项”民族“，以其到树根的路径<Hash1, Hash34> + MerkleRoot 来验证”生日“的正确性。

6. 采用零知识证明ZKP方式保护隐私

    用户拥有的凭据中涉及很多私密信息，比如年龄(女生最不愿意让别人知道的)、收入等，这些都不能直接给别人看，但很多情况下又必须要验证这些信息，比如下图中的年龄范围(ageOver 18)、在学校是否获得过奖学金(degree)，这些都是从原始VC中推导出来的，但为了保证推导过程的正确性，就必须附带零知识证明ZKP proof一同存放在VP中。

7. 如何撤销凭据

     比如证书到期了，颁发者需要撤销之前发布的凭据VC，这里用到了密码学中的累加器。
     在颁发者发布VC时，会给每个VC都设置一个大素数，并保存所有大素数的RSA累加结果；当需要撤销某个VC时，就先用该VC的大素数去除Accumulator，并更新Accumulator，之后验证时，用 VC 对应的大素数去除 Issuer 公开的 Accumulator，如果能整除，则表明是VC是有效的(未被撤销)。

DID的实现

    基于Ethereum，比较知名的DID是uPort。我也曾关注过Hyperledger的DID项目 Hyperledger Indy，但其底层采用了自己的一套区块链架构，而非Hyperledger Fabric，这估计是基于Fabric 的DID实现的场景较少的原因。微众银行FISCO BCOS基于自己的BCOS架构，实现了自己的一套WeIdentity.

结束语

     该章节只简单讲述了DID是什么，并粗略介绍了其使用原理，还有很多细节未能一一道来，如需要更多细节请移步：

1. DID core, https://www.w3.org/TR/did-core/#did-syntax
2. VC及VP: https://www.w3.org/TR/vc-data-model/
3. https://blog.csdn.net/studyzy/article/details/115266799?spm=1001.2014.3001.5502
4. 微众银行WeIdentity:https://weidentity.readthedocs.io/zh_CN/latest/README.html

补充：

在本文中介绍了DID的单一实现方式，今天看到另外一篇博客Demystifying Digital Identity (2/2)或参考其翻译揭开数字身份的神秘面纱2/2，建议通过一组链接文档来实现扩展的DID，以信息图谱的方式来组织文档，如主链、关联的多个账户、分类的基本信息profile、关联的外部服务或资源等，如下图。这样的DID，就可以对接任何应用程序、服务或用户，而且是一个全球可用的、分布式的、可审查的DID。