DID去中心化身份协议的简单原理及在WEB3中的应用（针对W3C的DID标准优化版）

概述

​ DID是Web3.0.0的核心技术,DID是英文“Decentralized Identifiers”的缩写，即去中心化身份。WEB3可以实现一个身份登录多个终端服务，而这个身份是以用户为中心去中心化的。因此基于去中心身份能力可在用户隐私保护、信息安全、数据审计等方面赋能。WEB3可以实现对等网络，让服务商的能力变为单纯的服务，避免服务商当方面的信息垄断。

基本概念

DID身份

​ 任何端点（endpoint），包括PC、手机、物联网设备等，都可以有一个去中心化的身份。依此去中心的身份可以实现端点间的数据交互，该身份是以用户为中心并且是具有自主权的。

构成：did+连接符+加密算法+连接符+publicKey
示例： did:Secp256k1:1FsbKR6UpV6GW8o8szccdxXkquzTg2VZLL

应用方

​ 应用方是提供服务的一方。

客户方

​ 使用应用方服务的用户，用户的授权签名操作基于DID APP。

签名

客户方或应用方使用去中心化身份【DID】进行身份认证的方式，此处的身份认证区别于可验证声明【VC】（对现实事物绑定DID身份的过程，此能力目前依赖于可信的中心化机构实现认证能力）。

交互方式

​ 所有的交互数据都可通过双方互相签名来确认身份,这是一种强数据审计的模式,通常只有银行需要这样做,这种方式类似于银行公户Ukey的工作原理,银行将企业身份和Ukey绑定,你的每一笔交易需要财务使用Ukey进行签名发送,当Ukey密码丢失时只能更换新的Ukey（现在的Ukey是和硬件绑定了）.但是日常我们用到的大多数应用不需要这么高的数据审计强度,用户在第一次授权后,后续的交互可使用授权证书携带的信息加密交互即可(传统的token或cookie验证方式).这样做有个显而易见的好处是用户不必在非可信设备上留下私钥信息,只需要通过自己的手机扫码即可登录。

高安全级别的数据审计实时互签过程:

一般安全级别的数据审计TOKEN验证过程:

实现

以下是基于以上基本概念以GRPC为通信协议实现的DID交互协议。其中的信息字段都是为必要的，不存在任何冗余的、增加复杂度的字段。

DID数据

​ DID数据是包含DID身份、交互内容、签名的数据，此数据可以被区块链数据库接纳，实现公开的永久存储。

//非技术人员可不必关注下面proto3代码示例：
syntax = "proto3";
package pub.module;

message DidMessage{
 string endpoint="xxx.xxx.xxx.xxx";//可以是IP|域名|接口
 string did="did:Secp256k1:1Fs···";
 string sign = "···";//使用私钥签名data的hash值
 bool level = 0;//当level=0时 【DID APP】无感知自动签,1时需要点击确认,2时需要输入私钥密码,3时需要生物验证
 string hash = "摘要算法:值"//签名grpc协议的data使用某算法得出值
 Data data;//数据体
}
//数据体：下面是一种支持RDFX语义网技术的交互格式
message Data{
  string hash;// 资源处在的位置，可用于ID
  string ontology;// 资源的本体描述
  string data;// 资源的实际数据
  repeated message Data<> relation: [] //该资源与其他资源的关系
}

签名服务

​ 无论是客户方还是应用方都遵循标准中的API实现对某一数据进行签名。但是签名过程是自动的还是需要人工确认遵循统一的标准，比如首次登录（退出后也作为首次登录）、付款、授权这些重要的场景需要人工确认，此标准至少在官方开源的项目中执行，以此避免签名被滥用，造成在实际社会活动中出现司法失利的情况。

//非技术人员可不必关注下面proto3代码示例：
syntax = "proto3";
package pub.module;
 
service DidService{
 rpc sign (Data,privateKey) returns (DidMessage didMessage);
 }

验签服务

​ 无论是DID APP还是应用方都有统一的API实现对某一DID数据验证对方的身份，数据完整性。

//示例：
syntax = "proto3";
package pub.module;
 
service DidService{
 rpc verify (DidMessage message) returns(bool);
}

消息及广播服务

​ 虽然现在非对称式加密算法是非常安全的，但不排除在将来会被量子计算机破解，所以不仅需要提供最安全的加密算法还要兼容未来可能出现的加密算法来提供支持WEB3.0体系的可持续发展。

​ 非对称式加密算法提供了去中心的思路，甚至当下所有的区块链系统都依赖了这种非对称式加密算法，但系统的本质是业务的去中心化，因此我们可以剖离加密这块业务，使一些机构可以黑盒的方式提供非对称式加密方式的业务能力，用户能够自由的在加密算法列表中选择这些机构提供的一种类似于非对称式加密算法，只不过这些加密业务是由中心化的服务机构提供的，因此我们可以称这类算法为伪非对称式加密算法协议（PAE），至于PAE机构与用户之间的数据审计由他们自行约定，比如重要操作需要通过人脸认证等。实际上这种把用户身份校验交给第三方执行的业务形式已经非常普及了，比如很多应用都支持微信登录、谷歌登录、github登录等。

​ 虽然以上提供了可持续发展的思路，但是我们面对灾难不应该是被动的，所以下面为所有用户提供了一种应对灾难的广播消息代码，DID APP应当支持接收、发布、导入广播消息的能力。消息类型以下划线作为分类的分隔符，未识别的前缀将作为自定义消息。

销户广播

​ 考虑到用户私钥有泄露的风险，为了第一时间终止损失，所有的应用方应该响应用户的销户广播，冻结用户资产，并提供一套资产处置方案。

//示例：
syntax = "proto3";
package pub.module;
//为了描述概念减少篇幅,此处未使用RDFX描述
message Data{
    string messageType = "BROADCAST_TERMINATE_ACCOUNT";
}

服务广播

​ 服务方将endpoint公布，并描述提供什么样的服务，方便用户使用【DID APP】的浏览器可以搜索到服务。

//示例：
syntax = "proto3";
package pub.module;
//为了描述概念减少篇幅,此处未使用RDFX描述
message Data{
    string messageType = "BROADCAST_SERVICE";
    string endpoint = "https://www.xxx.com"
    string serviceType = "pae"//目前DID特定几种服务类型以为用户提供丰富的服务支持:pae加密服务，应用服务
    string name = "xxxPAE加密服务";
    string description = "可以是富文本"
}

灾难广播

​ 应用方应该对用户声明自己响应哪个组织发出的广播，以防止灾难广播乱用。以下定义了几种灾难及处置办法。

非对称式加密算法破解灾难(rsa-crack,ecc-crack)

​ 当接收到此消息，应用方需要针对此算法启动传统的登录校验方式，即登陆时多层校验（手机号或人脸认证等）,登陆后使用access-token等。由于DID协议不限制底层通信协议，所以执行DID协议不与传统的软件架构冲突，比如使用HTTP协议，可以请求中使用cookie或在请求头中使用token。并且在后续登录注册过程中提醒用户摒弃此算法的DID。

//示例：
syntax = "proto3";
package pub.module;
//为了描述概念减少篇幅,此处未使用RDFX描述
message Data{
    string messageType = "BROADCAST_DISASTER_RSA_CRACK";
    string name = "Secp256k1加密算法被量子计算机破解";
    string description = "于国家安全局2025年4月1日量子计算中心公布··"
}

PAE伪非对称式加密算法协议

​ 伪非对称式加密算法协议，(Pseudorandom Asymmetric encryption algorithm) 简称PAE。是一种以中心化服务提供签名、验签服务的协议，他与传统的非对称式加密算法区别是，传统的加密函数，验签算法、在本机执行，而PAE是在服务端执行，底层可以基于对称式加密，而非对称式的特性可以以“黑盒”的方式提供给用户，所以对于用户来说使用伪非对称式加密算法还是对称式加密算法业务是一样的，无感知的。

syntax = "proto3";
package msg;

message Result {
  string publicKey;//公钥
  string privateKey;//私钥
}

service Pae {
  //获取公钥私钥方法
  rpc getPae() returns (Result);
  //验证签名方法
  rpc verify(string publicKey,string signature){returns{bool}}
	//签名
  rpc sign(string privateKey,string hash,string calculationMethod){returns{string}}

}

W3C 的DID标准的缺陷

​ W3C DID文档描述了太多架构的内容放到协议里面，如此导致W3C DID协议非常臃肿。协议和架构的本质的区别是协议更容易达成共识，这也是W3C DID最瑕疵的地方，此外W3C迎合ETH区块链的做法是本末倒置的，未来Web3.0互联网不可能基于ETH，区块链仅仅是数据库的概念而已。以下是几个缺陷的点。
对比本协议，W3C繁复的内容太多，描述了各类API的内容，已经脱离了"标准"的主题，更像是一个实现小程序的架构。DID应该是一个协议，可以有众多个性化DID协议功能的小程序实现，而不是包含太多个性化的内容成为“二不像”，不像协议、不像架构。
DID是使用public-key构成的身份，所以did definition中不需要复杂的构成方式，只需要一个public-key+签名算法名称作为前缀即可简单明了的表达出DID的身份构成。
区块链需要兼容DID协议,如此才能消除各种区块链系统的个性化差异，实现DID的广泛推广。W3C在DID在设计上迎合区块链增加了很多边缘的内容，甚至迎合了特定的区块链ETH。比如Germ方面的内容，而实际区块链仅仅是数据库的概念而已，需要区块链兼容DID协议将交易数据或是Dapp数据写入到链上。

关于架构

​ DID是一个交互协议，不限于端点架构，也不关心底层传输是http 1 2 3、websocket等，也不关心交互格式是gRPC还是json-RPC，只是说明了通信数据中要有这些约定的内容，然而既然是协议一定是要实现了才有意义，基于民用常见的互联网架构以下推出几种办法。

使用gRPC

​ gRPC是性能优异、开发友好、且在各类终端,BS/CS架构支持良好的框架。

应用方APP和【DID APP】如何通信

以下APP技术均可以实现无跳转,无感知的交互服务,而不必在系统层面进行开发,当然随着Web3.0的发展, 【DID APP】必然会集成进系统.

安卓：Activity bindService 技术
IOS：App Extension 技术
浏览器：插件