MCP delegated identity: platform-side ID-JAG broker (Forge-side collapses to assertion-forward)

[initializ-mk]

Layer: platform (initializ). Forge-side ≈ nothing. Per design-tool-registry.md §19, the Strategy A/B fork moves entirely to the platform: Forge's type: user resolver (#317) asks the platform for a token on behalf of subject X, and the platform decides how — interactive consent or ID-JAG. Forge never learns which. ID-JAG was never a "Strategy B in Forge." The broker work lives in initializ/aip/mcp-delegated-identity-broker.md.

What's left in the Forge repo

One thing, and it's already covered by #317: carry the raw assertion from the request edge (#317 item 1) and forward it to the platform token endpoint as part of the delegated request:

POST {token_endpoint}  { server, subject, user_assertion }  → { access_token }

That user_assertion is what a broker-side ID-JAG (RFC 8693 → RFC 7523) exchange consumes. There is no id_jag in Forge config, no method selection, no fallback logic in Forge — Forge declares type: user; the platform chooses the mechanism. This issue is retained only as the tracking anchor for that remnant + the pointer to the broker work.

Why the bulk isn't Forge (§18.1, test 3)

Whoever is registered at the IdP as the client permitted to request grants is the broker, and appears in the token's actor chain.

That role cannot live in an OSS agent framework: it would make every Forge deployment an IdP-registered broker and move credential minting inside the agent's own trust domain — readable by a malicious builder in Phase 1 (§15.1).

The split (§18.4 / §19)

Work	Owner	Where
Carry the raw assertion + forward to the token endpoint	Forge	#317 item 1 (same work)
Choose interactive-consent vs ID-JAG (opaque to Forge)	Platform	broker doc
Token exchange (RFC 8693) + JWT-bearer redemption (RFC 7523)	initializ (broker)	broker doc
IdP client registration + trust wiring (actor chain)	initializ (broker) — decisive	broker doc
Vault (per-user/service refresh tokens)	initializ (broker)	broker doc
Scope decisions (per instance ceiling, A6)	initializ (broker)	broker doc
Public callback + consent delivery	Platform (managed)	§18.4 / #317 items 4–5
Resolver selection / "fallback"	Platform (not Forge)	the platform chooses; Forge only declares type:

Integrate, don't rebuild (§18.4)

Where Kong is present (FanDuel), id-jag-relay + token-exchange already implement the exchange/redemption mechanics (§6, B1) — integrate, don't rebuild. But Kong does not manage permissions: it introspects token claims and allows/denies; the client registrations, secrets, vault, and scope decisions stay with initializ. There is no deployment where credential authority moves to the gateway.

Prerequisites — none is the PDP (§18.7)

ID-JAG (the platform's choice, not a Forge feature) waits on three things:

• Server-side EMA support — private beta, Atlassian Rovo only; public Linear will not have it (public Linear is plain OAuth → the interactive resolver, Epic: runtime per-user, ephemeral per-session MCP OAuth (interactive login via Slack / A2A UI) #317). The original Linear motivating example was wrong; the correct one is Atlassian Rovo (§7.2).
• An Okta-class IdP with XAA.
• A delegated use case with a real user subject. Most Forge agents are agent-principal (Agent-principal MCP OAuth resolver (type: platform) — unblocks headless-agent startup #324) with no requesting human — ID-JAG's subject is a user assertion, a semantic mismatch without a human.

Interim managed path (§18.3): the broker's oauth_3lo_user (vaulted per-user refresh) delivers real per-user delegation without EMA/XAA — "the vault ID-JAG later deletes." So the broker ships value before ID-JAG's prerequisites land; ID-JAG is the end-state the platform migrates to, invisibly to Forge.

Authentication ≠ authorization (§18.5)

• A valid token is necessary, not sufficient — acquisition never implies authorization.
• Ordering — delegation follows authorization, never precedes it. Never mint speculatively.
• Token never enters the agent's reasoning context (§8 invariant 4). Broker/egress proxy holds it and injects at egress (§17.3) — never through the agent.
• Risk-tiering: writes/destructive route through DEFER regardless of token validity, seeded by A9 side-effect class (§4.2). Enforceable now (DEFER v0.17.0).
• One-time OAuth consent is NOT a per-action fallback. 3LO consent is connection-level and permanent — "this app may write as me," forever. It cannot substitute for DEFER on a specific write (the connection-vs-per-action gap, §2). Interactive consent is a valid resolver choice; it is not an authorization fallback.
• The inversion: the less interactive the acquisition, the more the per-action gates carry the weight — frictionless delegation and write-gating ship together.

Related

Broker impl: initializ/aip/mcp-delegated-identity-broker.md · seam + assertion plumbing: #317 · agent-principal sibling: #324 · discovery/DCR: #316 · AARM R10 #319 · authority design-tool-registry.md §18–§19.

[initializ-mk]

Governance framing: this is Strategy B of AARM requirement R10 — delegated identity / on-behalf-of downstream authorization (#319). R9 (#215) scopes what a tool may do; R10 scopes whose authority it acts under. ID-JAG is the zero-interactive, enterprise-federated mechanism; Strategy A (interactive) is #317.