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

На этой странице даны ответы на часто задаваемые вопросы об интеграции с Google Wallet для цифровой идентификации и учета данных.

Регистрация и начало работы

В: Каков пошаговый процесс регистрации нового партнера в качестве зависимой стороны (Relying Party, RP)?

A: См. инструкции по применению идентификаторов из онлайн-кошелька .

В: Какова типичная продолжительность процесса адаптации в RP?

А: Как правило, процесс адаптации занимает 3-5 рабочих дней.

В: Как мы можем отслеживать статус нашей заявки от проверяющей стороны (RP) после ее подачи?

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

В: Где можно найти форму регистрации в RP и официальную документацию для разработчиков?

А:

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

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

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

А: Нет, принятие Условий предоставления услуг не является обязательным шагом для тестирования.

В: Где можно найти эталонную реализацию, примеры кода или демонстрационное приложение для начала работы?

А:

Регистраторы-верификаторы

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

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

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

A: См. инструкции по адресу: Руководство для регистратора верификаторов .

В: Чем это отличается от прямой интеграции с RP?

A: Регистраторы-верификаторы управляют доверительными отношениями для своих клиентов и занимаются интеграцией с Google Wallet от их имени, в то время как прямые регистраторы-верификаторы управляют собственной конфигурацией с Google.

В: Кто получает разрешение в конфигурации Google на доступ к данным регистратора-верификатора: сам регистратор-верификатор, конечный регистратор-верификатор или оба?

A: Google добавляет корневой сертификат центра сертификации регистратора-верификатора в список разрешенных. Затем регистратор-верификатор выдает новые конечные сертификаты для каждого последующего конечного участника.

В: Как происходит обмен данными между конечным RP, регистратором-верификатором и Google Wallet?

A: Регистратор-верификатор отправляет API-запрос в Google Wallet для конечного RP. Google Wallet возвращает зашифрованные данные учетных данных регистратору-верификатору, который затем обрабатывает их и отправляет окончательный сигнал конечному RP.

А: Нет. Регистратор-верификатор может по своему усмотрению не отображать свои данные.

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

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

В: Можно ли использовать промежуточные сертификаты подписи между корневым центром сертификации (Root CA) и конечными сертификатами ответственного за передачу данных (RP)?

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

В: Каков требуемый срок действия сертификатов?

A: 10-летний срок действия корневого сертификата центра сертификации вполне приемлем. Срок действия конечных сертификатов центра сертификации обычно составляет около года, чтобы обеспечить их эффективную ротацию в случае возникновения проблем.

В: Нужно ли нам управлять отдельным сертификатом доступа для каждого отдельного клиента-доверителя (RP)?

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

В: Могут ли партнеры одновременно иметь несколько действующих сертификатов?

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

В: Как следует оформить почетное имя (тему)?

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

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

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

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

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

В: Что нам нужно предоставить, чтобы начать тестирование в тестовой среде (Sandbox)?

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

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

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

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

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

Техническая интеграция и API

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

A: Основной протокол — OpenID для проверяемых презентаций (OpenID4VP) версии 1.0.

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

А: Google поддерживает Приложение D [в настоящее время находится в стадии проекта] (OpenID4VP с использованием API DC).

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

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

В: Позволяет ли API запрашивать общие учетные данные без перечисления всех возможных типов учетных данных?

А: Нет.

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

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

В: Каковы требования к нашей инфраструктуре PKI?

A: Для подписания запросов участникам процесса требуется инфраструктура открытых ключей (PKI). Регистраторы-верификаторы выступают в качестве собственных центров сертификации.

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

A: Регистраторам сертификатов (RP) необходим новый сертификат, подписанный Google или регистратором-верификатором. В случае с регистраторами-верификаторами Google будет доверять вашему корневому сертификату, если вы выполните шаги по установлению доверия, описанные в документации.

A: Весь запрос должен генерироваться на стороне сервера. На Android используйте API Credman; в веб-версии — API цифровых учетных данных (DC).

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

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

Учетные данные и информация

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

A: Список поддерживаемых регионов можно найти здесь: Поддерживаемые эмитенты и сертификаты .

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

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

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

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

В: Какие учетные данные, если таковые имеются, хранит Google на своих серверах, особенно в контексте GDPR?

A: Google не сохраняет данные, связанные с учетными данными, на своих серверах; они хранятся локально и в безопасном месте на устройстве пользователя.

Тестирование и среды

В: Как получить доступ к тестовой среде (песочнице) для проверки всего сквозного процесса?

A: Песочница открыта в режиме песочницы .

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

A: Отправьте адреса Gmail тестовых кошельков по электронной почте на адрес wallet-identity-rp-support@google.com .

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

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

Пользовательский опыт (UX)

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

A: Пользователи без приложения перенаправляются в Play Store. Те, у кого нет учетной записи, могут создать ее, используя интерфейс, занимающий половину экрана.

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

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

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

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

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

Безопасность и соответствие нормативным требованиям

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

А: Да, могут действовать ограничения, подробности см. в наших условиях предоставления услуг.

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

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

Расширенные возможности и план развития

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

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

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

A: Участники программы должны внедрить сервисы проверки ZK для запроса последних доступных каналов связи.

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

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

Другие

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

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

В: Как обрабатывается отзыв mDL? Это происходит в режиме реального времени?

A: Инициирование может осуществляться пользователем или эмитентом (DMV). Если устройство подключено к сети, инициирование происходит в режиме реального времени; в противном случае, кратковременные объекты безопасности (MSO) истекают.

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

А: Рекомендуется ежегодная ротация.

В: Какая минимальная версия Android поддерживается для API цифровых учетных данных?

A: Android 9 (уровень API 28) и выше.

В: Какая минимальная версия Chrome поддерживает API цифровых учетных данных?

A: Chrome версии 128 и выше.

В: Какие браузеры поддерживают API цифровых учетных данных?

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

В: Какие пользователи смогут добавить идентификатор при запуске новой страны?

A: Доступ предоставляется в зависимости от страны, указанной пользователем в Play Store.

В: Работает ли API цифровых учетных данных с iOS?

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