agentwallets.si
← Back to Blog

EDITORIAL ARTICLE

What Is an Agent’s Identity, and How Does It Prove Whom It Represents?

Article concepts · illustration
01Agent identity02User authorization03Transaction credential

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.

flowchart LR A[User requests purchase] --> B[Agent requests from merchant] B --> C[Merchant identifies request source] C --> D[Verify purchase conditions] D --> E[Payment provider processes transaction] E --> F[Merchant delivers under terms]

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.