Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 9

Bruno Brito <bhdebrito@gmail.com> Wed, 19 February 2020 20:21 UTC

Return-Path: <bhdebrito@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 F09CC120810 for <oauth@ietfa.amsl.com>; Wed, 19 Feb 2020 12:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 RgBja2rVnfK0 for <oauth@ietfa.amsl.com>; Wed, 19 Feb 2020 12:21:03 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 1BEA9120639 for <oauth@ietf.org>; Wed, 19 Feb 2020 12:21:03 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id e18so1711806ljn.12 for <oauth@ietf.org>; Wed, 19 Feb 2020 12:21:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HPfMGGkUgrnLWvhESFHMqTpBnft6fxTE4vIGMHLIK70=; b=Q9whwj4hVZ7lVwIJzzflkbXXRUIKFsyu4WfRUayA3JtdIhyW2SBW266k/rpUgZxibl cMGgplFYft6LxiTbJTdSVHo+dWmmDf9EKDhiJ4rSJ2A5M9gCi+xaFWoyLJEgGblI8Ei2 rXP3JuZQJT0GMNr4WxDWNtJVGotERHCuUBUXd7zdHsjiN4lxlU5oDTY3MkGNF1wKyMq6 8i5KG7jzf3HAefreRoyK2jpLT6WdWhzBc6JGc5I05fLtzMTt5eM5CNOut70YAyhOnT+4 QBtIWcK+qg+7RiRWhnRup16On7bfMHGOdcz2SAWbTFvBS+IKMZ3wy9R8t/IwBfeFncvL MHXQ==
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; bh=HPfMGGkUgrnLWvhESFHMqTpBnft6fxTE4vIGMHLIK70=; b=Kg9tQon9amGcSXC4rjF/uT7c/GxDkhZfzVV6L1Qj4VqZKXapJyV37RwTeRPZNSjaKZ KRzjihcliaSwwyJw5bXmNCdrfH6KmJ9p7N8XQ/dHOaANwk8Dyb4gzHJK6ivRiMw5l3L7 xpaDOSGrvT7UmW7kB3L8ABzvIqq0z13SqufqnOAggO/0Ig/KSNI6RfRqPGxR2JuQkwI8 MLj34JCRCmWxpAfYuoV6vJrVpCizYWryKAhPbH4vvw0sJwEnQ0xf9TO2OVHGDnM6Jpdb arnwXlAe9pO5XClHFlfKPsQgQWYqrryxp3EVYdXaA72pUr7F3P2gRqlquKfpXacoQ3ZN /B0Q==
X-Gm-Message-State: APjAAAVY2Bdnj7V6G69IuLzeHfV4zvDKghC3STgkKGAOzrUravfUZCJC gjdG//t7d5djsGpDHaP6QEvzHDZHeU3bsZBhMoAZ8NRL
X-Google-Smtp-Source: APXvYqxr6v+NNAagYcjc0tz1OjTskydZFq1LxVqxXXdot32L6NpNM+mhU9+fDSvx3K1WBwo7u9KNHcOd+FKRRARgRtc=
X-Received: by 2002:a2e:a490:: with SMTP id h16mr17027453lji.115.1582143660899; Wed, 19 Feb 2020 12:21:00 -0800 (PST)
MIME-Version: 1.0
References: <mailman.76.1582142417.22041.oauth@ietf.org>
In-Reply-To: <mailman.76.1582142417.22041.oauth@ietf.org>
From: Bruno Brito <bhdebrito@gmail.com>
Date: Wed, 19 Feb 2020 17:20:50 -0300
Message-ID: <CAKykFnJWQgKN2C5SJZFbmJphKL+=sc_NUbtRms-gbhCJMKyxHA@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e4459b059ef3868b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0jGltdCarG80SUCFS02qnzA93Gg>
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 9
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: Wed, 19 Feb 2020 20:21:09 -0000

No, I cannot see any use case where authorization code cannot replace
implicit. Go ahead and remove it!

Bruno

On Wed, Feb 19, 2020 at 5:01 PM <oauth-request@ietf.org> wrote:

> Send OAuth mailing list submissions to
>         oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         oauth-request@ietf.org
>
> You can reach the person managing the list at
>         oauth-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>    1. Re: OAuth 2.1 - drop implicit flow? (Dominick Baier)
>    2. Re: OAuth Digest, Vol 136, Issue 7 (Torsten Lodderstedt)
>    3. Re: [EXTERNAL]  OAuth 2.1: dropping password grant (Dick Hardt)
>
>
>
> ---------- Forwarded message ----------
> From: Dominick Baier <dbaier@leastprivilege.com>
> To: Dick Hardt <dick.hardt@gmail.com>om>, oauth@ietf.org
> Cc:
> Bcc:
> Date: Tue, 18 Feb 2020 22:49:05 -0800
> Subject: Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?
> 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
>
>
>
>
> ---------- Forwarded message ----------
> From: Torsten Lodderstedt <torsten@lodderstedt.net>
> To: Bruno Brito <bhdebrito@gmail.com>
> Cc: oauth@ietf.org
> Bcc:
> Date: Wed, 19 Feb 2020 08:25:19 +0100
> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 7
> Hi Bruno,
>
> thanks for your insights.
>
> The recommendation is not only based on security considerations but just
> utility. As soon as one wants to integrate federated login or multi factor
> authentication,  ROPG reaches its limits.
>
> Moreover, how do those teams implement user registration and user account
> recovery? In my experience, implementing this in a native experience will
> significantly increase cost of the implementation.
>
> Two reasons to go with the code flow.
>
> best regards,
> Torsten.
>
> > Am 19.02.2020 um 01:49 schrieb Bruno Brito <bhdebrito@gmail.com>om>:
> >
>
>
>
> ---------- Forwarded message ----------
> From: Dick Hardt <dick.hardt@gmail.com>
> To: Anthony Nadalin <tonynad@microsoft.com>
> Cc: "oauth@ietf.org" <oauth@ietf.org>
> Bcc:
> Date: Wed, 19 Feb 2020 11:35:03 -0800
> Subject: Re: [OAUTH-WG] [EXTERNAL]  OAuth 2.1: dropping password grant
> Tony: are you ok with dropping password grant?
>
> You reference valid use cases. If you think it should continue, would you
> provide the use cases?
>
> ᐧ
>
> On Tue, Feb 18, 2020 at 12:57 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
>> The security topics says MUST. If you want to change that, then that is a
>> different discussion. :)
>>
>> In the OAuth 2.1 document, it would just not be included. Applications
>> can continue to be OAuth 2.0 compliant.
>>
>> BUT ... if there are valid, new use cases. Please describe them! Perhaps
>> it should not be dropped.
>>
>>
>> On Tue, Feb 18, 2020 at 12:54 PM Anthony Nadalin <tonynad@microsoft.com>
>> wrote:
>>
>>> I would suggest a SHOULD NOT instead of MUST, there are still sites
>>> using this and a grace period should be provided before a MUST is pushed
>>> out as there are valid use cases out there still.
>>>
>>>
>>>
>>> *From:* OAuth <oauth-bounces@ietf.org> *On Behalf Of * Dick Hardt
>>> *Sent:* Tuesday, February 18, 2020 12:37 PM
>>> *To:* oauth@ietf.org
>>> *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant
>>>
>>>
>>>
>>> Hey List
>>>
>>>
>>>
>>> (Once again using the OAuth 2.1 name as a placeholder for the doc that
>>> Aaron, Torsten, and I are working on)
>>>
>>>
>>>
>>> In the security topics doc
>>>
>>>
>>>
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-14%23section-2.4&data=02%7C01%7Ctonynad%40microsoft.com%7C47bb597eef584c95ba4108d7b4b274b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637176550905333283&sdata=nA1S7TBfZg6cSwY2hI8hpRXhIA2joaaJFmNXrATgr2Y%3D&reserved=0>
>>>
>>>
>>>
>>> The password grant MUST not be used.
>>>
>>>
>>>
>>> Some background for those interested. I added this grant into OAuth 2.0
>>> to allow applications that had been provided password to migrate. Even with
>>> the caveats in OAuth 2.0, implementors decide they want to prompt the user
>>> to enter their credentials, the anti-pattern OAuth was created to
>>> eliminate.
>>>
>>>
>>>
>>>
>>>
>>> Does anyone have concerns with dropping the password grant 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
>