detecting inconsistent .well-known/openid-configuration vs .well-known/oauth-authorization-server on conformance tests

[jogu]

Vaguely related to #862

It's suggest that the conformance test could fetch the version it's not currently using (so if it's using openid-configuration, also fetch oauth-authorization-server) and raise a warning if the contents are different, suggesting that (as the keys in the document trace back to the same IANA registry) the contents should be consistent and that interoperability / race conditions might occur if they differ.

If the fetch of the other location fails (e.g. 404) that would be ignored (unless #862 comes to a different conclusion).

An opinion from the working group on whether this is a good idea to check would be appreciated.

[sakimura]

A very long discussion on Sep 23, 2026 call.

Several opinions stated in the discussion:

• Contents should be the same and if not the test suit should give 'warning' as it may cause interoperability problems.
• Contents can be different as openid-configuration and oauth-authorization-server can describe each specific configuration, so the test suite should give 'info' instad. This essentially means a client needs to merge the content.
• When merging the content and if the value for the parameter differs, what happens? (Perhaps using OAuth parameter when using purely oauth and if the client plans to use openid, then openid-configuration's value override it?)

@jogu is going to check what the current practice in the test suite on 'warning' and 'info'.