> Between an anonymous payment and a doxxed buyer sits the slot only a zero-knowledge proof can fill: human-backed, in scope, unrevoked — and unrevealed. MintID has drafted the standards-track transport profile that fits it, with machine-readable schemas and a validation suite. Blog · standards # The graduated-knowledge slot: an identity profile for x402 and Web Bot Auth Between an anonymous payment and a doxxed buyer sits the slot only a zero-knowledge proof can fill: human-backed, in scope, unrevoked — and unrevealed. MintID has drafted the standards-track transport profile that fits it, with machine-readable schemas and a validation suite. by Marc Miró i Rierola·published 2026-07-26·updated 2026-07-26·8 min read When Cloudflare put a per-call price on every resource behind its Monetization Gateway, it also put a question in front of every API seller on the open web: _how much do you need to know about the buyer?_ The gateway’s own tiers answer it as a ladder — open to anyone, better terms for verified agents, and the full identity-and-payment treatment where the risk warrants it. We [argued in July](/en/blog/x402-pay-per-use-web-needs-identity) that the interesting rung is the middle one, and that nothing on the shelf fills it. Between _anonymous_ and _doxxed_ there is a slot that only a zero-knowledge proof can occupy: **human-backed, in scope, unrevoked — and unrevealed**. Since then we have stopped describing that slot and started specifying it. MintID now has a **standards-track draft profile** for carrying an identity leg over [x402](/en/glossary#x402) and [Web Bot Auth](/en/glossary#web-bot-auth), with machine-readable schemas and a validation suite behind it. ## The ladder, rung by rung Tier What the seller learns Mechanism anonymous a payment cleared The x402 default. A wallet paid the quoted price and the request proceeds. The seller learns nothing about who is on the other end, and nothing carries over to the next request. identified software this call came from operator X’s fleet Web Bot Auth: HTTP message signatures against a published key directory. It authenticates the agent software. It says nothing about whether an accountable party stands behind it — and it works because the signing population is small and named. identified software, accountable human — unrevealed a KYC-verified principal is answerable for this agent, at a stated assurance grade, within a delegated scope covering this action The slot the profile fills. A zero-knowledge presentation adds the accountability layer to the signature without adding a name, a registry entry, or a handle that joins this seller’s log to any other. full KYC who the counterparty is Outside MintID’s lane, by design. Where the law demands identification, identification is the answer — but it should be the exception at the top of the ladder, not the default at the bottom. The third rung is the one the agentic economy will actually live on, because it is the only one that scales past the crawler oligopoly without building a public index of who runs which agent. ## One identity leg, on an unmodified payment cycle The design constraint we set ourselves was to change nothing about x402. The profile adds a leg; it does not fork a protocol. The seller’s `402 Payment Required` response carries an **identity-policy extension**: which claims the buyer must prove (human-backed; assurance at least the grade the seller requires; a delegated scope covering this action, this seller and this value; the credential active), which issuers are acceptable, the challenge endpoint, and the session mode. The buyer’s agent fetches a challenge from that endpoint, produces its proof, and retries the original request with **two headers**: the unchanged x402 payment payload, and a presentation envelope alongside it. The payment facilitator — already the party that verifies payment — gains an identity step: it decodes the envelope and validates it against **its own** self-deployed verifying core, as a registered verifier for its own origin. It answers with a decision, and the seller consumes that verdict over the trust relationship it already has with its facilitator for payment verification. **No new verifier class. Not one binding rule changed.** The seller is named inside the _claim policy_ — its payment address, its resource URL, the counterparty axis — never in the audience, which stays fixed to the verifying party’s registered origin. A seller that would rather not take its facilitator’s word for it registers as a verifier itself and runs the identity leg first-party. The profile is identical with the seller as the verifying party; only the deployment moves. ## Two session modes, honestly stratified A ten-second presentation per request is unusable at micropayment cadence. That is a real objection, and the answer is session design — never a longer proof. With **no funds at risk**, one accepted presentation bridges to a scoped, short-lived token carrying the proven predicates as its authorization basis; the rest of the session presents the token, whose lifetime and scope are the verifying party’s local policy. That mode is usable at MVP. Escrow-backed **value exclusivity** — reserved sessions — is a different risk class, and the draft treats it as one: its mode string has a reserved slot in the schema, and the profile _forbids_ offering or accepting it until the underlying session-reservation circuit clears its audit gate. Its wire fields land in a revision once that gate closes, not before. Reserving a name is a promise about scope; shipping the mechanism before an audit would be a promise about safety, and we do not make those. ## The Web Bot Auth rung: what we claim, and what we don’t Web Bot Auth gives an agent’s HTTP requests a verifiable key identity. It authenticates **the software**. A MintID presentation adds the sentence a signature cannot carry: _an accountable human stands behind this_ — without revealing who. Today that addition is a **session-level association**. A relying party that has verified a request signature runs the ordinary challenge → presentation → decision flow within the same session and associates the accepted decision with the signing key _for that session only_, under its own session policy. That is the same trust construction as any authenticated session, and it requires nothing new from the protocol. It is **not** key binding, and the draft is emphatic about the difference. A cryptographic predicate proving that the key signing this request belongs to the credentialled agent is a new predicate over attested key material; it belongs to the key-custody attestation family and inherits that family’s audit posture. The draft deliberately does not specify it, and a conforming implementation must not claim key-binding semantics from the session association. We say what is proven, and no more. ## The schemas are the enforcement The part of this work we are most pleased with is not prose. It is that the invariants are **structural**. The profile ships two JSON schemas — the policy extension and the payment-identity envelope — with three worked examples and seventeen validation tests. Both schemas set `additionalProperties: false`, and **no field exists** for a presentation lifetime, a condition skip, a staleness override or an audience override. The ten-second lifetime is a protocol constant the extension cannot lengthen, shorten or even mention. The nine acceptance conditions run in full on every presentation. Freshness tolerance stays local deployment policy and never rides the wire. There is no persistent “verified” badge, because a presentation is perishable and non-transferable by construction. The validation suite proves the mutations fail. Smuggling a knob into the extension is not a policy debate to be had in a working group at 2am — it is a schema violation. That is the difference between an invariant you document and an invariant you can’t express. ## Why publish a draft now Because the window is open. Agent payments are being standardised in public right now, and the identity layer is being decided in the same window — by whoever has text on the table. Ours is written, with schemas and tests, and it is honest about its state: a **Draft** under the project’s standards process, with a dispute annex reserved and open decisions still open. It freezes when the process says so, not when a blog post says so. What it establishes is that the middle rung of the ladder is buildable without inventing a new verifier class, without touching the payment protocol, and without a registry of who runs what. The rest of MintID is unchanged underneath: [agent KYC](/en/agent-kyc) on a [sovereign Layer-1](/en/technology), presentations that never enter the chain, and a proof engine that still has an independent audit ahead of it before any of this verifies a real proof. What is the x402 agent-identity profile? A standards-track draft that maps one identity leg onto the unmodified x402 payment cycle: the seller’s 402 response carries an identity-policy extension, the agent fetches a challenge and retries with both the payment payload and a presentation envelope, and the payment facilitator validates it on its own self-deployed verifying core. It ships with machine-readable schemas and a validation suite. Is the profile final? No. It is a Draft under the project’s standards process, and it is published here as a draft on the table while the identity layer of agent payments is being decided — not as a frozen or ratified specification. Parts of it, including the dispute annex, are explicitly reserved pending open decisions. Does it require a new kind of verifier or a change to the binding rules? Neither. The facilitator acts as a registered verifier for its own origin, on its own verifying core, and the seller consumes that verdict over the trust relationship it already has for payment verification. A seller that would rather not trust its facilitator can register and run the identity leg first-party — the profile is identical with the seller as the verifying party. A ten-second presentation per request is unusable at micropayment cadence. How is that answered? By session design, not by weakening the presentation. After one accepted presentation, the verifying party can mint a scoped, short-lived token carrying the proven predicates as its authorization basis, and the rest of the session presents that token. The ten-second lifetime is a protocol constant; the profile cannot lengthen it, and has no field in which to try. Does a MintID presentation bind the agent’s Web Bot Auth signing key? Not today, and the draft says so explicitly. A relying party associates an accepted decision with the signing key for that session only — the same trust construction as any authenticated session. Binding the key cryptographically into the credential is a new predicate over attested key material, deferred to an audited key-attestation track. A conforming implementation must not claim key-binding semantics from the session association. ## The rung between anonymous and doxxed Human-backed, in scope, unrevoked — and unrevealed. If you are building the identity layer of agent payments, we would like the argument. [How agent KYC works](/en/agent-kyc)[Talk to us](/en/contact) --- Source: https://mintid.net/en/blog/x402-web-bot-auth-identity-profile · The graduated-knowledge slot: an identity profile for x402 and Web Bot Auth — MintID blog