是否可以让did支持http？

http over did？进行身份认证与加密？如果这个路径可以跑通，那

did的问题

did all可能存在最终的问题：安全的根在哪里，用户是否能够接受。它的有点是成本低，比did web要低，did web要么需要自己部署，要么需要依赖于别人的服务并且自己其实是没有控制权的(也许可以通过URL的设计来获取控制权，在URL中把公钥的hash写进去)

回到根本上，web是通过域名的申请，来实现最终的信任根。域名与机构或个人绑定，机构或个人对域名下的内容负责。

我们是不是设计一个DID的域名系统？

规范学习

规范：https://www.w3.org/TR/did-core/ 用例（有助于理解DID过程，有很多过程描述，比did-core更详细）：https://www.w3.org/TR/did-use-cases/ 扩展：https://github.com/w3c/did-extensions

规范

去中心化标识符（DID）是一种新型标识符，可实现可验证的去中心化数字身份。DID 是指任何主体（例如，人员、组织、事物、数据模型、抽象实体等）由 DID 的控制器确定。与典型的联合标识符相比，DID 的设计使其可以与集中式注册表、身份提供商和证书颁发机构分离。具体来说，虽然其他方可能被用来帮助发现与 DID 相关的信息，但该设计使 DID 的控制者能够证明对它的控制，而无需任何其他方的许可。DID 是将 DIDsubject 与 DID 文档关联的 URI，允许与该主题关联的可信交互。

每个 DID 文档都可以表达加密材料、验证方法或服务，它们提供了一组机制，使DID 控制器能够证明对 DID 的控制。服务支持与 DID 主题关联的可信交互。如果 DIDsubject 是数据模型等信息资源，则 DID 可能会提供返回 DID 主题本身的方法。

我们可以使用测试套件验证是否符合规范在发布时，存在103 个实验性 DID 方法规范、32 个实验性 DID 方法驱动程序实现、一个确定给定实现是否符合此规范的测试套件以及 46 个提交给一致性测试套件的实施。建议读者注意 DID Core 问题和 DID Core Test Suite问题，它们都包含可能导致本规范更改的最新问题和拟议更改列表。在发布时，预计不会有其他实质性问题、更改或修改。

本规范中定义的去中心化标识符（DID）是一种新型的全局唯一标识符。它们旨在使个人和组织能够使用他们信任的系统生成自己的标识符。这些新的标识符使实体能够通过使用加密证明（如数字签名）进行身份验证来证明对它们的控制。

由于去中心化标识符的生成和断言是由实体控制的，因此每个实体都可以拥有任意数量的 DID，以维持其所需的身份、角色和交互分离。

本规范不预设任何特定的技术或密码学来支持 DID 的生成、持久性、解析或解释。例如，实施者可以基于在联合或集中式身份管理系统中注册的标识符创建去中心化标识符。事实上，几乎所有类型的标识符系统都可以添加对 DID 的支持。这在集中式、联合式和去中心化标识符的世界之间架起了一座互操作性桥梁。这还使实施者能够设计特定类型的 DID，以与他们信任的计算基础设施配合使用，例如分布式账本、去中心化文件系统、分布式数据库和点对点网络。

这些因素表明，在某些情况下需要“自我主权”的全局唯一标识符，即不依赖于任何颁发机构的标识符。通用唯一标识符（UUIDs） [] 履行此角色，但是，无法证明对 UUID 的控制。

用例

控制者、请求方和主体：

控制者和主体一般相同。但是，有点时候不同，比如当员工代表其雇主管理 DID 或父母代表其孩子使用 DID 时。
DID 控制者和请求方可以是个人或交互式系统，但为简单起见，在本文件中，我们将两者称为执行这些操作的个人。
只有 DID 控制器可以执行控制 DID 的操作，但是，如果他们希望检查或验证自己的 DID，任何人都可以充当他们知道的任何 DID 的请求方，包括 DID 控制器。

也许去中心化标识符最突出的一点是没有“身份提供者”。相反，这个角色被包含在控制者用来管理 DID 的去中心化系统中，反过来，请求方用来应用 DID。预计 DID 将使用分布式账本技术（DLT）进行注册。

概念

用例：https://www.w3.org/TR/did-use-cases/

authenticate 证实身份验证是一个过程（通常是某种类型的协议），通过该过程，实体可以使用一种或多种验证方法来证明它具有特定属性或控制特定密钥。对于 DID，一个常见的示例是证明对与 DID 文档中发布的公钥关联的私钥的控制权。

decentralized identifier (DID) 去中心化标识符（DID）一个全局唯一的永久标识符，不需要集中注册机构，因为它是以加密方式生成和/或注册的。DID 的通用格式在 DID Core 规范 [DID-CORE] 中定义。在 DID 方法规范中定义了特定的 DID 方案。许多—但不是全部—DID 方法利用分布式账本技术（DLT）或其他形式的去中心化网络。

DID controller DID 控制器能够更改 DID 文档的实体。一个 DID 可以有多个 DID 控制器。DID 控制器可以用 DIDdocument 顶层的可选 controller 属性来表示。请注意，一个 DID 控制器可能是 DID 主体。

DID方法一种定义了特定DID方案如何实现以适配特定可验证数据注册表的规范。DID方法由DID方法规范定义，该规范必须明确规定创建、解析和注销DID以及编写和更新DID文档的具体操作方式。

services 服务业通过一个或多个服务端点与 DID 主体或关联实体进行通信或交互的方式。示例包括发现服务、代理服务、社交网络服务、文件存储服务和可验证凭证存储库服务。

verification method 验证方法一组参数，可与流程或协议一起使用，以独立验证证明。例如，公钥可以用作数字签名的验证方法;在这种用法中，它会验证签名者是否拥有关联的私钥。

本定义中的“验证”和“证明”旨在广泛适用。例如，在 Diffie-Hellman 密钥交换期间，可能会使用公钥来协商用于加密的共享对称密钥。这保证了密钥协议流程的完整性。因此，它是另一种类型的验证方法，即使该过程的描述可能没有使用“验证”或“证明”这两个词。

Authenticate 5.2.2 身份验证请求方可能希望证明提供 DID 的个人实际上是其 DID 控制者或被指定为特定服务端点的控制者。这个身份验证过程应该使用 DID 文档中的 cryptographicmaterial 来测试所声称的 Controller 是否真的可以证明控制权，通常是通过某种质询-响应。DID 文档和方法可能允许对不同的服务端点进行单独的证明，这与 update 和 delete 操作不同。这种分离将支持预期会经常使用的事务性证明，而预期很少使用控制证明。

Resolve 5.3.1 解决将 DID 用于演示以外的任何用途的第一步是将 DID 解析为特定的 DID 文档，以显示与该 DID 关联的加密材料和服务端点。这种情况的发生方式应该是特定于方法的，并且超出了 DID 工作组的范围。

Dereference 5.3.2 取消引用取消引用 DID 会使用其 DID 文档中的材料来返回资源。预期结果是，默认情况下，在没有引用服务端点的情况下取消引用 DID 将返回 DID 文档本身。当 DID 与service parameter组合（形成 DID URL）时，取消引用将返回从命名服务端点指向的资源，该资源是通过将 DID 解析为其 DID 文档并按名称查找端点来发现的。通过这种方式，请求方可以动态地发现给定 DID 的当前服务端点并与之交互。因此，可以为服务提供持久标识符，即使底层 serviceendpoints 发生更改，这些标识符也不会更改。

Deactivate 5.5.1 停用控制器应该能够停用 DID，而不是删除 DID，这样 authentication 和 derefencing 等下游进程就不再起作用了。大多数分散式系统无法保证实际删除记录。事实上，分布式账本经常被吹捧为“不可变”。方法应定义停用过程以实现与删除相同的效果。停用机制因方法而异，因此“非活动”消息会有所不同。

DID WEB方法

DID并未制定身份验证和授权、对DID验证、完整性的方法。

DID web的信任核心在于DNS。

由于 did：web 方法的性质依赖于 DNS 来解析 Web 服务器，因此 did：web 标识符的所有解析都有可能被 DNS 提供商跟踪。此外，由于 DID 文档存储在 Web 服务器上，因此每次检索 DIDDocument 资源时，Web 服务器都能够跟踪 DID 文档的分辨率。为了缓解在解析 DID 文档时依赖方被跟踪的问题，依赖方应该考虑使用受信任的通用解析器服务来获得羊群隐私、使用 VPN 服务或通过 TOR 网络执行解析。另一个有助于解决此问题的新兴解决方案是 draft-pauly-dprive-oblivious-doh-03

版权声明

Did vs Other MC P Wba Commit