Consistently apply "if not understood MUST be ignored" language for endpoint request parameters

[Michael Jones]

We use this and similar language at https://openid.net/specs/openid-federation-1_0-34.html#name-constraints and other places:

Other constraint parameters MAY be defined and used. If they are not understood, they MUST be ignored.¶

But we’re not consistently applying this extension principle to endpoints throughout the specification. For instance, this language is missing from the list endpoint description.

We should include this language, where applicable.

[David W Chadwick]

I don’t believe that on its own this is the right course of action. It needs to be accompanied with a criticality flag, so that extensions that must never be ignored (whether known or not by the recipient) can be flagged as critical ones.

[Michael Jones]

I’ll note that the spec does define a general-purpose crit JWT claim for uses aligned with the comment above. See https://openid.net/specs/openid-federation-1_0-34.html#name-crit-critical-claim.

That said, the extension points in question are endpoint request parameters and not JWTs. The intent is to follow the same extension model as used for OAuth 2.0. https://www.rfc-editor.org/rfc/rfc6749.html#section-3.1 says:

The authorization server MUST ignore unrecognized request parameters.

To my knowledge, a criticality meta-parameter has never been applied to request parameters.

‌

[Michael Jones]

To be fixed by https://bitbucket.org/openid/connect/pull-requests/737

[David W Chadwick]

This situation may not apply to the federation spec, but it does apply to the OpenID4VP spec when an RP may make a request to a wallet that could compromise the user if the wallet does not understand one or more of the request parameters and consequently returns PII credentials to the RP, when a wallet that does understand the parameters would not return the PII credentials. Can you think of an analogous case in federation? For example, a request for federation trust data where the requestor wants to omit responses that do not comply with some parameter, but the parameter is not understood by the federation entity so it returns the trust data regardless.

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/737