核心概念:
DID: 由3个部分(scheme、method、 method-specific identifier)组成

一个示例的DID
{
"@context": [
"https://www.w3.org/ns/did/v1", // w3规范
"https://w3id.org/security/suites/ed25519-2020/v1" // 算法版本
]
"id": "did:example:123456789abcdefghi", // DID标识
"authentication": [{
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}]
}
可验证凭证,VC(Verificable Credential), 是一个 DID 给另一个 DID 的某些属性做背书而发出的描述性声明,并附加自己的数字签名,用以证明这些属性的真实性,可以认为是一种数字证书。
可验证表达,VP(Verifiable presentation),可以选择性的披露部分VC的内容


国内外的DID解决方案:
本体 ONTID: https://docs.ont.io/
sovrin: https://sovrin.org/
brightid:
ArcBlock的DID协议 : https://github.com/ArcBlock/abt-did-spec
以下两个项目,都属于uPort旗下
WeIdentity 的基本流程图:

其中Credential Repository是区块链智能合约。
以下内容摘自WeIdentity官方文档:
WeIdentity DID智能合约的功能:
- 负责链上ID体系建立,具体包括生成DID(Distributed IDentity)、生成DID Document、DID在链上的读取与更新。
- WeIdentity Authority智能合约,负责进行联盟链权限管理,具体包括链上DID角色的定义、操作与权限的定义与控制。
从业务视角来看,DID智能合约只需要做一件事,就是如何定义DID Document的存储结构和读写方式。DID Document的结构并不复杂(见规范文档);但在实际的业务中,存在一些挑战:
伴随着接入用户(人与物)的快速增长,DID的总量将会增长迅速,规模庞大。因此,设计一个大而全的映射表是不现实的,这会带来巨大的寻址开销,即使采用传统分库、分表、跨链的思路也难以应付。
DID存在更新的需求。因此,每次都存储完整的Document域在更新情况下会产生大量的历史数据。
因此,WeIdentity使用Linked Event:基于事件链的存储方法来解决以上问题。
WeIdContract.sol:
https://github.com/WeBankBlockchain/WeIdentity-Contract/blob/master/contracts/WeIdContract.sol
从合约代码可以看到, weidentity通过event机制,进行数据存储:
event WeIdAttributeChanged(
address indexed identity,
bytes32 key,
bytes value,
uint previousBlock,
int updated
);
event WeIdHistoryEvent(
address indexed identity,
uint previousBlock,
int created
);
创建credential操作需要和链进行交互。