EDITORIAL ARTICLE
What Is an Agent’s Identity, and How Does It Prove Whom It Represents?
A shopping agent requests a pair of shoes. The merchant must ask both who sent the request and whether that party may buy for the user. Agent identity, user identity, purchase authorization and payment confirmation are four different questions. A correctly signed agent request can still lack purchase permission.
This is conceptual. The use, data fields and availability of identity signals and authorization depend on the protocol and integration; no real product integration or transaction was tested.
What must a merchant know?
| Question | Example | What it cannot prove alone |
|---|---|---|
| Agent identity | Which agent service made the request? | The user approved this product |
| User or account identification | Does it match an existing customer? | This payment has valid authorization |
| Purchase authorization | What product, price and time conditions did the user set? | The bank or network will approve |
| Payment credential | Which scoped credential is used? | The goods will be delivered as promised |
One product can cover multiple layers, but authentication of an agent does not mean it can buy anything.
Visa TAP and AP2 address different questions
Visa Trusted Agent Protocol describes signed agent requests, consumer identification and payment-related information for merchants using the protocol. AP2 defines Checkout and Payment Mandates to express and verify purchase and payment authorization. Their focus differs; whether they work together depends on the integration. Visa’s product page says capabilities are in development and deployment, not available in every market.
Verification boundaries
A verifier needs more than a signature’s presence: the protocol may require checking issuer, recipient, expiry, purpose and content. Link authorization to the current transaction; permission to buy shoes does not authorize every product.
Identity data also raises privacy questions. Whether merchants need complete information or only transaction-specific fields depends on system design and rules; the diagram does not require all parties to see the same data. Ask which identity is trusted, who verifies it, for which transactions, and what happens on expiration or revocation.