Check referencing and normative language

[Mark Haine]

A few questions need to be addressed in this area.

1. Is all normative language correct? - I am concerned about the use of “REQUIRED” in condititional cases within the OP Metadata in particular
2. Are Normative references correct, particularly are any items in section 15 that are not in fact references in the document and are there any references in the document that do not exist in section 15
3. Are Informative References in section 16 all present and correct?

‌

[Mark Haine]

regarding point 1 and re-reading https://datatracker.ietf.org/doc/html/rfc2119 I think these cases are a good fit for use of “SHOULD”

[Mark Haine]

Suggest changing the following OP Metadata items from REQUIRED to RECOMMENDED because of their conditional nature:

documents_supported:

electronic_records_supported:

attachments_supported:

digest_algorithms_supported:

‌

[Daniel Fett]

Examples for conditional MUSTs from RFC9207:
”If the value does not match the expected issuer identifier, clients MUST reject the authorization response and MUST NOT proceed with the authorization grant. (…) If OAuth metadata is not used, clients MUST use deployment-specific ways (for example, a static configuration) to decide if the returned iss value is the expected value in the current flow (see also Section 4). If clients interact with both authorization servers supporting this specification and authorization servers not supporting this specification, clients MUST retain state about whether each authorization server supports the iss parameter.”

[Mark Haine]

After discussion in WG call - it was decided that the first part of the issue is not an issue so no need to change REQUIRED for OP Metadata items listed

[Mark Haine]

Resolved by PR #128