分布式数字身份DID调研
< 返回列表时间: 2020-01-16来源:OSCHINA
【围观】麒麟芯片遭打压成绝版,华为亿元投入又砸向了哪里?>>>
1. 分布式数字身份
分布式身份不止是人,包括组织,甚至未来也包括物品。这些人或者组织、物品不简单依靠于原先中心化权威机构,无法被拿走或者删除,而且是终身携带的身份。
1.1. 数字身份标识
国际电子技术委员会将“身份”定义为“一组与实体关联的属性”。数字身份通常由身份标识符及与之关联的属性声明来表示,分布式数字身份包括:分布式数字身份标识符和数字身份凭证(声明集合)两部分。
分布式数字身份标识符(DID)是由字符串组成的标识符,用来代表一个数字身份,不需要中央注册机构就可以实现全球唯一性。通常,一个实体可以拥有多个身份,每个身份被分配唯一的DID值,以及与之关联的非对称密钥。不同的身份之间没有关联信息,从而有效地避免了所有者身份信息的归集。
分布式身份标识(Decentralized Identifiers, DID)是一种去中心化的可验证的数字标识符,具有分布式、自主可控、跨链复用等特点。实体可自主完成DID的注册、解析、更新或者撤销操作。DID具体解析为DID Document,DID Document包括DID的唯一标识码,公钥列表和公钥的详细信息(持有者、加密算法、密钥状态等),以及DID持有者的其他属性描述。

并且,一个实体可对应多个DID。

“声明(claims)”是指与身份关联的属性信息,这个术语起源于基于声明的数字身份,一种断言(assert)数字身份的方式,独立于任何需要依赖它的特定系统。声明信息通常包括:诸如姓名,电子邮件地址、年龄、职业等。
声明可以是一个身份所有者(如个人或组织)自己发出的,也可以是由其他声明发行人发出的,当声明由发行人签出时被称为可验证声明。用户将声明提交给相关的应用,应用程序对其进行检查,应用服务商可以像信任发行人般信任其签署的可验证声明。多项声明的集合称为凭证(credentials)。
DID和一个DID文档(DID Document)关联。DID文档上记录的数据是由用户自己决定的,不必要的信息可以完全不记录在DID文档上。在DID系统中,有身份颁布者,身份持有人和验证者三类角色。持有人向颁布者申请身份,验证者在需要时验证持有人的身份。DID数据存放在区块链上,链上不存储隐私数据。而他们三者直接的相互交互使用非对称加密算法、零知识证明等密码算法。
1.2. 可验证声明
可验证声明(Verifiable Credential)提供了一种规范来描述实体所具有的某些属性,实现基于证据的信任。DID持有者,可以通过可验证声明,向其他实体(个人、组织、具体事物等)证明自己的某些属性是可信的。同时,结合数字签名和零知识证明等密码学技术,可以使得声明更加安全可信,并进一步保障用户隐私不被侵犯。

2. 可解决的问题
数字分布式标识可提供全局唯一的分布式实体身份标识、可信数据交换协议,促进跨部门、跨地域的身份认证和数据合作。摆脱对传统模式下单一中心ID注册的依赖。实体的现实身份和可验证数字凭证的内容可链下存储。支持实体将信息最小化或者选择性披露给其他机构,同时防止任何第三方反向推测出实体在现实世界或其他场景语义中的身份。
3. 使用场景
https://weidentity.readthedocs.io/zh_CN/latest/docs/use-cases.html
3.1. 数据共享 背景
当前,不同机构间存在着大量用户数据流通的需求。然而,由于各个机构之间通常难以组建有效的信任合作机制,因此,各机构间难以将各自保管的用户数据安全可信地授权共享给其他机构。通过分布式数字身份DID解决方案,可帮助机构间进行可信数据授权及共享,使得各机构可基于全面的数据为用户提供更高质量的服务。 参与方
用户、数据持有机构、数据使用机构、身份证明机构 解决方案及流程
1、在身份证明机构、数据持有机构、数据使用机构间搭建区块链网络,机构作为节点接入并注册DID
2、由身份证明机构为用户生成DID
3、用户授权数据使用机构使用自己的数据
4、数据使用机构生成授权凭证(Credential),标明授权对象、数据属主、有效期、授权内容等属性,并使用机构私钥进行签名;数据使用机构可选择将授权凭证生成摘要并写入区块链,达到增信目的
5、数据使用机构出示授权凭证给数据持有机构
6、数据持有机构通过凭证验证(Verify)接口,验证授权凭证
7、验证通过,数据持有机构将数据发送给数据使用机构
4. 如何实现与使用
4.1. W3C与DID标准
分散标识符(DID)是一种新型的标识符,它是全局惟一的、可解析的、高可用性的,并且可以通过密码验证。DID通常与加密材料(如公钥和服务端点)相关联,用于建立安全的通信通道。DID对于任何有利于自我管理、加密可验证标识符(如个人标识符、组织标识符和物联网场景中的标识符)的应用程序都非常有用。例如,目前W3C可验证凭据的商业部署大量使用分散的标识符来标识人员、组织和事物,并实现许多安全和隐私保护保证。
W3C的DID标准下的DID系统主要包括以下层次要素:

l基础层:DID规范,包括DID标识符(Identifier)和DID文档(Document)
l应用层:可验证声明或凭证(Verifiable Claims 或 Verifiable Credentials, VC)
有关w3c的DID标准官方地址:
A Primer for Decentralized Identifiers: https://w3c-ccg.github.io/did-primer/
Decentralized Identifiers (DIDs) 2019 v1.0: https://www.w3.org/TR/did-core
Decentralized Identifiers (DIDs) 2020 v1.0: https://w3c.github.io/did-core/
Verifiable Credentials Data Model 1.0: https://www.w3.org/TR/vc-data-model
4.2. DID与传统标识体系的区别

常见的有两种:UUID(全局唯一标识符)和URN(统一资源名称)。对于UUID,不用集中式注册机构即可提供全局唯一性,但不能全局解析。而URN,一次分配给实体并且永远不需要更改,需要集中的注册机构。此外,二者都没有加密验证标识符所有权的能力。
对于全新的DID,可提供不依赖任何集中授权的终生便携式数字身份,且满足:持久性,全局可解析性,密码可验证性和分散性。
4.3. DID格式
lDID示例一(W3C Credentials Community Group):did:example:123456789abcdefg

DID标识符不容易记忆。根据Zooko三角形理论,没有任何标识符能够同时实现易记忆、安全、去中心化。在这里,W3C的DID取了后两者。
lDID示例二(微众银行DID):did:weid:1:0x0086eb1f712ebc6f1c276e12ec21
Did **:** weid : chain-id : bs-specific-string
Did:遵循DID规范,固定前缀did
Weid:WeIdentity DID规范的method name字段,固定为weid
Chain-id:网络id,用于路由到不同的网络
bs-specific-string:基于底层区块链平台生成,代表Entity在链上的地址,保证全网唯一
关于更多合法地址: https://w3c-ccg.github.io/did-method-registry/
4.4.DID文档(DID Document)
DID基础设施可以被认为是全局键值数据库,其中该数据库是所有DID兼容的区块链,分布式分类帐或分散式网络。在此虚拟数据库中,键是DID,值是DID document。DID文档的目的是描述公钥、身份验证协议和服务端点,它们是引导与标识实体的密码可验证交互所必需的。
一个DID对应一个Document。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。
有关JSON-LD详解,可参见: https://json-ld.org/spec/latest/json-ld/
有关DID文档详细规范,可参见“6. DID Documents”: https://w3c.github.io/did-core/#did-documents
4.5. DID相关操作 Create:创建一个新的DID
DID方法规范必须指定客户端如何在DID注册表上创建DID及其相关的DID文档,包括建立控制证明所需的所有加密操作。 Read/Verify:解析验证DID文档
DID方法规范必须指定客户端如何使用DID从DID注册中心请求DID文档,包括客户端如何验证响应的真实性。 Update:DID文档升级
DID方法规范必须指定客户端如何更新DID注册表上的DID文档,包括建立控制证明所需的所有加密操作,或者声明不可能进行更新。 Deactive:停用DID
DID方法规范必须指定客户端如何在DID注册表上停用DID,包括建立停用证明所需的所有密码操作,或者声明不可能停用。
有关DID方法和操作规范,可参见“8. DID Methodds”: https://w3c.github.io/did-core/#did-method-schemes
4.6. DIDs与隐私设计
隐私是任何身份管理解决方案的重要组成部分,对于使用不可变的全球身份系统来说,这一点尤为重要。 成对匿名的DID
尽管DID可以用作众所周知的公共标识符,但它们也可以用作基于每个关系发布的私有标识符。因此,一个自然人A可以拥有成千上万的成对唯一的DID,而不是一个单独的DID(例如手机号码或国家ID号码),而无需A的同意就可以将其关联起来,可以像通讯录一样轻松地进行管理。 链下私有数据
链下存储所有的私有数据,仅通过对等连接进行加密交换。 选择性披露
DID使得分散式PKI(DPKI)成为可能,这使个人可以通过两种方式更好地控制其个人数据。首先,它可以使用加密的数字凭据进行共享。其次,这些凭证可以使用 零知识证明密码术 来 最小化数据 透露,例如,可以透露自己已经超过一定年龄,而无需透露确切的生日。
有关DPKI解释: http://www.elecfans.com/blockchain/996128.html
4.7.DIDs与可验证凭证(Verifiable Credentials, VC)
至此,以上都是DID规范基础,可验证声明才是建立DID整个体系的价值所在。因为在这一层中,DID既可以用来标识个体的身份,也可以用来标识组织的身份,甚至是物品。
4.7.1. 可验证凭证系统架构

在VC系统中,有一下几种参与者: 发行者Issuer
拥有用户数据并能开具VC的实体,如政府、银行、大学等机构和组织。 持有者Holder
持有者即用户。用户向Issuer请求、收到、持有VC的实体,向验证者出示VC。开具的VC可以自我保存,方便以后再次使用,例如保存在钱包里。 验证者Verifier
接受VC并进行验证,由此可以提供给出示VC者某种类型的服务。 标识符注册机构Verifiable Data Registry
维护DIDs的数据库,如某条区块链、分布式账本(可理解为前面提到的DID里的example字段)。
之所以需有Verifiable Data Registry,是因为验证者要验证VC,也要验证用户。验证VC用VC和发VC的Issuer,验证用户用DID和存DID的数据库。
关于“可验证凭证系统”解释,可参考: https://www.w3.org/TR/vc-data-model
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. 可验证凭证保护策略
5.1. 使用JSON网络签名确保 JSON  Web Token(JSON 网络令牌 )的安全
https://tools.ietf.org/html/rfc7519
https://tools.ietf.org/html/rfc7515
5.2. 链接数据签名
https://w3c-dvcg.github.io/ld-signatures/
5.3. Camenisch-Lysyanskaya 零知识证明
http://groups.csail.mit.edu/cis/pubs/lysyanskaya/cl02b.pdf
6. 微众银行的WeIdentity规范
https://weidentity.readthedocs.io/zh_CN/latest/docs/weidentity-spec.html
7. 微软的DID
https://www.microsoft.com/zh-cn/security/technology/own-your-identity
热门排行