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

Bron Gondwana <brong@fastmailteam.com> Wed, 24 February 2021 12:15 UTC

Return-Path: <brong@fastmailteam.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 CE4AE3A14CB; Wed, 24 Feb 2021 04:15:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level:
X-Spam-Status: No, score=-2.09 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_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=BHs9qQcZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L1PZvvEa
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 jnOBF8Lmmr0n; Wed, 24 Feb 2021 04:15:39 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63763A14C6; Wed, 24 Feb 2021 04:15:39 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 18C3AD3D; Wed, 24 Feb 2021 07:15:37 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 24 Feb 2021 07:15:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=CfUi I2T4kBowliICxECW3T81QtAEzSdAnul5DLO/Yt0=; b=BHs9qQcZu0eRO1yPQCmz bZRh+/c/LfBRDNHu3JPbRx6AbohLaeZ9fmkOeGE4dlmFWY88ZYd3NCHR4aQjF+ii oy9rQ4nSlxpxhFPAWmBtjj1U2eoHuGMBPlU2gh7vhUdBx/Es8sjT/VMPI/FGKDJF cYGjmeEiPFRlyNkQfnNkfxQnctK37kukj69a4Z/pV51KE3lglquGhOFSxIvNHQob VDImKpKTF2hagiJyLDTlZXUEYeST9viiqwyW6zWvBsKZ5ZSsaXR61mkLvSdbYt6i uV7G6xVPUZkK/gMSpZeeX+Ja081d2lto+Gza6FMEdE0x2RPgLlPd6ya0/r8D+S50 nA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=CfUiI2 T4kBowliICxECW3T81QtAEzSdAnul5DLO/Yt0=; b=L1PZvvEapIiCiCQZKZJQKp CslGu6eUh3Oj51+bz2LNWIYInK7NNqbMhxdWmuYgGrNJUc7vclw+JW8FRxjHyDAT ouxwqDh7PgxEcgJ4S5HRc5w4mHDWsHaAKIBbpvYUTzcEVTAZYzSzmhCCbAgNenTV LvmRQnH/r5LZMMHMh98KB5L3eINq+0tTXuvmoX0NunwVUTqdyRiLOvyUIeFq/RLG 5qbwKp6qhy29xuJ5DdGcnNveBBQXiJBBsRKsd2EHiB9Anb7Yokk7JcS/vbZi4cdI 7ewc5LavfaLYoOb0YGvSMx+O/xdzyF5JDq7El+yG2xET96phVbhoFOOU7s/kx1Xw ==
X-ME-Sender: <xms:Z0M2YA0Fk9yWSFEx6o0yI-FTGXkFp-kXesL-4QvWdk7fNZDThEmbsg> <xme:Z0M2YLHwFDfWVPygefb5fFzO5yEnK8rg5vamEgeHP1WK2PhM584TgjSNctJ7mDAFi _DHJtX6Pb0>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeejgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenog fuuhhsphgvtghtkfhmghffohhmrghinhculdeftddmnecujfgurhepofgfggfkjghffffh vffutgesrgdtreerreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoe gsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhep ieevffejudeiheffudetieejgeevfefhheehteegtdeghfefjeejledugeehieefnecuff homhgrihhnpegruhhthhhrvghsshdrihhopdhfrghsthhmrghilhdrhhgvlhhpnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfh grshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:Z0M2YI7ZtZxNjJa6y3ZVAlAY-OQSMbKML10y5LaUfCA5EXew6t-8Tg> <xmx:Z0M2YJ2hrhKvhusH4kj7bHU_hZFdbM6zMFTNoxdinI0-wTqE9BHCgA> <xmx:Z0M2YDGijThNZofZr8Z1arh0SGlFjtThENuxplTidlNZj3Q4mlcGmw> <xmx:aEM2YIRk3t7zGAIr5VfKxa6e6At00quMIdVLmcyACojp3u698sv47Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 800093605A4; Wed, 24 Feb 2021 07:15:35 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-179-g81f7aba968-fm-20210222.002-g81f7aba9
Mime-Version: 1.0
Message-Id: <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>
In-Reply-To: <CAJot-L2KO2dOzZQJJeB1kbk6_KTQwUYUsoJOoRt=9maynS1jZg@mail.gmail.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>
Date: Wed, 24 Feb 2021 23:15:15 +1100
From: "Bron Gondwana" <brong@fastmailteam.com>
To: "Warren Parad" <wparad@rhosys.ch>
Cc: "Carsten Bormann" <cabo@tzi.org>, "Phillip Hallam-Baker" <phill@hallambaker.com>, "oauth@ietf.org" <oauth@ietf.org>, ietf@ietf.org
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
Content-Type: multipart/alternative; boundary=15c3934dff084aa3a448abcc46af34e9
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZUgthtrhCmY7UHWDDjjv_DiHnfw>
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: Wed, 24 Feb 2021 12:15:43 -0000


On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
> (I tend to trend lightly in the pronoun area, mostly because I'm shocked that openid included gender but not pronouns)
> 
> I hadn't heard that to be called the NxM problem, so that definitely cleared up the potential confusion (at least for me).
> 
> I think GNAPs lack of clarity is a non sequitur for the handling or not of the multitrust arbitrary-client with arbitrary-service, however it's lack of clarity for me prevents me from knowing whether GNAP actually seeks to solve this problem. So from an OAuth WG perspective we can still ask:
> 
> *Is this or should this problem be left to GNAP to solve, or is an OAuth WG responsibility?*

Honestly I think the problem space is the whole ietf's responsibility. Protocols that allow an end user to safely transfer data between two parties that don't have a pre-existing trust relationship are a key part of enabling user freedom and user choice.

Bron.

> 

> *Warren Parad*

> Founder, CTO

> Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>.
> 
> 
> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana <brong@fastmailteam.com> wrote:
>> __
>> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
>>> I would prefer Bron to answer that question, as they are the one who started this email thread.
>> 
>> You can also use he when talking about me, or she for that matter - I do enough group fitness classes where it's roughly assumed that the entire class is female, and I have an ambiguous enough name that I'm used to it.  Most people use "he" most of the time.
>> 
>>> However let's look at GNAP, I've honestly been struggling to understand at least one fully documented case that GNAP supports. It seems in every document the only thing that is clear is GNAP wants to allow "everything", doesn't actually talk about an example.
>> 
>> That's my biggest fear for GNAP - it too will try to be everything to everybody and wind up being nothing to nobody because the super flexible "everything protocol" is the same as no protocol at all, since you have to special-case everybody you talk to anyway.
>> 
>>> By NxM, I assume we mean that the end user or client is free to select whichever AS they want, in a way which the RS can verify the AS credential and the user identity, without the RS having to (and really without the ability to limit) which AS are allowed.
>> 
>> Let's get down to use cases then, rather than talking in abstracts.
>> 
>> I'm an end user with a copy of {The Bat email client} and I want to connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely popular open standard.  I want to be able to authenticate to each of those services without saving my plaintext passwords on my hard disk where the next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account, leaving me destitute.
>> 
>> But, {The Bat} doesn't have a trusted client cert from my isp, because who does - so there's no good protocol for me - it's either plaintext auth, or it's some architecture astronaut multi-party nonsense that's massively over specified and doesn't work half the time.  So I write a plain text password on a post-it note which is lying in the dust under my monitor because the glue has gone bad, and I hope I never accidentally click "remember me" when I type it in.
>> 
>> That's been the reality of the end user experience for very many years.
>> 
>> NxM means that you can authenticate an arbitrary client against an arbitrary server so long as they are both speaking a known public protocol, without needing to build a trust relationship between the client vendor and the server vendor first.
>> 
>> Any "trust relationship" is made through a user both who trusts the client and trusts the server, and it's not transitive over to other users of the same client and the same server.  The client author doesn't need to get a signed "I trust you" from every single server, and the server author doesn't have to go identify every single client.
>> 
>> That's what NxM means to a user, the ability to use arbitrary clients with arbitrary servers so long as they both implement a documented protocol.  Interoperability.
>> 
>> OAuth has not given interoperability in the NxM sense outside some simple web use cases.  They're nice and all, but they don't tend to be useful with open protocols - OAuth gets used for accessing proprietary API endpoints after getting an access key for a single provider.  At least you get Nx1 or 1xM out of it depending who's the N and who's the M, and maybe some of your code can rhyme so you're not doing everything from scratch each time.
>> 
>> This is the sorry story of real open protocols.  The floor for true interoperability is still username + password over cleartext, over hopefully a TLS tunnel that's providing some level of protection.  Most so than a few years ago when Fastmail wrote our "starttls considered harmful"[1] objection to the IETF's habit at the time of putting a "STARTTLS" upgrade into an initially plaintext protocol, where an active intercepter could just strip the "I support STARTTLS" indicator from the protocol and convince the client to send the credentials in the clear.
>> 
>> We're a little better mostly these days, but it's still a tirefire, and in my heart I do hold the OAuth working group's squatting on this area of the landscape while failing to address this burning need partially responsible.  The result (as Phillip pointed out upthread) has been a consolidation towards a few big players - because NxM becomes tractable when you reduce the N and M to small enough numbers.
>> 
>> Bron.
>> 
>> [1] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS
>> 
>> --
>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>   brong@fastmailteam.com
>> 
>> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com