Trust in Depth for AI Agents
The Landscape

Universal Commerce Protocol (UCP)

Google and Shopify's composable commerce standard for agent-to-merchant interaction.

The Universal Commerce Protocol is a composable commerce standard for AI agent-to-merchant interaction. Created by a coalition led by Google and Shopify, UCP focuses on the merchant integration surface — how an AI agent discovers what a merchant offers, builds a cart, and completes a checkout.

Architecture

UCP is a REST API with JSON payloads. Its design philosophy is composability: merchants expose the capabilities they support, and agents interact only with those capabilities.

Discovery

Merchants publish a /.well-known/ucp manifest that describes their available capabilities, supported payment methods, and API endpoints. An agent can read this manifest and understand what the merchant supports without prior arrangement.

Authentication

UCP uses HTTP Message Signatures per RFC 9421. Both the agent and the merchant sign their HTTP messages, providing mutual authentication and message integrity. This is a stronger authentication model than bearer tokens — each message is individually signed, preventing replay and tampering.

Composable Capabilities

UCP defines four core capabilities as modular building blocks:

  • Catalog: Product discovery, search, and browsing
  • Cart: Cart creation, item management, price calculation
  • Checkout: Order initiation, shipping selection, payment
  • Fulfillment: Order tracking, delivery updates, returns

A merchant may support all four or any subset. A small merchant might expose only catalog and checkout. A marketplace might expose the full set with additional extensions.

The Checkout Flow

The typical UCP interaction follows a clear sequence:

  1. Discovery: Agent reads the merchant's /.well-known/ucp manifest
  2. Catalog browsing: Agent queries the catalog capability for products matching the user's requirements
  3. Cart building: Agent adds items to a cart, adjusts quantities, applies coupons
  4. Checkout initiation: Agent initiates checkout with shipping and payment details
  5. Merchant authorization: Merchant returns a merchant_authorization — a JWS detached content signature over the checkout body
  6. Payment: Payment service provider handles the actual payment processing
  7. Fulfillment: Order lifecycle webhooks provide status updates

Merchant Authorization

The merchant_authorization is UCP's most distinctive mechanism. When a merchant approves a checkout, it returns a JWS (JSON Web Signature) using detached content — the signature covers the exact checkout body without duplicating it.

This is a cryptographic commitment. The merchant has signed this specific checkout with these specific items at these specific prices. If a dispute arises later about what was agreed, the merchant_authorization is evidence. The merchant cannot claim the price was different or the items were different from what the agent submitted — the signature binds them.

This is stronger than a typical API response. An unsigned API response proves only that the server returned certain data. A JWS-signed authorization proves that the merchant's signing key endorsed that specific checkout.

Business Identity

UCP takes an interesting approach to identity. Merchants establish identity through DNS-verified business profiles. The business profile includes signing_keys[] — the cryptographic keys the merchant uses to sign authorizations and API responses.

This creates what might be called identity by implication. The merchant's identity is their domain. If shop.example.com publishes a UCP manifest and signs authorizations with a key listed in its business profile, the identity claim is: "the entity that controls this domain is the entity that authorized this checkout."

DNS verification provides a practical baseline. It is harder to spoof than a self-asserted identity, easier to implement than a full credential chain, and maps naturally to how businesses already establish web presence.

It is also limited. DNS verification tells you that shop.example.com is controlled by whoever controls that domain. It does not tell you:

  • Whether that entity is a legally registered business
  • In which jurisdiction it is incorporated
  • Whether the person operating the API is authorized to bind the business to this transaction
  • What dispute resolution mechanisms apply

What UCP Handles Well

UCP excels at the merchant integration surface. Its composable architecture is well-designed — merchants can adopt incrementally, agents can discover capabilities dynamically, and the protocol does not prescribe a single checkout flow.

The merchant_authorization JWS is genuine infrastructure for accountability. It creates a cryptographic record of what the merchant agreed to, which is more than most commerce APIs provide.

HTTP Message Signatures (RFC 9421) provide strong per-message authentication, and the composable capability model allows the protocol to evolve without breaking existing implementations.

What UCP Defers

UCP's gap is on the post-purchase side.

Disputes: UCP provides order lifecycle webhooks — status updates as an order moves through fulfillment. But webhooks are notifications, not a dispute mechanism. There is no defined process for a buyer to contest a charge, for a merchant to respond, for evidence to be submitted, or for resolution to be reached. If the item does not arrive, UCP tells you the order status changed. It does not tell you what to do about it.

Identity beyond DNS: DNS verification establishes domain control. It does not establish legal identity, organizational authority, or jurisdictional presence. For low-value consumer purchases, this is sufficient. For high-value B2B transactions, it is not.

Persistent agreements: UCP handles individual checkout sessions. It does not support ongoing commercial relationships — service level agreements, subscription terms, licensing arrangements, or any obligation that extends beyond a single order.

Jurisdictional framework: UCP is jurisdiction-agnostic. The protocol works the same way whether the merchant is in the United States, the European Union, or Singapore. This is a feature for adoption and a gap for enforcement. When something goes wrong, jurisdiction determines which consumer protection laws apply, which courts have authority, and what remedies are available.

The merchant_authorization is evidence. UCP does not define the forum in which that evidence would be presented.