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

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

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

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

Обычно регистрация занимает 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. Кроме того, с одним сертификатом можно связать несколько доменов. Для неподписанных запросов привязка выполняется с помощью домена или названия пакета приложения, а также цифрового отпечатка.

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

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

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

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

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

А: Агрегаторы проходят несколько модифицированный процесс. После принятия Условий использования регистратора верификаторов процесс регистрации делится на две части: заполнение основной формы для подтверждения статуса регистратора верификаторов и заполнение упрощенной формы для каждого подключаемого RP. Обычно для каждой заявки требуется видеозапись интеграции, а проверка занимает 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 будет доверять вашему корневому сертификату, если вы выполните шаги, описанные в разделе Trust Establishment (Установление доверия) документации.

Какую стратегию интеграции рекомендуется использовать для сайтов и приложений 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?

RP должны внедрить сервисы верификации ZK, чтобы запрашивать последние доступные схемы.

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

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

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

A: Пользователи могут удалять пароли из настроек учетной записи 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.