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

Aaron Parecki <> Fri, 26 February 2021 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E03AD3A0CAE for <>; Fri, 26 Feb 2021 13:49:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uTbPRAkfQ8G3 for <>; Fri, 26 Feb 2021 13:49:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58C173A0C9F for <>; Fri, 26 Feb 2021 13:49:43 -0800 (PST)
Received: by with SMTP id 81so7540469iou.11 for <>; Fri, 26 Feb 2021 13:49:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CHENElNI5uFUfxiROWSb7tFUiH0J3GnBfAV37tiA43g=; b=caaCxMqa5oOBDJK87y6emH22wmP9TWrWzcIfhbEIu5zY+uTVtiLNUqTgbDfaNVJ/Hw A3yTHtrkcy0yyhQaxfrkE8pzYwv6J2YS1fQoJchEuz56YCJ9Vcz57MQQa5TSvCSzf3yJ /LsI5JqKewnBsaIHN2P7NVPqJGXVjYPHhJzgwp3c9dw3CLK9sbaRF1yfkE+KsiGEx37i e0tIXdOqqhMm+YBt/e6BwgFgaB9v1bct35HSejRMDqdTGTdiLIHovaUwg2Wm+nMw1vIF IPRxd9nU9fNlKjh8SKJyQaWwW8c/ZbvRyJR2XbQJzfBzzUZ8XYp+XiGiYVfWFUfvfNx3 N7tQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CHENElNI5uFUfxiROWSb7tFUiH0J3GnBfAV37tiA43g=; b=TbiiwR4MNd/1VDcjmoSctn0lKk4iTbdzfOthHSbwWo/Y99+v10E2zPR2YPsMilESE+ ZMgSYw8Ng2k6owM5ZVEkXMhmCtHiqmhEc4Fmxr18sMSLZ3A6e9f9IeBNXMTPrHRhetyD pWUb+8Q/1vB6aA+pSjwxdnI80Gr+1HBkc9AuIMjM7VfcGmAMfHy0BfnsU/3mec6td2MO zMVCnzAvel9qpIyCfNIjp0EGpO0kgOzwauFsBE88VSL6FSe43cyXo5h54Rjm4InToPdi 3yHg1AVk807z+A1x5GHJ0V6/1e3s/gW0+9ija26gy6lJWTLcdnUXkQzE0BXDen31NE6H DP3Q==
X-Gm-Message-State: AOAM5337VOExitxT/vQA+5nkMbBV2anpQ0mYAmaxKglqlVXrVh+XBbVJ qSLSZdvOmwEL/BPGz/d0BiKxbNx9Tw4e/w==
X-Google-Smtp-Source: ABdhPJyILmNXKdwqJ/CVEWhnR5o+EBOcdC89IiaGGo499wBvbawlBntBZqVSbPjszhFNAIEOp4yQlQ==
X-Received: by 2002:a5d:81d1:: with SMTP id t17mr4513071iol.208.1614376182070; Fri, 26 Feb 2021 13:49:42 -0800 (PST)
Received: from ( []) by with ESMTPSA id q2sm5834860ioh.20.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Feb 2021 13:49:41 -0800 (PST)
Received: by with SMTP id c10so9311699ilo.8; Fri, 26 Feb 2021 13:49:41 -0800 (PST)
X-Received: by 2002:a05:6e02:1c2a:: with SMTP id m10mr4069474ilh.17.1614376181245; Fri, 26 Feb 2021 13:49:41 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Aaron Parecki <>
Date: Fri, 26 Feb 2021 13:49:30 -0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
To: David Waite <>
Cc: Warren Parad <>, Bron Gondwana <>, Phillip Hallam-Baker <>, IETF-Discussion Discussion <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000d12f6d05bc443ed4"
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 21:49:45 -0000

> Do you disagree that this gives them control over which things talk to
their servers?

Yes -- with a public client, I can impersonate a "real" app and it's
basically non-detectable by the AS. For a theoretical example, if I wanted
to use the Instagram API but they restrict which apps can upload photos to
only their own mobile apps, I can find the client ID of their own app, then
do an OAuth flow using their own client ID, and without a client secret it
looks the same as their own client. I'm unlikely to be able to get
arbitrary users to authorize my app because of limits and checks on the
redirect URI, but I can certainly do it myself for my own account. This is
the sort of false sense of security provided by the client registration
step I'm talking about.

I'd love to solve the app identity problem too, but that's only possible
with cooperation from the mobile OSs.


On Fri, Feb 26, 2021 at 1:36 PM David Waite <>

> > On Feb 26, 2021, at 9:32 AM, Aaron Parecki <> wrote:
> > The point is that basically nobody uses it because they don't want to
> allow arbitrary client registration at their ASs. That's likely due to a
> combination of pre-registration being the default model in OAuth for so
> long (the Dynamic Client Registration draft was published several years
> after OAuth 2.0), as well as how large corporations have decided to run
> their ASs where they want to have (what feels like) more control over the
> things talking to their servers.
> Do you disagree that this gives them control over which things talk to
> their servers?
> FWIW my personal mental model here is pretty simple:
> With users, there are services you provide anonymously and services you
> provide only to registered/authenticated/trusted parties for various
> reasons. Once you are delegating user access, you still have many of the
> same reasons to provide access to anonymous or
> registered/authenticated/trusted delegates.
> Dynamic registration arriving later and requiring additional complexity
> has unfortunately encouraged registration in use cases where anonymous
> clients might have been acceptable, but shifting the timelines or
> complexity balance would not  have changed business needs for
> authentication and trust of delegates. Omitting registration would have
> caused businesses to use other protocols that met their needs.
> If AS’s are only getting what feels like proper control for their business
> needs, we should attempt to give them the actual control they require.
> -DW