AP2 over A2A: extension activation, data keys and roles

What this experiment demonstrates

Tanishka's shopping agent buys three books from the Belgavi's Book Store merchant agent and gets a payment token from a credentials provider agent. Four exchanges carry AP2 mandates: an IntentMandate message to the merchant, a CartMandate artifact back, and a PaymentMandate message to the credentials provider and then to the merchant. Each mandate sits in an A2A data part under a key such as ap2.mandates.PaymentMandate.

Shapes follow the AP2 v0.1 A2A extension profile and models; activation follows the AP2 samples, which use the X-A2A-Extensions header with A2A protocol 0.3.0. It is a deterministic model of the decisions each agent makes. It checks structure and whether merchant_authorization is present; no signature is verified and no agent is called.

Run controlled comparisons

Start with the defaults: four messages sent, four accepted under an activated extension, and the order placed.

Now change one thing at a time. Untick the activation header: the merchant marks AP2 required, so message 1 is rejected with the -32008 style error and nothing else is sent. Also untick required: the receivers still refuse the data part. Also untick receiver enforcement: all four messages are accepted and four mandates are processed without the extension activated. Back at the defaults, untick merchant_authorization: the shopping agent refuses the cart at message 2; also untick the signature check and one unsigned cart is accepted and the order is placed. Set the merchant roles to shopper: the flow stops at discovery; untick client validation and one cart is accepted from a non-merchant peer. Choose the unprefixed PaymentMandate key or the v0.2 sample key: message 3 is rejected with the key named and the order is not placed. Untick credentials provider support: no activation echo, so the shopping agent stops at message 3; without client validation the mandate is handed over as opaque data, one mandate processed without the extension. Untick the merchant declaration with client validation off: three mandates are processed without the extension.

Inspect the trace and keep evidence

The table lists each exchange with sender, receiver, A2A object, data key, whether AP2 was activated, the result and the reason. The trace shows the agent card entry, every request and its activation header, and each decision. Start trace, Next step, Show all and the slider control how much of the trace is visible; the metrics always describe the whole run. Reset restores the defaults and Export JSON downloads the inputs, metrics and trace.

Limits and production translation

Real deployments verify JWT signatures and expiries, check that the PaymentMandate references the signed cart, may use AP2 v0.2 SD-JWT mandates under different keys, and may speak A2A 1.0, where the header is A2A-Extensions and parts have no kind field. The extension URI itself differs between the v0.1 document and the sample code, so peers must agree on one exact string. What carries over: declare the extension with roles, activate it per request and read the echo, refuse mandate data parts outside an activated extension, match keys exactly, check the sender role, and never show or pay for a cart without a verified merchant signature.