W3C的DID

2019年11月7日,W3C 分散式标识符工作组(Decentralized Identifier Working Group)发布分散式标识符:核心数据模型和语法(Decentralized Identifiers (DIDs) v1.0)规范的首个公开工作草案(First Public Working Draft)。分散式标识符(DIDs)是用于可验证的去中心化数字身份的一种新型标识符。 这些新的标识符旨在使 DID 的控制器能够证明对它的控制,并且可以独立于任何集中注册表、身份提供者或证书认证机构而实施。 DIDs 是通过 DID 文档的方式将 DID 主题(DID subject)和与之进行可信交互的方法联系起来的 URLs。DID 文档(DID document)是描述如何使用特定 DID 的简单文档。 每个 DID 文档都可以表示加密材料、验证方法和/或服务端点(service endpoint)。 这些提供了一组使 DID 控制器(DID controller)能够证明对 DID 控制的机制。 服务端点实现了与 DID 主题的可信交互。

这份规范为 DIDs、DID 文档以及 DID 方法指定了一个通用数据模型、一个 URL 格式以及一组操作。

主要有5个技术规范:

  • DID标识符(Decentralized Identifier)
  • DID文档(DID Document)
  • DID解析器(DID resolver)
  • 可验证声明(Verifiable Credential)
  • 身份存储库(Identity Hub)

这些技术规范的主要领导组织是W3C(World Wide Web Consortium)和DIF(Decentralized Identity Foundation)。

之所以有这几个规范,其实也和身份系统本身的需求有关:

  • DID标识符 :身份标识符的格式;
  • DID文档 :身份信息的格式;
  • DID解析器 :身份信息的获取,为身份认证(Authentication)提供了保障;
  • 可验证声明 :隐私数据披露的方式,为数据授权(Authorization)提供了保障;
  • 身份存储库 :隐私数据的管理。

DID标识符

根据Zcash创始人提出的标识符系统“Zooko三角理论”,标识符无法同时实现实现安全、去中心化、对人类有意义(易记忆)三者,W3C DID标识符主要考虑了安全、去中心化两者。
在这里插入图片描述

此处的ALPHA 和DIGIT在ABNF(Augmented Backus Normal Form)中有定义,而未在此ABNF中定义的其他语法在RFC3986中有定义,值得一提的是W3C DID标识符是符合W3C URI的规范的。

举个例子:did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6
即为一个DID标识,其中ethr是method-name,指明了身份所在的域(此处ethr所指的域就是以太坊);0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6是method-specific-id,表明了这个身份在域中的地址。

DID文档

DID标识符只是表示一个身份的标识符,不包含身份的信息。而DID文档就是用于描述身份详细信息的文档,一个DID标识符关联到一个DID文档。

DID文档一般包含以下内容:

  • DID标识符(必需);
  • 一个加密材料的集合,比如公钥;
  • 验证方法集合;
  • 一个服务端点的集合;
  • 时间,包括创建时间和更新时间。

DID文档的示例:

{ 
"@context": "https://w3id.org/did/v1", 
"id": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6",
"publicKey": [ { "id": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6#controller", 
		"type": "Secp256k1VerificationKey2018", 
		"controller": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6", 
		"ethereumAddress": "0xe6fe788d8ca214a080b0f6ac7f48480b2aefa9a6" } ], 
"authentication": [ { "type": "Secp256k1SignatureAuthentication2018", 
					"publicKey":"did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6#controller" } ]
}

其中:
@context字段指明了该文档的版本;
id字段指明了该文档关联到的DID;
publicKey字段指明了相关的公钥;
authentication字段则引用了publicKey字段里存储的公钥,并组成了验证该DID用户身份的方式。

DID文档其实和传统PKI系统里的证书有点类似。

DID文档实际格式可以是JSON,也可以是JSON-LD或者YAML、XML等。其存储需要上链,或者至少哈希上链。

DID解析器

解析器的作用是通过DID标识符来获取DID文档,这样,当DID用户登录某个服务时,该服务提供商调用解析器来获取DID文档,从而知道了如何来验证DID用户。

DID解析器的规范主要是DIF主导的。

DIF Universal Resolver的架构如下图。其先通过DID标识得到该DID标识的method,然后去调用该method对应的Driver来完成最终的解析,这些Driver的具体实现不做限定,但是要遵循接口的规范。

DIF Universal Resolver可以认为是一个Driver聚合器。

之所以这么设计架构,是因为不同DID的存储是位于不同区块链上,而且可能也是在不同的智能合约里存储的。用户要使用DID,首先需要完成DID的注册,而DID的注册肯定是和某条区块链(或者其它类型的去中心化系统)关联的,比如以太坊。

而且一般用户也是使用一些DID Registry服务来完成注册,比如以太坊上有uPort,uPort可以帮助以太坊上的用户完成DID的注册,如果是在其他链上可能有其他提供DID Registry的服务。

因此每个提供DID注册的Registry服务可能是不同的。使用这种聚合器架构能最大限度地兼容所有的DID Registry。
在这里插入图片描述

可验证声明

接下来介绍DID的第四个技术规范:可验证声明,其可能是目前DID生态里最重要的规范。可验证声明Verifiable Credential,简称VC。

VC的目的前面说过,就是数据授权,而且是尽可能细粒度的授权,从而尽量降低隐私数据的泄露。

在这里插入图片描述

对某个东西的证明可以通过披露不同程度的隐私来实现,如图3-2从左到右,隐私泄露程度逐渐降低。来看一个例子。

假设你今年24岁,如何证明你大于21岁?如果有三种选择:

  1. 出示身份证
  2. 出示出生年月日
  3. 开一个大于21岁的证明

你会选择哪种?
很明显,这三种方案对你个人隐私的披露程度是不同的。第一种对你隐私信息的泄露最大,而第二种其次,而第三种几乎没有泄露任何多余的信息。

在这里插入图片描述

VC运行需要有一套机制,需要有很多角色。可以看到图3-3里有很多角色,这些角色的功能如下:

  • 发行者(Issuer) :能开具VC(能访问用户数据),如政府、银行、大学等机构和组织。
  • 验证者(Verifier):能验证VC,由此可以提供给出示VC者某种类型的服务,如游戏网站、香烟店。
  • 持有者(Holder) :即用户,能向Issuer请求&接收、持有VC,向Verifier出示VC,开具的VC可以存放在钱包里,方便以后再次证明时使用。
  • 标识符注册机构(Registry) :维护DID标识符及密钥(DID文档)的数据库,如区块链、可信数据库、分布式账本等。

VC的数据格式是什么样的呢?其大致会包含以下字段:

  • VC的ID(必须);
  • VC的发行者;
  • 声明的主体内容;
  • 声明的证明。
  • 时间,如发行时间。

下面看一个实例:
{ “@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”: { “id”: “did:example:76e12ec712ebc6f1c221ebfeb1f”, “name”: “Example University” }, “issuanceDate”: “2020-01-01T19:73:24Z”, “credentialSubject”: { “id”: “did:example:ebfeb1f712ebc6f1c276e12ec21”, “alumniOf”: { “id”: “did:example:c276e12ec21ebfeb1f712ebc6f1”, “name”: [{ “value”: “Example University”, “lang”: “en” }]}}, “proof”: { “type”: “RsaSignature2018”, “created”: “2017-06-18T21:19:10Z”, “proofPurpose”: “assertionMethod”, “verificationMethod”: “https://example.edu/issuers/keys/1”, “jws”: “eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19…TCYt5XsITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk-uQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtjPAYuNzVBAh4vGHSrQyHUdBBPM” } }

在这个VC中:
@context字段指明了这个VC的格式;
id字段指明了VC的id;
type字段指明了VC的类型;
issuer字段指明了VC的发行者;
issuanceDate字段指明了发行日期;
credentialSubject字段指明了VC的主体内容;
proof字段指明了VC的证明部分,可以被Verfier验证。

这里最重要的内容当然是credentialSubject和proof。

身份存储库

接下来介绍DID的第五个技术规范,Identity Hub。

首先我们要明确身份数据和隐私数据是不同的。身份数据是指公钥这种只和这个账户相关的数据,而隐私数据是和用户自己真实信息相关的数据,如性别年龄等。

DID文档里只存储和身份相关的数据;而Identity Hub就是用来存储用户的隐私数据的。Identity Hub,虽然是身份的Hub,但是存储的是数据,可以理解为数据银行。

我们习惯将资产放到银行,为什么?因为安全,银行保证了我们资产的安全。同样地,未来我们将数据存储到数据银行,可以保证数据的安全。

其有如下特点:

  • Identity Hub是去中心化的、链下的个人数据存储,可将对个人数据的控制权交给用户。
    它们允许用户以安全而隐私的方式存储其敏感数据,无用户的显式授权就无法获取用户数据。
  • Identity Hub实际在哪由用户决定,可以是本地(手机、PC),也可以是云端。

在未来,用户将会把隐私数据存储到Identity Hub,然后当应用服务调用用户数据时必须请求用户的同意才能获取这些数据。

一个简例

最后来看一个简例,将上面的内容都串起来。

假设小明有一个以太坊上的账户0x96f…3d4,小明想使用DID来登录支持DID的游戏网站A。

  1. 小明找一个DID Registry服务(如uPort)帮其在以太坊上注册一个DID :did:eth: 0x96f…3d4;

  2. DID Registry服务将与该DID相关的DID 文档(包含了公钥等信息)存储到以太坊链上;

  3. 小明在游戏网站A上使用注册的DID登录(游戏网站A可以通过DID解析器得到DID 文档,从而知道该DID的验证方式);

  4. 小明将其个人隐私数据存储在多个身份存储库(Identity Hub),其中居民身份证上的隐私数据存在政府机构G,政府机构G也需要注册好自己的DID身份的;

  5. 在游戏网站A上,小明想证明自己年龄>16岁,从而获得游戏时间;

  6. 小明向政府机构G(Issuer)请求开具一个自己年龄>16岁的可验证声明(Verifiable Credential,VC);

  7. 政府机构G通过查询小明的居民相关隐私数据发现小明确实>16岁,因此开出了这个VC(带着G的签名)给小明;

  8. 游戏网站A验证这个VC的签名,发现确实是政府机构G开具的,选择信任,从而发放游戏时间;

  9. 假如某一天,游戏网站A倒闭了。此时小明的DID依旧存在,还可以用于其他应用(如游戏网站B)的登录。

总结

最后总结一下DID。

DID的提出是为了达到自主权身份。但是实际上是否能够完成其目的呢?从身份上看确实DID的方案是不错的,将身份存储在 区块链上,用 非对称加密的密钥保证用户对账户的完全控制。这部分确实DID做的不错。

不过我们也很明显能发现一些问题,主要是在数据存储上。在VC系统里发放VC的Issuer其实还是掌握用户数据的,因此VC的这个运转架构本质上还是中心化和可控的,用户必须要相信某些机构来托管隐私数据。但这已经比把这些隐私数据放在服务提供商的服务器上要好太多。而服务提供商(如4中的游戏网站A)虽然没办法拿到用户的隐私数据,但是用户在服务提供商处产生的数据,比如小明玩游戏产生的装备、皮肤、等级,这些数据的控制权似乎还是在游戏网站A上。

相关内容:
https://www.chinaw3c.org/archives/2409/
https://www.w3.org/blog/news/archives/8032

在数字时代,如何成为一个真正有身份的人?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值