我是靠谱客的博主 粗暴蚂蚁,最近开发中收集的这篇文章主要介绍DID系列1--去中心化数字身份DID简介Decentralized Identifiers (DIDs) v1.0DID Specification Registries,觉得挺不错的,现在分享给大家,希望可以做个参考。
概述
资料来源:
去中心化数字身份DID简介——一、基本概念 - 腾讯云开发者社区-腾讯云
https://www.jianshu.com/p/5d46dccc1f2e
去中心化数字身份(Decentralized Identity,DID)是基于区块链技术建立起来的一种数字身份系统。它可以保证身份数据真实可信,同时也能保护身份用户相关的隐私,确保跟个人身份相关的数据归属于个人所有。很吻合2021年11月开始实施的《中国个人信息保护法》。
1 身份认证的演进过程
V1.0 传统的身份认证:用户在每个网站上都重复注册账号,使用账号+密码的方式登录,每个网站各自掌握着用户的身份信息,如图1(a)所示。
缺点:重复注册账号,用户会时常不记得账号密码;而且多个网站都有用户的信息,也导致信息泄露。
V2.0 以单点登录代表的身份认证:用户在一个网站上注册的账号,可以授权登录到其他网站,比如在支付宝、微信、facebook、google等网站注册号账号后,授权登录到其他网站,如图1(b)所示。
缺点:用户的信息都掌握在几个大网站内,会有”店大欺客“的成分存在,也容易出现信息泄露的情况,如facebook的用户信息泄露问题。
V3.0 去中心化的身份认证:用户保管自己的身份信息,在必要的时候,以最小化的方式出示给各个网站确认即可,如图1(c)所示。
算缺点么?需要区块链作为底层技术支撑,将区块链作为一个可信任的第三方,来保证身份信息的完整性和正确性。
图1.身份认证的演进过程
2 DID 身份认证的原理
Decentralized IDentity去中心化身份,简称DID,相对于传统的基于PKI的身份体系,基于区块链建立的DID数字身份系统具有保证数据真实可信、保护用户隐私安全、可移植性强等特征,其优势在于:
去中心化:基于区块链,避免了身份数据被单一的中心化权威机构所控制。
身份自主可控:基于DPKI (分布式公钥基础设施),每个用户的身份不是由可信第三方控制,而是由其所有者控制,个人能自主管理自己的身份。
可信的数据交换:身份相关数据锚定在区块链上,认证的过程不需要依赖于提供身份的应用方。
2.1 DID长什么样?
图2.DID标识
前缀did: 固定的,表示它是一个did标识。
中间的example:被称为DID方法,用来表示是用哪一套方案(方法)来进行定义和操作的。可以自定义,比如腾讯旗下FISCO BCOS的DID标识为 tdid,Hyperledger Indy的标识为 indy,更多的请参考W3C的网站(
https://w3c.github.io/did-spec-registries/#did-methods)。
后面的字符串:是在该DID方法下的唯一标识字符串。
比如我们做了一个DID系统,我们把方法就起名叫cid吧,想把中国公民的身份证信息都DID化,那么我的DID标识就是: did:cid:5111**************5 这里我们就使用身份证号码作为cid这个DID方法下的唯一标识。
2.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在链上的读取和更新等。
图4. DID文档, VC, VP 的格式
个人觉得DID文档中最重要的就是公钥信息。
2.3 可验证声明 VC(Verifiable Claims)
可验证凭据
VC(Verifiable Credential)
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。
2.4 可验证表达 VP(Verifiable presentation)
可验证表达是VC持有者向验证者表明自己身份的数据。一般情况下,我们直接出示VC全文即可,但是在某些情况下,出于隐私保护的需要,我们并不需要出示完整的VC内容,只希望选择性披露某些属性,或者不披露任何属性,只需要证明某个断言即可。
比如一个求职者要进入某写字楼面试,写字楼的保安要求登记身份证号码和姓名,但是我们的VC中还包含了民族、住址等信息,我们的求职者不希望将自己的住址暴露给保安,所以他提供给保安的VP中应该只选择性的披露身份证号码和姓名,其他信息都不披露。
再比如我们规定必须年满18岁才有资格购买香烟,所以一个消费者在购买香烟时必须证明自己已经年满18岁,但是直接出示身份证给收银员又会暴露太多隐私信息,就算选择性披露生日属性,也会让收银员知道了消费者具体的年龄和生日日期,这种情况下消费者只希望在VP中证明自己大于18岁,其他什么信息都不能暴露。
-
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"
}}
以上都是一些基本概念。
3. 如何支持多种类型的claim
VC中的claim五花八门,可能是大学毕业证书、身份证、驾驶证、结婚证等,为了能正确地解析,就需要提前在区块链中注册其解析方式, 这就是
证书模板。
这种事情一般由Authority来完成,按照业务场景分类,定义不同类型数据结构的Claim结构,并注册在区块链上,以保证全网通用。
4. 如何支持选择性披露
以身份证为例,其完整的VC凭据包括姓名、性别、出生日期、民族、住址、照片等。在买火车票时,可能只需要姓名和身份证号码;上学报名时,可能仅需要姓名、出生日期等;确认少数民族身份时,必须要明确民族信息。所以很多场景下,不是全部选项都需要,可能只需要其中的一两项,可以仅仅披露必须项。
但如何确认披露的这几项是正确的,没有被修改过呢?这里用到了经典的Merkle Tree结构,如图5所示。比如在只需要披露生日的场景下,就可以借用”生日“的兄弟选项”民族“,以其到树根的路径<Hash1, Hash34> + MerkleRoot 来验证”生日“的正确性。
图5.Merkle Tree用于验证选择性披露项的正确性
6. 采用零知识证明ZKP方式保护隐私
用户拥有的凭据中涉及很多私密信息,比如年龄(女生最不愿意让别人知道的)、收入等,这些都不能直接给别人看,但很多情况下又必须要验证这些信息,比如下图中的年龄范围(ageOver 18)、在学校是否获得过奖学金(degree),这些都是从原始VC中推导出来的,但为了保证推导过程的正确性,就必须附带零知识证明ZKP proof一同存放在VP中。
图6.用ZKP保护隐私
7. DID的认证流程
DID的认证过程涉及四方的交互:证书颁发者,证书持有者(可以拥有一个app保存多张证书凭据VC),验证方,以及DID注册系统(比如区块链)。
证书颁发者是一个权威机构,比如某大学、公安机关等;持有者会保存权威机构发布的凭据VC(比如从大学拿到的毕业证,公安机关拿到的身份证等);验证者会对这些凭据的表示(VP),并结合区块链上的信息进行验证。
DID认证的前提是权威机构、VC持有者、验证者都已经在区块链上注册了各自的ID。
8 W3C标准
Decentralized Identifiers (DIDs) v1.0
Decentralized Identifiers (DIDs) v1.0
DID Specification Registries
DID Specification Registries
代码库
GitHub - w3c/did-core: W3C Decentralized Identifier Specification v1.0
最后
以上就是粗暴蚂蚁为你收集整理的DID系列1--去中心化数字身份DID简介Decentralized Identifiers (DIDs) v1.0DID Specification Registries的全部内容,希望文章能够帮你解决DID系列1--去中心化数字身份DID简介Decentralized Identifiers (DIDs) v1.0DID Specification Registries所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
发表评论 取消回复