Universal Commerce Protocol for Agent Checkout
How UCP business profiles describe services, capabilities, payment handlers, transport bindings, signed requests, and merchant responsibility.
A UCP business profile is a merchant's machine-readable front door. It tells an agent platform which commerce services exist, which capabilities and payment handlers they support, and which transport carries each interaction. The business then selects the mutually compatible set.
No checkout, no profile. /.well-known/ucp is useful only when its schemas and endpoints lead to working merchant systems with operational ownership. On a site that only accepts inquiries, the same JSON document would promise transactions that nobody can complete.
The UCP specification and official repository are active open-source work with date-based protocol and capability versions. An adopter should pin the release it implements and recheck every referenced schema before deployment.
The business profile is the discovery root
A participating business serves GET /.well-known/ucp. Its profile contains a ucp object that declares the protocol version and maps of services, capabilities, and payment handlers. Public signing keys appear in the same profile.
The service entry answers how to call a vertical. For the official shopping service, an entry names a version, transport, schema, endpoint, and specification URL. A REST binding can point to an OpenAPI description and an API base URL. The endpoint plus an OpenAPI path produces the actual request URL.
Capabilities answer what the business supports within that service. Checkout, cart, catalog lookup, fulfillment, and order handling are separate declarations. Each is independently versioned and named under a reverse-domain authority, such as dev.ucp.shopping.checkout. An extension can declare a parent with extends; fulfillment, for example, has no meaning if checkout isn't in the negotiated set.
Payment handlers describe compatible ways to supply a payment instrument. They can identify handler-specific schemas and configuration while keeping raw payment credentials out of general discovery. A declared handler is not proof that every transaction will accept it. The business still evaluates the checkout context and processes payment through its chosen provider.
The profile's URLs are active inputs. A client may fetch remote schemas, which introduces server-side request forgery and stale-content risk. The current specification binds a schema origin to the reverse-domain namespace and requires safe URL fetching. Implementers should also allow only HTTPS, reject user information in URLs, resolve and recheck public addresses, refuse redirects where the specification requires it, and cap response size and fetch time.
Date-based versions support explicit capability intersection
UCP version identifiers use YYYY-MM-DD and represent the last backward-incompatible change. Capabilities carry versions as well. The business can publish version-specific profiles for older protocol releases through supported_versions.
The platform advertises its own profile URL in the UCP-Agent request header. The business intersects capability names, finds mutually supported versions for each name, and selects the highest shared date. Extensions whose parents are absent are removed. The business includes the resulting active capability set in every response.
That repeated result matters during a long checkout. A platform doesn't have to infer that a previously advertised extension stayed active for this request. It reads the response and handles only the selected set.
Version dates are identifiers, not a promise that newer is always safe for a particular merchant. A production upgrade still needs schema compatibility tests, stored-session migration, partner coordination, and a rollback plan. Cache profile responses, but set an expiry that lets a withdrawn key or capability disappear promptly.
Transport bindings share the commerce model
UCP separates a service from its wire binding. Current documentation covers REST with OpenAPI, MCP with OpenRPC over streamable HTTP, A2A through an Agent Card, and an embedded OpenRPC binding. A business can publish more than one binding for the same service.
That doesn't mean every business should. Each transport adds authentication, conformance, support, and observability work. REST is usually the clearest first binding when a merchant already operates a server API. MCP may fit an existing agent tool surface, but it shouldn't be added merely because the caller is an agent.
The platform chooses a mutually supported binding and uses the schemas attached to it. Business logic must remain consistent across bindings. If REST refuses an out-of-stock item while MCP accepts it, the advertised common model has split into two products.
HTTP Message Signatures protect direct interactions
For UCP's public-profile interaction model, the current message signature specification applies RFC 9421 HTTP Message Signatures to HTTP-based transports. Profiles publish JWK public keys. Implementations must support ES256 verification as the baseline, with other algorithms subject to the specification and counterparty needs.
A state-changing REST request signs derived HTTP components and relevant fields, including the request method, authority, path, UCP-Agent, Idempotency-Key, Content-Digest, and content type in the documented profile. Covering the digest binds the signature to the exact body. Covering the idempotency key prevents an intermediary from changing the duplicate-operation identity without breaking verification.
Idempotency remains a business control. A valid signature authenticates a request and protects its integrity; it doesn't stop the same signed request from arriving twice. Store operation keys with their completed response, and return that result on retry without a second payment capture or order.
Key operations need their own runbook. Publish overlapping keys during planned rotation, remove a compromised key promptly, bound profile caches, and record which key verified a request. Never place private keys in the profile or application logs.
The business stays Merchant of Record
UCP keeps the business at the center of the transaction. The business typically remains Merchant of Record, owns the customer relationship, and carries financial responsibility. Its existing systems still decide price, tax, availability, fulfillment, returns, support, and payment acceptance.
An agent platform presents the interaction and acts for its principal within negotiated capabilities. A credential provider can tokenize payment data. A payment service provider authorizes and captures funds. Those roles reduce unnecessary credential exposure, but they don't transfer the merchant's obligations.
This boundary should appear in failure handling. A valid payment instrument can't make an unavailable item purchasable, so the business refuses or revises checkout. Late delivery remains a business support issue. And when a refund is due, the business's policy and processor execute it.
A service inquiry is not checkout
TKOResearch is building TARE as a LabSecOps platform and publishes information about private client services. The website has no machine-operated product catalog, cart, authoritative checkout session, payment handler, or order service.
The contact form asks a person or organization to describe a possible engagement. Scope and price are determined later. There is no item identifier to place in a cart, machine total to accept, or order object to return, so the current 404 at /.well-known/ucp tells the truth.
What would make a UCP profile honest
A future transactional TARE product would need a business system of record before it needed discovery. That system would own purchasable items, availability, checkout state, fulfillment, cancellations, returns, and partial delivery. It would calculate authoritative totals for price, discounts, tax, fees, and shipping at the moment checkout changes.
The service layer would expose versioned capability schemas and at least one supported transport, with stable errors, idempotency, and lifecycle operations. Payment design would name handlers, credential providers, processors, acceptance rules, reconciliation, and Merchant of Record responsibility. Customers would have a merchant-operated route for order status, delivery problems, refunds, and disputes.
Only after those paths work should the team publish keys and a profile. Verification would cover safe schema fetching, namespace authority, key custody and rotation, request signatures, authorization, personal data, replay, abuse, and dependency changes. Operations would trace profile requests, negotiated capabilities, signature results, checkout mutations, payment outcomes, orders, and webhooks.
A future UCP profile should be almost boring to verify. Every URL would resolve to a supported merchant operation, and retiring that operation would remove its discovery entry in the same release. TKOResearch has no transaction boundary like that on this site today.