验证域对分散式标识符 (DID) 的所有权

项目
01/11/2024

在本文中，我们会介绍如何验证为分散式标识符 (DID) 所使用的域名的所有权所需的步骤。

先决条件

若要验证域对 DID 的所有权，你需要：

完成入门和后续教程集。

验证域所有权并分发 did-configuration.json 文件

要验证其对 DID 的所有权的域在概述部分中定义。域必须由你控制，且其格式应为 https://www.example.com/。

在 Azure 门户中，转到“验证 ID”页。
选择“设置”，>然后选择“验证域所有权”，并为域选择“验证”。
复制或下载 did-configuration.json 文件。
将 did-configuration.json 文件托管在指定的位置。例如，如果指定了域 https://www.example.com，则需要在此 https://www.example.com/.well-known/did-configuration.json 上托管文件。除了 .well-known path 名称以外，URL 中不能存在其他路径。
当 did-configuration.json 在 .well-known/did-configuration.json URL 公开可用时，选择“刷新验证状态”对其进行验证。
尝试使用 Microsoft Authenticator 颁发或演示以进行验证。请确保 Authenticator 中已打开“警告不安全应用”设置。默认情况下设置为打开。

如何确认验证过程是否在工作？

当选择“刷新验证状态”按钮时，门户会验证 did-configuration.json 是否可通过 Internet 进行访问并且有效。 Authenticator 不支持 http 重定向。还应考虑验证是否可在浏览器中请求该 URL 以避免错误，例如未使用 https、SSL 证书错误或 URL 未公开。如果无法在浏览器中或通过 curl 之类的工具匿名请求 did-configuration.json 文件而没有警告或错误，则门户也将无法完成“刷新验证状态”步骤。

注意

如果在刷新验证状态时遇到问题，可以通过在具有 Ubuntu OS 的计算机上运行 curl -Iv https://yourdomain.com/.well-known/did-configuration.json 对其进行故障排除。使用具有 Ubuntu 的适用于 Linux 的 Windows 子系统也会正常工作。如果 curl 失败，刷新验证状态将不起作用。

为什么需要验证 DID 的域所有权？

DID 作为未定位到现有系统的标识符启动。 DID 的作用在于可以由用户或组织拥有并控制。若与组织交互的实体不知晓 DID 所属的用户，则 DID 不具备上述作用。

将 DID 链接到域允许任何实体对 DID 和域之间的关系进行加密验证，从而可解决初始信任问题。

VerifiedID 如何链接 DID 和域？

创建链接时，VerifiedID 将遵循已知 DID 配置规范。可验证凭据服务将链接你的 DID 和域。该服务包括你在 DID 中提供的域信息，并生成已知的配置文件：

VerifiedID 使用组织设置过程中用户提供的域信息在 DID 文档中编写服务终结点。所有与用户 DID 交互的参与方均可看到用户 DID 声明要关联的域。
```
"service": [
  {
    "id": "#linkeddomains",
    "type": "LinkedDomains",
    "serviceEndpoint": {
      "origins": [
        "https://verifiedid.contoso.com/"
      ]
    }
  }
]
```
VerifiedID 中的可验证凭据服务将生成一个合规的已知配置资源，你必须在域中托管该资源。配置文件包含凭据类型 DomainLinkageCredential 自行颁发的可验证凭据，该凭据使用来自用户域的 DID 进行签名。下面是存储在根域 URL 中的配置文件示例。
```
{
  "@context": "https://identity.foundation/.well-known/contexts/did-configuration-v0.0.jsonld",
  "linked_dids": [
    "jwt..."
  ]
}
```

钱包中的用户体验

用户在操作颁发流程或提供可验证凭据时，应了解组织及其 DID 的相关信息。 Authenticator 将验证 DID 与 DID 文档中的域的关系，并根据结果为用户提供两种不同的体验。

已验证的域

在 Authenticator 显示“已验证”图标之前，以下几点必须为 true：

签署自行颁发的开放 ID (SIOP) 请求的 DID 必须具有已链接域的服务终结点。
根域不使用重定向，而是使用 HTTPS。
DID 文档中所列的域具有可解析的已知资源。
签署已知资源的可验证凭据使用的 DID 与签署 Authenticator 用于启动流程的 SIOP 所使用 DID 相同。

若上述几点均为 true，Authenticator 将显示已验证的页面，其中包括已验证的域。

显示新权限请求的屏幕截图。

未验证的域

如果上述任何一点不成立，则 Authenticator 向用户显示一条完整页面警告，指示域未验证。用户会收到警告，指出它们处于潜在的危险事务当中，应慎用。它们选择此路由的原因如下：

DID 未定位到域。
配置未正确设置。
用户与之交互的 DID 可能是恶意的，并且实际上无法证明他们拥有了已链接的域。

将你的 DID 链接到用户可识别的域，这一点很重要。

显示“添加凭据”屏幕上未验证的域警告的屏幕截图。

如何更新 DID 上的链接域？

对于 Web 信任系统，不支持更新链接域。必须选择退出并重新加入。

链接域为开发人员提供方便

注意

DID 文档必须公开可用，DID 注册才能成功。

开发人员若要获取用于链接域的域，最简单的方法是使用 Azure 存储的静态网站功能。你无法控制域名，但是可以让它包含存储帐户名称，作为其主机名的一部分。

如何快速设置将用于链接域的域：

创建存储帐户。创建过程中，请选择 StorageV2（常规用途 v2 帐户）和本地冗余存储 (LRS)。
转到该存储帐户，然后在最左侧菜单中选择“静态网站”并启用静态网站。如果看不到“静态网站”菜单项，则表明你未创建 V2 存储帐户。
复制在保存后显示的主终结点名称。该值是你的域名。它类似于 https://<your-storageaccountname>.z6.web.core.windows.net/。

上传 did-configuration.json 文件时：

转到该存储帐户，然后在最左侧菜单中选择“容器”。然后选择名为 $web 的容器。
选择“上传”并选择文件夹图标以查找文件
在上传之前，打开“高级”部分，并在“上传到文件夹”文本框中指定 .well-known。
上传该文件。

现在，你已在类似于 https://<your-storageaccountname>.z6.web.core.windows.net/.well-known/did-configuration.json 的 URL 上公开提供文件。

后续步骤

自定义 Microsoft Entra 验证 ID

通过