AS advertises authorization_response_iss_parameter_supported: true

How to fix this

This is the honest, indirect form of RFC 9207 iss checking — iss validation is a CLIENT obligation and cannot be tested by probing a server. See /02-SPEC-VERIFICATION-2026-07-28.md §2.3.

How the validator checks this

Probe P8.3, against a streamable-http server on the modern protocol. What it reports:

pass

Every authorization server advertises authorization_response_iss_parameter_supported: true

warn

Does not advertise authorization_response_iss_parameter_supported: …. Without it a client cannot confirm which authorization server answered — the RFC 9207 mix-up defence.

Quoted from the probe that runs this check, so it cannot drift from what the validator actually reports.

This rule is checked deterministically: a fail here is a certain violation, not an inference.

Checked in the same request as MCP-AUT-004, MCP-AUT-010, MCP-AUT-011.

Check your own server against this rule

The validator makes real protocol requests and reports this rule as pass, warn or fail alongside the other 78. Validate a server or read how the check works.

Other Authorization rules

• MCP-AUT-001Unauthenticated request returns 401 with WWW-Authenticate resource_metadata
• MCP-AUT-002RFC 9728 Protected Resource Metadata is served and valid
• MCP-AUT-003PRM resource equals the canonical server URI
• MCP-AUT-004Each listed authorization server exposes RFC 8414 or OIDC discovery metadata
• MCP-AUT-006WWW-Authenticate includes a scope parameter
• MCP-AUT-007Insufficient scope returns 403 with error="insufficient_scope"
• MCP-AUT-008Tokens with a foreign audience are rejected
• MCP-AUT-009offline_access absent from scopes_supported / challenge scope
• MCP-AUT-010AS advertises S256 in code_challenge_methods_supported
• MCP-AUT-011AS supports Client ID Metadata Documents, not DCR alone