Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?

Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 07 March 2020 16:29 UTC

Return-Path: <torsten@lodderstedt.net>
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 E55713A0A55 for <oauth@ietfa.amsl.com>; Sat, 7 Mar 2020 08:29:19 -0800 (PST)
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, HTML_FONT_LOW_CONTRAST=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=lodderstedt.net
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 U7Ep5RDfUh6A for <oauth@ietfa.amsl.com>; Sat, 7 Mar 2020 08:29:18 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 D9A9C3A0A45 for <oauth@ietf.org>; Sat, 7 Mar 2020 08:29:17 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id f7so1118846wml.4 for <oauth@ietf.org>; Sat, 07 Mar 2020 08:29:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=LHwQlhrGQFv4S2dEt7KXOHBbeXy4gZ/bsTaxLHZnuLE=; b=HR/UINCHag9dNC4YECWJKUb+5QK5LnGyvuunjTzoAw2S6vz2qoQrSDy/JUr4eyf7Dl DsOP7xK1DgUXPhzGU38cUOzS1bk2dptl8TfgkaJ7BTOv+7JNXQlZliBkGD4XXZksjaL9 jVe1AZrnTuRqEvILj1JO6oH2w7N3iXCgpmKhNIK16jM37qOB9p8adegAj1qGQngUfiGy mugvvDnvXzy86Xoo3FgKDuyzPQovMaOaYPnG9YPoTQZrYI6ngWtcTKHrA3vaPoDx//v7 IK2UkePfiGZ1NRx3JbAL7r2aUqLXOWOzUz+HvP+JQfGUDnJvalmzzPP78CnuDtu11pHD nMZQ==
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=LHwQlhrGQFv4S2dEt7KXOHBbeXy4gZ/bsTaxLHZnuLE=; b=BeHA/cmRVrU+iIaJCwAIZdWxjM5Ch+dFUvTE1lARV3YGlWVDcJoTl07qmljK4R2vzB F5XpCaMz935MEvPd06hPm84UA5DbHVxcfDy49g2C4MdFrv2uTOzIAUYz3bfcPUtrjotb XwOzgXJq5+km/ZdvF6bIGEA/8ipmPjGbH0+WgvQrK5xYCDhfLVMicSL7gQMegUuc9BKo ni3J2owACb7WjlMn3P7jJtRmYF1rpLeH9AB0C48xl+llIdMw69fYFV8rdvpkGl3mL6al GHsAc+/O6Y+0nJG6s76ejNPIXgNLHHJqMYkfH35vkvfUAzKdMgsjCXAJF3dR07Zaas0g sw4w==
X-Gm-Message-State: ANhLgQ2HreN9fUks4krE2lPfPDe9jcpPcy0SRlYV7ZU469o32ZrKpl8I dLQPXRlO9BGbecRw+eK+Bzz4FQ==
X-Google-Smtp-Source: ADFU+vurdlp3Nf18+/DuIMAu1NjsiAKQC9CHaWsDr/OIABlY1QuaZLabSe+phW3ouWNEcerqkC9liQ==
X-Received: by 2002:a7b:c305:: with SMTP id k5mr10854887wmj.189.1583598556067; Sat, 07 Mar 2020 08:29:16 -0800 (PST)
Received: from ?IPv6:2a01:598:a090:1028:9069:f1b5:ad4a:b3a? ([2a01:598:a090:1028:9069:f1b5:ad4a:b3a]) by smtp.gmail.com with ESMTPSA id p17sm50590085wre.89.2020.03.07.08.29.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Mar 2020 08:29:15 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail-E8DC214A-01CB-445E-B311-3B68372B54B8"; protocol="application/pkcs7-signature"; micalg="sha-256"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Sat, 07 Mar 2020 17:29:13 +0100
Message-Id: <3F805BA8-8ABB-4939-96CC-FD2FEC811322@lodderstedt.net>
References: <CAD9ie-s9HT=9MKPK+GpVngZc+9QMxHS6KL-Sfq-UPQz2VQ3ioA@mail.gmail.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>
In-Reply-To: <CAD9ie-s9HT=9MKPK+GpVngZc+9QMxHS6KL-Sfq-UPQz2VQ3ioA@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: iPhone Mail (17D50)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hf4LudO03tMkHoLdNKuNP2QtmMU>
Subject: Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?
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: Sat, 07 Mar 2020 16:29:20 -0000
X-List-Received-Date: Sat, 07 Mar 2020 16:29:20 -0000

I think keeping the response type as extension point and not mentioning implicit at all is sufficient to support Brian’s objective.

> Am 07.03.2020 um 17:06 schrieb Dick Hardt <dick.hardt@gmail.com>:
> 
> 
> How about if we add in a nonnormative reference to OIDC as an explicit example of an extension:
> 
> "For example, OIDC defines an implicit grant with additional security features."
> 
> or similar language
> ᐧ
> 
>> On Sat, Mar 7, 2020 at 5:27 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
>> The name implicit grant is unfortunately somewhat misleading/confusing but, for the case at hand, the extension mechanism isn't grant type so much as response type and even response mode. 
>> 
>> The perspective shared during the office hours call was, paraphrasing as best I can, that there are legitimate uses of implicit style flows in OpenID Connect (that likely won't be updated) and it would be really nice if this new 2.1 or whatever it's going to be document didn't imply that they were disallowed or problematic or otherwise create unnecessary FUD or confusion for the large population of existing deployments. 
>> 
>>> On Fri, Feb 28, 2020 at 1:56 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>>> I'm looking to close out this topic. I heard that Brian and Vittorio shared some points of view in the office hours, and wanted to confirm:
>>> 
>>> + Remove implicit flow from OAuth 2.1 and continue to highlight that grant types are an extension mechanism.
>>> 
>>> For example, if OpenID Connect were to be updated to refer to OAuth 2.1 rather than OAuth 2..0, OIDC could define the implicit grant type with all the appropriate considerations.
>>> 
>>> 
>>> ᐧ
>>> 
>>>> On Tue, Feb 18, 2020 at 10:49 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
>>>> No - please get rid of it.
>>>> 
>>>> ———
>>>> Dominick Baier
>>>> 
>>>>> On 18. February 2020 at 21:32:31, Dick Hardt (dick.hardt@gmail.com) wrote:
>>>>> 
>>>>> Hey List 
>>>>> 
>>>>> (I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on)
>>>>> 
>>>>> Given the points Aaron brought up in
>>>>> 
>>>>> https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU
>>>>> 
>>>>> 
>>>>> Does anyone have concerns with dropping the implicit flow from the OAuth 2.1 document so that developers don't use it?
>>>>> 
>>>>> /Dick
>>>>> _______________________________________________ 
>>>>> OAuth mailing list 
>>>>> OAuth@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/oauth 
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth