Обзор

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

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

Как эмитент, вы несете ответственность за создание и управление этими ресурсами на протяжении всего жизненного цикла ЦОД.

Предположения

Основное предположение этого API заключается в использовании API учетных данных Android Identity устройством для хранения контроллеров домена, определенных в стандарте ISO/IEC 18013-5 .

Примечание: любой метод, ссылающийся на MobileDriversLicense , специфичен для mDL. Остальные методы не зависят от типа документа.

Модели ресурсов

Устройство

В модели API предоставления цифровых учётных данных устройство представляет собой не просто устройство на базе Android, где пользователь управляет своим контроллером домена через приложение Google Wallet. Вместо этого оно представлено как комбинация следующих компонентов:

• Физическое устройство на базе Android.
• Пара открытого и закрытого ключей (называемая «ключом идентификации»).
  • Открытый ключ используется эмитентом для проверки подлинности устройства.
  • Закрытый ключ хранится в защищенном хранилище устройства.

При выполнении вызовов API комбинация устройства и учетных данных идентифицируется с помощью идентификатора устройства (свойство deviceReferenceId ).

Примечание: Идентификатор устройства не совпадает с идентификатором устройства или ANDROID_ID . Две разные учётные записи на одном и том же физическом устройстве будут иметь разные ключи идентификации и идентификаторы устройств.

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

Дополнительную информацию о сертификате см. в документации Android IdentityCredential .

Если смоделировать этот ресурс как таблицу базы данных, он будет выглядеть примерно так. Обратите внимание, что свойство identityKey будет значением открытого ключа.

Расстойка

Расстойка представляет собой комбинацию следующих факторов:

• Доказательства, предоставленные пользователем для подтверждения своей личности
• Решение, принятое Эмитентом с учетом представленных доказательств

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

Возможные статусы проверки приведены в следующей таблице.

Статус	Описание	Конечное состояние
В ожидании	Эмитент еще не принял решения.	Нет
Принял	Эмитент решил, что доказательства являются удовлетворительными.	Нет
Отклоненный	Эмитент решил, что представленные доказательства неудовлетворительны.	Да*
Вызов	Эмитенту требуется больше информации для принятия решения.	Нет
Отменено	Пользователь отменил проверку.	Да
Отозвано	Эмитент отозвал проверку.	Да*
Истекший	Пользователь не выполнил задание вовремя.	Да

Статусы, отмеченные звездочкой ( * ), могут быть неокончательными в случаях, когда рецензент-человек допускает ошибку и обновляет статус вручную.

Следующая диаграмма состояний описывает возможные потоки состояний:

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

Если смоделировать этот ресурс как таблицу базы данных, она будет выглядеть примерно так.

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

Учетные данные

Учётные данные представляют собой виртуальную версию физических учётных данных для конкретного устройства. Каждый раз, когда виртуальные учётные данные предоставляются физическому устройству, им присваивается идентификатор учётных данных. Если одни и те же физические учётные данные предоставляются разным устройствам, они каждый раз будут иметь разные идентификаторы. Аналогично, если учётные данные были предоставлены устройству, удалены и снова предоставлены тому же устройству, они будут иметь другие идентификаторы учётных данных.

При изменении данных учётной записи пользователя (например, при изменении адреса в документе, удостоверяющем личность) эти данные должны быть обновлены для всех связанных виртуальных учётных записей. У одной и той же учётной записи могут быть разные версии, соответствующие таким изменениям. Текущая версия отслеживается с помощью идентификатора версии учётной записи.

Примечание: Идентификатор учётной записи не меняется на протяжении всего жизненного цикла. Однако идентификатор версии учётной записи может измениться.

Чтобы предоставить учётные данные проверяющей стороне, устройство должно сначала получить мобильные объекты безопасности (MSO) от эмитента. MSO содержит дайджесты учётных данных, подписанные эмитентом. MSO создаётся на основе ключа авторизации — открытого ключа, сгенерированного и подписанного ключом идентификации устройства. Ключ авторизации фактически привязывает MSO к устройству. Сочетание MSO и учётных данных подтверждает проверяющим сторонам, что учётные данные исходят от эмитента.

Примечание: MSO удаляются после использования. Устройства поддерживают пул MSO, обновляя его по мере необходимости.

После предоставления учётных данных устройству оно должно отправить объект ProofOfProvisioning обратно эмитенту. Это уведомляет эмитента о том, что учётные данные успешно предоставлены устройству и сохранены в защищённом хранилище устройства.

Примечание: Как эмитент, вы не должны выпускать MSO для учётных данных, пока не получите ProofOfProvisioning для этих учётных данных. Это также относится к обновлениям учётных данных.

Учетные данные могут иметь следующие статусы:

Статус	Описание
Положение в ожидании	Учётные данные были переведены в Google Wallet, но подтверждение их предоставления эмитенту не было возвращено. Учётные данные получают этот статус каждый раз при изменении идентификатора версии учётных данных. Ни один MSO не будет выдан по этой учетной записи.
Активный	Учетные данные были переданы в Google Wallet, а подтверждение предоставления было возвращено эмитенту. MSOs доступны для получения полномочий.
Отозвано	Эмитент окончательно отозвал учетные данные. Ни один MSO не будет выдан по этой учетной записи. В этом состоянии Google Wallet не предоставит учетные данные.
Удалено	Пользователь или Google Wallet навсегда удалили учетные данные с устройства. Ни один MSO не будет выдан по этой учетной записи. В этом состоянии Google Wallet не предоставит учетные данные.

Следующая диаграмма состояний описывает возможные потоки состояний:

Если смоделировать этот ресурс как таблицу базы данных, она будет выглядеть примерно так.

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