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

Michael Thomas <> Fri, 26 February 2021 20:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9AAF3A16DD for <>; Fri, 26 Feb 2021 12:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.749
X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_OPTOUT_3LD=1] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fsj51lHJs0vE for <>; Fri, 26 Feb 2021 12:36:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46C473A16D9 for <>; Fri, 26 Feb 2021 12:36:50 -0800 (PST)
Received: by with SMTP id e9so5913132plh.3 for <>; Fri, 26 Feb 2021 12:36:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=beq0+NSzhsScSb9Kf/jhSXCOhM8ivNtzDffR9trSmYA=; b=nTuKxyknjQGXnty9l0jiGRSoBb28W2zeqkYFqb+ij9FA83k6fW5N31kQVLgIaKF62h 7QOSFzTGoO7CGOv7BdT7o/lwuYIgBeOUEARBu25XXc+ia3nffOpZW1ryX+//zyW7AbgJ 0BuWsWKddFjsQCVogVMzzq4/nmo6LHdYfQDlJUZewT/ZbMn99AcW/W18OPs8NaYfgRtZ 3UQ/USg0HrcFGVb334gQLO5isU8ZT3SJ4O24leSaTBULJ3A+++uliUxkcxi2evWrpRGo fhE7B+aZjfAcHFhf7/R5RR1q0FpEQ3YcnyOMWNfxEJuGJPEe+NfJYf8jSHsT54+hxxvI RTUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=beq0+NSzhsScSb9Kf/jhSXCOhM8ivNtzDffR9trSmYA=; b=gvyLNUMFNZPmsO6iKGVKck/lr60wIU+neZhz6cYMb6E7VPzbARITdLS4CrMOp4YERf lITDiP3NMTlfcNrQndegiEd3PirwxXwGu9C0bdkOQrjX/OXqVTIRo7LKC9Azq85Jtb3H Cse06DhP2fWTSfG3r1qjTrsbcw8Hr/EYuKmSByEBruvlEAnS8wSN3L6GP8eAo2jXF5rl oC+sczZJZPDydrDI9kb9Dv1SQObjY3J6mfEWNMhKfUZj/o26DDH132+sgYbpYJ2ewGj8 1+hvtrPVrv3YA86k0sFRC1WzVCSXdeN7NYMrWXAvUrxZ1HsX0nXSAlq0XzUzI0h0xxXB 40BA==
X-Gm-Message-State: AOAM531T2zhl0lUDQjUOrtGu0vyEzQzN6bcKUBWN9DB8mYNnkRD9/U93 02zOjJ3QTnQ86VOANB0nD3pgMhxuEy7QFA==
X-Google-Smtp-Source: ABdhPJwjdKecOe+DrXux5rnwn54AL/5UCyNk1OLgDz0LWDuYiGn3t4xdjhQ1C4nG7PgT0B9HfwdAxQ==
X-Received: by 2002:a17:902:b941:b029:e3:1628:97b7 with SMTP id h1-20020a170902b941b02900e3162897b7mr4880935pls.60.1614371808986; Fri, 26 Feb 2021 12:36:48 -0800 (PST)
Received: from mike-mac.lan ([]) by with ESMTPSA id a1sm6637607pff.156.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Feb 2021 12:36:48 -0800 (PST)
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Fri, 26 Feb 2021 12:36:45 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------0BF51E2BC8E553229D279F60"
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2021 20:36:52 -0000

On 2/26/21 12:11 PM, Christian Huitema wrote:
> 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...
I'm coming to the conclusion that federation is inherently a bad idea 
for many of the reasons that Christian cites above. What's even worse is 
that for OAUTH in particular use in native apps is ripe for "master" 
password harvesting making all of the things he cites and then it's not 
even secure.

What we should really be doing here is going back to first principles: 
this is being driven mainly from the desire to have single sign on so 
that we don't have to type passwords over and over. Passwords sent over 
the internet are the source of lots of problems but these days they are 
not inevitable. With webcrypto (simple) or webauthn (crypto dongles) we 
can enroll device and service specific asymmetric keys directly into the 
services without the need for either a password or a trusted third party 
at all. This keeps the relationship between user and service as it 
should be: 1:1.