Мандаты AP2 v0.2: намерение пользователя, автономные покупки и управление стандартом в FIDO

Что это

Сведения актуальны на 25 октября 2026 года. Опубликованная спецификация AP2 обозначена как v0.2. Перед реализацией заново проверьте эту редакцию, её систему авторизации и последующие публикации FIDO. AP2 предоставляет подтверждение делегированного разрешения на покупку в рамках торгового протокола; он не определяет API каталога или обновления оформляемого заказа.

Терминология имеет значение. В спецификации v0.1.0 описывались Intent Mandate для разрешения действий в отсутствие пользователя, Cart Mandate для покупки, одобренной пользователем, и Payment Mandate для передачи сведений о платеже. В v0.2 есть два типа мандатов: Checkout и Payment. Каждый может быть открытым, задающим ограничения, или закрытым, разрешающим конкретную транзакцию. Не совмещайте старые примеры с текущими схемами без явно разработанного плана миграции.

Почему это важно

Checkout Mandate связывает одобрение с подписанными продавцом данными оформляемого заказа. Payment Mandate разрешает связанный с ним платёж. Так разные участники получают подтверждения, соответствующие их обязанностям, а основанием для списания не становится рассказ агента.

Система авторизации описывает проверяемые цифровые удостоверения на основе подписанных JSON-токенов с избирательным раскрытием данных — SD-JWT VCs. Подписи, привязка к ключу и проверка ограничений решают разные задачи. Одна лишь действительная подпись не подтверждает, что покупка укладывается в ограничения пользователя.

Описание управления стандартом тоже требует точных формулировок. 28 апреля 2026 года FIDO объявила о передаче AP2 компанией Google и его дальнейшем развитии в Payments Technical Working Group наряду с переданным Mastercard решением Verifiable Intent. Это объявление обозначает процесс разработки стандартов; оно не означает появления окончательной спецификации FIDO или сертификации какой-либо реализации.

Как применять

• Разделите обязанности. Определите участников в ролях Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor и Trusted Surface. AP2 требует, чтобы Trusted Surface не использовала агентную логику, а проверка выполнялась детерминированным кодом.
• Обеспечьте непосредственное одобрение. В описанном в документации сценарии с участием пользователя доверенный интерфейс показывает закрытые мандаты и получает согласие. Поставщик удостоверений проверяет разрешение на платёж; продавец проверяет разрешение на оформление заказа перед завершением транзакции.
• Обеспечьте предварительное делегирование. Для работы без участия пользователя тот одобряет открытые мандаты. Эти мандаты привязывают открытый ключ агента через cnf; позднее агент передаёт их вместе с подписанными им закрытыми мандатами. Задавайте узкие рамки разрешённых действий и подходящий срок действия.
• При неопределённости запрещайте операцию. Проверяйте цепочку мандатов, сохраняйте утверждения, зафиксированные открытыми мандатами, и проверяйте каждое ограничение. Система считает неизвестные ограничения основанием для отказа. unresolved_constraint может вернуть процесс к непосредственному одобрению пользователем; invalid_credential — окончательная ошибка проверки.
• Сохраняйте подтверждающие записи. В примерах сценариев возвращаются Checkout Receipts и Payment Receipts. На практике сохраняйте вместе с заказом ссылки на соответствующие мандаты и квитанции, ограничивая доступ к ним, чтобы при разбирательстве можно было восстановить ход одобрения.

Подводные камни

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