Re: [OAUTH-WG] Assessing the negative effects of proposed standards

Jim Manico <> Mon, 01 March 2021 14:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09E423A1CD5 for <>; Mon, 1 Mar 2021 06:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hw51iKqoO1WI for <>; Mon, 1 Mar 2021 06:13:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB1CE3A1CCD for <>; Mon, 1 Mar 2021 06:13:20 -0800 (PST)
Received: by with SMTP id d20so15564927qkc.2 for <>; Mon, 01 Mar 2021 06:13:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=yscKFTqYbjRqSY1fOA+SX5bwnKO0HkTk9zMkMY6CiJQ=; b=Iz8yKJ2IFJOUkWbp3RE5DFJ17IQaJQKm5kAJMejSU8y+devydD1xbGoOpGMkn3/Uxa txS0JxrZv9qVNcO+/dPeolcHcw6t7M8M+tY8v/TDwSxAhvw+MGEfK08SaoYJP4TU88TN 4/JWK7uilvrKDL/f5U5xLczSFp1D9V/dwntkWAUNmUdin2vPdKe/6g6n3DqLKcBp26kr UPGLFmiC8GrjCnb1jLuf+hzTT1AAJNy/NFF+ROL30nlqtMIs/3Qg1OQuVHDio821oRpI h5FnxRFZ/LluHGwpNkraXZNB3DX8TW9HdqTMSg1ccev4lfLfjI9xnBGC/kCJV3TEjYoF +0iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=yscKFTqYbjRqSY1fOA+SX5bwnKO0HkTk9zMkMY6CiJQ=; b=p96gncEVStDWpRIGkoIg3WJDY5eR6+crGNxDH6ajRIISczOEFO48lZauQbAwNaZLtQ mbxl5PV5Zr6hvOEYcedlmsG2URhO4XJ8huEo27/KhWGEdkjhZITT+NLOFpoW/XwkM8d/ ybCBSOeUvUB0wSYWQBOkHejnchMi00DoAm/JOP2LfbA4D4rKjxYeic4QzYtFSLVyg03c iy6rEOIVyRDT43UrZMLd6J0dMYICe51h+QmcalO0sMH6MeKBl5AKDrboeJQov3jq1Ooh hwrISkwT6pGSAejrQQZOytZbaKQoSYgJsZms9OHZuEg9+PQyXjBvW2DyeqvQ+RQvo/Fh mgyA==
X-Gm-Message-State: AOAM531rn1Hh8m/ndDp3iDJ6HKJBKnv9h5yAAyLoJ0NviXUy46ACC6MY ZAVAeRhdgRksU1j1V8htny5pEn0MbszZrw==
X-Google-Smtp-Source: ABdhPJxEzc/lFIe1SSpmgVLWlYcn80k2ghf9mhwsBNOjDvGsIZQi0YKi3WwQzqPQHVOHIJmlrzCtCA==
X-Received: by 2002:a37:604:: with SMTP id 4mr13761493qkg.346.1614607998837; Mon, 01 Mar 2021 06:13:18 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id k126sm137497qkb.4.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Mar 2021 06:13:18 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-C0EBC6B1-584B-4279-8E48-141299BF44DD
Content-Transfer-Encoding: 7bit
From: Jim Manico <>
Mime-Version: 1.0 (1.0)
Date: Mon, 1 Mar 2021 09:13:17 -0500
Message-Id: <>
References: <CWXP265MB0566C4B21C45E760B1BFED7FC29A9@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM>
Cc: Vittorio Bertola <>, Aaron Parecki <>, IETF-Discussion Discussion <>,
In-Reply-To: <CWXP265MB0566C4B21C45E760B1BFED7FC29A9@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM>
To: Andrew Campling <>
X-Mailer: iPhone Mail (18D52)
Archived-At: <>
Subject: Re: [OAUTH-WG] Assessing the negative effects of proposed standards
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: Mon, 01 Mar 2021 14:13:24 -0000

How does OAuth harm privacy? This critical delegation use case is user driven, protects leaking user passwords to third party services, limits access to user account features and allows the user to cancel this relationship at any time?

OAuth2 provides more security and privacy than the previous solutions pre-OAuth which was to hand your Twitter credentials (or similar) to a third party service (OAuth clients) exposing your entire account, permanently, to OAuth clients.

OAuth2 radically improves upon this needed web functionality. I don’t see how moving from handing your creds over to a third party to OAuth2 workflows, harms either privacy or security. It improves upon them both.

Also, OAuth2 is hard. It’s a complicated protocol. Delegation is tough. But luckily most developers just need a basic understanding and proper utilization of third party libraries for this need and the ecosystem is is getting much better. For example, PKCE is now integrated into most OAuth libraries.

I advise this working group to take a class or two (as a group, together) from the experts here such as Dr. De Ryck and others so we are all on the same page about what modern OAuth2 solutions really look like and what the OAuth2 framework/protocol actually is.

I am not being combative or trying to hurt anyone when I say that I feel many of the commenters here do not understand the details of OAuth2 and what it’s for.

Jim Manico

> On Mar 1, 2021, at 6:10 AM, Andrew Campling <> wrote:
> On 01/03/2021 10:44 Vittorio Bertola <> wrote:
> > Il 26/02/2021 17:32 Aaron Parecki <> ha scritto:
> >> Dynamic client registration does exist in OAuth:
> >> 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.
> > This is indeed a matter of product design. I am active in an OIDC-based open identity project where the specs say that providers MUST accept dynamic client registration, without a pre-determined client secret. This is the only way to create a federation that can work on an Internet scale, with relying parties accepting identities managed by providers unknown to them. Then, of course, this also creates lots of opportunities for abuse: you end up in an email-like scenario in which you need ways to ascertain trust in unknown parties and decide whether you want to accept interoperating with them and believe the information they provide, which in turn depends a lot on your specific use case. But we think that that is preferrable to the centralization that is inherent in the original registration model.
> I wonder whether proposed standards should be assessed for their negative properties, eg whether they are likely to exacerbate centralisation, much like security aspects are reviewed.  It may be that a given proposal might still go forward as the trade-offs are deemed worthwhile, however, they would at least be understood and, ideally, documented.  At present there seems to be an exorable drift towards centralisation which, in my view, has a detrimental impact on both resilience and privacy.  Such developments may satisfy the needs of their proponents but are unlikely to be in the long-term interests of end-users (RFC 8890) and, therefore, it would be helpful if this trend wasn’t made worse by the introduction of new standards.
> Andrew Campling
> _______________________________________________
> OAuth mailing list