Бөлісу құралы:

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

  • Мақала

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

Необходимые компоненты

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

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

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

  1. В портал Azure перейдите на страницу проверенного идентификатора.

  2. Выберите "Настройка>проверки владения доменом" и выберите "Проверить для домена".

  3. Скопируйте или скачайте did-configuration.json файл.

    Снимок экрана: скачивание известной конфигурации.

  4. did-configuration.json Размещение файла в указанном расположении. Например, если вы указали домен https://www.example.com, файл должен размещаться в https://www.example.com/.well-known/did-configuration.json. В URL-адресе нет другого .well-known path пути, кроме имени.

  5. Когда did-configuration.json он доступен по .well-known/did-configuration.json URL-адресу, проверьте его, выбрав "Обновить состояние проверки".

    Снимок экрана: проверенная хорошо известная конфигурация.

  6. Попробуйте выдать удостоверение или представить его Microsoft Authenticator для проверки. Убедитесь, что параметр "Предупреждение о небезопасных приложениях " в Authenticator включен. Параметр включен по умолчанию.

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

Портал проверяет, доступен ли did-configuration.json доступ через Интернет и действителен при выборе состояния проверки обновления. Authenticator не учитывает перенаправления HTTP. Кроме того, следует убедиться, что вы можете запросить этот URL-адрес в браузере, чтобы избежать ошибок, таких как использование HTTPS, плохой 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 для создания ссылки. Служба проверяемых удостоверений связывает DID и домен. Служба включает сведения о домене, предоставленные в DID, и создает известный файл конфигурации:

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

    "service": [
  {
    "id": "#linkeddomains",
    "type": "LinkedDomains",
    "serviceEndpoint": {
      "origins": [
        "https://verifiedid.contoso.com/"
      ]
    }
  }
]

  2. Проверяемая служба учетных данных в проверенном идентификаторе создает соответствующий хорошо известный ресурс конфигурации, который необходимо разместить в домене. Файл конфигурации содержит самоотдаемые проверяемые учетные данные типа 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 статического веб-сайта. Вы не можете контролировать имя домена, за исключением того, что он содержит имя учетной записи хранения в составе имени узла.

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

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

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

  1. Перейдите к учетной записи хранения и выберите контейнеры в левом меню. Затем выберите контейнер с именем $web.
  2. Нажмите кнопку "Отправить " и выберите значок папки, чтобы найти файл.
  3. Перед отправкой откройте раздел Advanced и укажите в текстовом поле "Отправить в папку ".
  4. Отправьте файл .

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

Следующие шаги