The bridge validated the `iss` claim inside an access token (RFC 9068) but had
no check on the authorization *response*. Those guard different steps. The
token claim says who signed a credential already in hand, which only means
something once that credential is trusted; RFC 9207 guards the step before it.
In a mix-up attack a client is steered to a malicious authorization server that
returns a code or token minted elsewhere. With no issuer on the response the
client cannot tell the answer came from a different server than the question,
and forwards the credential to the honest one. Comparing the response's `iss`
against the server the request actually went to is what breaks that, and it is
the check MCP's 2026-07-28 OAuth 2.1 hardening expects a client to perform.
A missing `iss` fails closed rather than being read as benign: a response that
cannot name its issuer proves nothing about its origin, which is precisely the
condition the check exists to rule out.
Decoding is the caller's job and is documented as such. The parameter arrives in
a redirect URI query where a did:key issuer's colons are percent-encoded, and
guessing at decoding here would silently compare an encoded string against a
decoded issuer — a test pins that a still-encoded value is refused rather than
quietly accepted.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
3172a43fbd