DEV Community

Cover image for Microsoft Dropped ACP for UCP in 104 Days. Identity Linking Is Why.
Peter
Peter

Posted on • Originally published at ucptools.dev

Microsoft Dropped ACP for UCP in 104 Days. Identity Linking Is Why.

#ucp #ecommerce #oauth #agenticcommerce

On January 8, 2026, Microsoft launched Copilot Checkout on ACP - OpenAI's Agentic Commerce Protocol, powered by Stripe.

104 days later, on April 22, Microsoft announced general availability of UCP feeds in Merchant Center. Target was the launch partner. The same day, Ulta Beauty went live with agentic commerce, linking 46 million loyalty members through UCP.

Microsoft didn't just add a second protocol. They switched horses mid-race.

The question nobody's answering clearly: what does UCP have that ACP doesn't?

The answer is one capability: Identity Linking.

The Loyalty Problem AI Agents Create

Think about what happens when an AI agent shops on your behalf.

It finds a product. Compares prices. Adds to cart. Checks out. Every step works. But it checks out as a guest.

The agent doesn't know you're a Target Circle member. It doesn't know you have 50,000 reward points. It doesn't know you qualify for member-only pricing on the item it just found.

Every AI-mediated purchase becomes a guest checkout. Merchants lose their most valuable signal: who this customer actually is.

This isn't an edge case. Target Circle has tens of millions of members. Ulta has 46 million. Sephora, Best Buy, Gap - all UCP endorsers - have massive loyalty programs. When AI agents ignore all of that, merchants lose the customer relationship they spent years building.

The protocol that solves this wins. That's why Microsoft switched.

How Identity Linking Actually Works

Identity Linking is a stable capability in the UCP spec (not draft, not experimental). It's been there since the January 2026 launch.

The namespace is dev.ucp.common.identity_linking - note it's under common, not shopping. This trips up a lot of implementations.

Here's what the capability declaration looks like in your /.well-known/ucp profile:

{
  "name": "dev.ucp.common.identity_linking",
  "version": "2026-01-11",
  "spec": "https://ucp.dev/latest/specification/identity-linking/",
  "schema": "https://ucp.dev/schemas/common/identity_linking.json",
  "config": {
    "supported_mechanisms": [
      {
        "type": "oauth2",
        "issuer": "https://yourstore.com"
      }
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

The flow uses standard OAuth 2.0 Authorization Code (RFC 6749). Nothing exotic:

  1. Agent reads your UCP profile and sees you support Identity Linking
  2. Agent discovers your OAuth server via RFC 8414 at /.well-known/oauth-authorization-server
  3. Agent requests authorization on the user's behalf
  4. User sees a one-time consent prompt (inside Copilot or Gemini)
  5. Agent gets an access token scoped to ucp:scopes:checkout_session
  6. Every subsequent checkout carries member pricing, points, preferences

The critical insight: one consent, persistent identity. The user approves once. After that, the agent carries their loyalty membership into every future session with that merchant. No re-auth. No per-transaction prompts.

Your OAuth server needs to publish a metadata endpoint per RFC 8414:

{
  "issuer": "https://yourstore.com",
  "authorization_endpoint": "https://yourstore.com/oauth/authorize",
  "token_endpoint": "https://yourstore.com/oauth/token",
  "scopes_supported": ["ucp:scopes:checkout_session"],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code"],
  "token_endpoint_auth_methods_supported": ["client_secret_basic"]
}
Enter fullscreen mode Exit fullscreen mode

Note: the OAuth endpoints are NOT declared in the UCP profile. They're discovered dynamically via RFC 8414. The profile only declares the issuer URL.

Target Circle in Copilot: What the Flow Looks Like

Here's what Microsoft built with Target as the launch partner:

  1. You ask Copilot to find running shoes under $80
  2. Copilot queries Target's UCP endpoint, finds matching products
  3. You pick a shoe. Copilot starts checkout
  4. Copilot sees Identity Linking in Target's profile. Prompts: "Connect your Target Circle account?"
  5. You approve. OAuth happens behind the scenes
  6. Checkout continues - but now with your Circle discount applied, your email pre-filled, your reward points available
  7. Next time you shop at Target through Copilot, step 4 is skipped. Your identity persists

This is why Microsoft specifically called out Identity Linking in their Merchant Center announcement. It's not a nice-to-have feature - it's the mechanism that makes loyalty programs survive the shift to AI-mediated commerce.

Why ACP Can't Do This

ACP uses Stripe delegated tokens. A Stripe token represents a payment credential - a card, a wallet, a bank account.

A Stripe token knows your card number. It does not know you're a rewards member. It does not know your loyalty tier. It does not carry member pricing.

ACP has no OAuth identity layer. No account linking mechanism. No way for an agent to say "this shopper is customer #4821 with Gold status."

This is a structural gap, not a missing feature. ACP was designed for payment delegation. UCP was designed for the full commerce lifecycle - including identity.

When Microsoft needed loyalty programs to work in Copilot Shopping, ACP couldn't deliver. UCP could. 104 days was all it took to make the switch.

Implementation: Adding Identity Linking to Your Profile

If you have a loyalty program and want it to work with AI agents, here's what you need:

1. Add the capability to your UCP profile

Add the dev.ucp.common.identity_linking entry to your capabilities array (see the JSON example above). Common namespace - not shopping.

2. Set up your OAuth server

You need a standard OAuth 2.0 Authorization Server with a metadata endpoint at /.well-known/oauth-authorization-server. If you already support OAuth for mobile apps or partner integrations, you're most of the way there.

3. Watch for these validation failures

Our validator catches 4 Identity Linking-specific issues:

Error Code What Went Wrong
UCP_IDENTITY_MISSING_MECHANISMS No config.supported_mechanisms in your capability
UCP_IDENTITY_INVALID_MECHANISM Mechanism entry missing required type field
UCP_IDENTITY_MISSING_ISSUER OAuth2 mechanism without an issuer URL
UCP_IDENTITY_ISSUER_NOT_HTTPS Issuer URL uses HTTP instead of HTTPS

The most common failure: declaring the capability but forgetting the config block entirely. A Level 1 validator (JSON structure only) won't catch this. You need Level 2 compliance validation.

What To Do Next

  1. Check if your profile declares Identity Linking - if you have a loyalty program and it's missing, your members are invisible to AI agents
  2. Validate your Identity Linking config at ucptools.dev - the validator checks all 4 error codes and tells you exactly what to fix
  3. Add UCP validation to CI/CD - catch regressions before agents do (GitHub Action)
  4. Test the OAuth flow end-to-end - a valid profile means nothing if the OAuth metadata endpoint returns a 404

Microsoft made their bet. Target and Ulta are live. The Identity Linking spec is stable and validated by multiple agent platforms. If you have a loyalty program, this is the capability that makes it travel with your customers into AI commerce.

UCPtools is an independent community tool - not affiliated with Google, Shopify, or the UCP consortium.

Top comments (0)