Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Обзор
На этой странице содержатся часто задаваемые вопросы о проверяемых и децентрализованных удостоверениях. Вопросы сгруппированы по следующим разделам.
Основные принципы
Что такое DID?
Децентрализованные идентификаторы (DID) — это уникальные идентификаторы, используемые для защиты доступа к ресурсам, подписи и проверки учетных данных, а также для упрощения обмена данными между приложениями. В отличие от традиционных имен пользователей и адресов электронной почты, сущности контролируют и владеют DIDs сами (будь то человек, устройство или компания). Удостоверения DID существуют независимо от любой внешней организации или доверенного посредника. Подробные сведения о DID приведены в статье Спецификации децентрализованных идентификаторов W3C.
Почему необходим децентрализованный идентификатор (DID)?
Для цифрового доверия необходимо, чтобы участники владели и контролировали свои идентичности, а идентичность начинается с идентификатора. В эпоху ежедневных и крупномасштабных случаев несанкционированного доступа к системам, и атак на ловушки централизованного удостоверения, децентрализованное удостоверение становится важным фактором безопасности для клиентов и предприятий. Люди, владеющие и контролирующие свои идентичности, могут обмениваться проверяемыми данными и доказательствами. Распределенная среда учетных данных обеспечивает автоматизацию многих бизнес-процессов, которые в настоящее время выполняются вручную и с большими усилиями.
Что такое проверяемое удостоверение?
Учетные данные — это часть нашей повседневной жизни. Водительские лицензии используются для утверждения того, что мы способны работать с автомобилем. Дипломы университета можно использовать для утверждения нашего уровня образования и паспортов, выданных правительством, позволяют нам путешествовать между странами и регионами. Проверяемые учетные данные предоставляют механизм для выражения таких данных в Интернете таким образом, чтобы это было криптографически безопасно, уважало конфиденциальность и проверялось на машинном уровне. Подробные сведения о проверяемых удостоверениях приведены в статье Спецификации проверяемых удостоверений консорциума W3C.
Концептуальные вопросы
Что происходит, когда пользователь теряет свой телефон? Могут ли они восстановить свое удостоверение?
Для пользователей существует несколько способов восстановления с различной степенью эффективности. Корпорация Майкрософт в настоящее время оценивает варианты и разрабатывает подходы к восстановлению, которые обеспечивают удобство и безопасность при уважении конфиденциальности и самоуверенности пользователя.
Как пользователь может доверять запросу от издателя или проверяющего? Как они узнают, что децентрализованный идентификатор (DID) действительно является идентификатором DID для организации?
Проверенный идентификатор реализует общеизвестную спецификацию конфигурации DID Фонда децентрализованных удостоверений, чтобы подключить ДИД к высокоизвестной существующей системе, доменным именам. Каждый DID, созданный с помощью Microsoft Entra Verified ID, имеет возможность включить корневое доменное имя, закодированное в документе DID. Чтобы узнать больше о связанных доменах, следуйте инструкциям из статьи " Связать домен с распределенным идентификатором ".
Каковы ограничения размера проверяемых учетных данных в проверенном идентификаторе?
- Для запроса на выдачу — 1 МБ.
- Фотография в проверяемом удостоверении — 1 МБ.
- Результат обратного вызова — 10 МБ без квитанции.
Каковы требования к лицензированию?
Нет специальных требований к лицензированию для выдачи удостоверяемых учетных данных.
Как сбросить службу Проверенные учетные данные Microsoft Entra?
Перезагрузка требует, чтобы вы отказались от службы Microsoft Entra Verified ID и затем снова присоединились к ней. Ваша существующая конфигурация проверяемых учетных данных сбрасывается, и клиент получает новую версию DID для использования во время выдачи и презентации.
- Следуйте инструкциям об отказе.
- Просмотрите шаги по развертыванию Проверенного идентификатора Microsoft Entra для перенастройки службы.
- Если вы настраиваете проверенный идентификатор вручную, выберите расположение для Azure Key Vault, который будет находиться в одном или ближайшем регионе. Выбор одного региона позволяет избежать проблем с производительностью и задержкой.
- Завершите настройку вашей службы проверяемых удостоверений. Необходимо повторно создать ваши учётные данные.
- Также необходимо выдать новые удостоверения, так как ваш арендатор теперь имеет новый DID.
Как проверить регион клиента Microsoft Entra?
На портале Azure откройте Microsoft Entra ID для подписки, используемой для развертывания проверенного идентификатора Microsoft Entra.
В разделе Управление выберите Свойства.
См. значение для страны или региона. Если значение является страной или регионом Европы, ваша служба Microsoft Entra Verified ID настроена в Европе.
Поддерживает ли Microsoft Entra Verified ID ION как метод DID?
Проверенный идентификатор поддерживает метод DID:ION в предварительной версии до декабря 2023 года.
Как перейти от did:ion к did:web?
Если вы хотите перейти от did:web к did:ion, вы можете выполнить следующие шаги, используя Admin API. Для изменения полномочий требуется повторное выпуск всех учетных данных.
Экспорт существующих did:ion определений учетных данных
- Для
did:ionавторитета используйте портал для копирования всех определений отображения и правил существующих учетных данных. - Если у вас есть более одного органа, необходимо использовать API администрирования, если
did:ionорган не является органом по умолчанию. В арендаторе проверенного идентификатора подключитесь с помощью Admin API, перечислите полномочия, чтобы получить идентификатор полномочий дляdid:ionполномочия. Затем используйте API контрактов списка, чтобы экспортировать их и сохранить результат в файл, чтобы их можно было воссоздать.
Создание нового did:web authority
- Используя встроенный API, создайте новый
did:webорган власти. В качестве альтернативы, если у вашего арендатора есть только одноdid:ionполномочие, вы также можете выполнить отказ от услуги, за которым следует выполнение включения услуги, чтобы перезапустить с проверенными конфигурациями идентификаторов. В этом случае можно выбрать вариант быстрого и ручного настройки. - Если вы настраиваете did:web-авторитет с помощью API администрирования, необходимо вызвать генерацию документа DID для создания вашего документа DID и затем вызвать генерацию хорошо известного документа, после чего загрузить JSON-файлы в соответствующий хорошо известный путь.
Повторное создание определений учетных данных
При создании нового did:web уполномоченного органа необходимо повторно создать определения полномочий. Вы можете сделать это либо через портал, если вы вышли из системы и затем вновь подключились, либо вам необходимо использовать API создания контракта для их повторного создания.
Обновление существующих приложений
- Обновите любое из ваших существующих приложений (приложений-издателей или приложений-проверяющих), чтобы использовать новое
did:web authority. Для приложений выдачи также обновите URL-адрес манифеста учетных данных. - Тестовые потоки выдачи и проверки из нового веб-центра. После успешного выполнения тестов перейдите к следующему шагу для
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
Независимо от того, какой язык образца вы используете, в качестве общедоступной конечной точки используется имя хоста Azure AppService https://something.azurewebsites.net. Чтобы заставить его работать, ничего больше настраивать не требуется. В случае изменений в коде или конфигурации необходимо повторно развернуть пример в Службах приложений Azure. Устранение неполадок и отладка не так просты, как запуск примера на вашей локальной машине, где трассировки в окне консоли отображают ошибки. Однако вы можете добиться почти того же, используя поток журналов.
Защита сети для событий обратного вызова
API службы запросов использует обратные вызовы к URL-адресу , предоставленному приложением проверяющей стороны. Этот URL-адрес должен быть доступен из системы проверенных идентификаторов для получения обратных вызовов. Обратные вызовы приходят из инфраструктуры Azure в том же регионе, что и клиент Microsoft Entra. Если вам нужно ужесточить сеть, у вас есть два варианта.
- Используйте теги службы брандмауэра Azure Azure и AzureCloud.
- Используйте опубликованный диапазон CIDR для настройки брандмауэра. Чтобы настроить брандмауэр и разрешить обратный трафик от API службы запросов, необходимо использовать регионы AzureCloud, соответствующие региону, где развернут клиент Microsoft Entra. Например, если клиент находится в ЕС, следует выбрать все диапазоны CIDR из AzureCloud. northeurope и westeurope в конфигурации брандмауэра.
Сканирование QR-кода
В документации инструкция scan the QR code ссылается на сканирование с помощью мобильного приложения Microsoft Authenticator, если иное не указано.
Вы можете сканировать QR-код с помощью приложения камеры мобильного устройства, которое затем запускает Microsoft Authenticator. Для этого обработчик протокола openid-vc:// должен быть зарегистрирован для Microsoft Authenticator. Если для этого зарегистрировано другое мобильное приложение, приложение Authenticator не откроется.
На мобильных телефонах Android известные проблемы сканирования QR-кода:
- В Android 9 и более ранних версиях сканирование QR-кода с помощью приложения камеры не работает, и нет другого обходного решения, кроме использования приложения Microsoft Authenticator для сканирования.
- На телефонах Android с рабочими и личными профилями каждый профиль имеет собственный экземпляр приложения Microsoft Authenticator. Если у вас есть учетные данные в приложении Authenticator рабочего профиля, и вы попробуете отсканировать QR-код с помощью приложения камеры из личного профиля, откроется личное приложение Authenticator. Это приводит к ошибке, так как учетные данные находятся в рабочем профиле, а не в личном. Сообщение об ошибке говорит: "Вам придется добавить этот проверенный идентификатор и повторить попытку".