The MCP release candidate for 2026-07-28 dropped last week. The biggest change is the protocol going from stateful to stateless. The rest of the coverage will go to MCP Apps and Tasks. The authorization hardening section is short, has no diagrams, and reads like a changelog. That is what mature protocol work usually looks like.

The six SEPs in this section pull MCP authorization closer to how OAuth 2.0 and OpenID Connect already run in production. From the identity side, that is the right kind of work for a protocol at this point.

1. iss validation on authorization responses (SEP-2468 / RFC 9207)

Mix-up attacks have been a known OAuth problem for almost a decade. RFC 9207 is the fix: the AS includes an iss parameter on the response, the client validates it. Most production OAuth deployments either implemented it or shrugged, because they only talk to one AS.

MCP changes the math. A single host (Claude, Cursor, an IDE plugin) talks to dozens of MCP servers, each potentially fronting a different authorization server. The mix-up attack surface is wider than in any traditional OAuth deployment I have worked on. Making iss validation mandatory now, and signaling that future versions will reject responses without it, is the right call.

If you run an AS that fronts an MCP resource, start emitting iss now.

2. application_type in Dynamic Client Registration (SEP-837)

Anyone who has tried to register a desktop or CLI MCP client via DCR has hit this one. The AS defaults application_type to "web", the client sends a http://127.0.0.1 redirect URI, and registration fails because that combination is not allowed for web clients.

The fix is to have the client declare its application_type during DCR. The friction it removes is real: a lot of the integration support tickets I see start with a localhost redirect being rejected by an AS that assumed a server-side client.

Or, hear me out, you could skip the DCR conversation entirely and go register with CIMD instead.

3. Binding credentials to issuer, re-registering on migration (SEP-2352)

A subtle one. If an MCP resource migrates between authorization servers, the previously issued client credentials should not silently keep working against the new AS. SEP-2352 binds registered credentials to the issuer they came from and forces re-registration on migration.

This closes a quiet trust transfer hole. In enterprise deployments where the IdP fronting a resource changes (more common than people admit), you can end up with a client that keeps presenting credentials minted for a different trust domain. Forcing re-registration also pushes client implementers to handle the migration path cleanly, which most do not yet.

4. Refresh tokens from OIDC-style authorization servers (SEP-2207)

OIDC has always had a footnote around refresh tokens: you need the offline_access scope to get one. In practice, several providers were already returning refresh tokens by default without it. The spec just stabilizes that behavior and documents how an MCP client should request refresh tokens against an OIDC AS.

This is the kind of thing you only appreciate after the third support ticket about “my agent stopped working after an hour.” Long-running agents need refresh tokens. There is now a documented way to ask for them.

5. Scope accumulation during step-up (SEP-2350)

This one is about delegation. Step-up is when an agent has a token with some scopes and needs more to complete a task. The question SEP-2350 answers: do the new scopes replace the old ones, or accumulate?

Accumulate, in MCP’s model. That matches how a human-driven OAuth flow usually works (you grant a thing, then another thing, both stick). For agents this is the more useful default, because an agent’s task routinely crosses tool boundaries and each new tool can need a different scope.

The harder question this SEP does not try to solve: when an agent steps up, on whose authority is it stepping up? The user’s, or its own? MCP today assumes the user’s, via the same browser-based consent flow. As agent identity matures (and it will), step-up will need to treat the agent as a distinct identity with its own authority surface, separate from the user’s. Different post.

6. .well-known discovery suffix (SEP-2351)

Pure cleanup. Discovery in MCP has been muddled by inconsistent suffix conventions. SEP-2351 fixes the suffix.

The bigger picture

MCP authorization is converging on the OAuth and OIDC patterns that already run in production. That convergence is what makes the protocol safe to deploy behind a real enterprise IdP.

Adjacent standards work is already covering the agent-specific identity problems. Cross-App Access, ID-JAG, and the IETF drafts on OBO for agents are in flight. MCP does not need to re-invent that work. When those drafts stabilize, MCP can adopt them, and the alignment work in this release is what makes that adoption path clean.

The operational challenge is the transition period. Client implementations will land at different speeds, and AS operators will need to keep the old behaviors running until enough clients support these SEPs fully. Worth tracking client by client.

This release removes a long list of small reasons not to run MCP in front of your enterprise IdP. After 2026-07-28, that list is shorter than it has ever been.