[AP2 specification clarification] Clarify the payment-credential recipient path and minimum security requirements

[zesttec]

Hi maintainers,

AP2’s Security and Privacy Considerations state that a Payment Credential or Token MUST ONLY be released to the Merchant after receipt and verification of a final Payment Mandate. ⁠Source

However, the main specification says that the Shopping Agent receives a payment credential and that the credential is then provided to the Merchant. ⁠Source The non-normative flows more explicitly show the Shopping Agent sending the token to the Merchant. ⁠Flow status ⁠Relay steps

These descriptions leave unclear whether the Shopping Agent receives a redeemable credential, relays an artifact usable only by the Merchant/MPP, or receives some other form of reference. Although the glossary allows a Payment Credential to be a credential, an instrument, or a reference to one, it does not resolve which artifact is used in these flows or who may redeem it. ⁠Glossary

AP2 already requires the MPP to verify that the credential is appropriately scoped to the Checkout, and gives inclusion of the Closed Payment Mandate as one possible method. ⁠Source

The remaining gap is that AP2 does not define or normatively reference a minimum cross-profile contract explaining:

• what artifact is returned after Payment Mandate verification;
• which party or endpoint may use it;
• how it carries or references the verified Checkout and Payment Mandate scope; and
• what credential-specific lifetime and replay protections apply.

Potential impact

AP2 explicitly treats the Shopping Agent as a potential attacker. ⁠Source

If an implementation returns a bearer-style or otherwise replayable credential to the Shopping Agent without equivalent payment-rail protections, routing it through the Agent could increase its exposure. Recipient and replay enforcement would then depend on implementation-specific behavior.

Suggested clarification and hardening

It would be good to clarify what artifact is transferred at each step and what “released to the Merchant” means.

If Shopping-Agent relay is permitted, AP2 should define or normatively reference requirements ensuring that the artifact:

1. is usable only by the intended Merchant/MPP;
2. is scoped to the verified Checkout and Payment Mandate;
3. has appropriate lifetime and replay or idempotency protection; and
4. is rejected when the required protections cannot be verified.

These properties may be supplied through token claims, sender-constraining, encryption, authenticated delivery, server-side state, or an external payment-rail profile with equivalent guarantees.

If direct CP-to-Merchant delivery is required, the main specification and flow examples should be updated accordingly.

Thanks for your work on AP2!

[zesttec]

I wonder if this is the preferred approach for spec hardening issues. If I have a few more specification security hardening notes to share, Is it OK to post them here? Or a different venue is preferred? I just wanted to check first so I don’t flood the discussion. Thx

[chopmob-cloud]

This is a real ambiguity, and the two statements reconcile once possession is separated from redemption. The Security Considerations line ("The Payment Credential/Token MUST ONLY be released to the Merchant upon the receipt and verification of a final Payment Mandate") and the Direct flow ("the Shopping Agent receives a payment credential" ... "then provided to the Merchant") only conflict if the artifact the Shopping Agent holds is bearer-redeemable. If it is not, routing it through the Shopping Agent is relay, not release, and both statements are true at once: the Merchant is the only party that can redeem, even though the Agent transports the artifact.

That reading is the one the threat model already forces. The spec states that when a role is agentic the Agent is a potential attacker and "additional tamper-evident mechanisms are needed", and the Shopping Agent is agentic by assumption. So an artifact whose possession alone confers redemption cannot pass through the Shopping Agent without contradicting the section that names it a potential attacker. The resolution is that the relayed artifact must confer no redemption capability on the relayer.

Most of the pieces to make that normative are already in the document, just not stated as one cross-profile contract:

1. The Credential Provider returns a credential only after verifying the Payment Mandate, so the credential is issued against a verified mandate.
2. The checkout_hash in the transaction_id "securely links the payment to the associated Checkout Mandate", which is the scope-binding primitive.
3. The Merchant Payment Processor MUST verify the credential is "appropriately scoped to the Checkout", and the spec offers "providing the Closed Payment Mandate inside the Payment Credential" as one way to do it. That same binding is what makes the artifact usable only in the context it was issued for.
4. The glossary already allows a Payment Credential to be "a credential or instrument (or reference to one)", which leaves room for the relayed form to be a scoped reference rather than a redeemable instrument.

What is missing is precisely the four properties in the issue, stated normatively for the relay case: usable only by the intended Merchant or MPP, scoped to the verified Checkout and Payment Mandate, lifetime and replay or idempotency bound, and rejected when those cannot be verified. Sender-constraining, encryption to the Merchant or MPP, server-side state, or an external payment-rail profile are all valid ways to supply them, so the spec would only need to require the properties and leave the mechanism open.

The single clarification that removes most of the ambiguity is a definition of what "released to the Merchant" means when the transport passes through an agentic role: that release is defined by who can redeem, not by who holds the bytes. With that stated, the Direct flow and the Security Considerations stop reading as a contradiction and start reading as the same requirement described at two levels.