Протокол Платежей для Агентов (v0.2)

Agent Payments Protocol (AP2) предоставляет протокол для обеспечения безопасности платёжных транзакций, выполняемых агентами. Он использует модель авторизации агентов.

Настоящая спецификация описывает:

• Различные роли сущностей в рамках AP2.
• Обязанности по верификации для этих ролей.
• Checkout Mandate и квитанцию для обеспечения безопасности того, что приобретается.
• Связанный Payment Mandate и квитанцию для оплаты корзины.
• Использование мандатов в качестве доказательств при разрешении споров.

AP2 функционирует как функция безопасности в рамках Коммерческого Протокола. Детали Коммерческого Протокола (API каталогов, обновления корзины и т. д.) выходят за рамки AP2. AP2 разработан для совместимости с Universal Commerce Protocol (UCP).

Иллюстративные примеры приведены для сценариев Human Present и Human Not Present.

Роли

AP2 рассматривает пять ролей с различными обязанностями по обработке и верификации:

• Shopping Agent (SA) — Торговый агент: Выполняет поиск товаров, формирует корзину и осуществляет покупку.
• Credential Provider (CP) — Провайдер удостоверений: Источник платёжных удостоверений. Проверяет авторизацию агента на доступ к удостоверению и определяет его область действия.
• Merchant (M) — Продавец: Предоставляет и завершает оформление заказа. Проверяет, что агент одобрен для покупки данных товаров, и отвечает за целостность инвентаря, цен и скидок.
• Merchant Payment Processor (MPP) — Платёжный процессор продавца: Обрабатывает платежи. Проверяет, что платёжное удостоверение авторизовано для оплаты данной корзины.
• Trusted Surface (TS) — Доверенная поверхность: UI-интерфейс для получения информированного согласия пользователя перед созданием подписанного пользователем мандата.

Хотя AP2 определяет пять ролей, одна сущность может играть несколько (или все) ролей. В таком случае она принимает на себя все обязанности каждой роли.

Роли МОГУТ делегировать свои обязанности другой стороне.

Агентское vs Неагентское

Роль считается Агентской, когда:

• Коммуникация с ролью или от неё осуществляется недетерминированной LLM.

Роль считается Неагентской, когда:

• Коммуникация осуществляется детерминированным кодом, проверяющим подлинность и корректность.
• Никакая обработка не делегируется LLM.

МОГУТ быть агентскими или неагентскими: Merchant, Merchant Payment Processor, Credential Provider.

ДОЛЖНА быть неагентской: Trusted Surface.

Ожидается агентской: Shopping Agent.

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

AP2 исходит из того, что как минимум Shopping Agent является агентским.

Мандаты

Мандаты — основное средство авторизации агентов в AP2. См. Фреймворк авторизации агентов для общего описания.

AP2 определяет два типа мандатов: Checkout Mandate и Payment Mandate.

Содержимое мандатов формируется Торговым Агентом после определения задачи пользователя. Агент использует Доверенную Поверхность для получения подписанных мандатов.

Checkout Mandate (Мандат на оформление заказа)

Предоставляет Продавцу криптографическое доказательство того, что Торговый Агент авторизован на покупку сформированной корзины.

Продавец ДОЛЖЕН предоставить агенту подписанный продавцом JWT, содержащий корзину. Закрытый Checkout Mandate привязывается к этому JWT через криптографический хеш.

После принятия или отклонения мандата Продавец ДОЛЖЕН вернуть Checkout Receipt.

Версионирование мандатов

Каждый тип мандата AP2 идентифицирует свою схему с помощью атрибута vct. Значение vct включает числовой суффикс как номер версии схемы (например, mandate.payment.1, mandate.checkout.open.1).

Payment Mandate (Платёжный мандат)

Предоставляет Провайдеру Удостоверений, Сети и Платёжному Процессору Продавца криптографическое доказательство того, что Торговый Агент авторизован на оплату конкретной корзины.

Мандат привязывается к корзине через криптографический хеш Checkout JWT. Для предотвращения атак по радужным таблицам JWT ДОЛЖЕН быть подписан цифровой подписью (например, ECDSA), а не детерминированной (например, Ed25519).

После принятия или отклонения мандата Платёжный Процессор ДОЛЖЕН вернуть подписанный Payment Receipt агенту, Провайдеру Удостоверений и, возможно, Сетям.

Режимы работы

AP2 может работать в двух режимах:

• Human Present (Прямой): Пользователь непосредственно видит закрытую корзину и явно одобряет её и её оплату.
• Human Not Present (Автономный): Пользователь видит и одобряет набор ограничений на то, какая закрытая корзина и платёж соответствуют его намерению. Агент затем самостоятельно формирует и одобряет закрытые мандаты от имени пользователя.

Верификаторы мандатов всегда получают закрытые мандаты, независимо от режима. Разница только в способе верификации.

Прямой режим (Human Present)

Когда у Торгового Агента есть Checkout JWT от Продавца, он формирует содержимое мандатов и передаёт их на Доверенную Поверхность для отображения пользователю и подписания.

Получив мандаты, агент передаёт Payment Mandate Провайдеру Удостоверений для верификации. При успешной верификации агент получает платёжное удостоверение.

Платёжное удостоверение и Checkout Mandate передаются Продавцу, который верифицирует корзину и инициирует платёж.

Автономный режим (Human Not Present)

Когда Торговому Агенту необходимо действовать автономно, он создаёт открытые мандаты и получает их авторизацию на Доверенной Поверхности. Они ДОЛЖНЫ включать публичный ключ агента как атрибут cnf. Рекомендуется устанавливать exp на минимальное значение, достаточное для выполнения задачи.

После формирования подходящей корзины агент МОЖЕТ подписать закрытый мандат своим ключом вместо получения одобрения на Доверенной Поверхности. Затем он ДОЛЖЕН предоставить и открытый (подписанный пользователем), и закрытый (подписанный агентом) мандаты верифицирующим сторонам.

Агенты НЕ ДОЛЖНЫ предъявлять последующие открытые мандаты без получения квитанции об отклонении предыдущего — для предотвращения двойного расходования.

Доказательства при спорах

В случае спора Checkout Mandate и Receipt, а также Payment Mandate и Receipt могут быть объединены для создания неоспоримой картины транзакции.

Верификация

Продавец (Merchant)

ДОЛЖЕН получить Checkout Mandate от Торгового Агента перед завершением корзины:

• Обработать и проверить мандат согласно правилам верификации.
• Проверить, что хеш Checkout JWT совпадает со значением атрибута checkout_hash.
• Если включены открытые мандаты — проверить соответствие закрытой корзины ограничениям.

Провайдер Удостоверений и Сеть

ДОЛЖНЫ получить Payment Mandate от Торгового Агента перед выдачей платёжного удостоверения:

• Обработать и проверить мандат согласно правилам верификации.
• Если включены открытые мандаты — проверить соответствие закрытого мандата ограничениям.

Платёжный Процессор Продавца (MPP)

ДОЛЖЕН получить платёжное удостоверение от Продавца перед обработкой транзакции. ДОЛЖЕН проверить, что удостоверение имеет соответствующую область действия.

Разрешение споров

При верификации в момент спора:

• Checkout Mandate проверяется по правилам Продавца.
• Хеш checkout_jwt вычисляется независимо.
• Ссылка в Checkout Receipt должна совпадать с хешем закрытого мандата.
• Payment Mandate проверяется по правилам MPP.
• Ссылка в Payment Receipt должна совпадать с хешем закрытого платёжного мандата.

Точки расширения

AP2 предусматривает несколько точек расширения:

• Ограничения мандатов (Mandate Constraints): Для поддержки сложных автономных сценариев. Требуется: уникальный type, схема, алгоритм оценки.
• Объект корзины (Checkout Object): AP2 агностичен к содержимому Checkout JWT.
• Платёжный инструмент (Payment Instrument): AP2 агностичен к конкретному платёжному инструменту.
• Форматы VDC: AP2 специфицирует использование SD-JWT для защиты мандатов.