分布式身份标识(Decentralized Identifiers, DID)、百度DID
分布式身份标识(Decentralized Identifiers, DID)


1.背景
中心化身份 => 联盟身份 => 中心化身份(DID)
中心身份的缺陷:身份不是由用户自己控制的。不同网站自己用的身份系统(及账户对应的数据)之间是不互通的。
后联合推出了联盟身份,用户的在线身份有了一定的可移植性,如“支持第三方登录”。
联盟身份的缺陷:①个人并不是真正意义上拥有自己的身份,②身份无法互通。
去中心化身份(DID):利用区块链技术实现让数字身份真正为用户所拥有并支配。
2.1分布式数字身份
①分布式数字身份标识符(一种去中心化的可验证的数字标识符,具有分布式、自主可控、跨链复用等特点)
②数字身份凭证(声明集合);
2.2 声明、可验证声明(Verifiable Credential,VC)
声明:与身份关联的属性信息。可由身份所有者发出、也可由发行人发出(可验证声明)。
VC提供了一种规范来描述实体所具有的某些属性,实现基于证据的信任。
VC可以快速地传输,使它们在尝试建立距离上的信任时比物理对等物更方便。
DID持有者通过VC向其他实体证明自己某些属性是可信的。第三方根据记录验证声明。
数字签名等技术的加入,使可验证的凭证比其物理对等物更不易被篡改,也更值得信任。
发行者(Issuer):拥有用户数据并能开具VC的实体。
验证者(Inspector-Verifier, IV):接受VC并进行验证,后提供某种类型的服务。
持有者(Holder):向Issuer请求、收到、持有VC,向IV出示VC。VC可放在VC钱包里,方便以后再次使用。
标识符注册机构(Identifier Registry):维护DIDs的数据库,如某条区块链、分布式账本。

2.4 DID文档(Document)
与DID标识符形成键值对。DID文档描述的是与被识别对象进行密码验证交互所必须的DID主体标识、公钥、验证协议、服务端点等,JSON-LD格式,LD(Linked Data),VC的格式也是JSON-LD,该格式可以将文档转换为结构化的数据。
3.基本实现原理
3.1DID标识符规范格式

Scheme: DID的统一资源定位符(URI),默认为did
DID Method: DID方法,一般用于指定DID平台
DID Method-Specific Identifier: DID平台上关于DID Document的资源定位字符串,在整个DID方法命名空间是唯一的。
DID本质上是一个全球唯一的地址标识符URL,指向写有与用户身份关联的属性信息的DID文档。
W3C的DID标准


WeIdentity DID规范



DID方法规范作用:如何在特定的区块链或者系统创建、解析、管理DID和DID文档,DID规范要包含:Create、Read、Update、Delete
3.2DID现有的方法
以bid方法为例——中国信息通信研究院(中国信通院)
经过椭圆曲线加密和SM2,输出公钥,并对公钥进行hash处理。
BID身份描述对象:
{
//@context是数据链接的词汇,这个特定的实例引用了URL
//标识一个did主体
//名称:设置昵称以提高出价标识符的可用性。
"@context": " <a href="https://www.w3.org/2019/did/v1/" ,"="">https://www.w3.org/2019/did/v1",
"id": "did:bid:3acdafe161ef702033bdf895",
"name":"shiweijun",
//公钥用于身份认证
"publicKey": [{
"id": "did:bid:3acdafe161ef702033bdf895#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:bid:3acdafe161ef702033bdf895",
"authorizations": ["all"],
"bid": "did:bid: 3acdafe161ef702033bdf895
}, {
"id": "did:bid:3acdafe161ef702033bdf895#keys-3",
"type": "Ieee2410VerificationKey2018",
"controller": "did:bid:3acdafe161ef702033bdf895",
"bid": "did:bid: 3acdafe161ef702033bdf895"
}],
//身份验证:一个列表,其中包含用户的身份验证身份属性信息
"authentication": [{
"type": "ED25519SigningAuthentication",
"publicKey": "did:bid:3acdafe161ef702033bdf895#keys-1",
"proofId":"c1cb770ac94000d946e583d13ea310"
}],
//服务:每个服务都用属性ID标识。
"service": [{
"id": "did:bid: 3acdafe161ef702033bdf895#home_page ",
"type": "DIDResolve",
"serviceEndpoint": "http://www.caict.ac.cn"
}
],
//证明:用于证明DDO文档的内容完整性和源可靠性。
"proof": {
"type": "RsaSignature2018",
"created": "2017-10-24T05:33:31Z",
"creator": "did:bid: 3acdafe161ef702033bdf895#keys-1",
"signatureValue": "eyiOiJJ0eXAK...EjXkgFWFO"
},
"Extra":"abc123",
"isEnable":true,
"createTime":1561945638,
"updateTime":1561945638
}
Create

管理私钥的两种方式:
①生成助记词
②将私钥或者密钥库反馈给用户
Update:通过调用API进行
Read:可通过查询BID或BID的昵称来获取BID文档以及对所有人公开的详细信息。以JSON格式反馈以响应查询
Delete:通过调用API完成
身份验证

3.3证明DID与DID文档之间的绑定关系
根据DID方法规范对一个DID文档进行解析
验证DID文档的id属性和DID解析出来的结果是否一致
3.4证明公钥的控制
静态和动态两种方法:静态方法是使用私钥对DID文档进行签名,这可证明在DID文档注册前的私钥控制权;若DID文档未被签名,则可以用文档中关于公钥信息来动态证明。
①将包含DID文档中的公钥信息和nonce的质询消息发送到DID文档中描述的适当服务端点。
②根据公钥信息验证响应消息的签名
4.DID CA:DID验证/VC
认证中心(Certification Authority,CA),又称为数字证书认证中心。
CA中心作为电子交易中受信任的第三方。
CA核心功能:发放和管理数字证书,主要有:证书发放、证书更新、证书撤销和证书验证。
涉及的流程内容:
CA向用户颁发数字证书(证书包含证书主体的身份,公钥数据,颁发机构名称等)
发证机构对信息进行数字签名形成证书
拥有证书的用户拥有自己的公钥私钥
用CA的公钥解密用户证书,即可得到用户认证公钥
VC生命周期:
Issuer向holder签发VC。
holder可以将一/多个VC传输给另一个持有者。
holder向verifiers显示其一/多个VC。
verifiers验证VC的真实性。包括检查撤销VC的声明状态。
Issuer可以撤销revoke VC
holder可以删除delete VC
验证过程:
用户申请注册DID,由用户自己管理
验证用户DID(用户与DID是否对应),用户出示VC凭证,
验证者验证VC是由发行者发行的,通过VC中URL找到用户的DID文档,用过DID文档中的公钥再验证用户DID标识
可验证声明的信任模型:
verifiers信任由Issuer发行的VC
所有实体都相信可验证数据注册表是防篡改的,且正确记录是由哪些实体控制哪些数据。
holder和verifiers信任Issuer发布真实的关于主体的声明,并在适当的时候迅速撤销。
holder信任存储库安全地存储声明,不会将其释放给holder以外的任何人,并且在保管声明不会损坏或丢失声明。
(holder和verifiers信任Issuer,绝对信任数据表,holder信任存储库)
与其他信任模型的区别在于:
Issuer和verifiers不需要信任存储库。
Issuer不需要知道或信任verifiers。
零知识证明
为了使用零知识可验证凭证,Issuer必须以一种使holder能够以增强隐私的方式将信息提供给验证者的方式来发行可验证凭证。这意味着holder可以证明Issuer签名的有效性,而无需透露已签名的值,或者仅透露某些选定的值。标准做法是通过证明签名知识而不公开签名本身来做到这一点。
5.答疑
DID与区块链的解决方案:
分布式数字身份体系并不局限于区块链技术,更不绑定到唯一区块链平台上,其系统模块可能基于不同的区块链平台实现,甚至是非区块链的其他分布式账本实现
解决方案及流程:
①在身份证明机构、数据持有机构、数据使用机构间搭建区块链网络,机构作为节点接入并注册DID
②由身份证明机构为用户生成DID
③用户授权数据使用机构使用自己的数据
④数据使用机构生成授权凭证(Credential),标明授权对象、数据属主、有效期、授权内容等属性,并使用机构私钥进行签名;数据使用机构可选择将授权凭证生成摘要并写入区块链,达到增信目的
⑤数据使用机构出示授权凭证给数据持有机构
⑥数据持有机构通过凭证验证(Verify)接口,验证授权凭证
⑦验证通过,数据持有机构将数据发送给数据使用机构
【All作为节点接入区块链、注册DID → 身份证明机构:生成用户的DID →用户:授权数据使用机构 →数据使用机构:生成授权凭证、签名、生成摘要、写入区块链,出示授权凭证给数据持有机构 → 数据持有机构通过凭证验证(Verify)接口,验证授权凭证,通过验证后,将数据发送给数据使用机构】
“区块+共识算法”解决分布式系统的数据一致性问题,将可验证声明和DID文档存证于区块链中
优势:
可公开访问、可信验证、操作成本低廉;
支持用户控制自己的标识符和凭证托管,转换数据治理模型,减少对受信任中介的依赖性;
用户可以管理自己的身份数据,并在知情和授权的基础上将其公开给依赖方;
企业依靠可验证的用户信息来简化其运营,不必充当数据托管人并处理相关的成本和风险。
关于保护隐私
用户可以拥有多个DID,且DID之间没有任何关联。
加密的数字凭证(VC)、零知识证明
将用户标识符和凭证加密后存储在区块链上,不可篡改,人人都可以验证
DID文档和区块链上不包含个人数据。所有个人资料应保存在DID当事人控制的服务端点后。(服务端点在DID文档中用于表示与DID主题或关联实体进行通信的方式)
DID文档中没有任何和个人真实信息相关的内容。因此光靠DID规范是无法验证一个人的身份的,必须要靠DID应用层中的可声明验证(VC)
可验证声明结合数字签名和零知识证明等密码学技术,可以使得声明更加安全可信,并进一步保障用户隐私不被侵犯
用户对ID身份的控制权
在DID系统中,用户对自己的身份拥有绝对的控制权,用户根据实际需要自主选择使用哪些个人身份信息来进行身份验证,并将身份信息的哈希值存储在区块链上,供其他人验证。
总结
DID 技术实现的去中心化身份:首先,你将不只有一个 DID,而是依据身份场合需要的不同拥有无数不同的 DID,每一个 DID 都给你一个单独的终生加密的私密渠道与其他个人、组织或事物交互沟通,因此更好的选择你的身份来交流,更好的保护你的隐私;DID 将不仅用来证明的身份,而且可用来交换可验证的数字证书;每个DID直接登记在区块链或分布式网络上,无需向中心化注册机构申请。
与UUID的区别,或者说DID的优势:
DID与URN的格式一致
UUID强调的是信息实体的唯一性,DID标识符也是唯一的,但DID更强调的是分布式管理和信息的可验证性
UUID的作用:应用:
它能保证每个节点所生成的标识都不会重复,并且随着WEB服务等整合技术的发展,UUID的优势将更加明显。根据使用的特定机制,UUID不仅需要保证是彼此不相同的。UUID最少在3000+年内不会重复。
URI,URL,URN:
URI是统一资源标识符,进一步分为定位符(URL)和名称(URN):类似住址和人名(类比人名和地址是不能重复的)
用户代理的具体步骤为:
a. Jane首先要求她的用户代理帮她获得VC;
b.用户代理将Jane的物理文件连接到能够验证其身份的issuer;
c.issuer检查文件;
d.当issuer觉得文件符合要求,就会为Jane生成一个VC,VC包含了与Jane之前提供的文件相关联的身份信息;
e.issuer将VC发给Jane的用户代理;
f. Jane获得声明并进行查看,确保其正确反映自己的身份信息;
g.当Jane对声明确认并认可后,她指示她的用户代理保存该VC,以便将来可以使用它;
h.用户代理与Jane的凭证存储库进行通信,指示它存储新的声明;
i.凭证存储库将凭证清单返还给用户代理;
j.用户代理将凭证清单展示给Jane。
DID开发者中心
介绍
使用场景:认证+授权,如网络拍卖。
DID系统架构:

(1)Layer 1:区块链层
分布式存储中保存的是DID文档(DID Document),文档内最关键的是DID与公钥的对应关系。
目前我们方案中区块链支持Ethereum(以太坊)和Quorum(企业级区块链平台、联盟链),分布式存储支持IPFS。
(2)Layer 2:去中心化二层网络
目前区块链较低的TPS(系统吞吐量)无法满足上层业务的需求,百度自研了L2层节点–Germ。Germ节点会把上层的DID相关的操作打包,并创建一个 L1 链上交易并在交易中嵌入该操作批次的哈希。从而提高系统的整理处理性能。同时,我们对上提供了统一的DID解析服务(DID Resolver),此服务同时也对接DIF社区的通用解析器。
(3)Layer 3:可信交换层
L3是可信交换层,是DID系统中各个生态参与方互相建立安全身份认证与数据交换层。
DID Agent:用户使用的DID客户端。
Identity Hub:用户安全存储身份数据的组件。
百度发布了DID小程序,作为DID客户端,能够方便用户便捷的管理自己的DID。
主要流程:
(0) 用户使用DID小程序创建自己的DID
(1) 用户在小程序内获取发证方列表
(2) 用户向指定的发证方提交可验证声明申请,并提供相关材料
(3) 发证方审核完材料后,给用户颁发可验证声明
(4) 用户使用DID登入第三方应用,并获知应用需要用户提供某可验证声明
(5) 用户授权第三方应用去Identity-Hub中去获取可验证声明
(6) 第三方应用获取已授权的可验证声明
(7) 用户登入第三方应用成功

Identity Hub:用户安全存储身份数据的组件
实现满足几个要求:
①可以由用户选择部署于任何地方。
②用户数据加密保存。
③不保存任何私钥。
④用户数据的访问需要认证。
⑤第三方经用户授权后可访问用户数据。
可验证声明
可验证声明(Verifiable Claim,简称Claim),是发证方使用自己的DID给用户的DID的某些属性做背书而签发的描述性声明,并附加自己的数字签名,可以认为是一种数字证书。
发证方的DID是做背书的,签发出来的Claim,称之为:Proof Claim。
如果发证方是用户本身,即一个 DID对自己签Claim,称之为:Profile Claim。
Proof Claim
{
"@context": [
"https://www.w3.org/2018/credentials/v1"
],
"id": "xxxxx",
"type": [
"ProofClaim"
],
"issuer": "did:ccp:7f8ca8982f6cc6e8ea087bd9457ab8024bd2",
"issuanceDate": "2017-04-01T12:01:20Z",
"expirationDate": "2017-04-01T12:01:20Z",
"credentialSubject": {
"id": "did:ccp:97c30de767f084ce3080168ee293053ba33b235d71",
"shortDescription": "xxx",
"longDescription": "xxx",
"type": "xxx"
},
"revocation": {
"id": "https://example.com/v1/claim/revocations",
"type": "SimpleRevocationListV1"
},
"proof": [
{
"creator": "did:ccp:7f8ca8982f6cc6e8ea087bd9457ab8024bd2/1",
"type": "Secp256k1",
"signatureValue": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19"
}
]
}
id:用于在发证方内唯一标识此claim
type:所属大类的类型:ProofClaim,ProfileClaim
issuer:签发Claim 的发证方的 DID
proof:签名相关内容
revocation:定义了查询claim吊销列表的地址
credentialSubject 中的内容定义了发证方声明的内容:
id:被签发方的 DID
shortDescription:简短的描述
longDescription:详细的描述
type:claim 的类型
设计 claim 支持如下类型:
RealNameAuthentication:实名认证
FingerprintAuthentication:指纹认证
EnterpriseAuthentication:企业认证
BusinessAuthentication:商户认证
VIPAuthentication:大客户认证
7