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

Evert Pot <me@evertpot.com> Thu, 25 February 2021 19:50 UTC

Return-Path: <me@evertpot.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 82DD93A1F28 for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2021 11:50: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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=aq8owPcu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kSlVrnFc
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 59LuBCIre1uz for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2021 11:50:09 -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 58ECC3A1F2F for <oauth@ietf.org>; Thu, 25 Feb 2021 11:49:47 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B6DE55C0130 for <oauth@ietf.org>; Thu, 25 Feb 2021 14:49:46 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 25 Feb 2021 14:49:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=mesmtp; bh=WPC4hQX4dmJN8vmZojuqYSZ/ ouaAQ/eKoF5tzomkgO8=; b=aq8owPcuX5yROVgAic3Hl3m5a/Pu45E/pBllwbPh UYsTghb6YZfbUvrCELTzDEFHB60uJnmsVosAp8hrfk3+XWNkdM7XfNZvL019VWup heICWC4I8x3QupdAPGz48L5lD3Mn7uhrAkCyIrya1CCaQNTmuTwcdagXuRUe77ta QXI=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=WPC4hQ X4dmJN8vmZojuqYSZ/ouaAQ/eKoF5tzomkgO8=; b=kSlVrnFcXS1wF1JCpK6vDf SM0p17oOWKkzNZWcfO3si5zDF+WvyxhRgvwIVSQKtcJc5P/tKNMMwOdLl1xB2akt ONjb9/DRSTA5gfZYoaCQn9TwCbD6pDcPLPHNtobemVSzOeOXz1u1ppk0Cg/VC8gJ 4NoFFm6TFGI4YnxnnQ6sJYiqHRkyivRaHT5knDO4TWKMiKB33PKbxR1JceibfjUg 1Z2Fetk1LwJkN5R4h+fnLAkF44F0DpkVe6cGG1EMxya5FEmTZIKUm0vW59Kk70l/ wy+dYZJowhJIs/YpHLb3fxdf/rB0e0z83zzR6mcBYUxZfz1C+nIo7O7D2hLIFxtw ==
X-ME-Sender: <xms:Wv83YA46umNIDccC0FVBeav8BnxtfiIeVFZI0lPc5xHS7dqBuwsZUQ> <xme:Wv83YB5oUbdNW5ELMv-kZgLD3qRsz2s4QUxAarND8FDIoTpWcc5j0iGH22umzOnWq TgMCOzLFrvVxcja>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeelgddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgt ohhmqeenucggtffrrghtthgvrhhnpeethfekfeelvdejudeugeeugefgteeiheeivddvtd dtheelvddtgeduhfelheeitdenucfkphepudegvddruddviedrudeiiedrvddtjeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmvgesvghvvg hrthhpohhtrdgtohhm
X-ME-Proxy: <xmx:Wv83YPegPCgdvSZxLrVWvZboxn4n-tihyHcy_Mlq4LVZoukoJvNarg> <xmx:Wv83YFLfBXWTdH6br1xH6MqGHYP11OSJJd9BDEdwfq3RPq-2Gj4UiQ> <xmx:Wv83YEKG_1EMCrgo2DhiPJJUKLRk0W9P57GjXQIf9M4_FuTc_WQOow> <xmx:Wv83YJWYZifMVi5a_X3SkvZQlsTHAaCAsUuLVhB-TMdsmIN06htqSg>
Received: from [192.168.2.61] (unknown [142.126.166.207]) by mail.messagingengine.com (Postfix) with ESMTPA id EBE0824005A for <oauth@ietf.org>; Thu, 25 Feb 2021 14:49:45 -0500 (EST)
To: oauth@ietf.org
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>
From: Evert Pot <me@evertpot.com>
Message-ID: <6573391f-fb72-3175-5f70-3e4c00977dc6@evertpot.com>
Date: Thu, 25 Feb 2021 14:49:42 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <CAPLh0AMfncjJ0iaZ5gmzrh1D0Z7WCOtG-+6GZkmzfQuAttsBtw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A5285F7AC20DC22826ED5776"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1AJLIRAk57geDTbQKBVjD9Vyz7Y>
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: Thu, 25 Feb 2021 19:50:11 -0000

On 2021-02-25 3:22 a.m., 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.

The usefulness of this goes beyond standardized protocols / multiple 
implementors of an API. Some examples of what's possible with Basic 
auth, and not with OAuth2:

 1. I can point my browser to a Basic Auth-protected endpoint. I get a
    pop-up and it will let me log in.
 2. Basic auth is supported in tools like Curl.
 3. It makes generic clients more viable for things like APIs. SDKs for
    specific APIs can be helpful, but HTTP is the universal interface. I
    should be able to use a generic HTTP client and point it to a
    generic HTTP destination and for this to work.
 4. Similarly for the cases where there is a common standard
    server-side, implementors should not have to decide on an
    authentication system. If Auth is baked into the HTTP layer and
    widely supported, POP can be agnostic about how Auth is performed.
    This allows independent upgrading/decoupling of 'POP' and 'Auth'.
    Imagine if we had to update *every client* if a new TLS version is
    released? That's what OAuth2 is like now.

Evert