PRM resource equals the canonical server URI

How to fix this

Set `resource` in the Protected Resource Metadata to this server's canonical URI (RFC 8707 §2). It is the audience every token will be minted for, so a wrong value produces tokens your server should reject.

How the validator checks this

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

pass

resource matches the probed server URI (…)

warn

resource is "…" but this server was probed at "…". If they genuinely differ, every token the client requests will carry the wrong audience — but a proxy or vanity domain can also explain it, so this is a warning rather than a failure.

fail

Protected Resource Metadata has no `resource` field — the client has no canonical URI to request a token for

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-002, MCP-AUT-009.

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-004Each listed authorization server exposes RFC 8414 or OIDC discovery metadata
• MCP-AUT-005AS advertises authorization_response_iss_parameter_supported: true
• 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