The checks
Fourteen checks before it buys. Ten before it charges.
Before the buyer asks anyone to approve a purchase, it verifies the seller the way a stranger would: from DNS, from the seller’s own published files, and from a third party’s log. Then the seller, for its part, accepts nothing it has not verified. Every check runs in code, in order, and writes its result to a public ledger.
What the buyer checks about the seller
Each check writes one line of evidence to the buyer’s ledger, as counterparty.verified, signed by the buyer’s own running instance. Each uses public records only: anyone given the ledger can repeat every check from the seller’s domain name alone.
A. The DNS record: where the seller says it is
Everything starts from one signed record under the seller’s own domain.
| # | Check | What it does | Why |
|---|---|---|---|
| 1 | record_validated | Reads the seller’s SVCB record and validates its DNSSEC signature locally against the zone’s key, with the DS matched at the parent. | Everything else starts from this record. If DNS could be forged, the buyer could be sent anywhere. |
| 2 | card_url_declared | The record names the URL of the agent card (key65400). | The buyer finds the card from the signed record, never by guessing a URL. |
| 3 | dane_endpoint | Connects to the host and compares the TLS certificate’s public key with a TLSA record in signed DNS. | DNS says which key this host must present, so a certificate from a rogue certificate authority fails. |
| 4 | card_digest | The fetched card hashes to the cap-sha256 value in the record. | The card says what the seller offers. It cannot change without the DNS record changing. |
| 5 | endpoint_in_zone | The endpoint the card names is inside the seller’s own domain. | A card cannot send the buyer to a host outside the zone that vouched for it. Stricter than DNS-AID and A2A require: a rule of this implementation. |
B. The signed record and the seller’s identity
Who signed the record, which running copy of the seller is answering, and whether anyone outside the zone vouches for it.
| # | Check | What it does | Why |
|---|---|---|---|
| 6 | dane_key_host | The host that publishes the zone’s signing keys is also reached over a DANE-pinned connection. | Check 7 needs a key set, and that key set must not arrive over an unpinned connection. |
| 7 | record_signature | A second signature (JWS, key65405) verifies under that key set and binds name, host:port and protocol, over the SVCB parameters as they sit on the wire. | It proves the parameters were not altered in transit, and that the signer holds the zone’s key. |
| 8 | seller_instance | The seller’s SPIFFE identity (SVID) verifies against its trust bundle and vouches for the key that signs quotes and receipts. | It ties the running seller to the key that will sign everything later, so a quote can be traced to this identity. |
| 9 | ans_registration | The _ans record points to a receipt in a known ANS transparency log, never one the seller picks; its Merkle proof leads to a root the log signed, and the receipt is active and names this host. | Checks 1 to 8 all live inside the zone, so a lookalike domain with its own DNSSEC, TLSA and keys would pass them. This is the one check anchored outside the zone, in a third party’s log. |
C. UCP: what the seller can do in a purchase
Whether the buyer can do business with this seller at all, found out before anyone is asked to approve.
| # | Check | What it does | Why |
|---|---|---|---|
| 10 | ucp_profile | Reads /.well-known/ucp: version, endpoints (REST and MCP, on the seller’s own origin), capabilities, keys and payment handler. | This is how the seller declares what it can do in a purchase. Without it the buyer cannot buy. |
| 11 | ucp_negotiation | The capabilities both sides support include checkout and the AP2 mandate extension, at the highest mutual version. | The buyer only buys with a mandate. If the seller cannot take one, it stops before asking anyone to approve. |
| 12 | ucp_key | The profile’s keys contain the same instance key the SVID vouches for (check 8). | The key that signs every UCP response is the one proved in DNS, so the two identities cannot diverge. |
| 13 | ucp_handler | The payment handler takes a card instrument whose credential is the closed AP2 Payment Mandate. | The buyer knows what it hands over: a mandate, not a card number. |
| 14 | ucp_issuers | The seller lists the mandate authorities it accepts, and the person’s approval service is among them. | A mandate from an authority the seller does not accept would be refused at checkout. Better to find out before the person approves. |
Reading the count
- “14 of 14 checks passed” is the buyer’s own count. The independent verifier quotes it from the buyer’s ledger beside its own verdict, and does not run it again; its scorecard has its own checks, grouped in nine dimensions.
- Checks 1 to 8 are anchored in the seller’s own zone, so on their own they cannot tell the real seller from a lookalike that controls its own domain. Check 9 is the one that does.
What the seller checks before it charges
A fixed sequence, in the order the seller’s published contract numbers it. If any check from 2 to 10 fails, the seller answers with a typed refusal, such as identity_revoked at check 3 or mandate_revoked at check 10, and writes a signed refusal to its public ledger.
| # | What the seller verifies |
|---|---|
| 1 | Size, content type, method, protocol version |
| 2 | Signed request envelope: algorithm, key id, forbidden headers, 60-second window, nonce, audience, method, path and body hash |
| 3 | Buyer identity: attestation on the buyer’s domain, SVID chain, not revoked |
| 4 | Mandate issuer is on the seller’s allow-list; the signature verifies under the issuer’s key set; the person and buyer match |
| 5 | Audience: the mandate is for this seller |
| 6 | Seller, action, stage, currency and amount equal the checkout total |
| 7 | The quote exists, has not expired, and its hash recomputes |
| 8 | Time window has not expired |
| 9 | Single use; the mandate key equals the key that signed the request |
| 10 | Not cancelled: status read live at the approval service |
Four ways to stop a purchase
People change their minds, and operators retire keys. The last two are the identity controls: both act at the domain that owns the agent, so the operator can withdraw an identity without asking any registry or counterparty.
The person
Stops their agent on the approval service’s panel, with the passkey or a stop-only link. Every mandate still out is revoked, waiting requests are denied, and nothing new is issued.
The person
Cancels one approval on its own page. The seller reads the mandate’s status live at check 10, so the next attempt is refused.
The operator
Withdraws the agent’s key, with a signed withdrawal on the agent’s own domain. The seller refuses that identity at check 3.
The operator
Removes the agent’s DNS record. Once cached copies expire, the agent can no longer be found.