分布式数字身份DID调研
1.分布式数字身份
分布式数字身份不止是人,包括组织,甚至未来也包括物品。
1.1数字身份标识
-
数字身份通常由身份标识符及关联的属性来表示,分布式数字身份包括:分布式数字身份标识符和数字身份凭证(声明集合)两部分
-
分布式数字身份标识符DID是由字符串组成的标识符,用来代表一个数字身份,不需要中央注册机构就可以实现全球唯一性。通常,一个实体可以拥有多个身份,每个身份被分配唯一的DID值,以及与之相关联的非对称密钥。不同的身份之间没有关联信息,从而可以有效的避免所有身份信息的归集
-
DID是一种去中心化的可验证的数字标识符,具有分布式、自主可控、跨链复用等特点。实体可以自主完成DID的注册、解析、更新或者撤销操作。DID具体解析为DID Document,DID Document包括DID的唯一标识符,公钥列表和公钥的详细信息(持有者、加密算法、密钥状态),以及DID持有者的其他属性。另外一个实体可以对应多个DID。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ppB5bWby-1597202803145)(分布式数字身份DID调研.assets/屏幕快照 2020-08-05 下午8.53.56.png)]
-
DID和DID Document相关联。DID文档上记录的数据是由用户自己决定的,不必要的信息可以完全不记录在DID文档上。在DID系统中,有身份颁布者,身份持有人和验证者三类角色。持有人向颁布者申请身份,验证者在需要时验证持有人的身份。DID数据存放在区块链上,链上不存储隐私数据。而他们三者直接的相互交互使用非对称加密算法、零知识证明等密码算法。
1.2可验证声明
可验证声明VC提供了一种规范来描述实体所具有的某些属性,实现基于证据的信任。DID持有者,可以通过可验证声明,向其他实体证明自己的某些属性是可信的。同时,结合数字签名和零知识证明等密码学技术,可以使得声明更加安全可靠,并进一步保障用户隐私不被侵犯。
2.DID现状
2.1提出的标准
- W3C的DID标准:A primer for Decentralized Identifiers
- DIF(Decentralized Identity Foundation)的DID Auth:DIF官网
2.2在研项目
- MicrosoftDID、Sovrin、uPort、Evernym、Civic、ShoCard
- 公安部第三研究所华为DID
- 公安部第一研究所国家队“互联网➕”可信身份认证平台(CTID平台)
- 井通J-DID
- 百度DID
- 微众银行DID
3.可以解决的问题以及使用场景
3.1可以解决的问题
分布式数字标识可提供全局唯一的分布式实体身份标识、可信数据交换协议,促进跨部门、跨地域的身份认证和数据合作。摆脱对传统模式下单一中心ID注册的依赖。实体的现实身份和可验证数字凭证的内容可链下存储。支持实体将信息最小化或者选择性披露给其他机构,同时防止任何第三方反向推测出实体在现实世界或其他场景语义中的身份。
3.2数据共享
-
背景
当前,不同机构间存在着大量用户数据流通的需求。然而,由于各个机构之间通常难以组建有效的信任合作机制,因此,各机构间难以将各自保管的用户数据安全可信地授权共享给其他机构。通过分布式数字身份DID解决方案,可帮助机构间进行可信数据授权及共享,使得各机构可基于全面的数据为用户提供更高质量的服务。
-
参与方
用户、数据持有机构、数据使用机构、身份证明机构
-
解决方案以及流程
- 在身份证明机构、数据持有机构、数据使用机构之间搭建区块链网络,机构作为节点接入并注册DID
- 在身份证明机构中为用户生成DID
- 用户授权数据使用机构使用自己的数据
- 数据使用机构生成授权凭证,表明授权对象、数据属主、有效期、授权内容等属性,并使用机构的私钥进行签名;数据使用机构可以选择将授权凭证生成摘要并写入区块链,达到增信目的
- 数据使用机构出示授权凭证给数据持有机构
- 数据持有机构通过凭证验证接口,验证授权凭证
- 通过验证,数据持有机构将数据发送给数据使用机构
3.3选择性披露
-
背景
合作方为某娱乐机构。此机构需要年满18岁方可入场消费。某个实体人想进娱乐机构消费,但他不想暴露自己的真实姓名等隐私信息。
-
参与方
- 实体
- 娱乐机构
-
解决方案与流程
- 实体人及娱乐机构进行DID注册及KYC认证。
- 实体人向娱乐机构进行选择性披露,只披露KYC认证(Credential)的DID、有效期、出生日期等信息,隐藏其他信息。
- 娱乐机构通过凭证验证(Verify)接口对选择性披露的数据进行验证。
- 验证通过,允许进入。
4.如何实现和使用
4.1W3C与DID使用
分散标识符(DID)是一种新型的标识符,它是全局惟一的、可解析的、高可用性的,并且可以通过密码验证。DID通常与加密材料(如公钥和服务端点)相关联,用于建立安全的通信通道。DID对于任何有利于自我管理、加密可验证标识符(如个人标识符、组织标识符和物联网场景中的标识符)的应用程序都非常有用。例如,目前W3C可验证凭据的商业部署大量使用分散的标识符来标识人员、组织和事物,并实现许多安全和隐私保护保证。
- 基础层:DID规范,包括DID标识符和DID文档
- 应用层:可验证声明或者凭证VC
4.2DID与传统标识体系的区别
常见的有两种:UUID(全局唯一标识符)和URN(统一资源名称)。对于UUID,不用集中式注册机构即可提供全局唯一性,但不能全局解析。而URN一次分配给实体并且永远不需要改变,需要集中的注册机构。此外,两者都没有加密验证标识符所有权的能力。
对于全新的DID,可以提供不依赖任何集中授权的终生便携式数字身份,且满足:持久性,全局可解析性和分散性。
4.3DID格式
-
DID示例一(W3C Credentials Community Group):did:example:123456789abcdefg
-
DID示例二(微众银行DID):did:weid:1:0x0086eb1f712ebc6f1c276e12ec21
4.4DID文档
DID基础设施可以被认为是全局键值数据库,其中该数据库是所有DID兼容的区块链,分布式分类账本或分散式网络。在此虚拟数据库中,键是DID,值是DID document。DID文档的目的是描述公钥、身份验证协议和服务端点,它们是引导与标识实体的密码可验证交互所必需的。
DID文档是一个JSON-LD Object
DID文档内容 | 描述 |
---|---|
DID主题 | DID标识符本身,也就是DID文档所描述的该DID。由于DID的全局唯一特性,因此在DID文档中只能有一个DID |
公钥 | 公钥用于数字签名及其他加密操作,这些操作是实现身份验证以及与服务端点建立安全通信等目的的基础。如果 DID 文档中不存在公钥,则必须假定密钥已被撤销或无效,同时必须包含或引用密钥的撤销信息(例如,撤销列表)。 |
身份验证 | 身份验证的过程是 DID 主题通过加密方式来证明它们与 DID 相关联的过程。 |
授权 | 授权意味着他人代表 DID 主题执行操作,例如当密钥丢失的时候,可以授权他人更新 DID 文档来协助恢复密钥。 |
服务端点 | 除了发布身份验证和授权机制之外,DID 文档的另一个主要目的是为主题发现服务端点。服务端点可以表示主题希望公告的任何类型的服务,包括用于进一步发现、身份验证、授权或交互的去中心化身份管理服务。 |
时间戳 | 文档创建时间和更新时间 |
{
"@context": "https://w3id.org/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
// used to authenticate as did:...fghi
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\\r\\n"
}],
"service": [{
// used to retrieve Verifiable Credentials associated with the DID
"id":"did:example:123456789abcdefghi#vcs",
"type": "VerifiableCredentialService",
"serviceEndpoint": "https://example.com/vc/"
}]
}
需要注意的是,DID文档中没有任何和个人相关的内容,比如个人的真实姓名、地址、手机号等。因此光靠DID规范是无法验证一个人的身份的,必须要靠DID应用层中的可验证声明VC
4.5DID的相关操作
- create:创建一个DID
- DID方法规范必须指定客户端如何在DID注册表上创建DID及其相关的DID文档,包括建立控制证明所需的所有加密操作。
- read/verify:解析验证DID文档
- DID方法规范必须指定客户端如何使用DID从DID注册中心请求DID文档,包括客户端如何验证响应的真实性。
- update:DID文档升级
- DID方法规范必须指定客户端如何更新DID注册表上的DID文档,包括建立控制证明所需的所有加密操作,或者声明不可能进行更新。
- deactive:停用DID
- DID方法规范必须指定客户端如何在DID注册表上停用DID,包括建立停用证明所需的所有密码操作,或者声明不可能停用。
4.6DIDs与隐私设计
隐私设计是任何身份管理解决方案的重要组成部分,对于使用不可变的全球身份系统来说,这一点尤其重要。
- 成对匿名的DID
- 尽管DID可以用作众所周知的公共标识符,但它们也可以用作基于每个关系发布的私有标识符。因此,一个自然人A可以拥有成千上万的成对唯一的DID,而不是一个单独的DID(例如手机号码或国家ID号码),而无需A的同意就可以将其关联起来,可以像通讯录一样轻松地进行管理。
- 链下私有数据
- 链下存储所有的私有数据,仅通过对等连接进行加密交换。
- 选择性披露
- DID使得分散式PKI(DPKI)成为可能,这使个人可以通过两种方式更好地控制其个人数据。首先,它可以使用加密的数字凭据进行共享。其次,这些凭证可以使用零知识证明密码术来最小化数据透露
4.7DIDs与可验证凭证VC
4.7.1可验证凭证的系统架构
- 发行者
- 拥有用户数据并能开具VC的实体,如政府、银行、大学等机构和组织。
- 持有者
- 持有者即用户。用户向Issuer请求、收到、持有VC的实体,向验证者出示VC。开具的VC可以自我保存,方便以后再次使用,例如保存在钱包里。
- 验证者
- 接受VC并进行验证,由此可以提供给出示VC者某种类型的服务。
- 标识符注册机构
- 维护DIDs的数据库,如某条区块链、分布式账本(可理解为前面提到的DID里的example字段)。
VC的格式也是JSON-LD
{
// 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"
}
}
4.7.2验证者验证VC
因为VC中是没有Issuer的公钥的(也不应该有,因为就算有了,验证者还需要亲自验证公钥是否是真的)。这里VC的id是一个URI,而VC中的Issuer字段也是一个URI。而Issuer也可能是使用DID来作为其身份的。因此,通过VC中的Issuer字段——URI地址得到其DID,然后从DID对应的DID文档里可以得到其公钥。用公钥验证对VC的签名就能验证VC是否Issuer发的。
4.7.3验证者验证用户
用Holder(即用户)的DID对应的DID文档里的公钥来验证其数字签名的合法性。
5.WeIdentity
5.1什么是WeIdentity
WeIdentity是一套分布式多中心的技术解决方案,可承载实体对象(人或者物)的现实身份与链上身份的可信映射、以及实现实体对象之间安全的访问授权与数据交换。WeIdentity由微众银行自主研发并完全开源,秉承公众联盟链整合资源、交换价值、服务公众的理念,致力于成为链接多个垂直行业领域的分布式商业基础设施,促进泛行业、跨机构、跨地域间的身份认证和数据合作。
WeIdentity目前主要包含两大模块:WeIdentity DID以及WeIdentity Credential
5.2WeIdentity参考场景
5.3WeIdentity规范
设计目标:多中心、开放开源、隐私保护、可移植性、互操作性、可扩展性
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z4q19wkr-1597202803149)(https://weidentity.readthedocs.io/zh_CN/latest/_images/weidentity-er.png)]
从图中可见,WeIdentity DID与WeIdentity Credential的关系并非单纯的一对多:从设计目标上看,WeIdentity DID用来描述实体(人或物),WeIdentity Credential用来描述实体的身份、属性和实体间关系。因此,一个WeIdentity DID可以持有多个WeIdentity Credential;而一个WeIdentity Credential则会包含至少一个所描述的WeIdentity DID,可能会有多个。最后,每个WeIdentity DID都有一个WeIdentity Document,用来存储此DID的认证方式(如公钥、私钥套件)等信息,与WeIdentity Credential无关。
总体流程
如何生成WeIdentity DID
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TH7AJH78-1597202803154)(分布式数字身份DID调研.assets/屏幕快照 2020-08-11 下午5.54.03.png)]
5.4场景
6.微软DID
7.百度DID
来源:oschina
链接:https://my.oschina.net/u/4332858/blog/4497062