UCP Identity Linking and Loyalty: What the Spec Leaves Open

Direct Answer UCP standardizes account delegation and the presentation of loyalty membership, tiers, benefits and earn forecasts. Its loyalty extension does not standardize points balances or redemption. For technical leaders evaluating agent-mediated commerce, that boundary matters: a linked account, a recognized membership and a usable reward are separate integration questions.

We read the released UCP 2026-08-25 specifications to see where loyalty fits, and published the result as an identity linking and loyalty analysis. It is written for CTOs and technical leaders deciding where authorization, membership verification and reward operations belong in their architecture. This post is the short version.

Disclosure: StabileRewards is a loyalty vendor, so we have a commercial interest in loyalty support in UCP. The analysis says so up front and labels our interpretations as analysis.

Three questions, three different answers

An agent that wants to use a shopper's loyalty program has to settle three things. The spec treats them separately.

Question	UCP capability	Status
Can the agent act for this user?	dev.ucp.common.identity_linking (OAuth 2.0, PKCE)	Specified
Is this person a member, and which benefits apply?	dev.ucp.common.loyalty extension	Specified
Can they see or spend a points balance?	None in the loyalty extension	Left to the payment instrument or a future redemption capability

Advertising one of these does not establish support for the others. When you review an integration, ask each question on its own.

Account delegation is not loyalty presentation

Identity linking lets a platform obtain authorization to act for a user at a business. Its direct flow is OAuth 2.0 Authorization Code with PKCE (S256), which supplies account context and delegated permissions.

The loyalty extension does a different job. It carries membership, tiers, benefits and earn forecasts inside catalog, cart and checkout responses, and a business can advertise it for only some of those. Applicable monetary benefits show up in the normal price fields and totals.

An earn forecast is not a balance

Here is the shape of a loyalty response, abbreviated. The field names follow the spec's example; the values are illustrative:

{
  "loyalty": {
    "com.example.retail_club": {
      "id": "membership_1",
      "name": "Retail Club",
      "display_id": "****5678",
      "provisional": false,
      "rewards": [{
        "currency": {
          "name": "LoyaltyStars",
          "code": "LST"
        },
        "earning_forecast": { "amount": 30 }
      }]
    }
  }
}

The response says who the member is and what this cart would earn. It says nothing about how many points they already hold or how to spend them. The spec leaves redeemable balances and stored value to the negotiated payment instrument or a future redemption capability. A team that sees loyalty data in a response should not conclude that an agent can look up a balance or redeem one. Those need their own supported path.

Linking is not the only way to get recognized

A platform can submit membership claims in context.eligibility. An accepted claim that has not been verified gets provisional recognition, and accepted claims must be resolved before checkout completes. Provisional recognition does not unlock stored personal data.

The reverse also holds: linking alone does not make someone a member. It gives the business an authenticated account from which membership may be determined. A business can still require user authorization for specific operations through config.scopes, so the real design question is where authorization and verification are required in your flow.

Protocol support is not deployment, and it is not selection behavior

In our four-store Shopify sample on 2026-09-24, the platform-hosted UCP profiles showed identity linking and no loyalty capability. Our two-store re-check on 2026-10-21 showed the same. Those are observations about the sampled stores on those dates, not a platform-wide audit.

Whether exposing loyalty value changes which merchants agents pick is an unproven hypothesis. The specifications we reviewed define no merchant-ranking function and say nothing about how shopping surfaces weight loyalty. Test the integration you care about before making claims about selection.

What we did not verify

We did not establish platform-wide deployment, support in every shopping surface, or any effect on merchant selection. The analysis is not evidence that a particular integration can complete a balance lookup or a redemption.

For the protocol details, the access-level comparison and the payment-authorization layers, read the full analysis or download the PDF. If we got something wrong, or you have evidence that points the other way, write to info@stabilerewards.com and we will correct it.

The released specs are on ucp.dev: identity linking and the loyalty extension.