去中心化身份和Web3

最近在看去中心化身份(DID)和Web3,在这里写一篇笔记。说实话,这个领域目前还处于摸索阶段,真正落地的项目不多。刚接触的人对Web3.0的描述只能停留于加密货币、区块链、去中心化、数据所有权、反垄断等花里胡哨的关键词(蛮符合我对区块链的刻板印象的)。

Web3和DID的关联

我认为,Web3就是为了解决一个issue:数据归于用户。比如用户在注册中心化平台账号时一般需要给平台提供手机号等身份信息,一些服务甚至还需要提供身份证进行实名认证,这导致了用户数据的主动权泄露给了服务器。在Web3,用户不需要将他们的数据存储到中心化平台,避免了自己数据资产被中心化实体控制的风险,自己享有数据的使用权。

DID的诞生和Web3类似,用户登录不同的中心化网站需要注册账户,不同网站的身份系统不互通。即使现在登录中心化网站可以使用联邦身份,支持使用微信、QQ账号进行第三方登录,但是第三方登陆后往往也需要用户输入手机号+验证码来注册。中心化身份想要让用户在网络空间中具有一种全局唯一的身份,用户在使用任何平台的服务时,用这种标识符来进行登录或者身份验证。

乍一看,两者的思想是非常相似的。Web3是想要数据归于用户,DID具体实现了身份信息归于用户,所以DID是Web3的一种实现。而DID可以解决Web3的身份验证问题,所以DID也是组成Web3的一种关键技术。Web3的数字钱包地址也可以整合到DID中从而标识钱包的所有权

DID

从W3C的规范来谈,DID包含标识符和文档,标识符负责表示全局唯一的身份,文档包含和这个数字身份的相关的数据。平台通过DID对用户进行认证。如果平台需要认证用户额外的信息,比如用户的年龄,用户需要向政府部门请求关于年龄的可验证声明,政府部门向用户返回声明后,用户向平台发送声明,如果声明的验证通过并且DID的验证通过,则用户在该平台登录成功,或者说认证成功。

这里补充一下,用户的DID文档是存储在区块链上的

DID具体结构

DID标识符是全局唯一表示身份的key,举个例子:did:eth:123456789abcdefg

DID文档是用来存储和这个身份相关联的数据 ,目前一般使用JSON字符串,其中至少包含:DID标识符、公钥、支持的加密协议、服务的功能及其对应的URL,时间戳,证明DID合法的签名。一个符合W3C标准的基本DID文档如下所示 :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
"@context": "https://w3id.org/did/v1",
"id": "did:example:123456789abcdefghi", // DID标识符
"authentication": [{
// 用于验证DID的参数
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}],
"service": [{
// 服务集合,下列服务用于返回和DID相关的可验证声明
"id":"did:example:123456789abcdefghi#vcs",
"type": "VerifiableCredentialService",
"serviceEndpoint": "https://example.com/vc/"
}]
}

可以看到DID文档中并没有和真实身份相关联的信息。如果平台需要验证用户年龄、用户手机号等信息,单独靠DID是不能完成的,需要权威机构开具可验证声明。

可验证声明

可验证声明系统是DID的一部分,本质上就是一个PKI体系。一个可验证声明系统有四个实体:

  • 发行者(Issuer):拥有用户数据,并且能够开局可验证声明 (Verifiable Credential, VC) 的实体,比如政府。
  • 验证者(Inspector-Verifier, IV):负责提供服务,但是在提供服务之前需要验证VC
  • 持有者(Holder):向Issuer请求VC的实体,它可以将开具的VC存到数字钱包中
  • 标识符注册机构(Identifier Registry):负责提供注册DID,维护DID服务的实体,如某条区块链

可以看到DID和VC其实是分开的。

当用户需要使用某个平台的服务,平台需要用户出示证明自己已满18岁。这时用户需要向Issuer请求对应的VC,Issuer返回VC后用户将VC存储在数字钱包中并发送给平台。平台对VC验证通过就允许用户使用服务。VC可以重复使用,只要VC还在有效期内,用户就可以一直使用VC来表明自己已满18岁。W3C提供的VC参考如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
{
// 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"
}
}

VC的id是一个URI,而VC中的Issuer字段也是一个URI。而Issuer也可能是使用DID来作为其身份的。因此通过VC中的Issuer字段——URI地址得到Issuer的DID,然后从对应的DID文档里就可以得到Issuer的公钥。VI可以用公钥验证对VC的签名,就能验证VC是否Issuer发的。

一些QA

  1. Q1:DID系统中哪些东西需要上链,哪些东西需要私下保存?

    A1:DID标识符和文档需要上链。目前VC因为包含了用户的隐私信息,需要私下保存。但是即使是私下保存VC,把VC发给平台认证的时候依然会把隐私信息泄露给平台,这个我认为可以使用公钥密码的技术来解决这个问题。

  2. Q2:使用了Web3和DID是否就能自己掌握数据和帐号了?

    A1:我认为只是做了改进,自己完全掌握自己的数据和账号是不现实的。

    1. DID中自己的信息依然存储在中心化机构。相比于中心化身份,DID的身份信息只保存在给用户颁发对应身份信息的机构中(比如政府颁发身份证号,银行颁发银行卡号,运营商颁发手机号)。中心化身份的身份信息既保存在颁发身份信息的机构中,也保存在中心化平台中(因为用户注册需要提供相关信息)。如果颁发身份信息的机构可信,那用户就完全具有了对身份数据的控制权。
    2. 其次,用户在平台上的行为数据依然全部被这个网站所拥有,但是用户最关键的身份信息不会透露给中心化网站,用户可以使用VC的方式来披露部分身份信息(比如之前的例子,自己是否已满18周岁)
    3. DID确实有保护隐私的作用,DID中不存有用户任何和现实身份有关的信息,如果真需要对现实身份信息进行认证,就需要Issuer开具VC。在DID中研究隐私保护其实就是在VC中研究如何保护用户数据隐私
  3. Q3:DID真的能火起来吗?

    A3:我对此比较怀疑,从受众角度来讲,这改变了用户使用互联网的习惯,这需要有公司提供软件对Web3和DID技术做足够的封装,帮助用户一键处理麻烦的步骤(包括但不限于申请DID并上链,申请VC并保存到本地等),如果能在保证用户使用体验的情况下保护用户隐私那可能会吸引一部分受众,但是使用区块链就决定了小众且低效;从标准角度来讲,目前并没有能够颁发大家都信服的Web3和DID标准,这会阻挠DID的基础设施建设;从基础设施来讲,这会损害现有中心化平台的利益,对于能从中心化平台牟利的公司来说应该不会积极开发DID的技术以及相关基础设施的建设(比如Web3的密钥管理,协议建设等)。

DID的隐私问题

隐私是Web3去中心化和数据主权之后的第三大目标,我认为现有Web3的隐私问题和改进主要有以下几点(从密码学角度来说,可能比较严格):

  1. 较多用户有分享的习惯,在使用平台服务时,他们可能会以DID的名义分享和自己真实身份相关的信息,造成隐私泄露。但这是用户习惯造成的,很难避免。
  2. 在使用VC进行验证时有暴露用户身份信息的风险
  3. 用户在使用数字钱包进行数据共享时,需要对数据进行细粒度的访问控制
  4. 能否在Issuer生成可验证声明时不知道这个可验证声明是什么

密码学天生就是为了隐私保护而生的,目前利用密码学技术来解决DID的隐私问题具有很大的研究空间。比如

  1. 各种通用的隐私计算技术:比如使用零知识证明当用户使用VC进行认证时VC不包含用户的隐私信息,但是平台能知道用户有对应的隐私信息能够满足认证要求。
  2. 门限加密,身份基加密,属性基加密:为用户使用数字钱包进行数据共享时提供细粒度的访问控制。
  3. 群签名、环签名、盲签名:虽然在区块链中还是环签名用的最多,但是Web3.0的DID隐私可能会为群签名和盲签名注入新的活力,比如保证用户使用平台服务的匿名性,但是当用户做出违法操作时可以追踪到具体用户;用户想让Issuer生成VC并且Issuer知道用户想对什么信息生成VC,同时Issuer还能知晓用户申请的VC是合规的。

总结

Web3+DID是区块链技术的一种新的应用,能够让用户的身份数据以及一些其他的数据归用户所有,由用户决定是否把自己的数据发送给平台。它具有去中心化,数据主权,隐私保护,验证等比较吸引研究人员的特点。

但是在多数用到了区块链的解决方案上,往往都能用目前比较成熟的技术的另一个方案(除了数字货币本身)。而且区块链往往确实没有特别的优势。只要是这样,由于惰性的存在,区块链的落地就很难进行。而且目前大多数人关注区块链不是因为他有去中心化等花里胡哨的性质,而是他们能炒币赚钱割韭菜,真正适合区块链的应用场景依然有待探索(我对在金融领域的探索依然抱有信心,其他的领域就不一定了)。