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

Jim Manico <jim@manicode.com> Mon, 01 March 2021 14:13 UTC

Return-Path: <jim@manicode.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E18B3A1CD6 for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 06:13:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.com
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 ClcIZPy5TURo for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 06:13:21 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB37B3A1CD5 for <ietf@ietf.org>; Mon, 1 Mar 2021 06:13:20 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id h8so16571080qkk.6 for <ietf@ietf.org>; Mon, 01 Mar 2021 06:13:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; 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; d=1e100.net; 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=ouSBOOh/GFKJPzLp1nOKAOc/gTqR/Fi6WEv6n8wv+MMHGKMjAwPH45EQ3caQX559ZF OH/SaHnt6AyhAkteifV5wpWnEsh8HSvYoKVOOPfTBtopIgD57FOB7BdZs6JtC4FnNlSQ qBhlpi6QcIy4I1rBj2F384lfQyi/Lr3SEAjLbFZiQwIngDLZDQ4+cnPMNXuFSXfd9Vci IQky1NRn+cSquFHih/j6Z8R7z2Xh7ZrXTPnAvZQjD+blVTwOsL/Gg25o0t/rdV+zwSBN 9TZ/DFVKFA6s0z3BQI38dv7yBnLV/dEH8NbyUxBCEVq2F7DNiZQWhFHAFGuQRO3jEM1s fOiA==
X-Gm-Message-State: AOAM532B9H6dMlclxZcdGk5dlRhNhKt6xgROnFnHqjs4NwrWfh6Y0b6+ lnNqP5jQpgrwi7AHmSXFpMoNPA==
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 [192.168.86.30] (c-71-62-187-187.hsd1.va.comcast.net. [71.62.187.187]) by smtp.gmail.com with ESMTPSA id k126sm137497qkb.4.2021.03.01.06.13.18 (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 <jim@manicode.com>
Mime-Version: 1.0 (1.0)
Subject: Re: [OAUTH-WG] Assessing the negative effects of proposed standards
Date: Mon, 1 Mar 2021 09:13:17 -0500
Message-Id: <EF14E7AC-CA19-44EE-9EC6-D21A81ECA756@manicode.com>
References: <CWXP265MB0566C4B21C45E760B1BFED7FC29A9@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM>
Cc: Vittorio Bertola <vittorio.bertola@open-xchange.com>, Aaron Parecki <aaron@parecki.com>, IETF-Discussion Discussion <ietf@ietf.org>, oauth@ietf.org
In-Reply-To: <CWXP265MB0566C4B21C45E760B1BFED7FC29A9@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM>
To: Andrew Campling <andrew.campling@419.consulting>
X-Mailer: iPhone Mail (18D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4xwf7LX76m7IQAIxZ_-xH_QMRFg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 14:13:23 -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
@Manicode


> On Mar 1, 2021, at 6:10 AM, Andrew Campling <andrew.campling@419.consulting> wrote:
> 
> 
> On 01/03/2021 10:44 Vittorio Bertola <vittorio.bertola@open-xchange.com> wrote:
>  
> > Il 26/02/2021 17:32 Aaron Parecki <aaron@parecki.com> ha scritto:
>  
>  
> >> Dynamic client registration does exist in OAuth: https://tools.ietf.org/html/rfc7591
>  
> >> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth