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

Christian Huitema <> Fri, 26 February 2021 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5249B3A166D for <>; Fri, 26 Feb 2021 12:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D-UvbmnAotbj for <>; Fri, 26 Feb 2021 12:11:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D4AB3A166F for <>; Fri, 26 Feb 2021 12:11:38 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1lFjSW-0013ay-Up for; Fri, 26 Feb 2021 21:11:36 +0100
Received: from (unknown []) by (Postfix) with ESMTPS id 4DnLQV3MGPz1RWp for <>; Fri, 26 Feb 2021 12:11:30 -0800 (PST)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1lFjSU-0006JX-BO for; Fri, 26 Feb 2021 12:11:30 -0800
Received: (qmail 23270 invoked from network); 26 Feb 2021 20:11:29 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 26 Feb 2021 20:11:29 -0000
To: Tim Bray <>, Justin Richer <>
Cc: =?UTF-8?Q?Se=c3=a1n_Kelleher?= <>, Phillip Hallam-Baker <>, "" <>, IETF-Discussion Discussion <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Fri, 26 Feb 2021 12:11:27 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------48E3803F2B4E0F219BF5EDD8"
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8uEaMc9v2z//gxoDgwFDrHPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yor/eCA3dHrmTLi/t2S44TfYzfQXcfqmra3dmoHS4ygqt2 eVsmjp+9Ijq5HCI5CwJWuRWrkPihq53YqAd1ENNqBHtNXu1E6L4+KyOXc4QYanQOD0r6/AaHZiEt dTMtMlia0Lmg/jgHfCNZd+W+PXf6Pjb130VX+iieImINR22zmiue9TLOhN8AYRsvkjfngQDbNI0R 22tddiGKm8EgkM9zzDkBvlIN1pUDU5DU5DggD98cjIN3reG9z0FKKQ5m2Qpw7sOVVcM1Xk+Tdz6g /UMvfWqyN3veeFIMJz/vumcqAwMU9kjfE7EFo+kP5riIEUmxU01QhuxnshSbl6nxbLZ35/xY0uvo WBEOfzq3RG28wI7w4vcwqZanLHsZM8r4s5ZjlHoGly8aneNxj+pRyx6DAzHPcWsnfqGSaNoXhWPo OpFVgpT1b21uZVckGp0ccOZtuBWXiK6eoWgQZnNLL6SbpUc7peFeo3eDQNYbhOKhzzgqmaDn5SlD Y9mmtv6e91aWBLor1oCWetcUjeG94V2XjoV9/BLvlyUvLzL6lsKk96TeVLW3pB0Q/PTyowo5AfvG OBMN2od+PeP79VOTtEEkCFXoGKtafvOtcW/mP16byrL/nwvREHuP3/Ps3A4Pt7hRyBl07OVp2D/S 9ogT8aIX6abOyKlLsxs8P4CT3FEuG1XPGkvWCCTmYu1mXbT/IvWC1AI9a3irbifzymzQYX+Pr3ZM ctiC/YQAlJjw8umpOJTjAZmlRsj5gYoNz52VfvCKuZkMyFBGaEBYeh6pTEjUL/n+3uEzmvwRmti3 9+fizX6m+UeFXprlCOm3BAEbJtAT1BYHStA0OogdNtRxnRSLF+XCKxIG9XMEgRDdaWpvCv+zESlk TxdSCNcDfRohcehWBb39uS1TjWG2Inx+Ts2QNOYPIz4ynMa7pZQ4hi/HGtuWeHzx9sLaQmDwvYQn 76e9NXttZBkk6PeFqH6So31P
Archived-At: <>
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2021 20:11:41 -0000

On 2/26/2021 8:31 AM, Tim Bray wrote:

> On Fri, Feb 26, 2021 at 8:10 AM Justin Richer < 
> <>> wrote:
>     Right, it’s possible to patch OAuth to do this, but the whole
>     “registration equals trust” mindset is baked into OAuth at a
>     really core level. That’s one of the main reasons there’s been
>     hesitance at deploying dynamic registration. It’s an extension
>     that changes your trust model’s assumptions, and does so in a way
>     that is challenging for a lot of large scale providers.
> Justin is correct but being extremely diplomatic. “There’s been 
> hesitance”, as he puts it, translates in practice to some lawyer or VP 
> saying “You want to accept auth assertions for business transactions 
> from unknown parties?  I have no interest in jail time, so forget it.”

Tim's point is very important. It shows a tension between "blindly 
accepting authentication claims from unknown parties", which would 
indeed lead to adversarial business consequences, and "only accepting 
authentication claims from parties that have been marked as trusted by 
my organization", which in theory looks safe but in practice drives 
concentration. If the trust decision is delegated to each site, we have 
the recipe for a network effect, in which only a very small set of big 
organizations can provide authentication for everybody, and collect the 
corresponding data and statistics.

This is both a very hard problem and an urgent problem. An IETF working 
group works on a hard issue and produces an incomplete solution. Big 
companies can fill the gaps by providing their own value. The result is 
further concentration of the Internet.

Such problems are very hard, but they are not impossible to solve. Look 
for example at PKI and its supporting infrastructure like the CAB Forum. 
It is not perfect, but at least it had the property of allowing web 
sites to use HTTPS without routing all authentication transactions 
through third parties. Wouldn't it be nice if we had a federation system 
on top of OAUTH? I suppose that is difficult. Not a reason to not try...

-- Christian Huitema