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 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 and 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 on a sovereign Layer-1, 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.