Until now, every AI agent shopping session has been anonymous. The agent connects to a store, searches the catalog, builds a cart, reaches checkout — and the merchant has no idea who the buyer is. The agent is a stranger with a shopping cart.

That just changed. The UCP spec now defines identity linking as a core capability, and the protocol is evolving fast to support it. On March 18, a breaking change landed in the UCP repository — feat!: redesign identity linking with mechanism registry and capability-driven scopes — that reshapes how agents authenticate on behalf of real buyers.

We've been building support for this in UCP Playground since the capability first appeared in the spec. Here's what identity linking is, how the protocol defines it, and why it's the missing piece between agent browsing and agent commerce.

#The problem: anonymous agents can't really shop

Without identity, there's no loyalty pricing. No saved addresses. No order history. No member discounts. No way to say "ship it to the same place as last time." The agent has to collect buyer information from scratch every session — name, email, phone, shipping address — through a back-and-forth that adds 4-5 messages before checkout can even start. The merchant can't personalize anything.

This is fine for product discovery. It's a dead end for real commerce.

Merchants have spent years building loyalty programs, membership tiers, and personalized pricing. None of that is accessible to an anonymous agent. The store can't tell if the buyer is a first-time visitor or a ten-year customer with a 20% loyalty discount. Every session starts cold.

Identity linking solves this. The UCP spec defines it as a capability that enables platforms to obtain authorization to perform actions on a user's behalf via OAuth 2.0. In practice: the user grants the agent permission to act as them at a specific merchant, and the merchant can resolve who they are and what they're entitled to.

It's the difference between an agent shopping for you and an agent shopping as you.

#What the spec defines

Identity linking — dev.ucp.common.identity_linking — is one of four core capabilities in the current UCP spec, alongside Checkout, Order, and Payment Token Exchange.

The capability uses standard OAuth 2.0 to establish authorization. When an agent needs to interact with a merchant on behalf of a user, it initiates an authorization flow. The user authenticates directly with the merchant — the agent never sees credentials — and the merchant issues a scoped access token that the agent can use for subsequent requests.

The March 18 redesign introduced two important concepts:

Mechanism registry. Merchants can now declare which authentication mechanisms they support in a structured registry within their UCP manifest. This isn't limited to a single OAuth flow — the registry pattern allows for multiple mechanisms, letting the spec evolve to support new authentication methods without breaking existing implementations.

Capability-driven scopes. OAuth scopes are no longer static. A merchant might require one set of scopes for catalog access and a different set for checkout. The agent negotiates the scopes it needs based on the capabilities it wants to use. This is least-privilege authorization applied to commerce — an agent that only needs to browse the catalog doesn't get checkout permissions.

These two additions are significant because they move identity linking from "we support OAuth" to "here's a structured, extensible framework for merchant-to-agent authentication." The mechanism registry in particular is forward-looking — it creates the architecture for whatever authentication patterns emerge as the ecosystem matures.

#How the OAuth flow works

The protocol specifies an OAuth 2.0 Authorization Code flow with PKCE (Proof Key for Code Exchange). Here's what happens:

Discovery. The agent reads the merchant's UCP manifest. If the manifest declares dev.ucp.common.identity_linking as a capability and includes OAuth endpoints — authorization URL, token URL, and optionally a client registration URL — the flow can proceed.

Client registration. The spec supports RFC 7591 dynamic client registration. Rather than requiring developers to manually register an OAuth app at each merchant, the agent can send a registration request to the merchant's registration endpoint and receive client credentials automatically.

Authorization. The agent generates a PKCE code verifier and challenge, then directs the user to the merchant's authorization endpoint. The user sees a consent screen controlled entirely by the merchant — what permissions are being requested, what data will be shared. The agent can't bypass this step. The human stays in the loop.

Token exchange. After the user consents, the merchant redirects back with an authorization code. The agent exchanges it for access and refresh tokens server-side, validating the PKCE verifier to ensure the code was issued to the same client that requested it.

Profile resolution. With a valid access token, the agent calls the merchant's profile endpoint to resolve buyer identity — name, email, phone, address. This is the data that flows into checkout, replacing the manual collection that currently adds friction to every session.

The PKCE requirement is worth emphasizing. It ensures the authorization code can only be exchanged by the client that initiated the flow, even in public clients without a client secret. This is standard security practice for OAuth in native and single-page applications, and the UCP spec applies it consistently.

#What changes for merchants

For merchants already running OAuth — which is most major ecommerce platforms — the infrastructure work is modest. The UCP-specific additions are:

Declaring dev.ucp.common.identity_linking in the manifest so agents can discover the capability.

Exposing the mechanism registry with supported auth methods and the OAuth endpoints.

Implementing a profile endpoint that returns normalized buyer identity in a format agents can consume.

The payoff is significant. When an agent can resolve buyer identity, the merchant gets access to their full customer relationship — loyalty tier, saved addresses, payment preferences, order history. A returning customer who says "order my usual" through an agent gets the same treatment they'd get on the merchant's own app.

Merchants who don't implement identity linking will still work with agents — anonymous checkout is the baseline. But they'll be competing with merchants who can offer personalized, one-click agent checkout experiences. As agent-mediated shopping grows, that gap widens.

#What changes for agents and platforms

For platforms building agent commerce experiences, identity linking unlocks a fundamentally different interaction model:

Pre-filled checkout. The agent knows the buyer's email, shipping address, and phone number before checkout starts. No more asking "what's your email?" — the session moves directly to cart and payment.

Personalized results. With identity, the merchant can return member pricing, loyalty-exclusive products, and personalized recommendations through the same catalog and checkout tools.

Trust signal. An authenticated session carries more weight than an anonymous one. Merchants can apply different rate limits, offer different payment methods, or surface different inventory to authenticated agent sessions.

Reduced friction. In our testing, anonymous checkout sessions required 4-5 back-and-forth messages to collect buyer information. With identity linking, that drops to zero. The agent checks out with the right identity on the first attempt.

#Where we are in adoption

Today, identity linking is declared in the UCP spec but early in real-world adoption. Our monitoring across 3,000+ domains shows the capability starting to appear in merchant manifests, but most implementations are still at the declaration stage — merchants list the capability without fully wiring up the OAuth flow behind it.

In UCP Playground's audit system, identity linking currently earns 2 points in the manifest score if a merchant declares it. If the manifest declares it but the runtime tools don't support buyer identity fields, the gap analysis flags it as a merchant gap. We're scoring declaration, not yet probing whether the flow works end-to-end.

That will change. Runtime probing of identity linking endpoints — testing whether the registration endpoint accepts requests, whether the token endpoint responds, whether the profile endpoint returns valid buyer data — is on our roadmap. When merchants start shipping production OAuth flows, we'll be ready to test them.

In UCP Playground, we've built full support for the identity linking flow: dynamic client registration, PKCE authorization, token management with auto-refresh, and profile resolution with field normalization across different merchant response formats. When a merchant's manifest declares a working identity linking endpoint, the playground will walk you through every step of the flow — from PKCE generation to profile resolution — visualized in a step-by-step timeline.

#What to watch

Identity linking is where UCP starts to get interesting for the long term. Discovery and checkout are table stakes — every commerce protocol needs them. But identity is what turns agent commerce from a novelty into infrastructure.

Three things we're watching:

Merchant adoption. Which platforms will be first to ship production identity linking endpoints? Shopify already supports OAuth extensively for their app ecosystem — extending it to UCP identity linking is a natural step. Custom platform developers building against the spec are likely to move faster.

Scope standardization. The capability-driven scopes model is powerful but new. As more merchants implement it, patterns will emerge around which scopes map to which capabilities. Early standardization here prevents fragmentation.

The mechanism registry evolving. OAuth 2.0 is the starting point, but the registry pattern is designed to accommodate new mechanisms. Passkeys, verifiable credentials, federated identity — the architecture is there. What fills it will shape the next phase of agent authentication.

The spec is moving. The infrastructure is ready. Now we wait for merchants to plug in.

Check your domain: ucpchecker.com/check Test with Playground: ucpplayground.com Follow the spec: github.com/Universal-Commerce-Protocol/ucp Browse verified merchants: Directory — see which stores already declare identity linking Set up monitoring: UCP Alerts — get notified when merchants add or change capabilities

Related reading: Identity linking was a key enabler of the first fully autonomous AI agent purchase — an end-to-end transaction where the agent authenticated, built a cart, and completed payment without human intervention. For platform-specific implementation details, see our guides for Shopify, WooCommerce, Magento, and BigCommerce.