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

Bruno Brito <bhdebrito@gmail.com> Wed, 19 February 2020 00:49 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 B14A312084F for <oauth@ietfa.amsl.com>; Tue, 18 Feb 2020 16:49:44 -0800 (PST)
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, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 9tbm8lVtmSIM for <oauth@ietfa.amsl.com>; Tue, 18 Feb 2020 16:49:40 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 CCC7112083A for <oauth@ietf.org>; Tue, 18 Feb 2020 16:49:39 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id b15so15968282lfc.4 for <oauth@ietf.org>; Tue, 18 Feb 2020 16:49:39 -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=YOcTh8/uJfelQj7flXZVjwmA4JzeRrax11+PMbnglCo=; b=Hj1MybPSj0zMNSPkXZgi07TmcD88HTOj8Pzs87OByt+490YQK2ponPIJp9Pvfd6/LA F/Z0gL8u+TtSGRkKE5/Eph5plHI8SkH+LNx4Jwp4RvGKeyp6sWubhCbc/S3yympZWbw3 8GTofvLjGJnqaKy4pHmiqcduhocBByiew6gPRZOtJ3ozcYzysn2c1QQVFt4AsxZZCNdc Hg5ONVdeeRDnJjGddAZiO2jyEkXCJDQdmNOvsuaBNxwo1jAKqWJOybOOj/nm4fUzm5GA 1vqXxhzB4Juzg6B9dhksIoVeM+hyxrzjcnHPRUcuqTZYKpv8tk5E1BUcp0SfptKc37nr i0Yg==
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=YOcTh8/uJfelQj7flXZVjwmA4JzeRrax11+PMbnglCo=; b=Net9A+Jc7pIWP2fpkKotM+SzFyuYzz1Lxyhe3V6DdXroPvEap2W0Dpj5LrErgieeB1 R0D2fA1HQeh4meO5UQ40LiT1rZNB4YN5/F7bTX1fgR+M95UxknOzSkzrxfZfde1Bt+xd AEzChiEwnK1qLgp+lI52hWxYkUPgjqhCLYjfPQ65qJ4Uh4ICEI5JjCTqY/w51+AnLI4D NnymhXlPd91edQd/D1QOUhPqJW8Rh+7YxAfqXIO3roQqDRrbT5wS4qMdrho5uIJRsdOj uT5p0DzqzNhvf1z6e1rXcJ4eAdbHn8KR00tNZ2mj5kEHj5KjnKnDLjgWohCSjR2GCaVW h9zQ==
X-Gm-Message-State: APjAAAW3riffYoLYcIwJIMgjzzQoFGLaAm9/KpzZympyEQ/JbdYb6uAB o8WJN3EY7WdNkcmI4000/b1WuS7SMSlq7MItGCbxMsdk
X-Google-Smtp-Source: APXvYqyYtH9t0agDRsmPTMW6vZYhm4IpEPwlvJIeLPjgG6wiGYukS8dOJqvkb4dabJ9mZVSC3evi0QjbgM8Uq3y/ABI=
X-Received: by 2002:ac2:52a3:: with SMTP id r3mr11828873lfm.189.1582073377445; Tue, 18 Feb 2020 16:49:37 -0800 (PST)
MIME-Version: 1.0
References: <mailman.154.1582063067.6828.oauth@ietf.org>
In-Reply-To: <mailman.154.1582063067.6828.oauth@ietf.org>
From: Bruno Brito <bhdebrito@gmail.com>
Date: Tue, 18 Feb 2020 21:49:27 -0300
Message-ID: <CAKykFnLRnNR+016xmhO5cgYJsdtWgzAVcGn_C65B6az9oruMdQ@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000abdc30059ee329c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/96Up3R77Tx2eVT1RX10Zw0YM4t0>
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 7
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 00:49:45 -0000

Hi Guys,

I really understand the security and motivations behind ROPC and I'm not
against the decision it is deprecated. Actually I see many devs and teams
using ROPC to deliver a better UI experience in Mobile apps and easy
integration.
They try to follow specs of RFC 8252 and AppAuth isn't easy to use. Many
bugs shows up in the way, and it's not a good user experience at all. At
the end of the day, they became to use ROPC as an alternative. Tremendous
easy to implement compared against AppAuth.

My question is, we are really prepared to go away from ROPC? In one hand
the best practice says: Use AppAuth for Native apps. But in this case the
time and efforts the teams need to implement it in a good manner is
substantially high if we compare against a SPA Frontend using javascript
oidc. So my point is, isn't better for us before remove oidc, try something
to improve a better and easy integration with native apps?

/Bruno

On Tue, Feb 18, 2020 at 6:57 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: dropping password grant (Aaron Parecki)
>    2. Re: OAuth 2.1: dropping password grant (Hans Zandbelt)
>
>
>
> ---------- Forwarded message ----------
> From: Aaron Parecki <aaron@parecki.com>
> To: Justin Richer <jricher@mit.edu>
> Cc: Anthony Nadalin <tonynad=40microsoft.com@dmarc.ietf.org>rg>, "
> oauth@ietf.org" <oauth@ietf.org>
> Bcc:
> Date: Tue, 18 Feb 2020 13:43:37 -0800
> Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant
> Agreed. Plus, the Security BCP is already effectively acting as a grace
> period since it currently says the password grant MUST NOT be used, so in
> the OAuth 2.0 world that's already a pretty strong signal.
>
> Aaron
>
>
>
> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <jricher@mit.edu> wrote:
>
>> There is no need for a grace period. People using OAuth 2.0 can still do
>> OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
>>
>>  — Justin
>>
>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin <
>> tonynad=40microsoft.com@dmarc.ietf.org> 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
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk <http://twitter.com/aaronpk>
>
>
>
>
> ---------- Forwarded message ----------
> From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
> To: Aaron Parecki <aaron@parecki.com>
> Cc: Justin Richer <jricher@mit.edu>du>, Anthony Nadalin <tonynad=
> 40microsoft.com@dmarc.ietf.org>gt;, "oauth@ietf.org" <oauth@ietf.org>
> Bcc:
> Date: Tue, 18 Feb 2020 22:57:33 +0100
> Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant
> I would also seriously look at the original motivation behind ROPC: I know
> it has been deployed and is used in quite a lot of places but I have never
> actually come across a use case where it is used for migration purposes and
> the migration is actually executed (I know that is statistically not a very
> strong argument but I challenge others to come up with one...)
> In reality it turned out just to be a one off that people used as an easy
> way out to stick to an anti-pattern and still claim to do OAuth 2.0. It is
> plain wrong, it is not OAuth and we need to get rid of it.
>
> Hans.
>
> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki <aaron@parecki.com> wrote:
>
>> Agreed. Plus, the Security BCP is already effectively acting as a grace
>> period since it currently says the password grant MUST NOT be used, so in
>> the OAuth 2.0 world that's already a pretty strong signal.
>>
>> Aaron
>>
>>
>>
>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <jricher@mit.edu> wrote:
>>
>>> There is no need for a grace period. People using OAuth 2.0 can still do
>>> OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
>>>
>>>  — Justin
>>>
>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin <
>>> tonynad=40microsoft.com@dmarc.ietf.org> 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
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> --
>> ----
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk <http://twitter.com/aaronpk>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> hans.zandbelt@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>