Add 10.4.10: bind MCP client consent and authorization to the server's connection endpoint (#1119)

[aminekhazraj]

Closes #1119

Summary

Adds 10.4.10 to C10.4: MCP client consent and authorization must be bound to the server's connection endpoint, with user re-approval required when that endpoint changes. Wording is @ottosulin's from the issue thread; level (L2) and placement (C10.4, alongside 10.4.8 and 10.4.9) are as agreed there.

Changes

In 1.01-dev/en/0x10-C10-MCP-Security.md:

• 10.4.10 is added:
  • "Verify that MCP clients bind each approved MCP server's granted consent and authorization to the connection endpoint approved for that server, and require user re-approval before any further interaction once that endpoint changes."

Background

10.4.8 binds client re-approval to what a tool declares; nothing binds it to where the client connects. A client that has approved server S retains that approval when S's connection endpoint changes — including a path-only rebind on an already-allow-listed host, which leaves tool definitions byte-identical, so 10.4.8 and 10.1.2 both remain satisfied while cached consent, credentials, and tool-call payloads flow to the new destination. Full analysis and testability procedure in #1119.

Why "connection endpoint" rather than "canonical URI": the MCP spec permits a client to use https://host as the canonical URI for a server at https://host/tenant-a/mcp (most-specific is a SHOULD), so a path-only rebind can leave the canonical URI — and with it the resource value and token audience — unchanged. The connection endpoint is the URL the client actually opens the transport connection to, as configured, which may be more specific than the canonical URI the client derives for token audience. Neither term currently appears in C10, so the definition is recorded here.

Rationale

• Not covered by SEP-2352 (Authorization Server Binding, 2026-07-28 spec): SEP-2352 binds client registration credentials to the authorization server's issuer and forces re-registration when the AS changes. This requirement binds user consent and tool-call data to the resource server's endpoint. An AS-keyed rule does not fire when the server endpoint moves and the AS stays put. SEP-2352 is precedent for the principle (destination changed, so prior state must not carry), not coverage of this case. The DCR deprecation reinforces the gap: CIMD client IDs are "portable across authorization servers" with no re-registration when the AS changes.
• Comparison discipline: per @Santoshkumarpuppala's observation in [C10.4] Granted MCP server authorization is not bound to the server's connection endpoint #1119, endpoint comparison must not let normalisation erase a real difference. The spec already sets that discipline for iss validation — simple string comparison per RFC 3986 §6.2.1, with no scheme or host case folding, default-port elision, trailing-slash, or percent-encoding normalisation before comparison. That rule is written for mix-up defence, so it is cited as discipline, not as coverage of endpoints.
• Testable, black-box, client-side: approve server S at endpoint E1; change the configured endpoint to E2 without altering any tool definition (run once varying only the path, once varying host/port); trigger a tool call. Pass: the client blocks pending fresh user approval before opening a connection or transmitting anything to E2. Fail: the client proceeds under the prior approval.

Scope

One requirement, 1.01-dev only. Does not restate token-audience or registration-binding obligations already in the MCP spec; it verifies the client-side consent binding the spec does not oblige.

References

• MCP Authorization (2026-07-28), Canonical Server URI: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization#canonical-server-uri
• MCP Client Registration (2026-07-28), Authorization Server Binding (SEP-2352): https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#authorization-server-binding
• MCP Authorization (2026-07-28), Authorization Response Validation: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization#authorization-response-validation
• RFC 8707 §3, Security Considerations (tenant-identifying path component): https://www.rfc-editor.org/rfc/rfc8707.html#section-3