Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

David Waite <david@alkaline-solutions.com> Fri, 26 February 2021 21:36 UTC

Return-Path: <david@alkaline-solutions.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFEF3A0C28; Fri, 26 Feb 2021 13:36:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.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 gq9G8G4ZB9qA; Fri, 26 Feb 2021 13:36:08 -0800 (PST)
Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F013A0C23; Fri, 26 Feb 2021 13:36:08 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id D83B120511C; Fri, 26 Feb 2021 21:36:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1614375365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XzNa/FeuwVfR8Bay5xW5Z/Cz6ylpXzhPFHfObgrQKl4=; b=j26VsexMM9UZWirBA10U4IbT/ggf3nhYnW5r733RIWigsepWklxR3l9ubbNp745821IJ3d lO+mSD+QnSWXVBCpZvWxOEW6ylKrKGZQGmQAvIWlcy/EZQ8A7vuAbVJlbTPTY3BQhqARyF 6uh2YXI9zZZX5egu6EQ0TvS4Lasqf2w=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <CAGBSGjqE4XKQmx2B8Lvh4faazfZPYqAYBy2NhSrewaBmEEBzpw@mail.gmail.com>
Date: Fri, 26 Feb 2021 14:36:02 -0700
Cc: Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>, Bron Gondwana <brong@fastmailteam.com>, Phillip Hallam-Baker <phill@hallambaker.com>, IETF-Discussion Discussion <ietf@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A4ABDE3-7175-4E5B-8807-437EE3CE427D@alkaline-solutions.com>
References: <CAMm+LwgbK3HYDjSHnTN3f6hWSQCQrEjHLNn6z0JpfY7hdxaQpg@mail.gmail.com> <A8128346-B557-472F-B94F-8F624F955FCE@manicode.com> <eb2eaaa7-7f7e-4170-ab87-1cc1fdd3359b@www.fastmail.com> <CAJot-L0PS_3LxEkC-jd1aqXDdYF+z8BajSs4Rhx3LgRPn6wkdQ@mail.gmail.com> <DAB127D7-809F-4EC2-A043-9B15E2DB8E07@tzi.org> <CAJot-L1e8GegjXjADRQ87tGqnSREoO4bEKLX+kPkZFsQpevGQA@mail.gmail.com> <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com> <CAJot-L2KO2dOzZQJJeB1kbk6_KTQwUYUsoJOoRt=9maynS1jZg@mail.gmail.com> <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com> <E84B4446-5F74-402B-8071-A1164EF0B02C@mit.edu> <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com> <CAPLh0AMfncjJ0iaZ5gmzrh1D0Z7WCOtG-+6GZkmzfQuAttsBtw@mail.gmail.com> <CAPLh0AMEnbak8=6boESQCgTd=Au4V9O=wCqGCz5qEU-d3y0g5g@mail.gmail.com> <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu> <CAJot-L1x_AxjQAH7uJ+GsW1jcc93b8ijJ7uyiVRRDZtZf=NXCw@mail.gmail.com> <CAGBSGjqE4XKQmx2B8Lvh4faazfZPYqAYBy2NhSrewaBmEEBzpw@mail.gmail.com>
To: Aaron Parecki <aaron@parecki.com>
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/nMeR0RLdcwYIAwr68wvwlPEadBc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2021 21:36:10 -0000


> On Feb 26, 2021, at 9:32 AM, Aaron Parecki <aaron@parecki.com> wrote:

> The point is that basically nobody uses it because they don't want to allow arbitrary client registration at their ASs. That's likely due to a combination of pre-registration being the default model in OAuth for so long (the Dynamic Client Registration draft was published several years after OAuth 2.0), as well as how large corporations have decided to run their ASs where they want to have (what feels like) more control over the things talking to their servers.

Do you disagree that this gives them control over which things talk to their servers?

FWIW my personal mental model here is pretty simple:

With users, there are services you provide anonymously and services you provide only to registered/authenticated/trusted parties for various reasons. Once you are delegating user access, you still have many of the same reasons to provide access to anonymous or registered/authenticated/trusted delegates.

Dynamic registration arriving later and requiring additional complexity has unfortunately encouraged registration in use cases where anonymous clients might have been acceptable, but shifting the timelines or complexity balance would not  have changed business needs for authentication and trust of delegates. Omitting registration would have caused businesses to use other protocols that met their needs.

If AS’s are only getting what feels like proper control for their business needs, we should attempt to give them the actual control they require.

-DW