Часто задаваемые вопросы о цифровых удостоверениях личности и документах

Как новому партнеру стать доверяющей стороной?

Ознакомьтесь с пошаговым руководством Выберите свой путь.

Сколько времени обычно занимает регистрация проверяющей стороны?

Обычно регистрация занимает 3–5 рабочих дней.

Как отслеживать статус заявки на регистрацию в качестве полагающейся стороны?

Если вы не получили ответ в течение пяти дней, обратитесь в службу поддержки по адресу wallet-identity-rp-support@google.com.

Где найти форму регистрации проверяющей стороны и официальную документацию для разработчиков?

Ответ.

• Форма регистрации: Google Wallet Identity Relying Partners Contact Form
• Документация для разработчиков: обзор цифровых удостоверений личности

Как предоставленная информация (например, название товара и логотип) будет использоваться в продукте?

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

Нужно ли принимать Условия использования, если мы планируем использовать только тестовую среду для разработки и тестирования?

Нет, принимать Условия использования для тестирования не требуется.

Где найти пример реализации, образец кода или демоприложение, чтобы начать работу?

Ответ.

• Репозиторий GitHub: Identity Reference Implementation.
• Тестовый сайт: verifier.multipaz.org.

Что такое реестр верификаторов и как он работает?

Регистратор верификаторов действует как центр сертификации, который подключает дочерних клиентов (конечных проверяющих сторон). Конечная полагающаяся сторона не взаимодействует с Google Кошельком напрямую.

Как проходит регистрация регистратора-верификатора и его клиентов?

О: Ознакомьтесь с инструкциями в руководстве для регистраторов верификаторов.

Чем это отличается от прямой интеграции с поставщиком услуг по возврату?

О. Регистраторы верификаторов управляют доверительными отношениями для своих клиентов и от их имени выполняют интеграцию с Google Кошельком, а прямые проверяющие стороны самостоятельно управляют своей конфигурацией с Google.

В: Кого нужно добавить в белый список в конфигурации Google: регистратора верификаторов, конечную проверяющую сторону или обоих?

Google добавляет в белый список корневой сертификат ЦС регистратора верификаторов. Затем регистратор верификатора выдает новые сертификаты конечного субъекта для каждой последующей конечной проверяющей стороны.

Как данные передаются между конечной полагающейся стороной, регистратором проверяющих сторон и Google Кошельком?

Регистратор верификаторов отправляет запрос к API в Google Кошелек от имени конечной полагающейся стороны. Google Кошелек возвращает зашифрованные данные удостоверения регистратору проверяющего, который обрабатывает их и отправляет конечный сигнал конечной проверяющей стороне.

В: Нужно ли в решениях, продаваемых под брендом покупателя, показывать название регистратора верификаторов в процессе получения согласия пользователя или можно ограничиться названием конечной полагающейся стороны?

Нет. Регистратор может скрыть свои данные.

Какие типы ключей и кривые разрешены для корневых центров сертификации и сертификатов проверяющей стороны?

Сертификаты должны быть сгенерированы с использованием P-256/ECDSA.

Можно ли использовать промежуточные сертификаты подписи между корневым ЦС и сертификатами конечного субъекта проверяющей стороны?

Да. Вы можете безопасно хранить долгосрочный корневой сертификат (например, в HSM), чтобы время от времени подписывать операционные промежуточные сертификаты. Эти промежуточные сертификаты можно использовать для подписания сертификатов конечного субъекта проверяющей стороны, что упрощает ротацию в случае нарушения безопасности без влияния на корневой сертификат.

Какой срок действия должен быть у сертификатов?

Для корневого сертификата ЦС срок действия 10 лет вполне приемлем. Сертификаты конечных субъектов для конечных платформ проверяющей стороны обычно обновляются раз в год, чтобы их можно было эффективно заменять в случае проблем.

Нужно ли управлять отдельным сертификатом конечного субъекта для каждого клиента, являющегося полагающейся стороной?

Да. На начальном этапе агрегаторы должны управлять отдельными сертификатами для каждой последующей проверяющей стороны. Это позволяет настраивать отображение для каждой проверяющей стороны и точно отслеживать злоупотребления. Хотя это увеличивает операционные расходы, мы планируем рассмотреть возможные альтернативы (например, использование хешей метаданных проверяющей стороны) после первоначального развертывания.

Может ли у партнера быть несколько активных сертификатов одновременно?

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

Как должно быть отформатировано уникальное имя (тема)?

Уникальное имя должно быть глобально уникальным для каждого партнера. Это статический идентификатор, который Google использует для отслеживания входящих запросов партнеров и обеспечения доверия к экосистеме.

Как работает привязка домена? Нужно ли встраивать источники в сертификат?

Домены не обязательно должны быть встроены непосредственно в сертификат. Вместо этого домен подтверждается с помощью параметра expected origins в вызове API. Кроме того, с одним сертификатом можно связать несколько доменов. Для неподписанных запросов привязка выполняется с помощью домена или названия пакета приложения, а также цифрового отпечатка.

Можно ли не указывать сведения об агрегаторе в интерфейсе проверки для белой этикетки?

Да, информация об агрегаторе (например, название, логотип, URL и политика конфиденциальности) в метаданных верификатора необязательна. Это позволяет создать решение, в котором пользователю будут видны только данные конечной проверяющей стороны.

В: Что нужно предоставить, чтобы начать тестирование в изолированной среде?

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

Чем процесс регистрации для регистраторов верификаторов (агрегаторов) отличается от процесса для прямых проверяющих сторон?

Для агрегаторов предусмотрен немного другой процесс. После принятия Условий использования для регистраторов верификаторов процесс регистрации делится на две части: заполнение основной формы для подтверждения статуса регистратора верификаторов и заполнение упрощенной формы для каждого проверяющего лица, которое вы регистрируете. Обычно для каждой заявки требуется видеозапись интеграции, а проверка занимает 2–3 рабочих дня.

Можно ли регистрировать клиентов, которые намерены выступать в качестве посредников или перепродавать услуги по проверке другим организациям?

Нет. Google предпочитает работать напрямую с регистраторами верификаторов (агрегаторами) и их непосредственными конечными проверяющими сторонами, а не поддерживать вложенные модели реселлеров или посредников.

Какой протокол используется для запросов? Какие версии поддерживаются?

Основной протокол – OpenID for Verifiable Presentations (OpenID4VP) версии 1.0.

Какие приложения ISO 18013-7 (например, B, C, D) поддерживает Google для предъявления mDL?

Google поддерживает приложение D (в настоящее время в черновом варианте) (OpenID4VP с использованием DC API).

Как правильно составить запрос к API, чтобы получить несколько учетных данных в одном представлении пользователя?

Оба типа учетных данных должны запрашиваться в одном объекте запроса dcql в одном запросе JSON.

Можно ли с помощью API запросить общие учетные данные, не перечисляя все возможные типы?

Нет.

Как API обрабатывает подтверждение возраста? Можно ли запрашивать точную дату рождения или только подтверждение того, что пользователь старше определенного возраста?

Поддерживаются оба варианта. Вы можете запросить birth_date, age_in_years или сигнал "старше X лет", обеспечивающий конфиденциальность. Доказательства с нулевым разглашением (ZKP) также можно использовать для сигнала "истина/ложь".

Какие требования предъявляются к инфраструктуре открытых ключей?

О: Для подписания запросов RP требуется PKI. Регистраторы, выполняющие проверку, действуют как собственный ЦС.

Можно ли использовать существующие сертификаты или нужно получить новые, подписанные Google?

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

В: Какова рекомендуемая стратегия интеграции для веб-приложения и для приложения Android?

Запрос должен полностью генерироваться на стороне сервера. На Android используйте Credman API, а в интернете – Digital Credentials (DC) API.

Какие инструменты отладки, ведения журналов и наблюдения доступны разработчикам?

Партнеры могут использовать псевдоним службы поддержки wallet-identity-rp-support@google.com. Специальные инструменты для ведения журналов и наблюдения не предоставляются.

Какие цифровые удостоверения личности, эмитенты и учетные данные поддерживаются в разных странах и регионах?

Ознакомьтесь со списком поддерживаемых поставщиков и сертификатов.

Когда вы планируете добавить поддержку удостоверений из других стран или регионов?

Мы активно добавляем новые регионы. Следите за обновлениями на странице со списком поддерживаемых эмитентов.

Получает ли конечный пользователь уведомление, когда эмитент обновляет учетные данные?

Да, пользователь получит уведомление, и обновление будет применено автоматически.

Как получить доступ к тестовой среде, чтобы проверить весь процесс от начала до конца?

О: Песочница доступна по адресу Sandbox Mode.

В: Какова процедура добавления партнеров, не находящихся в официально запущенном регионе, в список разрешенных для тестирования?

Ответ. Отправьте идентификаторы Gmail тестовых кошельков на адрес wallet-identity-rp-support@google.com.

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

Партнеры должны пройти стандартную процедуру регистрации в программе рекомендуемых партнеров, в том числе предоставить видеодемонстрацию в тестовой среде.

Что произойдет, если у пользователя нет цифрового удостоверения личности или приложения "Google Кошелек", когда он начнет процесс подтверждения?

Если приложение не установлено, пользователи попадают в Google Play. Если у пользователя нет удостоверения личности, он может создать его в полуэкранном интерфейсе.

Можно ли программно определить, есть ли у пользователя цифровое удостоверение личности в Кошельке, прежде чем показывать ему вариант подтверждения?

Нет. Чтобы защитить конфиденциальность, API должен вызываться пользователем.

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

О. Аутентификация пользователя (биометрическая, PIN-код или графический ключ) требуется по умолчанию и не может быть отключена.

Можно ли настроить порядок запрашиваемых атрибутов в окне запроса согласия пользователя?

А: Нет, Google Кошелек переупорядочивает их по алфавиту.

В. Наш сценарий использования предполагает передачу пользовательских данных третьим лицам. Разрешено ли это Условиями использования?

Да, могут действовать ограничения. Подробную информацию вы найдете в Условиях использования.

Какие документы о безопасности, надежности и доступности решений для цифровой идентификации доступны для проверки соответствия требованиям?

Партнеры могут ознакомиться с отчетами Trail of Bits о проверках безопасности.

Какие возможности есть у доказательств с нулевым разглашением (ZKP) для подтверждения возраста с обеспечением конфиденциальности?

Доказательство с нулевым разглашением (ZKP) – это криптографический метод, который позволяет пользователю (доказывающему) подтвердить проверяющему, что он обладает определенной информацией, удостоверяющей личность, или соответствует определенному критерию (например, ему больше 18 лет или у него есть действительное удостоверение личности), не раскрывая при этом сами данные.

Как обрабатываются разные версии схем ZK?

О: Полагающиеся стороны должны внедрить сервисы проверки ZK, чтобы запрашивать последние доступные схемы.

Как работает обмен учетными данными и управление ими на нескольких устройствах, например на телефоне и носимом устройстве?

Учетные данные предоставляются для одного устройства и не могут быть переданы другим пользователям.

Как Google обрабатывает отзыв удостоверения личности, если паспорт был отозван?

О: Пользователи могут удалять пропуска в настройках аккаунта Google. Если устройство потеряно, можно сообщить об этом, чтобы отозвать учетные данные.

Как обрабатывается отзыв mDL? Обновляются ли данные в реальном времени?

О: Это может сделать как пользователь, так и эмитент (департамент транспортных средств). Если устройство подключено к интернету, это происходит в реальном времени. В противном случае срок действия объектов безопасности с коротким сроком действия (MSO) истечет.

В. Каковы правила ротации ключей для проверяющих сторон?

О. Рекомендуется менять ключи ежегодно.

Какая минимальная версия Android поддерживается для Digital Credentials API?

Android 9 (уровень API 28) и более поздние версии.

Какая минимальная версия Chrome поддерживает Digital Credentials API?

Chrome 128 и более поздних версий.

Какие браузеры поддерживают Digital Credentials API?

О: Информацию о поддержке браузеров можно найти на странице https://digitalcredentials.dev/ecosystem-support.

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

Доступ зависит от страны, указанной в настройках Google Play.

Работает ли Digital Credentials API на iOS?

Да, API работает в поддерживаемых браузерах, например Safari. Однако OpenID4VP не поддерживается Apple.