A client builds the URL https://auth.example.net/.well-known/oauth-authorization-server and the document it receives contains "issuer": "https://login.example.org". What must the client do?
Select an answer to reveal the explanation.
Short Explanation
If you dial one number and a different company answers claiming to be someone else, you hang up. Metadata works the same way: the issuer inside has to match the issuer you used to build the URL, character for character. A mismatch means you don't use that document at all.
Full Explanation
The authorization server discovery specification requires that after retrieving a metadata document, MCP clients MUST validate it as RFC 8414 or OpenID Connect Discovery requires: the issuer value in the document MUST be identical to the issuer identifier used to construct the well-known URL, and if they differ the client MUST NOT use the metadata. The specification gives this very example, a document fetched from an attacker's host claiming an honest issuer, which must be rejected. Using the metadata while filtering endpoints by host still trusts a document that has already failed validation, and the recorded issuer would then be wrong for later RFC 9207 checks. Believing the issuer field over the URL is exactly what an attacker hopes for, because anyone can write any issuer string into a document they serve. Retrying another discovery path and taking whichever answers first does not address the mismatch, and the client already must try OAuth and OpenID Connect paths in a defined priority order, not a race. Exam caveat: the recorded issuer from validated metadata is what later protects the authorization response against mix-up, so this check underpins that one. Operational check: serve a test metadata document whose issuer differs from the fetch URL and confirm the client aborts discovery rather than proceeding.