RFC 9207 iss validation in the 2026-07-28 MCP spec, and Sume OAuth

The MCP specification dated 2026-07-28 lists RFC 9207 iss validation as SEP-2468. For a client, that means checking that the authorization response names the issuer you started with. For Sume, the issuer you should expect is https://mcp.sume.com: the protected-resource metadata names the MCP origin as the authorization server, not www.sume.com or app.sume.com. Whether Sume's authorization response includes an iss parameter is not stated in the Sume docs, so test your client against it rather than assuming.

What is documented

The Sume flow, step by step

The docs describe six steps. The client connects to the MCP endpoint and receives an OAuth challenge and protected-resource metadata. It sends the user to /oauth/authorize, which redirects to the consent page on the MCP host. After sign-in, the consent page shows Read locked on and a Write toggle that is off by default. The client then exchanges the code with PKCE and calls the MCP endpoint with the bearer token.

www.sume.com is still a secondary and deprecated authorization-server surface. The metadata does not advertise it now, and the docs say not to send interactive clients to app.sume.com.

What a client author should check

• Record the issuer from the metadata before you redirect, and compare it with the iss value in the response if one is present.
• Reject a response whose issuer does not match. Do not fall back to a different authorization server.
• Do not hard-code the consent URL. Use the metadata endpoints.
• Remember scopes: mcp:read by default, mcp:write opt-in, no mcp:paid.

Why it matters for paid tools

An OAuth session with mcp:write can call paid tools. A wrong-issuer redirect is the sort of mix-up that RFC 9207 is meant to catch, and a bearer token that can spend is worth that check. Spend is also gated by wallet and admission, and max_spend_usd is enforced when you send it.

A test plan for your client

Run three cases against a staging setup. First, the normal path: the issuer matches and login succeeds. Second, a response whose iss names another host: the client should stop. Third, a response with no iss at all: decide what your client does, and document it, since the Sume docs do not say whether the parameter is sent.

Then confirm after login that the granted scope is what you expect by calling tools_list: with Write off you should see read-only tools.