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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
