Skip to content

feat: delegated identity providers and accelerated IdP flow#423

Open
igrigorik wants to merge 2 commits intomainfrom
feat/identity-with-idp
Open

feat: delegated identity providers and accelerated IdP flow#423
igrigorik wants to merge 2 commits intomainfrom
feat/identity-with-idp

Conversation

@igrigorik
Copy link
Copy Markdown
Contributor

The v1 design (#354) only supports direct OAuth between platform and business: every business requires a fresh redirect, fresh consent, fresh credentials. In practice, many businesses already offer delegated IdPs (Sign in with Google, Shop, Apple, etc.) to give their users accelerated sign-in and account creation+linking. Platforms that already hold an identity at one of those IdPs benefit too: they can complete the link without re-prompting the user, which is essential for agentic flows where redirects and per-merchant consent screens are prohibitive.

This PR closes the gap by letting a business advertise the IdPs it trusts. Platforms that already hold a token at one of those IdPs chain identity to the business via a back-channel token exchange — no redirect, no extra prompt — and the business still issues its own access tokens under its own authority.

How a business advertises providers

Strict delegation: the business uses an external IdP and does not run its own oAuth infrastructure. Platforms authenticate via a listed provider (in this example accounts.shopify.com):

"config": {
  "providers": {
    "com.shopify.accounts": { "auth_url": "https://accounts.shopify.com/" }
  },
  "scopes": { "dev.ucp.shopping.order:read": {} }
}

Hybrid: the business self-lists alongside an external IdP. Platforms pick either the IdP for accelerated flow, or the business directly (Account Linking Flow), based on what they already hold a token for or what the user prefers:

"config": {
  "providers": {
    "com.shopify.accounts": { "auth_url": "https://accounts.shopify.com/" },
    "com.example.merchant": { "auth_url": "https://merchant.example.com/" }
  },
  "scopes": { "dev.ucp.shopping.order:read": {} }
}

Checklist

  • Core Protocol: Changes to the base communication layer, global context, or breaking refactors.
  • Capability: New schemas (Discovery, Cart, etc.) or extensions.
  • Documentation: Updates to README, or documentations regarding schema or capabilities.
  • I have followed the Contributing Guide.
  • I have updated the documentation (if applicable).
  • My changes pass all local linting and formatting checks.
  • (For Core/Capability) I have included/updated the relevant JSON schemas.

Adds delegated authentication to the identity linking capability so
businesses can outsource user authentication to trusted external IdPs
and let platforms chain identity to new businesses without a fresh
browser-based OAuth flow.

Schema (source/schemas/common/identity_linking.json):
* New `provider` $def: `auth_url` (URI, required) + `type`
  discriminator (default `oauth2`, reserved for future non-OAuth
  mechanisms like wallet attestation).
* New `config.providers` map keyed by reverse-domain identifier in
  the business schema.

Spec (docs/specification/identity-linking.md):
* `config.providers` semantics: absent = business is implicitly its
  own (and only) IdP; present = strict whitelist, platforms MUST NOT
  fall back to direct OAuth on the business domain; businesses
  self-list to opt back in alongside externals.
* New "Accelerated IdP Flow" section: RFC 8693 token exchange at the
  IdP -> RFC 7523 JWT bearer assertion grant at the business token
  endpoint. Profiles draft-ietf-oauth-identity-chaining-08 with two
  UCP-specific tightenings: token exchange MUST use `resource` (not
  `audience`); JWT grant MUST carry single-valued `aud` and unique
  `jti`.
* JWT grant validation defers to RFC 7523 §3 with UCP-specific
  constraints (iss in `config.providers`, fail-closed JWKS, jti
  single-use).
* Token Lifecycle: SHOULD NOT issue refresh tokens on JWT bearer
  grants (per draft §5.4); dual-layer revocation at IdP + business
  on unlink.
* New "IdP Requirements" section: AS metadata must advertise
  `revocation_endpoint`, `jwks_uri`, and the token-exchange grant
  type.
@igrigorik igrigorik added this to the Working Draft milestone May 8, 2026
@igrigorik igrigorik self-assigned this May 8, 2026
@igrigorik igrigorik requested review from a team as code owners May 8, 2026 04:53
@igrigorik igrigorik added the TC review Ready for TC review label May 8, 2026
@igrigorik igrigorik requested review from a team as code owners May 8, 2026 04:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

TC review Ready for TC review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant