Re: [OAUTH-WG] OAuth GREASE

Vladimir Dzhuvinov <vladimir@connect2id.com> Thu, 23 April 2020 07:55 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005CB3A1680 for <oauth@ietfa.amsl.com>; Thu, 23 Apr 2020 00:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGvoA0-DtvAs for <oauth@ietfa.amsl.com>; Thu, 23 Apr 2020 00:55:01 -0700 (PDT)
Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4965A3A167B for <oauth@ietf.org>; Thu, 23 Apr 2020 00:55:01 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id RWh2jhEUp9JjyRWh4jg5f2; Thu, 23 Apr 2020 00:55:00 -0700
X-CMAE-Analysis: v=2.3 cv=ZO6pZkzb c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=BqEg4_3jAAAA:8 a=Vq__D_9_wrZ_-0_00VMA:9 a=QEXdDO2ut3YA:10 a=gNR8PH0IMfoA:10 a=RQUf42KgQNQA:10 a=6Hd0po06xlgA:10 a=3aknrV82MZcA:10 a=UM_DoP-0AAAA:8 a=NqJpTMeShTPr8V1-VBAA:9 a=H3iPujJrdPWw1yro:21 a=_W_S_7VecoQA:10 a=ZkqgyM_Zep0A:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=0mFWnFbQd5xWBqmg7tTt:22 a=TEVHQOIvcflanWNqQbWu:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <9F472A63-FC87-416E-A7FF-78B87B45EE18@forgerock.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <e420ec51-29cb-a23b-ae43-81215ed8196c@connect2id.com>
Date: Thu, 23 Apr 2020 10:54:42 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9F472A63-FC87-416E-A7FF-78B87B45EE18@forgerock.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050205010408080809080406"
X-CMAE-Envelope: MS4wfCxRNsF58t+FsENFmYM0ewTUwBPLdxjgB99q/0LOBTkKWqYV0d4QuCBnQrLIS18Ne1y6uteSPYwqa48X8NsUN8qySkqqNY03YFp7+r3sQNmjXM5nFWkX Pt5uPOh1u6oEB+iMZJfiRgd/avCXEoqSTh1Xe9nOgZP7Eu+zu/oPFqQy
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/wqpko4TkSVOziVSKkUBNZvgacgs>
Subject: Re: [OAUTH-WG] OAuth GREASE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 07:55:03 -0000

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