Часто задаваемые вопросы

На этой странице содержатся часто задаваемые вопросы о проверяемых и децентрализованных удостоверениях. Вопросы сгруппированы по следующим разделам.

• Словарь и основные сведения
• Общие вопросы о децентрализованном удостоверении

Основные принципы

Что такое децентрализованное удостоверение (DID)?

Децентрализованные идентификаторы (DID) — это уникальные идентификаторы, используемые для защиты доступа к ресурсам, подписи и проверки учетных данных, а также для упрощения обмена данными между приложениями. В отличие от традиционных имен пользователей и адресов электронной почты, сущностей и владельцев и управления идентификаторами идентификаторов (будь то человек, устройство или компания). Удостоверения DID существуют независимо от любой внешней организации или доверенного посредника. Подробные сведения о DID приведены в статье Спецификации децентрализованных удостоверений консорциума W3C.

Назначение DID

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

Что такое проверяемое удостоверение?

Учетные данные являются частью нашей повседневной жизни. Водительские лицензии используются для утверждения того, что мы способны работать с автомобилем. Дипломы университета можно использовать для утверждения нашего уровня образования и паспортов, выданных правительством, позволяют нам путешествовать между странами и регионами. Проверяемые удостоверения предоставляют механизм сортировки таких учетных данных в Интернете, обеспечивающий криптографическую защиту, конфиденциальность и машинную верификацию. Подробные сведения о проверяемых удостоверениях приведены в статье Спецификации проверяемых удостоверений консорциума W3C.

Концептуальные вопросы

Что происходит, когда пользователь теряет свой телефон? Могут ли они восстановить свое удостоверение?

Для пользователей существует несколько способов восстановления с различной степенью эффективности. Корпорация Майкрософт в настоящее время оценивает варианты и подходы к восстановлению, которые обеспечивают удобство и безопасность при уважении конфиденциальности и самоуверенности пользователя.

Как пользователь может доверять запросу от издателя или средства проверки приложений? Как они узнают, что децентрализованное удостоверение (DID) действительно является удостоверением DID для Организации?

Мы реализуем спецификацию хорошо известной конфигурации DID Decentralized Identity Foundation, чтобы подключить DID к известной существующей системе, доменным именам. Каждый файл DID, созданный с помощью Проверенные учетные данные Microsoft Entra, имеет возможность включить корневое доменное имя, закодированное в документе DID. Чтобы узнать больше о связанных доменах, следуйте инструкциям из статьи " Связать домен с распределенным идентификатором ".

Каковы ограничения размера для проверяемых учетных данных в проверенном идентификаторе?

• Для запроса на выдачу — 1 МБ
• Фотография в проверяемых учетных данных — 1 МБ
• Результат обратного вызова 10 МБ без получения

Каковы требования к лицензированию?

Для выдачи проверяемых удостоверений никаких особых требований к лицензированию не предъявляется.

Разделы справки сброс службы Проверенные учетные данные Microsoft Entra?

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

1. Следуйте инструкциям по отказу.
2. Выполните действия по развертыванию Проверенные учетные данные Microsoft Entra для перенастройки службы.
   1. Если вы настраиваете проверенный идентификатор вручную, выберите расположение для Azure Key Vault, который будет находиться в одном или ближайшем регионе. Выбор одного региона позволяет избежать проблем с производительностью и задержкой.
3. Завершите настройку службы проверяемых удостоверений. Необходимо создать удостоверения повторно.
   1. Также необходимо выдать новые удостоверения, так как ваш арендатор теперь имеет новый DID.

Как проверить регион клиента Microsoft Entra?

1. В портал Azure перейдите к идентификатору Microsoft Entra для подписки, используемой для развертывания Проверенные учетные данные Microsoft Entra.

2. В разделе Управление выберите Свойства.

   

3. Просмотрите значение для параметра "Страна или регион". Если значение является страной или регионом в Европе, ваша служба Проверенные учетные данные Microsoft Entra настроена в Европе.

Поддерживает ли Проверенные учетные данные Microsoft Entra ION как его метод DID?

Проверенный идентификатор поддерживает метод DID:ION в предварительной версии до декабря 2023 года, после чего он был прекращен.

Разделы справки перейти на сайт:web from did:ion?

Если вы хотите перейти к did:web этому элементу, выполните следующие действия с помощью API администрированияdid:ion. Для изменения центра требуется повторное получение всех учетных данных:

Экспорт существующих определений учетных данных did:ion

1. did:ion Чтобы центр использовал портал для копирования всех определений отображаемых и правил существующих учетных данных.
2. Если у вас несколько центров, необходимо использовать API администрирования, если did:ion центр не является центром по умолчанию. В клиенте проверенного идентификатора подключитесь с помощью API администрирования, чтобы получить идентификатор центра для did:ion центра. Затем используйте API контрактов списка, чтобы экспортировать их и сохранить результат в файл, чтобы можно было повторно создать их.

Создание нового центра did:web authority

1. С помощью API подключения создайте новый did:web центр. Кроме того, если у вашего клиента есть только один центр did:ion, вы также можете выполнить отказ от службы, за которой следует выполнить операцию согласия, чтобы перезапустить с помощью проверенных конфигураций идентификаторов. В этом случае можно выбрать вариант быстрого и ручного настройки.
2. Если вы настраиваете веб-центр с помощью API администрирования, необходимо вызвать документ DID для создания документа и вызова создания хорошо известного документа , а затем отправить JSON-файлы в соответствующий известный путь.

Повторное создание определений учетных данных

При создании нового did:web центра необходимо повторно создать определения учетных данных. Это можно сделать с помощью портала , если вы отказались от использования и повторно подключены, или необходимо использовать API создания контракта для их повторного создания.

Обновление существующих приложений

1. Обновите любое существующее приложение (издатель или проверяющее приложения), чтобы использовать новое did:web authority. Для приложений выдачи также обновите URL-адрес манифеста учетных данных.
2. Тестовые потоки выдачи и проверки из нового веб-центра. После успешного выполнения тестов перейдите к следующему шагу для удаления центра did:ion.

Удаление центра did:ion

Если вы не отказались от использования и повторно подключиться, необходимо удалить старый did:ion центр. Используйте API центра удаления для удаления центра did:ion.

Если я перенастрою службу Проверенные учетные данные Microsoft Entra, необходимо ли повторно связать мою службу DID с моим доменом?

Да, после повторной настройки службы ваш арендатор использует новый DID для выдачи и проверки проверяемых удостоверений. Вам нужно связать новый DID со своим доменом.

Можно ли попросить корпорацию Майкрософт предоставить "старые идентификаторы DID"?

Нет, на этом этапе невозможно сохранить DID клиента после того, как вы отказались от службы.

Я не могу использовать ngrok, что делать?

В руководствах по развертыванию и запуску примеров описывается использование средства ngrok в качестве прокси приложения. Этот инструмент иногда блокируется ИТ-администраторами в корпоративных сетях. Альтернатива — развертывание примера в Службе приложений Azure и его запуск в облаке. Материалы по ссылкам ниже помогут развернуть соответствующий пример в Службе приложений Azure. Ценовая категория "Бесплатный" достаточно для размещения примера. Для каждого руководства необходимо сначала создать экземпляр Службы приложений Azure, пропустить этап создания приложения, так как оно у вас уже есть, а затем перейти к его развертыванию.

• Dotnet — публикация в Службе приложений.
• Node — развертывание в Службе приложений.
• Java — развертывание в Службе приложений. В пример необходимо добавить подключаемый модуль Maven для Службы приложений Azure.
• Python — развертывание с помощью Visual Studio Code

Независимо от того, какой язык примера используется, имя https://something.azurewebsites.net узла приложение Azure Service используется в качестве общедоступной конечной точки. Чтобы заставить его работать, ничего больше настраивать не требуется. В случае изменений в коде или конфигурации необходимо повторно развернуть пример в Службах приложений Azure. Устранение неполадок и отладка не так просто, как запуск примера на локальном компьютере, где трассировки в окне консоли отображают ошибки, но вы можете добиться почти того же, используя поток журналов.

Защита сети для событий обратного вызова

API службы запросов использует обратные вызовы к URL-адресу , предоставленному приложением проверяющей стороны. Этот URL-адрес должен быть доступен из системы проверенных идентификаторов для получения обратных вызовов. Обратные вызовы приходят из инфраструктуры Azure в том же регионе, что и клиент Microsoft Entra. Если вам нужно ужесточить сеть, у вас есть два варианта.

• Используйте теги службы брандмауэра Azure AzureCloud.
• Используйте опубликованный диапазон CIDR для настройки брандмауэра. Необходимо использовать AzureCloud.регионы , соответствующие развертыванию клиента Microsoft Entra для настройки брандмауэра, чтобы разрешить обратный трафик из API службы запросов. Например, если клиент находится в ЕС, следует выбрать все диапазоны CIDR из AzureCloud.northeurope, .westeurope и т. д. в конфигурацию брандмауэров.

Сканирование QR-кода

В документации инструкция scan the QR code ссылается на сканирование с помощью мобильного приложения Microsoft Authenticator, если иное не указано. Вы можете сканировать QR-код с помощью приложения камеры мобильного устройства, которое затем запускает Microsoft Authenticator. Для этого обработчик протокола openid-vc:// должен быть зарегистрирован для Microsoft Authenticator. Если для него зарегистрировано другое мобильное приложение, средство Authenticator не откроется. В некоторых старых мобильных версиях Android сканирование QR-кода с помощью приложения камеры не работает, и нет другого обходного решения, кроме использования приложения Microsoft Authenticator для сканирования.

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

• Настройка проверяемых удостоверений