Подтвердите владение доменом для вашего децентрализованного идентификатора

2025-06-25

В этой статье мы рассмотрим шаги, необходимые для проверки владения доменным именем, который вы используете для децентрализованного идентификатора (DID).

Предпосылки

Чтобы проверить владение доменом в DID, необходимо выполнить следующие действия.

Завершите начало работы и последующий набор учебников.

Проверка владения доменом и распространение файла did-configuration.json

Домен, владение которым вы проверяете для вашего DID, определяется в разделе обзора. Домен должен быть доменом под вашим контролем, и он должен находиться в формате https://www.example.com/.

В Центре администрирования Microsoft Entra выберите страницу проверенного идентификатора .
Выберите "Обзор " и в этом разделе выберите "Проверить владение доменом".
Выберите Проверить для домена.
Скопируйте или скачайте did-configuration.json файл.
Разместите файл did-configuration.json в указанном месте. Например, если вы указали домен https://www.example.com, файл должен размещаться в https://www.example.com/.well-known/did-configuration.json. В URL-адресе не может быть другого пути, кроме названия .well-known path.
Когда did-configuration.json публично доступен по .well-known/did-configuration.json URL-адресу, проверьте это, выбрав "Обновить статус проверки".
Протестируйте выдачу или презентацию с помощью Microsoft Authenticator для проверки. Убедитесь, что параметр "Предупреждение о небезопасных приложениях " в Authenticator включен. Параметр включен по умолчанию.

Как проверить, работает ли проверка?

Портал проверяет, доступен ли did-configuration.json через Интернет и корректность подтверждается при выборе Обновить статус проверки. Authenticator не учитывает перенаправления HTTP. Кроме того, следует убедиться, что вы можете запросить этот URL-адрес в браузере, чтобы избежать ошибок, таких как использование HTTPS, плохой TLS/SSL-сертификат или URL-адрес, который не является общедоступным. Если файл не может быть запрошен анонимно в браузере или с помощью таких средств, как did-configuration.json, без предупреждений или ошибок, то портал не может выполнить шаг curl.

Замечание

Если у вас возникли проблемы с обновлением статуса проверки, вы можете устранить их, выполнив curl -Iv https://yourdomain.com/.well-known/did-configuration.json на компьютере с операционной системой Ubuntu. Подсистема Windows для Linux с Ubuntu также работает. Если curl завершится ошибкой, обновить состояние проверки не удастся.

Почему вам нужно подтвердить права на домен для нашего DID?

Идентификатор DID начинает свое существование как идентификатор, который не привязан к существующим системам. Цифровой идентификатор (DID) полезен, потому что пользователь или организация могут владеть им и управлять. Если сущность, взаимодействующая с организацией, не знает, кому принадлежит ДИД, то ДИД не так полезен.

Связывание DID с доменом решает начальную проблему доверия, позволяя любой сущности криптографически проверять связь между DID и доменом.

Как проверенный идентификатор (Verified ID) связывает децентрализованные идентификаторы (DID) и домены?

Проверенный идентификатор следует известной спецификации конфигурации DID для создания ссылки. Служба проверяемых учетных данных связывает ваш DID и домен. Служба включает сведения о домене, предоставленные в DID, и создает известный файл конфигурации:

Проверенный идентификатор использует сведения о домене, предоставляемые во время настройки организации, для записи конечной точки службы в документе DID. Все стороны, взаимодействующие с вашим DID, могут видеть домен, с которым он ассоциируется.
```
"service": [
  {
    "id": "#linkeddomains",
    "type": "LinkedDomains",
    "serviceEndpoint": {
      "origins": [
        "https://verifiedid.contoso.com/"
      ]
    }
  }
]
```
Верифицируемая служба учетных данных в Verified ID создает соответствующий требованиям общеизвестный ресурс конфигурации, который необходимо разместить на вашем домене. Файл конфигурации содержит самовыпущенные проверяемые учетные данные типа DomainLinkageCredential, подписанные вашим DID, происходящие из вашего домена. Ниже приведен пример файла конфигурации, хранящегося по URL-адресу корневого домена.
```
{
  "@context": "https://identity.foundation/.well-known/contexts/did-configuration-v0.0.jsonld",
  "linked_dids": [
    "jwt..."
  ]
}
```

Пользовательский опыт в кошельке

Когда пользователь проходит процесс выдачи или представляет удостоверяющие данные, он должен знать что-то об организации и её DID. Authenticator проверяет связь DID с доменом в документе DID и предоставляет пользователям два различных интерфейса в зависимости от результата.

Проверен домен

Прежде чем Authenticator отображает проверенный значок, несколько точек должны иметь значение true:

Для подписания самовыданного запроса ДИд (SIOP) должна быть серверная точка для привязанного домена.
Корневой домен не использует перенаправление и использует ПРОТОКОЛ HTTPS.
Домен, указанный в документе DID, имеет разрешаемый известный ресурс.
Проверяемые учетные данные известного ресурса подписаны с помощью того же DID, который использовался для подписывания SIOP, используемого для запуска потока.

Если все ранее упомянутые пункты имеют значение true, то Authenticator отображает проверенную страницу и включает проверенный домен.

Снимок экрана: новый запрос на разрешение.

Непроверенный домен

Если какое-либо из предыдущих утверждений не соответствует действительности, Authenticator отображает полноэкранное предупреждение, указывающее, что домен не подтвержден. Пользователю предупреждают, что он находится в середине потенциально рискованной транзакции и ему следует действовать с осторожностью. Возможно, они решили принять этот маршрут, так как:

Приложение DID не привязано к домену.
Конфигурация не была настроена должным образом.
DID, с которым взаимодействует пользователь, может быть вредоносным и фактически не может доказать, что он владеет доменом, связанным.

Очень важно связать приложение DID с доменом, узнаваемым пользователем.

Снимок экрана: предупреждение о неотверенном домене на экране

Как обновить связанный домен в моем DID?

В системе веб-доверия обновление связанного домена не поддерживается. Вы должны выйти и заново зарегистрироваться.

Связанный домен прост для разработчиков

Замечание

Документ DID должен быть общедоступным для успешной регистрации DID.

Самый простой способ для разработчика получить домен для связанного домена — использовать статический веб-сайт службы хранилища Azure. Вы не можете контролировать имя домена, за исключением того, что оно содержит имя вашей учетной записи хранения в имени узла.

Чтобы быстро настроить домен для использования в связанном домене:

Создайте учетную запись хранения. Во время создания выберите StorageV2 (учетная запись общего назначения версии 2) и локально избыточное хранилище (LRS).
Перейдите к учетной записи хранения и выберите статический веб-сайт в левом меню и включите статический веб-сайт. Если вы не видите пункт меню статического веб-сайта, вы не создали аккаунт хранения версии V2.
Скопируйте имя основной конечной точки, которое отображается после сохранения. Это значение — это ваш домен. Оно будет выглядеть примерно так — https://<your-storageaccountname>.z6.web.core.windows.net/.

Когда пришло время отправить did-configuration.json файл:

Перейдите к учетной записи хранения и выберите контейнеры в левом меню. Затем выберите контейнер с именем $web.
Нажмите кнопку "Отправить " и выберите значок папки, чтобы найти файл.
Перед отправкой откройте раздел Дополнительные параметры и укажите .well-known в текстовом поле "Загрузить в папку".
Отправьте файл .

Теперь у вас есть общедоступный файл по URL-адресу, который выглядит примерно так https://<your-storageaccountname>.z6.web.core.windows.net/.well-known/did-configuration.json.

Дальнейшие шаги

Настройка Проверенные учетные данные Microsoft Entra