【译】A Brief Overview of SSI Core Concepts - Sovrin/自主身份治理的一些核心概念解释及个人想法

原文链接：https://docs.google.com/document/d/1rZXE-0Ce9qYKTiY_Czg2MP0Qy3rtFAR45BNK7IbxKBg/edit#heading=h.tw5lk59wzexv

不喜欢通篇翻译，有些专业名词也不想翻译，希望是原来的名词，记录一些重点内容，如果有写的不好或不对的也欢迎指正，后续要是有时间也会更新其他的翻译。

这篇文章定义了一些比较基本的术语，可以在一些介绍性文章中使用，也有一些其他的参考文章很有用，比如 Sovrin Glossary, SSI Notation Conventionshttps://docs.google.com/document/d/14Qy9FaHbq8zti4lprOcgmi_ArRgnWtlADVT8tipSTxk/edit](https://docs.google.com/document/d/14Qy9FaHbq8zti4lprOcgmi_ArRgnWtlADVT8tipSTxk/edit), Sovrin Trust Framework, and Self-Sovereign Privacy By Design.

核心概念

identity owner（或者owner）: 是Sovrin 系统中的重要市民，可以是个人也可以是机构

agent：是代表一个owner来工作的软件，仅仅代表一个owner. 分为edge agent 还有cloud agent.
edge agent是运行在直接由owner控制的设备上。cloud agent运行在由其他人控制的设备上。edge agent的可信度比cloud agent更高.cloud agent 被设计的稳定且公开，所以他的终端地址很有可能被外部组织用来联系owner

wallets: Owners and agents 将私密信息存在wallets 钱包中

没有agent的关系是数字上无法实现的（即只有owner，没有agents）,因为人和机构不能直接加密，签名或者传输bytes, 这种关系无法实现数字上的交互。 最简单的数字上可实现的关系因为包含两个identity owners, 并且他们每一个都包含他们的agent - 总共四个实体。 在Sovrin系统中最普遍的关系就是每一个owner有一个agent（比如运行在他们的手机上）和一个cloud agent(比如，运行在一个agency,这个agency提供Saas类的cloud agent的服务)（注 SaaS :Software as a Service）

这一系列的东西 – agents, devices, storage, services, software 在一个owner 控制之下的我们称为这个owner的 sovereign domain(or domain, for short)

就像女王可以按照自己的喜好来安排他的部队和命令他的王国，大多数情况下不需要和其他的君主协调，domain（领域）在很大程度上对外是不透明的，并且可以有owner自行决定是否改变。

在Sovrin系统中，在描述行为的时候我们习惯将人和他们的agents合并起来说。

比如我们说：“Alice 把一个message加密了发送给Bob", 要是我们用一种更精确的方式来说，其实是：”Alice 的 edge agent(有Alice直接控制，可能是在他的手机上)在她的命令下加密了一个message，然后将他传输给Bob的domain（可能通过一个很复杂的路径），然后我们希望Bob的domain包含一个邮件传输服务，然后能够让这个message最终展示在Bob面前。

我们不确定实际上就是这样实现的。Bob 控制了他自己的domain, 但是也许有一个代理AI或者一个恶意的间谍在没有和他协商的情况下读并且回复了这个message。这样的中间者可能运行在云上，甚至在Bob的手机上。然而密码学让我们能够区分在Bob控制下的不同的agents, 假设Bob公开了一些他domain的一些细节（他的cloud 和 edge agent 的公钥），我们可以加密message, 这样这个message就只能在他的edge device上才可以被读取了。当Bob答复的时候，我们可以区分这个回复来自哪个agent。

这可以防止Bob在他不直接控制的情况下，被无辜或恶意的中间者冒充，不管在不在他的domain – 这是一个非常重要的安全需求

一个DID (Decentralized Identifier) 是一个owner 在一个关系中的 identifier（标识符），通常是成对的关系。当人们第一次接触DIDs的概念的时候，经常想象DIDs也可能被用来定义其他实体–owners自己或者他们的agents. 这不是他们的功能。

Alice一般不会被一个DID识别，她只能通过一个关系内的DID来识别。她可能和一个远程的组织建立第二个，第三个关系，每次都用不同的DID，Alice使用的agents他们不需要DIDs, 他们通过主要受到关系从属或派生出来的密钥保护和赋能。因此，一个典型的关系如下：

1. party A 关于 party B 的DID
2. party B 关于 party A 的DID
3. A的任意agent x，x有一对用来促进A~B关系的密钥对
4. A 其他授权密钥对对用来满足她的目的
5. B的任意agent y，y有一对用来促进A~B关系的密钥对
6. B 其他授权密钥对用来满足她的目的

注意所有的密钥对在概念上都是等效的，没有特殊的主密钥，没有密钥对是属于DID本身的，有些密钥对可能有特权，但是他们也仅仅是密钥对而已。

我的理解

在我看来，这里我们要注意几点：
1. agent 和 agency是不一样的
agent是必须存在的，用来代表owner实际执行操作的软件，比如加密，签名，传输数据等等，agent是owner必须要有的存在，根据agency存储在本地还是云上，是否由owner直接控制，又可以分为edge agency和 cloud agency。

agency 是一个提供类似SaaS服务的平台，owner的cloud agency可以运行在一个agency提供的服务上，但是显然，一个agency肯定不仅仅为一个owner提供cloud agent服务。agency提供存储等功能能，但是对于整个系统来讲，不是非有不可的。

2. DID是成对出现的，没有关系的DID没有任何意义
DID是用来标记一对关系的，比如在A视野下的AB关系的DID就是did@A:B, 在B视野下的AB关系的DID就是did@B:A。did@A:B 和 did@B:A建立起了A和B之前的联系，但是他们并不是一个DID。

3. 不同的关系之前用不同的DID
如果A要与B和C建立联系，那么他需要产生did@A:B ,did@A:C 这是不同的DID.

4. DID 没有自己的密钥对，但是他对应了一个密钥对
DID虽然没有自己的密钥对，但是每一个DID都会有独立的密钥对与之对应，进行相应的加解密工作

附原文

A Brief Overview of SSI Core Concepts

This document defines some basic terminology in a fast, informal way, so it can be referenced in introductory materials. Be sure you understand what’s here, before you tackle more advanced topics. You may also find it useful to consult more in-depth references such as Sovrin Glossary, SSI Notation Conventions, Sovrin Trust Framework, and Self-Sovereign Privacy By Design.

Core Concepts

An identity owner (or owner, for short) is a person or institution that participates as a first-class citizen in the Sovrin ecosystem.

An agent is a piece of software that works on behalf of–and only on behalf of–a single owner. There are 2 major categories of agent: edge agents (running on devices directly controlled by the identity owner) and cloud agents (running on devices controlled by someone else). Edge agents are usually more trusted than cloud agents. The endpoint of a cloud agent is the most likely address for external parties to use to contact an owner, since it is designed to be stable and public.

Owners and agents store secrets in wallets.

An agentless relationship (consisting only of owners, but not agents) is digitally incapable; because humans and institutions can’t directly encrypt, sign, or transmit bytes, such a relationship can have no digital interactions. The simplest digitally capable relationship consists of two identity owners, and each of their agents–four entities, total. The most common relationship in the Sovrin ecosystem is one where each owner has an edge agent (for example, running on a mobile device) and a cloud agent (for example, running at an agency that offers SaaS-style cloud agent subscriptions).

The set of things–agents, devices, storage, services, software–under the control of an owner is that owner’s sovereign domain (or domain, for short). Just as a queen should be able to arrange her troops and order her kingdom according to preference, mostly without consulting or coordinating with other monarchs, a domain should be mostly opaque to the outside world, and should be changeable at the owner’s discretion.

We are in the habit of speaking of actions in the Sovrin ecosystem in a way that conflates people and their agents. For example, we say, “Alice encrypts a message and sends it to Bob.” What we really mean, if we are especially precise, is that Alice’s edge agent (which is under her direct control, perhaps on her mobile device) encrypts a message at her behest and delivers it–possibly through a complex route–to Bob’s domain–and we hope that Bob’s domain includes a mail delivery service that eventually causes it to be displayed to Bob. We cannot guarantee that this actually happens; Bob controls his own domain and might have an deputized AI or a malicious spy reading and answering his messages without consulting him. Such an intermediary could run in the cloud, or even on Bob’s mobile device. However, cryptography lets us distinguish between different agents under Bob’s control; assuming Bob exposes a few details about his domain (the public keys of his cloud and edge agents), we can encrypt so a message can only be read on his edge device. And when Bob replies, we can tell which agent originated the reply. This prevents Bob from being impersonated by innocent or malicious intermediaries not under his direct control, either inside his domain or without–a crucial security requirement.

A DID (Decentralized Identifier) is one owner’s identifier for a relationship–usually, a pairwise relationship. When people first encounter the concept of DIDs, they often imagine that DIDs might be used to identify other entities as well–owners themselves, or their agents. This is not their intent. Alice isn’t generically identified by a DID–she is only identified by a DID within a relationship context. She might establish a second relationship with the same remote party, and a third–and use a different DID each time. The agents that Alice uses do not need DIDs; they are protected and enabled by keys that are subservient to or derived from the primary relationship. Thus, a typical relationship is governed by:

1. The DID for party A with respect to party B

2. The DID for party B with respect to party A

3. For each agent x that works for A, the key pair that x uses to facilitate the A~B relationship.

4. Any other key pairs that A has authorized to suit her purposes.

5. For each agent y that works for B, the key pair that y uses to facilitate the B~A relationship.

6. Any other key pairs that B has authorized to suit his purposes.

Notice that all key pairs are conceptually equivalent; there is no special key pair that is a master, no key pair that belongs to the DID itself. Some keys may be more privileged than others, but they are all just key pairs.**