> One > interesting case comes down to stuff like channel_binding=require > require_auth="md5,scram-sha-256", where I think that we should still > fail even if the server asks for MD5 and enforce an equivalent of an > AND grammar through the parameters. This reasoning limits the > dependencies between each parameter and treats the areas where these > are checked independently, which is what check_expected_areq() does > for channel binding. So that's more robust at the end.
Agreed.
That just makes me want to not implement OR'ing...
The existing set of individual parameters doesn't work as an API for try-and-fallback.
Something like would be less problematic when it comes to setting multiple related options:
Absent that radical idea, require_auth probably shouldn't change any behavior that exists today without having specified require_auth and having the chosen method happen anyway. So whatever happens today with an md5 password prompt while channel_binding is set to require (not in the mood right now to figure out how to test that on a compiled against HEAD instance).
