feat: Brokered MCP Server with CIMD Authentication

[nkempter]

Question: does #988's stance against brokering a downstream MCP server's own OAuth (CIMD) still stand?

Context

MCP servers that authenticate the real end user via their own IdP using Client ID Metadata Documents (CIMD) — an increasingly common, spec-endorsed pattern (e.g. @backstage/plugin-mcp-actions-backend makes CIMD its primary path) — can currently only be onboarded to the registry in catalog mode. None of the egress modes broker a downstream's own IdP (oauth_user needs a pre-registered client_id/secret; obo_exchange needs the backend to accept a gateway-minted JWT), and caller auth headers are stripped before any non-internal upstream (_forward_headers, #1266), so a client-supplied backend token can't traverse the gateway either.

We found #988, which deliberately declines gateway-brokered downstream-IdP auth ("we'd be running a federated identity service") and designates catalog mode as the pattern for backends with their own IdP.

The concern (opinion)

For CIMD-authenticated servers, routing them to catalog mode is — in our view — a reduction of the product from (gateway + registry) down to (registry only): discovery still works, but everything the gateway adds on the data path (a single governed endpoint, centralized identity/entitlement enforcement, audit, egress control) is dropped. As CIMD adoption grows, the gateway half of the project quietly stops applying to a growing class of servers — which feels like it undercuts the reason the project is a gateway and not just a registry.

We also note work that looks adjacent to brokering such downstreams: public PKCE egress clients (#1613, merged), client-side DCR on egress (#1519), and publishing the registry's own CIMD document (#992).

Questions

1. Does the position in Umbrella: Coding-Assistant OAuth Integration (catalog + gateway modes) #988 still stand as the intended long-term design?
2. Given feat(egress): support public OAuth clients (token_endpoint_auth_method=none) with PKCE #1613 / feat(egress): client-side Dynamic Client Registration for Atlassian Rovo authv2 #1519 / [Phase 4] Publish CIMD (Client ID Metadata Document) for AI Registry Tools MCP client #992 moving the gateway toward acting as a dynamic OAuth client to downstreams, is brokering a CIMD (or DCR) downstream on the data path being reconsidered — or are those strictly scoped to other goals?
3. Is catalog mode considered the permanent answer for CIMD-authenticated servers, with the gateway intentionally staying out of their data path?

[nkempter]

Can anyone confirm if this is now on the roadmap?
Or does the position something like this is not planned still stand?