Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Nov Matake <matake@gmail.com> Fri, 15 May 2020 00:12 UTC

Return-Path: <matake@gmail.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 8B5603A07AD for <oauth@ietfa.amsl.com>; Thu, 14 May 2020 17:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4ZjEE0ZX6URQ for <oauth@ietfa.amsl.com>; Thu, 14 May 2020 17:12:24 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3011E3A079A for <oauth@ietf.org>; Thu, 14 May 2020 17:12:24 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id w65so110596pfc.12 for <oauth@ietf.org>; Thu, 14 May 2020 17:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ITVyk1/CbzY9sRdXKGtuE/TLR74VQ3S+3pDaHzFnEAY=; b=sTFmI/sTif1PxEVkbq/kpFB1cKuOo6TdNau1VrTbHpDE3Uw9XpcTQ61wPctwQ440Yl QfplZ0g4NBpKSZ8az3lM8prDyZhP4NxRopsiaa0lT5JyDzBTu42I3srRXFaZjb2FzYLF Hsuufld5SIfusU//1AsUfSrXKoXHiR4hnB0PA5aAKkHKj8bL4FzGnts2LsucloSmvRhL kNHLcFAZNPQ7mWHuMUpotOOeljGKKkLPklKDSNlndsmmGIlFvId9ZvYMxJ/L5tu5oiCi JGU/hW1VP1de9TyhQr3gYPRDjHZ+/zj4LtO8ae1qh4gqetygwPsxKLY2S08EPIvE3cjX lJJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ITVyk1/CbzY9sRdXKGtuE/TLR74VQ3S+3pDaHzFnEAY=; b=LHzf/AGYKqYRyyoB1Upw/XJLassdHfA2rxeX71ryzhyjV1CdBExgLovzR3dRTivZ07 zSRsUWQ4uuDZ3yGPpaY7wzr2THc2t43FPpt0mzp0yywGcHTHS9iluEIO//IGtrMpoGNf 2vYuaX1GPh7IBkQjVvYRZlDbDU2+aFg95XnEIF6IlfkHpir+6pFtHgSMzgwaXJI3nyXg 0/MnAsyUc35fwwNyW6xBBeNGXbd/bJy7NR5KTBD3yVxfoCyKacc1NJisC8Yvk/3Yn2iw BzCmYiztAbZuS5zrjVFbISy5thrO3480z/QuzjQZNPKbx0nn5thB+Rx9V39glhJIG6RB IgqA==
X-Gm-Message-State: AOAM533EM+mZQQ3nHWvnayNcXiiuz5nFFvp21mHmlJxNxH6Ttq6qsRBj 4f9XyJOLRFvKjmWDiQuqRPSxxZaCDnna5w==
X-Google-Smtp-Source: ABdhPJwnQbzkbzkfvvkglg4Fa/s6a39QRgqaKoQWLoNPyMD6aqgM5hMNzD9EhXR3EPuV9zB+aj2CXA==
X-Received: by 2002:a63:155f:: with SMTP id 31mr667560pgv.0.1589501543055; Thu, 14 May 2020 17:12:23 -0700 (PDT)
Received: from [172.16.80.56] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id q25sm307999pfh.94.2020.05.14.17.12.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 May 2020 17:12:22 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-519DDF2A-8705-43F6-93BE-B8AC6ADF4427
Content-Transfer-Encoding: 7bit
From: Nov Matake <matake@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 15 May 2020 09:12:20 +0900
Message-Id: <8A81492B-F950-4018-8AC1-849047023534@gmail.com>
References: <CAGBSGjq_naf9qMRiQHrFEfvZnECTgNY=W=Aq-ZZTXDnKQu0AOw@mail.gmail.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, OAuth WG <oauth@ietf.org>
In-Reply-To: <CAGBSGjq_naf9qMRiQHrFEfvZnECTgNY=W=Aq-ZZTXDnKQu0AOw@mail.gmail.com>
To: Aaron Parecki <aaron@parecki.com>
X-Mailer: iPad Mail (17E262)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/eoCpVPAyiHB1xIiA4uVP8jtV_GM>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
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: Fri, 15 May 2020 00:12:27 -0000

Then the sentence should not open extension points even for confidential clients,
- by mention OIDC notice explicitly
- by allowing currently existing alternatives only (and prohibit new ones)
etc.

iPadから送信

> 2020/05/15 8:36、Aaron Parecki <aaron@parecki.com>のメールt;のメール:
> 
> 
>> There is no specific mechanism right now.
>> But future developers won’t be able to read the reason why the extension point is given only for confidential clients.
> 
> This is not a compelling argument.
> 
> The current situation is that we know of a handful of threats and attacks, we know that PKCE solves them for both confidential and public clients, and we also believe that OpenID Connect has solved one of the threats for confidential clients a different way. The reason this conversation is happening at all is because we want to make sure that OpenID Connect can continue to solve that problem its own way outside of OAuth without conflicting with OAuth.
> 
> It's not useful to anyone to leave extension points open for hypothetical solutions later when we already know of a solution that works for public clients. At that point that should just be a new spec.
> 
> Aaron Parecki
> 
> 
>> On Thu, May 14, 2020 at 3:18 AM Nov Matake <matake@gmail.com> wrote:
>> There is no specific mechanism right now.
>> But future developers won’t be able to read the reason why the extension point is given only for confidential clients.
>> 
>> > On May 14, 2020, at 18:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> > 
>> > Are you aware of any suitable mechanism? I’m asking since from my perspective this clause is mainly intended to allow existing OpenID Connect deployments to use nonce instead of PKCE in combination with OAuth 2.1. It’s a compromise. I think we should not encourage others to invent their own OAuth security mechanisms. 
>> > 
>>