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>, 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>: > > > > > > ---------- 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 >
- Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 9 Bruno Brito
- Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 9 Bhupinder Saini