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

[heskew]

Forward-work remainder split out of #100 (the 2026-07-28 RC tracker, now closed — everything actionable there shipped). Nothing here is RC-required; what remains is one blocked v1.1 feature and a tiny MAY.

Update 2026-07-11: CIMD — originally item 2 of this issue — has shipped via the #159 train: #167 (from #166) implemented the AS-side flow (HTTPS-URL client_id fetch with exact-match validation, caching, SSRF-protected pinned fetch, localhost-redirect mitigations) and advertises client_id_metadata_document_supported; #171 added the fixed per-URL fetch rate limiter. Removed from the list below.

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. (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 SEP-2350 when it lands, 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.

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) · CIMD (MCP OAuth: Client ID Metadata Documents (CIMD) — URL client_ids with SSRF-guarded resolution #166 → feat: Client ID Metadata Documents with SSRF-guarded resolution + consent interstitial (#166) #167, rate-limited in feat(mcp): rate-limit client_credentials issuance and CIMD fetch attempts (#163) #171) · 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

[heskew]

Item 2 (the SEP-2207 offline_access MAY) is implemented in #192: AS metadata advertises scopes_supported: ["offline_access"], PRM keeps it out, and the opt-in gate ships as mcp.refreshTokenRequiresOfflineAccess (default off — default issuance policy unchanged). Remaining here after that merges: SEP-2350 (blocked on per-tool scopes, v1.1) and the July 28 final-spec re-verify.

---

🤖 Posted by Claude on Nathan's behalf

[heskew]

From the 2026-07-28 conformance pass (#204 adds docs/mcp-oauth-conformance.md, a requirement→code→test matrix). Two concrete code-side deltas surfaced for this issue's re-verification — neither is a security gap:

1. RFC 9068 typ: at+jwt access-token header not set. tokenIssuer.ts:signAccessToken emits alg+kid but leaves typ as the default JWT. The claims shape (iss/sub/aud/exp/iat/jti/client_id/scope) is fully RFC 9068-conformant and tested; only the media-type header is missing. withMCPAuth verifies by alg/kid/claims, so impact is low — but a strict RFC 9068 resource server keys on typ: at+jwt.
2. Token error-response no-store header has no test. token.ts:errorResponse() applies the same NO_STORE_HEADERS constant as the success path, but only the success path asserts it (token "sets no-store cache headers on a successful token response"). Add an error-path assertion.