简 介
Ontology Mercury 是基于去中心化标识（Decentralized Identifier, DID）的点对点通信框架，保证点对点通信过程中的消息安全性，增强 DID主体之间交互能力。
Ontology Mercury 支持多种消息类型，包括通用消息、可验证凭证和展示等的相关消息、以及根据业务需要自定义的消息。不仅支持本体的去中心化身份 ONT ID，也支持采用不同去中心化标识符的去中心化身份实体之间相互通信，具有极大的扩展性。
DID 和 ONT ID
去中心化标识符（Decentralized Identifier, DID）是一种新型的身份标识符，可用于可验证的去中心化数字身份。DIDs 完全由其主体控制，不依赖于任何集中式注册机构、身份提供商或证书颁发机构。2019年11月，W3C 去中心化标识符工作组（Decentralized Identifier WorkingGroup）发布了关于去中心化标识符的首个公开工作草案 Decentralized Identifiers (DIDs) v1.0规范。
ONT ID 是本体基于 W3C 去中心化标识符规范，使用区块链和密码学技术打造的去中心化身份框架，能快速标识和连接人、财、物、事，具有去中心化、自主管理、隐私保护、安全易用等特点。ONT ID 帮助用户充分保护其身份与数据的隐私和安全，赋予他们全面掌控自己的身份和数据的权利。
Ontology Mercury
基于 DID，Ontology Mercury 可以在传统互联网之上为去中心化身份主体提供一个可信的、安全的、去中心化的通信层。通过该通信层，DID 主体之间可以传输基本的文本，可验证凭证（Verifiable Credential）以及可验证展示（Verifiable Presentation）等多种类型的信息。
DID 通信框架 Ontology Mercury 可以帮助 DID 主体（普通用户，公司及其他组织等）方便地创建和管理与其他 DID 主体的通信连接。基于此通信连接，DID主体之间可以颁发或者请求可验证凭证或展示，传输加密的文本信息，或者根据业务需要自定义协议。
1 代理
代理掌握 DID 主体的私钥，根据 DID 主体的授权行动，可和其它代理之间进行消息交互。通常情况下，代理是实施在不同平台的软件。Ontology Mercury 为 DID 的所有者创建一个代理（agent），根据实际的业务需要，代理可以有以下几种：
用户代理（User agent）
云代理（Cloud agent）
服务代理（Service agent）
用户代理由普通的用户控制，一般是移动 App 等。用户代理只需要实现 Ontology Mercury 的基本协议，就可以和其他的 DID agent 进行通信。用户代理一般会将数据，比如可验证凭证等保存在本地手机存储里。
用户代理也有一些缺点。由于一些业务的处理流程可能不是同步的，比如颁发可验证凭证的机构需要几个工作日来进行处理请求，在此期间用户代理 App 可能无法一直在线，而基于成本原因，颁发机构也不会将可验证凭证存储到自己的服务器上。在这种场景下，用户可以通过云代理来解决。
云代理（Cloud Agent）部署在云端，可以提供24/7服务。云代理可以为多用户（即多个DID主体）提供代理以及存储等服务，云代理可以通过Restful等API为瘦客户端（如浏览器）提供加密文本信息或可验证凭证的传输服务。
服务代理（Service agent）本身也是一种云代理，一般是机构对外提供如颁发可验证凭证的服务，机构服务商可以根据自身的需要，可能有下面几种服务模式。
服务模式 1
服务模式 2
Service agent 将自己的 DID 和服务发布到智能合约中；
用户通过智能合约查询到需要的服务商的DID和使用要求（包括收费等）；
用户向智能合约支付通证，并向服务商 DID 发送服务请求；
Service agent 根据用户的请求提供用户所需的信息（可验证凭证等）；
服务商可以从智能合约中定期提取收到的通证。
服务提供商部署在私有的网络中，或者无法支撑互联网的大规模请求；
服务提供商授权少数外部的代理可以访问自己的服务；
外部代理负责接收公网用户的请求，并负责用户管理，存储和收费等操作，然后将用户的请求转发给服务提供商；
服务提供商将用户请求的响应信息（可验证凭证等）发送给外部服务代理，由外部代理根据业务需要直接转发给用户或者为用户提供存储等服务；
服务提供商和外部代理可以定期或按次数进行收费结算。
2 消息安全保证
为了保证通信过程中的消息内容的安全性和收发双方的可信性，通常 DID 通信的消息需要采用密码技术处理。在不保持长连接的情况下，Alice 和 Bob 不需要进行密钥协商，采用公钥加密和签名的方式来保证消息的安全性。以 Alice 和 Bob 之间通信为例，我们来简单说明这个流程：
Alice 使用自己的 DID 绑定的某个公钥对应的私钥对消息原文进行签名；
Alice 使用 Bob DID 绑定的某个公钥对消息原文和签名进行加密；
Alice 将加密后的数据发送给 Bob；
Bob 接收到数据后首先用自己的 DID 对应的私钥对消息密文进行解密；
Bob 对解密后的消息使用 Alice 的 DID 绑定公钥对签名进行验证。
3. 简要通信流程
我们以 Alice 向她的大学 O University 申请学历的可验证凭证为例，简单概括下 DID 实体之间通信的一般流程。我们分为两种情形，来看一下Alice如何在手机端和浏览器上完成和 O University 之间的通信，取得学历的可验证凭证。
Alice 在手机端向 O University 申请学历的可验证凭证：
a) O University 生成邀请信息（invitationmessage）；
b) Alice 通过自己的手机 App Agent 直接向 O University 的 Service agent 发送连接请求；
c) 连接成功后，Alice 可以通过 App 管理所有的连接；
d)Alice 通过与 O University 的连接向 Service agent 发送生成学历可验证凭证的请求；
e) O University 在验证过 Alice 的身份后，生成学历的可验证凭证并发送给 Alice 的 Agent；
f) Alice 将凭证保存在手机中以便使用。
2. Alice 通过浏览器向O University申请学历的可验证凭证：
a) O University 生成邀请信息（invitation message）；
b) Alice 通过 Cloud Agent 的 portal（可能需要注册）向 O University 的 Service agent 发送连接请求；
c）连接成功后，Alice 可以通过 cloud agent portal 管理链接；
d) Alice 通过与 O University 的连接向 Service agent 发送生成学历可验证凭证的请求；
e) O University 在验证过 Alice 的身份后，生成学历的可验证凭证并发送给Alice 的 Cloud agent；
f) Cloud agent 为 Alice 保存凭证，Alice 可以随时下载保存或分享学历凭证。
Alice 通过浏览器访问 cloud agent portal 需要进行 DID 认证，可以使用 Cyano 等浏览器插件钱包完成该操作，也可以通过 ONTO 进行扫描认证。
4 消息路由和转发
在某些场景下，由于网络等原因，agent 直接无法进行直接通信，这样就需要其他的 agent 对消息进行转发。
下面是一个 Alice 通过 Carol 向 Bob 转发消息的流程，其中信封的含义是信封外面有接收人信息，只有信封接收人 Bob 才能查看和验证发信人 Alice 的消息。整个流程概述如下：
Alice 将消息装入写有 Bob 地址的信封内、；
Alice 将1的信封装入写有 Carol 地址的信封内；
Alice 将2的信封发送给 Carol；
Carol 拆开信封后发现是需要转给 Bob 的消息，Carol 将消息装入写有 Bob 地址的信封内；
Carol 将4的信封发送给 Bob；
Bob 拆开信封得到 Alice 的信封；
Bob 拆开 Alice 的信封得到 Alice 的消息。
上述过程中每一步的信封即为对消息的加密，只有接收者可以通过自己的 DID 对应的私钥进行解密，转发者只能够看到消息的路由信息，比如[Alice -> Carol ->Bob]，这样就可以在传输的过程中保证信息的安全。
结 语
通过基于 DID 的安全通信框架 Ontology Mercury, 您可以方便地创建一个云代理（cloud agent）或者通过连接其他的服务代理来创建自己的去中心化身份服务。用户也可以方便连接到其它 DID 实体，并保证通信过程中的消息安全性，享受可信的、安全的、去中心化的点对点通信。