Module 1 introduced the three protocols the Deutsche Bundesbank places at the authorization layer and described how each treats a mandate. This lesson looks at the same three from the identity side, at step 6, where the payer's payment service provider has to verify the agent and the authority behind it. The Bundesbank's own footnote on identification is the starting point, and it is more specific than the body text.
What the Bundesbank says about the mechanisms
Its footnote reads, in substance: TAP and Agent Pay use HTTP message signatures to make agent identities verifiable without proprietary identity infrastructure. AP2 relies on decentralized identifiers for identification and verifiable credentials for authentication, which are independent of a central body but require infrastructure that is not yet universally available.
That is three anchors, two mechanisms. Two of the protocols sign the request. One signs a credential that travels with the request. And one of the two request-signers also binds the whole thing to a network token. Take them in turn.
Anchor one: a signed credential (AP2)
Google's Agent Payments Protocol makes the mandate itself the proof. The customer's intent and the agent's assembled cart are each captured as a verifiable credential, cryptographically signed, and carried with the transaction. Version 0.2 of the specification, released April 28, 2026, reorganized the launch set into two types, a Checkout Mandate and a Payment Mandate. Standardization work has since moved into the FIDO Alliance, and the specification lives at ap2-protocol.org.
At step 6 the provider receives a credential and verifies its signature chain: the principal signed the intent, the agent is the subject, the instruction matches the mandate. Identification uses decentralized identifiers; authentication uses the credentials themselves.
What it depends on: an infrastructure for issuing, resolving and checking decentralized identifiers and verifiable credentials. The Bundesbank's caveat is that this infrastructure is not yet universally available. A provider that cannot resolve a decentralized identifier cannot verify an AP2 mandate, however well formed.
Anchor two: a signed request (TAP)
Visa's Trusted Agent Protocol, developed with Cloudflare, signs the HTTP request the agent makes. The merchant's existing web infrastructure, or its edge provider, checks the signature and learns that a known agent, with a stated intent, is behind the traffic. The problem TAP started from was the merchant's: telling a legitimate shopping agent from a scraper. Its partner list at launch ran across acquirers, processors and platforms.
At step 6 the equivalent check is on the request that reaches the gateway or provider: is it signed by a key registered to a recognized agent, and does the signed payload say what the agent intends? The mandate information rides in the signed request rather than in a separate credential.
What it depends on: a registry that maps signing keys to agents, and a party willing to run the check at the edge. The Bundesbank's phrase "without proprietary identity infrastructure" is the attraction: HTTP message signatures are a web standard, so the merchant and the provider do not need a new identity system to verify them, only a way to know which keys to trust.
Anchor three: a network token (Agent Pay)
Mastercard's Agent Pay also uses HTTP message signatures for the agent's identity, per the Bundesbank's footnote, and binds the transaction to an agentic token: an extension of network tokenization in which the credential presented at payment is tied to the agent and the consumer rather than being a raw card number. The Bundesbank's reference is the Agent Pay Acceptance Framework, which it describes as geared toward merchants, offering integration without development work so that merchants already accepting Mastercard can accept trusted agentic transactions.
At step 6 on a card rail the provider's check is the network's: the token resolves to a registered agent and a consenting consumer, and the transaction falls inside the token's provisioning rules. The May 2026 German pilot described in Module 1 ran this way, with the three banks acting as issuers.
What it depends on: the network's existing token and authentication infrastructure, which is the point. Verification happens where card verification already happens. The flip side is that this anchor is native to a card rail; the Bundesbank's stylized flow is an instant credit transfer, where a network token is not the natural instrument.
The interoperability problem, stated precisely
Module 1 said the question for a product team is which anchor its provider, its merchants and its agent framework can all verify. Now the question can be made exact. A step 6 check needs the payer's provider to verify the anchor. A step 3 delegation needs the merchant or gateway to verify it. A framework needs to be able to produce it. If those three parties are set up for different anchors, the flow breaks at a hand-off, not at a protocol.
The Bundesbank describes the landscape as early and fragmented, with several approaches competing. For a provider the practical response is not to pick a winner but to decide which anchors it can verify at step 6 and publish that, so that agents and merchants know which route reaches its customers.
One more observation. Every one of the three anchors relies on a registry of some kind: identifiers, keys, or tokens. Whoever runs the registry decides which agents exist. The Bundesbank's sovereignty concern from Module 2 lands here as well. My own measurement of what happens when agents build their own identity layer, with no registry anyone else verifies, is in The Agents Built Their Own Identity Layer. Then They Forged Their Own Logs.
Disclosure: Charlie Major is a Product Development Manager at Mastercard. The views and opinions expressed in Major Matters are his own and do not represent those of Mastercard. Mastercard's Agent Pay is covered on the same factual basis as every other protocol in this course, with no ratings, rankings or comparative positioning.
Next lesson: making the proof hold under PSD2. Strong customer authentication, the three exemptions, and the step 6 check as a table.