Implement SEP-1933: Workload Identity Federation (Extension)

This is a tracking issue for implementation of SEP-1933 (extension id io.modelcontextprotocol/auth/wif).

Summary

Workload Identity Federation lets an MCP client running with no user present authenticate to an authorization server by presenting a platform-issued workload JWT (Kubernetes projected service account token, SPIFFE JWT-SVID, cloud identity token) via the RFC 7523 jwt-bearer grant. No client secret is provisioned and no dynamic client registration happens; the workload's existing platform identity is the credential. The TypeScript SDK needs a client-side provider for the jwt-bearer grant flow: assertion sourcing (static or per-request callback), non-interactive operation with no authorization-code fallback, and conformance with the auth/wif-jwt-bearer scenario.

Status

• Client conformance scenario merged and extension-tagged: modelcontextprotocol/conformance#268, reclassified in modelcontextprotocol/conformance#401.

• This SDK already tracks the gap: auth/wif-jwt-bearer was added to the client expected-failures baseline in #2557.

• Roadmap agreed on the SEP thread (comment):

  The best path forward I see is:

  1. conformance test
  2. SDK implementation
  3. submit for official extension consideration

  We've got (1) for WIF, and in progress for DPoP, and (2) is much more feasible now with betas having stabilized on the python & typescript sdks

  This issue is step (2) for the TypeScript SDK.

Related Issues & PRs

• Implementation PRs: #2572
• Related PRs: #2557 (baseline entry), modelcontextprotocol/conformance#268, modelcontextprotocol/conformance#401
• Related Issues: modelcontextprotocol/conformance#223 (client conformance tracking)

Read the auth/wif-jwt-bearer conformance scenario and the expected-failures baseline added in #2557 first. Trace the TypeScript SDK's client-side authentication provider entry point, then verify support for static or callback-sourced assertions, non-interactive operation, and the jwt-bearer flow. Done means the conformance scenario passes without an authorization-code fallback.