Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF

Jim Manico <jim@manicode.com> Wed, 24 February 2021 06:26 UTC

Return-Path: <jim@manicode.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C103A09A5 for <oauth@ietfa.amsl.com>; Tue, 23 Feb 2021 22:26:37 -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 mtoy-9kJHYyH for <oauth@ietfa.amsl.com>; Tue, 23 Feb 2021 22:26:35 -0800 (PST)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 BD0623A098D for <oauth@ietf.org>; Tue, 23 Feb 2021 22:26:35 -0800 (PST)
Received: by mail-qv1-xf2d.google.com with SMTP id s3so552583qvn.7 for <oauth@ietf.org>; Tue, 23 Feb 2021 22:26:35 -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=sFo4SbvJUmC/7TuwinRlABAIH8ZwrdZmI5xsc0nvZl4=; b=aZKC8g70VYDoObuppEX+yBa+Ffr7Qnvc+AeR/QnFw18mwLpfTum6otvxQ51AA9MPvD 3RC+wtE+c7ZsZrpchqRXtYIHHoBeA8YXi8iJ9Ze6v/aMQMIbaiYDJWxNjylvfIxp5Olc M5BUW7LWLeKTgvv4YYswcKHbxIG4bZCs7vBJDwLx7k+KyH2y+Z7Owr5Gw/xG0c6f6Ahh ++t9b9NvzOcI0oN64R1g/M8yVQifxtADihw4hmyOiYqPMXHcJRSGUOW7mtkOXgY8Gy/l miKNPWUFPGYmNdXmEUsDF3WK8m52cbhCmsnUnbtF8yiRfhJexac8EmAqOs/CDtC+PqpK 7FdQ==
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=sFo4SbvJUmC/7TuwinRlABAIH8ZwrdZmI5xsc0nvZl4=; b=F5FwJUgfC+OfuOp+DdEOJHkIhDsWvKj37xn/f+YOV6NwqFBDVG7fBoeKv+Ij5J1dBZ bTQkLHoxBfYYgvo2j0TSdLngjzwqudNeAtisDThAZahOYmDquL9nxYlL4dAKQaalgFzL F5gMXfd4OjQXUy9n18UPBYn6dN/XKkDKYQWGIPJ7EgK3HeA5TFvnCChnfz30Ysal5y/i ziOuQpTI86nYQNIcAi9Rppljn1tceSjFNZ3NmmgqDE2nvx8Y9lD7zFnizN2rdJhcCHH0 TkrgMnFdLqSXSrv2hoKm8QgfO0pPsq2adWvxHKcEHUOAB5s0VGiqnBqYbnK6mCXVCg1q PLEQ==
X-Gm-Message-State: AOAM533kDxVewMSYyFskRiC/1/sposG33Fl57whIOtLjPmm67VRdKNhe G3cPr1ud6wOvvgLbAejMW9rqgd1ME4ZFXA==
X-Google-Smtp-Source: ABdhPJwNzNoernNjGqHYPgZ8TeaPy3JHdDRdsLoZ8nKXaC8a04YmMUxwIN2KiqebY426geF/pWOyDg==
X-Received: by 2002:a0c:fc4b:: with SMTP id w11mr16552821qvp.41.1614147994689; Tue, 23 Feb 2021 22:26:34 -0800 (PST)
Received: from [10.62.107.212] (mobile-166-172-63-24.mycingular.net. [166.172.63.24]) by smtp.gmail.com with ESMTPSA id i6sm719245qti.30.2021.02.23.22.26.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Feb 2021 22:26:33 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-D143320B-BF0C-47DD-9687-03FA1725EE4A"
Content-Transfer-Encoding: 7bit
From: Jim Manico <jim@manicode.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 24 Feb 2021 01:26:32 -0500
Message-Id: <A8128346-B557-472F-B94F-8F624F955FCE@manicode.com>
References: <CAMm+LwgbK3HYDjSHnTN3f6hWSQCQrEjHLNn6z0JpfY7hdxaQpg@mail.gmail.com>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, ietf@ietf.org, oauth@ietf.org
In-Reply-To: <CAMm+LwgbK3HYDjSHnTN3f6hWSQCQrEjHLNn6z0JpfY7hdxaQpg@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
X-Mailer: iPhone Mail (18D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7AgK8SoX1PCefXu7-jTjYjK2zh0>
Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2021 06:26:38 -0000

I think it’s important to point out that OAuth is not an authentication protocol. It’s for delegation. OAuth is one of the most mis-used protocols on the modern web. If you really want to support end users, a good place to start is to make it clear to developers what OAuth is really for so secure solutions are built as opposed to the dumpster fire that OAuth solutions have become today.

Regards,
--
Jim Manico
@Manicode
Secure Coding Education

> On Feb 24, 2021, at 12:48 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> 
> 
> I am worried by the advice 'use OAUTH' but for a very different reason.
> 
> OAUTH and SAML are both attempts to provide a secure authentication scheme that works within the very particular and very peculiar environment of Web browsers. They are schemes that necessarily involve techniques that are rightly regarded as alchemy if not outright witchcraft.
> 
> That is fine, that is more than fine if you are developing an authentication scheme for use within Web browsers (or if you are developing whatever SAML and OAUTH are these days, neither was originally billed as authentication). But it is completely inappropriate to ever suggest let alone demand that anyone use a technology whose primary design constraint is to work around the voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application where none of those legacy issues apply.
> 
> One of the big problems of IETF is that a lot of people don't think about how to get their scheme deployed and when they do, their plan is to tie it to some other group as a boat anchor. Back when we were doing DKIM and SPF we had to tell certain DNS folk that the fact that almost no DNS Registrars offered customers the ability to specify new RRTypes was their problem and was going to remain their problem no matter how loudly they tried to complain that it should become our problem. 
> 
> In the case of OAUTH, there is another problem in that OAUTH really isn't a very open protocol from the standpoint of the user. I can use my Google or my Facebook or my Twitter accounts to log in via OAUTH at a large number of sites. But if I want to use any other OAUTH provider I am completely out of luck. Or at least I will be until this becomes one of the multifaceted complaints in the anti-trust hearings coming soon to a capitol hill near you. And yes, that is a consequence of how the protocol has been deployed, but that probably not going to get people very far on capitol hill.
> 
> 
> The Internet is for everyone. The Internet is for end users.
> 
> I am really not that interested in who makes the ingredients except to the extent that it determines what sort of cake emerges. One of the unexpected side effects of Web 2.0 has been that it has greatly centralized power in the hands of a tiny number of individuals. Individuals who are at best accountable to shareholders, but in the case of some of them, a separate share class ensures that they are accountable to nobody. In neither case are the people with power accountable to end users because they are not even customers, they are the product.
> 
> What I am interested in is the extent to which Internet technologies are Technologies of Freedom. The question we need to ask ourselves is 'does this technology increase end user autonomy or increase their reliance on third parties'.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth