微软 DID是⼀套基于 Azure云服务的分布式数字⾝份技术架构和基础功能，让解决⽅案实施商可⽅便的在不同区块链上实现分布式数字⾝份整体解决⽅案。微软是 DIF联盟的重要成员，以标准的开源技术、协议和参考实现为主要⽬标。 微软 DID的技术架构包括区块链 BAAS服务、注册 DID的 Layer2⽅法 ION、隐私数据管理模块 Identity Hub，均以 API的形式为开发者提供服务，ION和Identity Hub还提供了开源软件。在未实现的计划中，还包括⼿机端的⾝份管理模块。 通过区块链 BAAS服务向不同区块链注册分布式数字⾝份标识，可以成为⼴泛使⽤的中间层，实现 DIF的互联互通⽬标。
ION⽅法是 SideTree协议基于⽐特币⽹络的实现，⽤于解决向公有链注册 DID存在的效率低下问题。
Identity Hub为开发者提供了管理⽤户隐私数据的基础模块。
1.分布式账本
微软 DID的基础设施不依赖于特定的分布式账本。与 Azure区块链服务的设计思想⼀脉相承，微软 DID
依托于 Azure云服务⽀持多种分布式账本协议，并且注册了基于该分布式账本的 DID操作⽅法，对开发者隐藏分布式账本的接⼊细节，提供 Restful API接⼝。
⽬前微软 DID⽀持以下两个 DID操作⽅法：
Ion-test：注册到⽐特币测试⽹络
test：注册到微软数据库同时正在开发对以下三个分布式账本的⽀持：
⽐特币正式⽹络
通过 uport的 DID⽅法，注册到以太坊
通过 Sovrin的 DID⽅法，注册到 Sovrin⽹络
在 DID注册和查询过程中，为解决公链效率低下的问题，微软和 DIF联盟的⼏个成员发起了 SideTree协议，构建了 L1层公链和 L2层 DID 操作的分层架构：
L2层保存了 DID操作的源数据并推送到 IPFS⽹络，汇聚尽可能多的 DID操作后锚定到 L1层；
L2层的每个“节点”各⾃与 L1层同步，获取 Sidetree锚定交易后，拉取DID操作源数据。
2.基于 DID的交互 &可验证凭证应⽤
微软 DID中未提供完整的 DID交互和可验证凭证应⽤软件，由开发者根据⾃⼰需求进⾏设计。微软 DID主要为开发者提供了 Identity Hub 模块，它的⽬标是为⽤户存储和管理隐私数据，以增强数据表达能⼒的“语义数据模型”实现。在DIF的认可下，已发布了第⼀版开源代码。
与传统的数据存储解决⽅案相⽐，Identity Hub具有去中⼼化的特性：
标准化接⼝：Hub的实现⼚商需要满⾜标准化的数据存取接⼝，包括为每个⽤户的 Hub注册 DID，不同⽤户的 Hub通过 DID标识符进⾏互操作。
开源：通过开源代码，⿎励开发者运营⾃⼰的 Hub。
Identity Hub⽀持与⽤户通过 DID进⾏点对点的安全通信，遵循 DIDAuth的相互认证和加密传输。
3.微软的DID⽅案
微软的DID⽅案可以拆解为三个部分：Sidetree、ION、以及DID，它们分别对应协议层、⽹络层和应⽤层，三者属于逐级向上建构的关系。其中ION既是⽹络层的名称，也是微软这⼀DID⽅案的项⽬名称。我们来进⼀步解析⼀下三个部件的特性：
Sidetree
作为协议层，它可以被部署在⽐特币以及以太坊⽹络上，据其官⽅Medium介绍，之后该协议或可被部署于更多种类的区块链⽹络上。
需要注意的是，⽬前的微软DID⽅案中，Sidetree作为协议层，仅被部署在⽐特币的测试⽹上，预计接下来的⼏个⽉中可能会部署在⽐特币主⽹上。
Sidetree的核⼼功能有如下三项：
Sidetree 核⼼（Sidetree Core）
观测来⾃⽬标区块链（就当前的状况⽽⾔，这是代指⽐特币区块链）的传⼊事务（incoming trasactions), 抓取其观测到的、所有的DID操作（operations)，进⽽验证每⼀个DID的状态。
内容可寻址存储协议( Content Addressable Storage Protocol）
这⼀功能类似于IPFS，它将数据在链下存储以减少链上的负担，并允许跨节点的事务传播（transaction propagation across nodes)。
区块链/账本适配器 (Blockchain/Ledger Adapter)
向底层区块链读取和写⼊DID操作的代码。
ION
微软对ION做出了如下的定义：电机风罩
ION是⼀个基于Sidetree协议的开源⽹络，可以通过将操作写⼊安全且不可变的区块链（如⽐特币）来巩固和维护对DID的所有权。
当介绍ION的特性时，其指出ION在具有全球可扩展性的（globally scalable)的同时，还“保有⽐特币区块链去中⼼化的特性“( “while inheriting and preserving the attributes of decentralization present in the Bitcoin blockchain.” )。
需要指出的是，作为Layer 2，ION不受限于⼀层的⽐特币区块链的吞吐量限制。据悉，其上的TPS是”成千上万“的("tens of
thousands of operations" per second)。
此外，ION还涉及⼀些需要付费的事项。当ION的节点想要将事务锚定到⽐特币区块链（anchoring transactions to the Bitcoin blockchain)时，他们需要付费。
⼀般来说，这⼀部分费⽤会被转嫁⾄终端⽤户那⾥。据微软去中⼼化⾝份事务的⾼级副总丹尼尔.布什（Daniel Buchner）测算，⼀项包含3万个操作的事务，每个⽤户需要付出的⼿续费为0.0003美元。
丹尼尔进⼀步补充道，未来微软可能使⽤⾃⼰的节点来运⾏ION，这样就可以给终端⽤户免除这部分费⽤了。⽽包括Casa、Equnix、Learning Machine、Civic、Cloudflare等公司，也都对运营ION节点表⽰了兴趣。
DID
Decentralized IDentity去中⼼化⾝份，简称DID，相对于传统的基于PKI的⾝份体系，基于区块链建⽴的DID数字⾝份系统具有保证数据真实可信、保护⽤户隐私安全、可移植性强等特征，其优势在于：
去中⼼化：基于区块链，避免了⾝份数据被单⼀的中⼼化权威机构所控制。
⾝份⾃主可控：基于DPKI （分布式公钥基础设施），每个⽤户的⾝份不是由可信第三⽅控制，⽽是由其所有者控制，个⼈能⾃主管理⾃⼰的⾝份。
可信的数据交换：⾝份相关数据锚定在区块链上，认证的过程不需要依赖于提供⾝份的应⽤⽅。
要理解DID，不妨将其⼀分为⼆：
1. 唯⼀标识符。( a unique identifier)
2. 相关的DID⽂档。(an associated DID Document)
前者充当着后者的标签，后者则包含诸如DID可以授权什么，以及在哪些服务中，DID可以被使⽤等信息。需要注意的是，DID⽂档中不直接包含任何个⼈信息（姓名、地址、电话等）。 DID标识：
DID标识是⼀个特定格式的字符串，⽤来代表⼀个实体的数字⾝份，这⾥的实体可以是⼈、机、物。DID标识的格式为：
前缀did：是固定的，表⽰这个字符串是⼀个did标识字符串。
中间的example被称为DID⽅法，就是⽤来表⽰这个DID标识是⽤哪⼀套⽅案（⽅法）来进⾏定义和操作的。这个DID⽅法我们可以⾃定义，并且注册到W3C的⽹站（w3c.github.io/did-spec-registries/#did-methods）中。
最后⾯的部分是在该DID⽅法下的唯⼀标识字符串。⽐如我们做了⼀个DID系统，我们把⽅法就起名叫cid吧，想把中国公民的⾝份证信息都DID化，那么我的DID标识就是：
did:cid:5111**************5
这⾥我们就使⽤⾝份证号码作为cid这个DID⽅法下的唯⼀标识。
DID⽂档：
每⼀个DID标识都会对应⼀个DID⽂档（DID Document）。这个⽂档就是⼀个JSON字符串，⾥⾯⼀般会包含如下信息：
DID主题
DID标识符本⾝，也就是DID⽂档所描述的该DID。由于DID的全局唯⼀特性，因此在DID⽂档中只能有⼀个DID。
pg接头
公钥
公钥⽤于数字签名及其他加密操作，这些操作是实现⾝份验证以及与服务端点建⽴安全通信等⽬的的基础。如果 DID ⽂档中不存在公钥，则必须假定密钥已被撤销或⽆效，同时必须包含或引⽤密钥的撤销信息（例如，撤销列表）。
⾝份验证
⾝份验证的过程是 DID 主题通过加密⽅式来证明它们与 DID 相关联的过程。
授权
授权意味着他⼈代表 DID 主题执⾏操作，例如当密钥丢失的时候，可以授权他⼈更新 DID ⽂档来协助恢复密钥。
服务端点
验货平台除了发布⾝份验证和授权机制之外，DID ⽂档的另⼀个主要⽬的是为主题发现服务端点。服务端点可以表⽰主题希望公告的任何类型的服务，包括⽤于进⼀步发现、⾝份验证、授权或交互的去中⼼化⾝份管理服务。
时间戳
⽂档创建时间和更新时间
以上信息并不是必须有，不过⼀般我们建议包含。我们来看⼀个具体的DID⽂档⽰例：
{
"@context": "/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
// 本DID⽂档对应的DID标识
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:example:123456789abcdefghi",
刻字笔>无卡轴旋切机//本DID对应的公钥信息时钟显示器
"publicKeyPem": "-----BEGIN END PUBLIC KEY-----\r\n"
}],
"service": [{
// 获取本DID对应的VC的服务接⼝
"id":"did:example:123456789abcdefghi#vcs",
"type": "VerifiableCredentialService",
"serviceEndpoint": "example/vc/"
}]
}
个⼈觉得DID⽂档中最重要的就是公钥信息，这是我们接下来要进⾏VC和VP验证的基础。
我们⼀般是把DID标识作为Key，把DID⽂档作为Value存储到区块链中，利⽤区块链不可篡改、共享数据访问的特点，实现接下来在验证⾝份时能快速访问获取可信数据。
Sidetree、ION、DID这三项功能组合后的⽅案⼜如何发挥作⽤呢？不妨以具体的场景来理解：
以为例，⽬前⽤户使⽤各类互联⽹服务，往往都会直接选择的第三⽅登录/注册，以统⼀⾝份，免除逐个平台账号登录/注册的⿇烦。
但这⾥的隐含问题是，可以对你的头像、ID、昵称等信息保有所有权，最近的案例是⽤户使⽤注册&登录“飞聊”后，相关的信息被申明为“所有”，不得在其他平台使⽤。更严重的的情况可能是，或许会关停你的账号，这可能使你所⽤⽤类似⽅法注册的服务都⽆法使⽤。
DID引⼊后，情况可能会转变为，可以关停你的账号，但是你的ID、昵称、头像等信息依然可以使⽤，依靠这些信息的其他平台服务也⼀样可以继续使⽤。换⾔之，⾝份信息的控制权被转交到了⽤户⼿中。
⽬前 , 微软这⼀项⽬已经开源运作，相关代码也已经公开在了Github上。
据Cointelegraph，微软对这⼀DID⽅案颇有野⼼，准备将其推向数⼗亿⼈⼝与设备(Specifically, the company aims to create an ecosystem where “billions of people and countless devices)，但其⾯临着不少现实的阻⼒。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议