Description
Thanks for publishing AP2 and for making the early design and samples available. I realize v0.1 is still at an early stage and that the current repository is positioned mainly as samples and demos. With that in mind, I wanted to raise what seems to be a protocol-completeness gap in the human-present flow: AP2 spec does not yet make fully clear which object is the final user-approved proof artifact, what must bind that approval to the cart and payment details, and what a verifier is expected to check. Because of that, two independent implementations could produce different approval artifacts and still believe they follow AP2. That would make issuer interpretation, merchant evidence, and dispute handling less consistent.
A concrete example is the relationship between the Cart Mandate and the PaymentMandate. In Section 4.1.1 of docs/specification.md, the Cart Mandate is described as the “foundational credential” for the human-present case and as being “cryptographically signed by the user.” Section 5.1 also says the user’s signed approval creates a cryptographically signed Cart Mandate. But the same Section 5.1 says the merchant signs the cart, and Section 7.1 Step 10 says the cart mandate is “first signed by the merchant entity.” Separately, Section 4.1.3 describes the PaymentMandate as a separate credential “bound to Cart/Intent mandate but containing separate information.” So the main question is still unclear: in the human-present flow, does final user approval live on CartMandate, on PaymentMandate, or on both together?
The current implementation does not make that answer much clearer. In src/ap2/types/mandate.py, the split between CartMandate and PaymentMandate still leaves it unclear where final user approval is meant to live. In the Python human-present flow, samples/python/src/roles/shopping_agent/tools.py uses a placeholder user_authorization, and samples/python/src/common/validation.py only checks that the field is present. That is understandable for an early v0.1 demo, but it also means the implementation does not yet show a complete and reproducible approval chain that external AP2 implementers can follow consistently.
I think that is the core gap. Section 4.1.3 also says AI-agent presence and transaction modality signals must always be shared, but the current model does not make the full human-present approval chain easy to read and verify from the canonical objects alone. Right now, too much of that chain still lives in prose.
Potential hardening improvements
- Spec can state explicitly where final user approval lives in the human-present flow:
CartMandate, PaymentMandate, or both.
- Define the required bindings between the approved cart, the payment details, and the modality / agent-presence signals.
- Document one canonical verifier procedure that merchants, processors, issuers, and dispute systems can all follow.
I think this is mainly a protocol-completeness issue, and clarifying it would likely make independent AP2 implementations easier to align. I hope this is useful, and thanks again for publishing AP2 and sharing the work.
Description
Thanks for publishing AP2 and for making the early design and samples available. I realize v0.1 is still at an early stage and that the current repository is positioned mainly as samples and demos. With that in mind, I wanted to raise what seems to be a protocol-completeness gap in the human-present flow: AP2 spec does not yet make fully clear which object is the final user-approved proof artifact, what must bind that approval to the cart and payment details, and what a verifier is expected to check. Because of that, two independent implementations could produce different approval artifacts and still believe they follow AP2. That would make issuer interpretation, merchant evidence, and dispute handling less consistent.
A concrete example is the relationship between the Cart Mandate and the PaymentMandate. In Section 4.1.1 of
docs/specification.md, the Cart Mandate is described as the “foundational credential” for the human-present case and as being “cryptographically signed by the user.” Section 5.1 also says the user’s signed approval creates a cryptographically signed Cart Mandate. But the same Section 5.1 says the merchant signs the cart, and Section 7.1 Step 10 says the cart mandate is “first signed by the merchant entity.” Separately, Section 4.1.3 describes thePaymentMandateas a separate credential “bound to Cart/Intent mandate but containing separate information.” So the main question is still unclear: in the human-present flow, does final user approval live onCartMandate, onPaymentMandate, or on both together?The current implementation does not make that answer much clearer. In
src/ap2/types/mandate.py, the split betweenCartMandateandPaymentMandatestill leaves it unclear where final user approval is meant to live. In the Python human-present flow,samples/python/src/roles/shopping_agent/tools.pyuses a placeholderuser_authorization, andsamples/python/src/common/validation.pyonly checks that the field is present. That is understandable for an early v0.1 demo, but it also means the implementation does not yet show a complete and reproducible approval chain that external AP2 implementers can follow consistently.I think that is the core gap. Section 4.1.3 also says AI-agent presence and transaction modality signals must always be shared, but the current model does not make the full human-present approval chain easy to read and verify from the canonical objects alone. Right now, too much of that chain still lives in prose.
Potential hardening improvements
CartMandate,PaymentMandate, or both.I think this is mainly a protocol-completeness issue, and clarifying it would likely make independent AP2 implementations easier to align. I hope this is useful, and thanks again for publishing AP2 and sharing the work.