MCP OAuth v1.1: remaining 2026-07-28 spec forward-work (SEP-2350 scope step-up, CIMD)

[heskew]

Forward-work remainder split out of #100 (the 2026-07-28 RC tracker, now closed — everything actionable there shipped). Neither item here is RC-required; both are v1.1 features we cannot act on yet.

1. SEP-2350 — scope accumulation in step-up flows · blocked on per-tool scopes

"When re-authorizing, clients SHOULD include these scopes alongside any previously granted scopes to avoid losing permissions needed for other operations."

v1 token scoping is role-level (matching human OAuth); per-tool scoping was explicitly deferred to v1.1 in #86 (resolved decisions, item 2). Step-up + scope accumulation only becomes meaningful once per-tool scopes exist. Unblocks when: per-tool scopes land.

2. Client ID Metadata Documents (CIMD) · deferred (new registration path)

The RC demotes DCR to fallback; the client-registration priority order is:

1. pre-registered client information
2. Client ID Metadata Documents — if the AS advertises client_id_metadata_document_supported
3. Dynamic Client Registration as fallback

We satisfy "at least DCR" today, so nothing breaks. Implementing CIMD means:

• AS-side flow: when client_id is an HTTPS URL, fetch the metadata document, validate client_id matches the URL exactly, validate redirect_uri against the document, cache per HTTP cache headers
• Advertise client_id_metadata_document_supported: true in AS metadata
• Security: SSRF protection on the AS-side fetch; localhost-redirect-impersonation mitigations (RC §"Localhost Redirect URI Risks")

Worth doing when a real client that prefers CIMD shows up, or when the RC promotes to stable and adoption picks up.

3. (Optional, tiny) SEP-2207 offline_access MAY

The required parts of SEP-2207 are satisfied (refresh tokens implemented; PRM correctly does not advertise offline_access in scopes_supported). The remaining bit is a MAY: honoring an explicit offline_access scope opt-in at the token endpoint / listing it in AS metadata scopes_supported. Fold into whichever of the above lands first, or ignore.

When this moves

• Re-verify against the final spec text once the RC promotes to stable on July 28, 2026 (RC→stable diffs are usually small but nonzero).
• SEP-2350 → sub-issue when per-tool scopes (v1.1, Add MCP OAuth flow support #86) is scheduled.
• CIMD → own PR when prioritized.

Context

• Predecessor: MCP OAuth v1.x: 2026-07-28 RC spec changes #100 (full RC catalog + per-SEP analysis — see it for spec quotes)
• Shipped from that catalog: iss/SEP-2468 (MCP OAuth: emit iss on authorization responses (SEP-2468 / RFC 9207) #149/Emit RFC 9207 iss on MCP authorization responses #150, v2.1.1) · path-suffixed PRM discovery/SEP-2351 (fix: MCP OAuth endpoints broken on Harper 5.1.x (well-known 404 + response envelope) #133/MCP OAuth Stage 5: withMCPAuth bearer-token guard (#95) #134) · SEP-837/2352/2207-required were already satisfied
• Related: core-side modern-era tracker MCP 2026-07-28 "modern" era: stateless protocol support (dual-era server) harper#1548
• Spec: https://modelcontextprotocol.io/specification/draft/basic/authorization

---

🤖 Generated with Claude Code