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

Bron Gondwana <brong@fastmailteam.com> Mon, 01 March 2021 04:35 UTC

Return-Path: <brong@fastmailteam.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 9569B3A1496; Sun, 28 Feb 2021 20:35:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.22
X-Spam-Level:
X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=FProOofa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mvv7/yBe
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 JU7QbmUs7CsD; Sun, 28 Feb 2021 20:35:55 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBB13A1495; Sun, 28 Feb 2021 20:35:55 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2F4855C00B4; Sun, 28 Feb 2021 23:35:54 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Sun, 28 Feb 2021 23:35:54 -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=VUmn 2RIrpI0Fq6S1qfBgpEnnQbMhWqJrkDweQIM9Kj8=; b=FProOofakGlOB/T97imj OQqK1R9shIunnzlCn0ORKyqb5Q/KXXDGw5T97zJEUqMQIPKe7LlwzFNDbXFEjY2Z lO/rIi9+dSPEt7sRS8szlbwEr2vjKEEnwZdlVNJq6/BjDgXIyJzPwnvTnY3X9eyL d2ZSUfaGTcCq05rKfAXO5f5uTcplCc0VUjhvchDG+fMUDL+ZSpWfYYcp3r0iEPXg m22P00N6uD8JCwVzZHDDQyENToL6z3sxAdhj2havp2jWU5ASIWhPrbY4vCpRjddL O3tl0aZHF5g60Jbr8XzJsXp6YsVhyF2pLHSxym2brqLDgFUBq7BNYGdbyVAf1+2p JA==
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=VUmn2R IrpI0Fq6S1qfBgpEnnQbMhWqJrkDweQIM9Kj8=; b=mvv7/yBeDbL6bHQnHoV04V oV47X5LF62Kh7I+XAFTZRg6cgiWp081Za5yNsHI4guyxFaUntbDo+WxxQMsJwYDq 7zDyIZ2V9IzZdPs6yIRCdogqo31dPfrAMRWAVjv9luGNKsURqr/2X5UDszZ/r9NH 8KXGth8OuLk3Rlom9XjJvxKF2srmt1bZV2mPBQYEdnimy+4tWWUcGz7fug3AFL/n Cd7FYxjTW6FjlNzBWtcNePW6qrTYSs9Ui+6F0/NaHyCvp3tmppvU9dTIcEuX4/vU aZOU24cCQUDr1axhsOOVGPkSK8mr7rj5xoxvmv08CEMuKsGCbDAJP1qu6CIIC12A ==
X-ME-Sender: <xms:KW88YFJCzBb7vs5tIOvS7bXA-M8PNH3or66LKi15KFcwQmeGguwSPA> <xme:KW88YBIFHMAoKRD962VopzQwA3JQrlDy4w8SnOJU3XZnjlxCkfKg5wyLYsiLQmfu9 3eVnHrevYY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrleejgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpefgteeutdeftedtffeftdduudfhkedvffeuhfejjeevueev tedvudduueeifedtffenucffohhmrghinhepfihikhhiphgvughirgdrohhrghenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:KW88YNusdDjhBCJO8Hv_bfxFcb08cHmUVj7w0Vh5dP0Y8ao_zYpjsQ> <xmx:KW88YGbHwWU6pXhG5Y52OUkga8SNXWm5ozbYapNDXZHu1Jc-iW28BA> <xmx:KW88YMZO8-47vscQj0j8JRXTlmWXXaqB25VPPfpWzn-po4Y3w-jBNg> <xmx:Km88YLkuswSywUlLSGtWMnyiq_QbGohHnF4XPWNE56babt8C1hNTyw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4E114360592; Sun, 28 Feb 2021 23:35:53 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-Id: <7ee21778-2ab2-40f5-9273-775f8a88744b@beta.fastmail.com>
In-Reply-To: <CAPLh0AMfncjJ0iaZ5gmzrh1D0Z7WCOtG-+6GZkmzfQuAttsBtw@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> <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>
Date: Mon, 01 Mar 2021 15:35:23 +1100
From: "Bron Gondwana" <brong@fastmailteam.com>
To: =?UTF-8?Q?Se=C3=A1n_Kelleher?= <sean@trustap.com>
Cc: "Justin Richer" <jricher@mit.edu>, "Phillip Hallam-Baker" <phill@hallambaker.com>, "oauth@ietf.org" <oauth@ietf.org>, ietf@ietf.org
Content-Type: multipart/alternative; boundary=c792c58e39f145ceaadf3ef6c453c130
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2fIeupSTlpK-aqLAfDc6XXuwS5s>
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
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: Mon, 01 Mar 2021 04:35:58 -0000


On Thu, Feb 25, 2021, at 19:22, Seán Kelleher wrote:
> Just to clarify, I assume in this discourse that the "server" in this client and server relationship refers to an AS/RS pair in OAuth terminology? Based on this, one big sticking point for me on the applicability of NxM, or even 1xM, is that all of the "M" RSs need to publish the same interface for any meaningful implementation in the first place.
> 
> It probably makes more sense with email clients, since as Bron said, there is the common standard of POP. If we assume that all the email services that we want to connect to publish the same POP interface, and would accept tokens in the same way, then the way the authZ is handled is indeed the point of divergence that needs to be resolved.
> 
> However, we're talking about NxM in the general case here. I feel like using the likes of discovery and dynamic registration, etc. that's already supported by OAuth, the "N" part of this equation is surmountable. But each of the "M" servers also need to export the same interface, otherwise a client is going to have to write custom code to deal with talking to the service after the authZ step anyway, reintroducing the "problem" part of the NxM problem.
> 
> As such, I would actually suggest constraining this discussion to just the POP NxM problem rather than NxM in general because, for me at least, the authZ part of the general case is the most "solved" part of the problem, and the outstanding work lies more in consolidating the "M" RS interfaces.

Sorry for the delay in responding - real life got in they way of this general discussion.

Yes, the common standard of POP - or indeed any common standard.  A fine example of common standards is the move towards many devices being charged by USB-C these days.  Previously, there was this:

https://en.wikipedia.org/wiki/Common_external_power_supply

Why?  So you that you don't need a new charger for each new device.

The whole point of being a standards org is to try to guide each "M" towards exporting the same interface when providing the same (or similar enough) underlying service, so that the network effects of interoperability are realised.

So yes, constrain to POP (and IMAP, and SMTP submission, and file storage, and calendars, and ... everything where there's enough similarity that clients should be able to portably interoperate with multiple services).

Right now the problem with POP/IMAP/etc is that the interoperable authentication choice is "username+password".  There's nothing better than that because there's no Micro-USB-like thing that has sufficient technical and political clout behind it that everyone implements it.

Bron.

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