Neil Madden <> Thu, 23 April 2020 09:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB8723A17C5 for <>; Thu, 23 Apr 2020 02:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CNObloYdNtBq for <>; Thu, 23 Apr 2020 02:29:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03C1D3A17B7 for <>; Thu, 23 Apr 2020 02:29:35 -0700 (PDT)
Received: by with SMTP id h2so5650545wmb.4 for <>; Thu, 23 Apr 2020 02:29:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=si9xs2Nd5djg301n4mOSeXIo9tq9aKeABCH9i/ZO/NQ=; b=ByHM4ik92YJeZE+4Q4cPnHj9cOgWFRLh9f8QXfR/7y9aAbsFaau6i3qi3Wwdj/BEdl Fv+4II7h7/9mX98KZnyjKx9YnhY9S5LFKiAW9Ft81cp5Fs9Aoh6xUUt0HiKi5YBVDRdx Cmw75N7325Qd0nfzOGdBv2QfOkxavPcQHYWRY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=si9xs2Nd5djg301n4mOSeXIo9tq9aKeABCH9i/ZO/NQ=; b=n1OUcCSc2LSI8O2YEEAGqQgN7XvAbtRNru6e+C15CztiUFQFVUUnoOHRZnZw/R62Y1 RYj2JPdwrxQHoIfoAgshHodT+iaa1xOru9rUETBK/fPbdwrLHBervsGWMjygohqVqVb1 zQ8B70YYyquKHGM6AWYY6y0LWMPVMMmyvLVwws8vQwEajybtUfQhQfpYCnvmhiXuO7Cl a30yX8K+FbbTmBGpdf/8h4KXNJ8rKDfIKRnTyL/CE8MuKSvGxAv3huRkK0as+b8LwBVd GYmEpMH+gXX+kJTs2G8d7OXVPzG+npAA3SCIsTbXkJ4IHzWqlKFJmNGOEkMsB8/KdOfo 4StA==
X-Gm-Message-State: AGi0PuYh8tzQH9Xk8Sh7QfD2McBzCkvURojddrj2njv5X8zKyLs52pm4 KU8zOEs0D6MUGeWsfc0ljqtRnQ==
X-Google-Smtp-Source: APiQypKUv6Wxboj8C1yKtSH/DYYkVvBYDr2qvAj5S3JRj9HJL+RTqe3UX37yUed39VNAO+ERbMCrqA==
X-Received: by 2002:a1c:6a17:: with SMTP id f23mr2989091wmc.136.1587634174068; Thu, 23 Apr 2020 02:29:34 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j13sm2869405wro.51.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2020 02:29:33 -0700 (PDT)
From: Neil Madden <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BAA363B3-0C48-46AE-AA29-9DF552D26546"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Thu, 23 Apr 2020 10:29:32 +0100
In-Reply-To: <>
To: Vladimir Dzhuvinov <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth GREASE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Apr 2020 09:29:43 -0000

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 <> 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?
>> <>
>> — Neil
> _______________________________________________
> OAuth mailing list