← Articles

UCP Identity Linking Revert: Mechanism Registry Pulled Back

Revert UCP Identity Breaking Change

April 3, 2026 · Ilya Grigorik · PR #329

About the Author

Ilya Grigorik is a Principal Engineer at Google and co-author of the Universal Commerce Protocol specification. He previously led web performance initiatives at Google and authored "High Performance Browser Networking." His involvement in UCP core decisions signals specification-level priority.

In a significant development for the Universal Commerce Protocol, Ilya Grigorik has reverted the identity linking mechanism registry that merged just two weeks ago. PR #329 rolls back PR #265, which had introduced an extensible registry pattern for identity providers.

⚠️ What This Means for Implementers

If you began implementing the mechanism registry pattern from PR #265, pause that work. The specification is returning to the previous identity linking model while the design is reconsidered.

What Was Reverted

The original PR #265 introduced several breaking changes to identity linking:

Mechanism registry — A discoverable pattern for identity providers (OAuth, passkeys, wallet attestation)
Capability-driven scopes — Automatic scope derivation based on requested capabilities
Trust level declarations — Explicit trust tiers for different authentication mechanisms

The revert returns UCP to the simpler, hardcoded identity linking model that preceded it.

Why This Matters

This revert is notable for several reasons:

Specification stability concerns — A breaking change that merged after extensive review is being pulled back, suggesting the review process may need strengthening
Timeline pressure — With UCP adoption accelerating, specification churn creates integration risk for early adopters
Design complexity — The mechanism registry pattern may have introduced more complexity than the problem warranted

Technical Context

The reverted mechanism registry was designed to solve a real problem: UCP's original identity linking was tightly coupled to OAuth 2.0. As enterprise use cases emerged requiring SAML, passkeys, and wallet-based authentication, the specification needed extensibility.

However, the registry pattern introduced significant complexity:

// Before (simple, direct)
{
  "identity_link": {
    "provider": "google",
    "scope": ["profile", "email"]
  }
}

// After PR #265 (registry-based, reverted)
{
  "identity_link": {
    "mechanism": "oauth2",
    "registry_entry": "google_oauth",
    "capability_scopes": ["commerce.order.read"],
    "trust_level": "verified"
  }
}

The registry approach required implementers to maintain mechanism definitions, handle capability-to-scope mappings, and validate trust level transitions — overhead that may not have been justified for current adoption levels.

What Happens Next

The revert PR doesn't close the door on identity extensibility — it pauses the current approach. Expect:

Revised proposal — A simpler extensibility mechanism that doesn't require full registry infrastructure
Incremental rollout — New authentication methods added individually rather than via generic registry
Stronger review gates — Breaking changes may face additional scrutiny before merge

Implications for Adopters

For teams building on UCP:

Early adopters — Continue with OAuth 2.0-based identity linking; it remains the stable path
Enterprise SSO needs — Work with your UCP implementation vendor; most support SAML behind OAuth facades
Wallet/Web3 use cases — Wait for revised extensibility guidance before building production integrations

This revert is a healthy sign of specification governance — better to pull back a premature abstraction than force adoption of unstable infrastructure. The identity extensibility problem remains real; the solution needs more iteration.

Related: UCP Identity Linking Mechanism Registry — Breaking Change (original merge analysis)