Apply defaults without inventing capabilities
03Some omitted lists have specified defaults; others deliberately have no default. An advertised feature is still separate from client policy.
The illustrative metadata explicitly advertises S256. Omission in §2 means no PKCE support; it is not a successful exchange or permission to bypass a client’s security requirements.
Source for this drawing: RFC 8414 · Read RFC section 2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Omission does not always mean the same thing.
- If response_modes_supported is omitted, §2 defaults to query and fragment. If grant_types_supported is omitted, its default is authorization_code and implicit. These are the published metadata interpretation defaults; they do not override later OAuth security guidance or recommend deploying every listed grant.
- The omitted token_endpoint_auth_methods_supported default is client_secret_basic. The revocation endpoint has the same omitted-method default. Introspection is different: if its authentication-method list is omitted, supported methods MUST be determined by other means. Do not copy the token default into introspection (§2).
- For token, revocation or introspection endpoint authentication, if private_key_jwt or client_secret_jwt is specified, the corresponding signing-algorithm metadata entry MUST be present. No default algorithms are implied by an omitted entry, and none MUST NOT be used. The token-endpoint list additionally says servers SHOULD support RS256 (§2).
- These algorithms are for JWTs used to authenticate a client at the relevant endpoint. They are not an access-token format declaration or algorithms for signed_metadata. Metadata support is separate from an actual client credential, successful signature or authorization decision.
- code_challenge_methods_supported is OPTIONAL. In this publication, omission means the server does not support PKCE; if present, it lists supported methods such as S256. Proof Key for Code Exchange (PKCE) binds an authorization-code exchange to a fresh verifier kept by the client. Metadata absence does not instruct a client to bypass its security policy or silently downgrade. The OAuth security BCP remains separate guidance (§2; companion RFC9700).
- Advertised scopes may be incomplete; an advertised grant, response type or authentication method does not mean every registered client may use it. Client registration, eligibility, authorization and current deployment security are outside these default calculations.
The helper calculates a selected set of publication defaults and algorithm-presence checks. It is not a complete metadata validator, client registration policy or cryptographic verifier.
Read the RFC section ↗