If a clients sends a handful of random additional parameters on authorization requests a compliant AS will already ignore them, so there should be no additional burden on the AS.
However, the ship may already have sailed on the specific issue of request parameters, as there are major deployed services already rejecting unknown parameters. (I won’t name them, but probably a fair proportion of people on this list have an account with at least one of them). Of course, even if they eventually do enable PKCE we won’t start using it until we notice and remove them from the blacklist, so this harms security as well as interoperability. I’m not saying the situation is anywhere near as bad for OAuth as it is for TLS with all the incompatible middleboxes, but there are definitely some other areas of potential ossification: - I know of services that error if a published JWKSet has more than one key in it - some error if there’s a JWK with an unknown “kty” (e.g “okp”) even if they don’t need to use that JWK, same for unknown “crv” values - there are clients that error if any value in the id_token_signing_alg_values_supported is not one of the original JWS signing algorithms (e.g., “EdDSA”), making it hard to adopt a new signature algorithm (Basically there are quite a few clients that use JSON mapping tools with enum types - List<JWSAlgorithm>. I know there are parts of our own codebase where we do this too). I was only semi-serious about GREASE, but I think this is a problem that will only get worse over time. — Neil > On 23 Apr 2020, at 08:54, Vladimir Dzhuvinov <vladi...@connect2id.com> wrote: > > I get your frustration with PKCE. It would be a bad policy and example to > burden compliant ASes with additional stuff just because a few AS > implementations are not complying with the spec. It's not fair and can end up > creating all sorts of bad incentives in future. > > Vladimir > > On 22/04/2020 10:29, Neil Madden wrote: >> Section 3.1 of RFC 6749 says (of the authorization endpoint): >> >> The authorization server MUST ignore >> unrecognized request parameters. >> We hoped to be able to use this to opportunistically apply PKCE - always >> send a code_challenge in the hope that the AS supports it and there should >> be no harm if it doesn’t. >> Sadly I learned yesterday of yet another public AS that fails hard if the >> request contains unrecognised parameters. It appears this part of the spec >> is widely ignored. >> Given that this hampers the ability to add new request parameters in future, >> do we need our own GREASE to prevent these joints rusting tight? >> https://www.rfc-editor.org/rfc/rfc8701.html >> <https://www..rfc-editor.org/rfc/rfc8701.html> >> — Neil > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
