> On 28 October we presented to the Agentic Commerce Working Group of the Agentic AI Foundation (AAIF). At checkout the merchant needs yes-or-no answers about the person behind the agent. With MintID one zero-knowledge proof answers all of them. The merchant learns each answer and none of the values behind it. Blog · agentic commerce # What a merchant can verify about the person behind an agent On 28 October we presented to the Agentic Commerce Working Group of the Agentic AI Foundation (AAIF). At checkout the merchant needs yes-or-no answers about the person behind the agent. With MintID one zero-knowledge proof answers all of them. The merchant learns each answer and none of the values behind it. by Marc Miró i Rierola·published 2026-10-30·updated 2026-10-30·4 min read On 28 October we presented to the Agentic Commerce Working Group of the Agentic AI Foundation (AAIF), the group that compares the protocols agents use to buy: UCP, ACP, AP2, x402 and the card networks’ agent programmes. According to the Agentic Standards Map by Francesco Marinoni Moretto (v1.0, 14 October 2026), one of the places where those protocols meet, seam S3 “Agent identity and delegation”, asks “how an agent shows who it acts for”. The session took that question from the merchant’s side. **The merchant does not need a name.** A name is hard to check, has to be protected once it is stored, and says nothing about whether the person approved this purchase. At checkout the merchant needs yes-or-no answers about the person behind the agent: that a KYC-verified person stands behind it, at a stated assurance level; that the person delegated paying this merchant, for this action, in this category and this country; that the basket is under the limit the person set; and that the delegation is still in force. With MintID one zero-knowledge proof answers all of them. The merchant learns each answer and none of the values behind it: no name, no date of birth, neither the exact assurance grade nor the exact limit. Each proof is valid for ten seconds, answers one request and works at that merchant only. **The recorded run.** We showed a run recorded on 23 October on [the public testnet](/en/developers), in its KYC sandbox. One agent credential covered one merchant, one action, one category and one country, with a 250 USDC limit. A 60 USDC checkout was accepted, with about 16 kB of proof and nothing in it that names the person. The same proof sent again was refused. For a 400 USDC basket, over the limit, the agent’s own software could not build a proof, and an older proof pushed in its place was refused by the verifier. An action the person never delegated was refused at the agent and at the verifier. Then the person withdrew the delegation in the middle of the session. An agent that follows the protocol stopped at its next status check; a copy that nobody stopped was accepted until the issuer’s new status could be proven, and refused from then on. **How long a withdrawal takes.** Revocation travels in the issuer’s status on the chain, and a verifier refuses as soon as it can prove that status. On this deployment every conforming verifier refuses within 185 seconds of the issuer’s revocation. The holder’s own kill switch has a bound of 245 seconds; revoking the person’s own credential, which takes all their agents with it, has a bound of 395 seconds from the status update that revokes them. A run’s own timing is an observation; the bound is what we guarantee. **What it does not cover yet.** The testnet runs a single validator and issues test credentials only. An agent cannot pass its authority on to another agent yet. An age check that never reveals the date of birth is built, but the testnet and production do not offer it yet. Funded recourse for disputes is specified and scheduled, not built. MintID sits beside the payment and executed no payment in this run; the binding that carries the proof next to an x402 payment is a draft, not yet proposed to the x402 maintainers. **What we asked for.** We asked the group to record principal verification in its Capability Map and Gap Analysis as a checkout step of its own, between the agent’s authorisation and the payment: evidence that an accountable person stands behind the agent at a stated assurance level, without identifying them; a proof bound to one request, so nobody else can reuse it; and withdrawal with a declared bound, stated and measured per path. The building blocks belong to another group. According to the Agentic Commerce Working Group’s charter, “Identity & Trust WG owns agent and buyer identity primitives, delegation models, and credential formats. AC WG applies these to commerce flows”. And according to the Reference Architecture draft of the Identity & Trust Working Group, section 5, “A relying party must be able to verify that such a principal exists, at a stated assurance level, without necessarily learning who it is.” We suggested that sentence; the draft’s editors adopted it on 14 October. **The deck** from the session is [attached as a PDF](/docs/MintID-AAIF-Agentic-Commerce-2026-10-28.pdf). The code, the test harness and the public testnet are open source under Apache-2.0. ## The deck The deck from the session is attached as a PDF. The code, the test harness and the public testnet are open source under Apache-2.0. [Deck (PDF)](/docs/MintID-AAIF-Agentic-Commerce-2026-10-28.pdf)[Developers](/en/developers) --- Source: https://mintid.net/en/blog/what-a-merchant-can-verify · What a merchant can verify about the person behind an agent — MintID blog