Enable non-breaking extensibility

[selfissued]

The OAuth and OpenID Connect specifications use a standard pattern to enable extensibility in a way that the use of extensions does not break existing deployments. That pattern is:

• Where a set of values is defined, specify that additional values MAY be defined and used.
• Where a set of values is used, specify that values that are not understood MUST be ignored.

Language incorporating this pattern is currently missing from the specification. We should add it where metadata parameters are defined and also for other parameter sets. Otherwise, we'll be building a brittle specification whose deployments will break by rejecting unexpected values when they are added as their ecosystems evolve.

Examples of this pattern are:

• Connect Core: "ID Tokens MAY contain other Claims. Any Claims used that are not understood MUST be ignored.", "Other parameters MAY be sent, if defined by extensions. Any parameters used that are not understood MUST be ignored by the Client."
• Connect Discovery: "Additional OpenID Provider Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Session Management 1.0 [OpenID.Session]."
• Connect Registration: "Additional Client Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect RP-Initiated Logout 1.0 [OpenID.RPInitiated].", "An Authorization Server MAY ignore values provided by the client and MUST ignore any fields sent by the Client that it does not understand."
• OAuth 2.0: "New request or response parameters for use with the authorization endpoint or the token endpoint are defined and registered in the OAuth Parameters registry", "The authorization server MUST ignore unrecognized request parameters.", "The client MUST ignore unrecognized response parameters.", "The client MUST ignore unrecognized value names in the response."
• OAuth DCR: "Extensions and profiles of this specification can expand this list with metadata names and descriptions registered in accordance with the IANA Considerations", "The authorization server MUST ignore any client metadata sent by the client that it does not understand", "Other members MAY also be included and, if they are not understood, they MUST be ignored".
• OAuth AS Metadata: "Additional authorization server metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Discovery 1.0 [OpenID.Discovery].".
• JWT: "all claims that are not understood by implementations MUST be ignored".

[selfissued]

@jogu commented during today's working group call "already implicit, so its normitive and change seems reasonable", per the minutes.

[jogu]

The only thing we need to be wary of (and I forgotten to mention it on yesterday's call) is that we don't yet have a registry that can be a centralised list of where some of the parameters are defined (e.g. some parameters will be going into the IANA OAuth registries, but there's currently nowhere like that for e.g. credential issuer metadata) so in the short-medium term we probably need to guide all generally applicable metadata to be in the main VCI/VP specs unless there's very good reason to start new specs and we're careful to coordinate where necessary so we don't end up with specs that are incompatible with each other.