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

Aaron Parecki <aaron@parecki.com> Thu, 14 May 2020 23:36 UTC

Return-Path: <aaron@parecki.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 1BC6B3A0789 for <oauth@ietfa.amsl.com>; Thu, 14 May 2020 16:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.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 fraF8KTPWQR3 for <oauth@ietfa.amsl.com>; Thu, 14 May 2020 16:36:04 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 836E83A079D for <oauth@ietf.org>; Thu, 14 May 2020 16:36:03 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id k18so775826ion.0 for <oauth@ietf.org>; Thu, 14 May 2020 16:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FHJBcWGMh/D15Z7EC83ru0aDLW/ycqaPnRQaQMOr31U=; b=l/xBDqnEWysuRPVGtVGzwxW6+Da177jncIZYqFad+7uZ2AuKDMoeW7t+P9mmCFna/d CESAcB7hu10H9R5xNUDJFEyzDyQulGbA08ykYSLSBAjnjax2KKWUm1l9Gezxpgca/AA8 VfG64EmjDgkStc2JtFbNx/hK36Luh8JiAt9f/tCikhD8wHiyoAXwTPc0pXJ4lQ6wwMaQ 72KM+buTSSHiSmSdncULqA4iNUTASbjQTd5LF7OhSiUioVByjqM8SNMsD00CtJp8d6Up 3KyiYhpdwtS4RSnB0HLPngJdXD20QUTkK92RbF09JeCHkq9IR1Jih0uEew5wg/nu3/Gq e0yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FHJBcWGMh/D15Z7EC83ru0aDLW/ycqaPnRQaQMOr31U=; b=sU/e0blyCDH7iaSjV+dQgqG8sVJrwUFfnzYhVeB1edYNnv00bWt3yM+tbODf4yInfX eehjuHDoYeHb/Df22dN/bIu+6Y0e3UBpfuyQZuZPbJ0kfHsFxoTMlwjucrSst3o0X2vY XsQP6Wsda8U9me8upW1EshBvbFmZNbxvPS75r6SxgfT6IJmgYY4Uql2gCvajDi4tYQOz XbW+sIgAlhEFqcREkjUraygpH0lwBXB5UwDflJRn7v1uXV78vEyx8RwLCngCpKalksXu xKPHxkpXeNaKFf0Ty0UIXJyuv/yOjvJVBDr8/RIyrR1elBTpk6Q2xEOgnbyGWlAPp/yO kPkQ==
X-Gm-Message-State: AOAM530RUE+7xJXhNhAWT5A1V1/nEBh/fT40CCCIegPU61G4lkXZub8/ XBaQNN6p1n21oKAXTi9x16vOOeWGvBs=
X-Google-Smtp-Source: ABdhPJzv7B/CXjH3o1HLx8kqHEHMMGYFNQNHr0fijAHcqjUWmCwIGD11hHW+dR+aUDa1nt/ky/Yj/Q==
X-Received: by 2002:a5d:8d1a:: with SMTP id p26mr491111ioj.131.1589499362222; Thu, 14 May 2020 16:36:02 -0700 (PDT)
Received: from mail-il1-f171.google.com (mail-il1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id s22sm163036iow.40.2020.05.14.16.36.00 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 May 2020 16:36:01 -0700 (PDT)
Received: by mail-il1-f171.google.com with SMTP id j2so667256ilr.5 for <oauth@ietf.org>; Thu, 14 May 2020 16:36:00 -0700 (PDT)
X-Received: by 2002:a92:3954:: with SMTP id g81mr665912ila.105.1589499360732; Thu, 14 May 2020 16:36:00 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR00MB068633B7B72E5416AA8984D1F5BE0@MN2PR00MB0686.namprd00.prod.outlook.com> <2298156A-1CAE-478D-B036-DD32A6EEBEF0@lodderstedt.net> <9B5EBD2C-09EF-403A-9270-A53EEE691E40@gmail.com> <1887D983-7A43-41C3-AAAD-786AD749240A@lodderstedt.net> <23145A44-5232-4312-9E51-627DB0FAFB44@gmail.com>
In-Reply-To: <23145A44-5232-4312-9E51-627DB0FAFB44@gmail.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Thu, 14 May 2020 16:35:49 -0700
X-Gmail-Original-Message-ID: <CAGBSGjq_naf9qMRiQHrFEfvZnECTgNY=W=Aq-ZZTXDnKQu0AOw@mail.gmail.com>
Message-ID: <CAGBSGjq_naf9qMRiQHrFEfvZnECTgNY=W=Aq-ZZTXDnKQu0AOw@mail.gmail.com>
To: Nov Matake <matake@gmail.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c46c1e05a5a428d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/KEPg2dolI3ElHQcaRR9rcS9mhGk>
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: Thu, 14 May 2020 23:36:17 -0000

>
> 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.
> >
>
>