Visual RFC.
ALL RFCs / RFC 9207
Read the RFC ↗
RFC 9207 / AUTHORIZATION RESPONSE ISSUER

Remember support for each server

04

Capability discovery and response policy distinguish required rejection from recommendations and local choices.

DIAGRAMRead RFC section 3 ↗
RFC 9207 · § 3EXAMPLE
4 / 4
Remember support for each serverFour separate server-policy cases: advertised true plus missing iss MUST reject; omitted support defaults false; unadvertised present iss SHOULD discard unless explicit local policy allows it with exact validation; nonsupporting missing iss MAY accept or reject locally, still requiring a multi-server mix-up defense. JSON is a metadata fragment, not full discovery.Track support separately for each serverNonsupporting server · no iss in responsepolicy acceptspolicy rejectsMAY acceptMAY rejectMulti-server clients still need a mix-up defenseConfigured support true is a different MUST-reject case
04
Choose a policy for a nonsupporting server.

Separate nonsupporting server sends no iss. A local policy MAY accept or reject this response. Acceptance here is only a policy gate; a multi-server client still needs another valid mix-up defense.

Source for this drawing: RFC 9207 · Read RFC section 3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A key is different from permission.

An app, a person, and a server have different roles. Follow who asks, who grants permission, and who checks the credential. A key in the drawing is an analogy, not a literal protocol field.

Helpful first, if these ideas are unfamiliar

RFC 6749 OAuth 2.0 RFC 3986 URI syntax RFC 9700 OAuth security

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Do not turn a missing required issuer into a silent downgrade.

  • authorization_response_iss_parameter_supported is a boolean; omission defaults to false. Supporting servers publishing metadata MUST advertise true and the matching issuer.
  • Clients using both supporting and nonsupporting servers MUST retain each server’s support state. A response without iss from a server configured as supporting MUST be rejected.
  • Clients SHOULD discard a response containing iss from a server not indicating support. Legitimate unadvertised support is possible; local policy can allow it, while still validating the present iss as required.
  • Clients MAY accept responses without iss from nonsupporting servers, or require iss everywhere. That local policy does not override the configured-support MUST. Clients not implementing this extension MUST ignore unrecognized iss under RFC 6749.
  • Accepting a legacy response is not a complete mix-up defense. Later RFC 9700 §4.4.2 still requires a defense for clients using multiple servers; other countermeasures have their own conditions.
DETAILS

Metadata fragments omit unrelated required fields for readability; they are not complete discovery documents. A client that does not implement this extension ignores the unknown parameter; that behavior is not drawn as a supporting client’s bypass.

Read the RFC section ↗

All chapters in RFC 9207

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗