Proceed with the authorization grant when `iss` does not match the expected issuer identifier..

Condition: when the issuer comparison fails

MUST NOT proceed with the authorization grant

Assume that an error response originated from the intended authorization server..

Condition: when processing an error response

clients MUST NOT assume that the error originates from the intended authorization server

Allow multiple authorization servers to use the same issuer identifier..

Condition: when supporting RFC 9207

MUST NOT allow multiple authorization servers to use the same issuer identifier

Extract `iss` from received authorization responses when the parameter is present..

Condition: when supporting RFC 9207

MUST extract the value of the iss parameter

Decode `iss` from its `application/x-www-form-urlencoded` form and compare it with the issuer identifier of the authorization server to which the request was sent..

Condition: when supporting RFC 9207 and `iss` is present

Clients MUST then decode the value

Use simple string comparison when comparing issuer identifiers..

Condition: when validating the authorization-response `iss` value

comparison MUST use simple string comparison

Reject the authorization response when `iss` does not match the expected issuer identifier..

Condition: when the issuer comparison fails

clients MUST reject the authorization response

Compare `iss` with the `issuer` value in the authorization server's RFC 8414 metadata document..

Condition: when interacting with an authorization server that supports RFC 8414 OAuth metadata

MUST compare the iss parameter value to the issuer value

Use a deployment-specific mechanism, such as static configuration, to determine the expected issuer..

Condition: when RFC 8414 OAuth authorization server metadata is not used

clients MUST use deployment-specific ways

Retain state indicating whether each authorization server supports the `iss` parameter..

Condition: when interacting with both supporting and non-supporting authorization servers

clients MUST retain state

Reject an authorization response that lacks `iss` when the authorization server is configured as supporting the parameter..

Condition: when the authorization server supports `iss` according to client configuration

Clients MUST reject authorization responses without the iss parameter

Validate `iss` precisely as specified by RFC 9207 Section 2.4..

Condition: when supporting RFC 9207

Clients MUST validate the iss parameter precisely as described in Section 2.4

Ensure that accepted `iss` values are unique for each authorization server..

Condition: when authorization server details can be manually configured

client MUST ensure that the accepted iss values are unique

Reject an authorization response containing multiple issuer identifiers when those identifiers do not match..

Condition: when multiple issuer identifiers are present

client MUST reject the response if these issuer identifiers do not match

Discard an authorization response containing `iss` when the authorization server does not indicate support for the parameter..

Condition: subject to local policy for legitimate unadvertised support

Clients SHOULD discard authorization responses with the iss parameter

Accept authorization responses without `iss`, or reject them and support only authorization servers that provide `iss`..

Condition: according to local policy or configuration

clients that support this specification MAY accept authorization responses that do not contain the iss parameter

Indicate its identity by including the `iss` parameter in authorization responses, including error responses..

Condition: when supporting RFC 9207

MUST indicate its identity by including the iss parameter

Use an `iss` value that is an HTTPS URL without query or fragment components..

Condition: when supporting RFC 9207

value MUST be a URL that uses the "https" scheme without any query or fragment components

Provide its issuer identifier so clients can validate the `iss` parameter..

Condition: when supporting RFC 9207

MUST provide their issuer identifier

Make the RFC 8414 metadata `issuer` value identical to the authorization-response `iss` value..

Condition: when publishing OAuth authorization server metadata according to RFC 8414

metadata value issuer MUST be identical to the iss parameter's value

Advertise support by setting the OAuth authorization server metadata parameter `authorization_response_iss_parameter_supported` to `true`..

Condition: when publishing OAuth authorization server metadata according to RFC 8414

server MUST indicate its support for the iss parameter

Make the authorization-response `iss` value identical to the ID Token `iss` claim..

Condition: in an OpenID Connect flow where an ID Token is returned from the authorization endpoint

value in the iss parameter MUST always be identical

Additionally provide its issuer identifier to clients through another mechanism..

Condition: when supporting RFC 9207

MAY additionally provide the issuer identifier

Represent parameter names and string values, including a string-valued `iss`, as JSON strings..

Condition: when constructing a Request Object

Parameter names and string values MUST be included as JSON strings

Encode JSON strings in a Request Object using UTF-8..

Condition: when constructing a Request Object

these JSON strings MUST be encoded using UTF-8

Include `iss` and `aud` claims with JWT semantics in a signed Authorization Request Object..

Condition: when the Request Object is signed

Authorization Request Object SHOULD contain the Claims iss (issuer) and aud (audience)

Omit use and verification of the `iss` response parameter when another issuer identifier is included and checked as specified in RFC 9207 Section 2.4..

Condition: when an authorization response identifies the authorization server by another checked mechanism

use and verification of the iss parameter is not necessary and MAY be omitted

Include the JWT `iss` claim..

Condition: when constructing a JWT unless another specification requires it

Use of this claim is OPTIONAL