I will point out that OpenID Connect certification tests that the
implementation ignores not-understood request parameters. So at least all the
authorization servers that are also certified OpenID Connect implementations
should be successfully ignoring not-understood parameters.
I’d personally point out these non-compliant behaviors to the vendors and ask
them to fix them. Their non-compliance makes it harder for clients to
interoperate with them, hurting both. Name names, if that’s what it takes.
-- Mike
From: OAuth <oauth-boun...@ietf.org> On Behalf Of Neil Madden
Sent: Thursday, April 23, 2020 2:30 AM
To: Vladimir Dzhuvinov <vladi...@connect2id.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth GREASE
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<mailto: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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
