上篇我们分享了区块链演变的逻辑与关注点，本篇将对 DID 的设计进行硬核分享。

W3C的努力

1、网络形态

回到 Web 这个概念，Web 这个逻辑本身是描述了不同的网络形态：

• 一种是中心化的网络形态。
• 第二种是多中心的网络形态，从数据库角度看是一个读写分离的逻辑。它可以支持大规模的读操作，但是在写操作的层面会有强一致性的需求，导致性能会有一定的损耗。
• 第三种是分布式的网络形态，即点对点沟通的逻辑。在这个过程中，网络对使用者来说仅是一个基础设施，所有在其上的操作都是透明的。

2、DID 的设计愿景和标识协同DID 常规单元

DID 本身的核心是去中心化标识，由一系列的 JSON-LD 来描述这个标识所对应的实体的相关性文档。任何一个实体都可以有一个标识，且该标识会被存到某一个储存介质或者 resolver 中。通过这个 resolver ，任何人可以查询，第三方也可以使用它。当描述 DID document 这个常规单元时，我们关注的是标识本身，关于标识的鉴权，以及一系列鉴权相关的服务和内容。

DID 标准是从具体慢慢演化成抽象的。在 DID 初始版本里有一些严格的定义，比如说通过公私钥非对称加密的形式来用一组公钥描述标标识者本身，用私钥表示标识本身所指代的个人或实体；除此以外，还有一系列的身份验证协议，以及刚刚上文提到的服务和一些服务终端；对应的还有一些诸如时间戳、签名等，都是基于完整性的校验，用一系列密码学来保证防篡改的。

这里面比较核心的一点是，只有公共的服务才适用于放在 DID doc 里面，如果是私有服务的话，可能会有个人信息泄露，或者说违反个人隐私保护的一系列需求。

可验证凭证 - 去中介而不是去中心

接下来跟 DID 结合起来的是 verifiable credential（VC），也就是可验证凭证。可验证凭证的工作流程大概是这么描述的：首先是由 Issuer 来颁发这个凭证，一个拥有 DID 的实体可以在任何地方获取到；其次在实际使用中，该凭证仅需要通过公允的第三方密码学鉴权，就可以对完整性和一致性进行校验，因此全程无需 Issuer 参与。这其实就是去中介化。某种意义上来说， DID 的 decentralized 更适合翻译为去中介，而不是我们常常理解的去中心。保存可验证凭证并发放对应公钥，这一过程经常会使用去中心化网络，或许一定程度上让大家误以为一定要在区块链上进行。但事实上 DID 并不对区块链有强依赖的需求，它只要有一个信任背书来维持包括 VC、DID 的发放逻辑即可。同时，DID 和 VC 还共同组成了一个去中介的交互逻辑。以上所有一切都是通过密码学来实现的，这就使得验证模型可以被做成可编程的模式。这个可编程的验证模型与 Web3 的愿景，也就是点对点直接进行交互，是不谋而合的。于是出现了把区块链作为基础设施的业务思路，就是用去中介的方式结合可编程的区块链技术来把相关的鉴权过程做编程的原子性实现。

跨系统实体识别

单点登录(SingleSignOn，SSO)，就是通过用户的一次性鉴别登录。当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的。

但实际上，用户使用 A 账户登录 B 应用时，本质上是 B 应用获取了 A 的数据，用户仅仅是参与了部分授权。从互联网的角度来看，SSO 其实更多的是需要支持用户的易用性，即这个 SSO 的服务提供商本身需要一个强的服务维持能力。比如现在 Facebook ID、google ID，或者微信账号，等等都可以做 SSO 提供。

那对应的如果用 DID 这个模式，因为它是一个去中介的逻辑，同时它又是一个可编程的方案，所以通常会考虑到 Self-Sovereign，就是用户自治。即，把标识扩展为身份，变成用户自治的一个身份体系。使用这个身份系统，其实仍然可以做到终端用户无感，但是对于身份管理的手段其实是在用户自己的个人设备上的，可以是手机，也可以是电脑。也就是说，DID 可以帮助终端用户，为他的用户身份做一个圈子隔离。

现在，我们习惯是靠不同的马甲来玩不同的应用，以此做隔离。如果使用 SSO 这个方式，虽然用户易用，但打破了不同账户之间的协同关系。因此，我们考虑如果是在应用层面，或者说是在用户终端层面做一个分割，其实站在服务端角度来看，一个终端用户的圈子隔离就已经完成了。

那么，回到刚刚对 DID 常规单元的描述，它的 verification method 里就有可以对公私钥对里的公钥做查询的模式。而这个公私钥对，我们可以考虑使用 PKI 系统。目前很多 SSL ，包括一些证书发送方都是用这套标准协议来做的。我们可以基于现有的网络体系，做一个外部的封装以实现这个 SSI 。

所以对于 DID 的使用，并不一定是做现有系统的一个完整的升级或者替换，很多情况其实是在现有系统上做一个可能的封装。这个封装是站在用户角度，使用户个人的圈子管理和各方面的身份管理可以更加灵活，同时它也可以进一步加大自己的隐私保护力度，而且还有一个更加潜在的可能性，就是把一些目前很多 To B 的 DNS 的这种方案应用到个人终端。只不过，目前因为操作性过于复杂，导致很多个人用户没有办法用起来。

这个是我在 ITU 那边参与一个标准的时候提到的，可以用一些区块链的方式，把 DNS 这个逻辑做一个分布式账本的改造。主要关注的点是它仍然通过标准的这套逻辑支持到终端的发放，这个终端证书的发放绑定到的这个身份，其实本身也是可以用 DID 这套系统来进行一个完整的维护。

DID的应用模型

在我们描述 DID 的时候，并不是说要打破现有的应用逻辑。我们可以基于当前的逻辑，把数据令牌化，在令牌化的过程中跟业务逻辑进行一个绑定。简单来说就是，我持有这个令牌就是拥有对该数据进行一定业务逻辑操作的权限。

对于业务的信任关系，也就是我们普通系统设计中提到的权限管理（对于业务的信任需求），从某种意义上来说是可以通过一些密码学的方案把可验证凭证的一些数据进行脱敏。脱敏之后，仍然可以验证这个凭证的有效性，但是一些敏感信息会被隐藏。这套方案的核心点就是业务信任需求的满足，只要满足了信任需求，就可以直接进行业务操作。而这整个过程，其实我们可以使用 DID 的方式对现有的应用系统进行一个外部的封装，使得它可以做一些额外的操作，也就是我们经常描述的叫跨系统。

其实对于我们令牌化这个逻辑来说的，这个额外操作就是跨系统的权限管理。什么是跨系统的权限管理？如果用一般的系统来描述，其实就是一个主谓宾结构——就是某些实体拥有某些权限通过某些业务操作了某些数据；如果是一个区块链系统，基于它提供了一个公允的平台来进行去中介化互操作的底层支持，且数据的使用只需要通过令牌鉴权，于是就可以在不打破现有系统业务逻辑的情况下额外提供了一个可能性，即跨系统的互操作。

所以我们描述的这个跨系统互操作，其实就是把数据归到某一个通用的平台之上，并在当前系统的基础上做一个数据拾取。这时候又可以使用前面关于比特币的一些灵感，用一些物本位的逻辑，也就是说这些数据本身也可以认为是实体，那既然是数据实体，就当然可以适用于整个 DID 的逻辑。

所以如果是机器人来驱动这些数据，或者这些数据本身作为实体，实际上它也是可以成为上述流程（主谓宾结构）的主语。而当我们描述这个业务操作的时候，我们主语和宾语之间，其实是可以互换的。在这个基础上就会有很多好玩的玩法。

互联网到语义网

在跨系统互操作的情况中，我们可以引入不同的实体，这个实体可以是用户，也可以有很多传感器，或者数据本身；在不同系统之间进行协同，我们需要做数据对齐、句法对齐、语义对齐。

在 W3C 的标准体系里面有一套 semantic web（语义网），通过工程妥协之后它有一个比较完整的实现——名为 JSON-LD 的一套标准体系。所以在这个基础之上是可以通过机器来自动实现数据的结构、数据结构的抽象，及句法和语法的对齐。因此哪怕没有区块链，在普通情况下，其实我们仍然可以实现跨系统的互操作。

*本次分享内容将分上中下三篇，下期我们来谈谈 Web3的发展，以及应用案例。了解最新资讯，参与精彩活动，欢迎加入本体中文电报群！扫描下方二维码或复制链接即可加入：

https://t.me/OntologyNetworkCN