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

Phil Hunt <phil.hunt@independentid.com> Mon, 01 March 2021 18:11 UTC

Return-Path: <phil.hunt@independentid.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 5B53F3A209F for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 10:11:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.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 uwgitXcrfWMM for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 10:11:13 -0800 (PST)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 A862C3A20A0 for <ietf@ietf.org>; Mon, 1 Mar 2021 10:11:13 -0800 (PST)
Received: by mail-pl1-x632.google.com with SMTP id z7so10408900plk.7 for <ietf@ietf.org>; Mon, 01 Mar 2021 10:11:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CM1gPhoxdsEbB/x+ARvkIz1XEFC0T3rTZfji+mbKnuU=; b=03S/jzxi2x1uvvSiR7cIa1THC4UoI0eD5JWS8E2/NM0E01XiU0uaTOpUPX4Zz9kIwP E2w90HFmHBSwvh57op53buelfSFsyriDhLWzZ0hnqEp3zzAdapvFkF94wNqRccv/f3/B IeH4sab2MDPIZtTjBTJbrdIIMAy7Vn58Cf+PVbbBQywnhhPiqrPqrmcIC4olSJyuAdNr wLiZ2TlduG8NCqWdROYub2Cb35n0JWqz+ykWN1MrETwYp9VQ4pNvQPqjKXaXX7Uli9Uj qCU3gBx+oNP9Und/JVqG8jZOO7VaPsCMJPmAL6owclDnVw7RoIApMdFfOWYT0s0xeA0E XmYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CM1gPhoxdsEbB/x+ARvkIz1XEFC0T3rTZfji+mbKnuU=; b=XWmI2wdPYZ88/zZH4LH2kgvXT/jpxn+ZGtMHbOGpZ45NLSqd7ckUIm/mgN60Nrln6F BjkuCus03b6u+m7jrWKH8XV9AuyJaCZ7/hVYoEBMgtoqJT0YIdI5yu21SY2w5K0O7s6n TVrTi4uuk0qQMlq3OUhQRnPZASSHzaN1RTlEfllhqbopqOzTKyXmGfQ1W7F2vUvM30w0 uLLqbVkqDDHWC09w3OT3p4OyCHBkf4ygiUtkLOYLRkfWh9PZRflgMuJP3Gaw/dZ9YdHj vkdDqRPAeuris440iUyMGDQ0l3BUZf2sq8vBoDZw4KhfRnPF7eTsAWpVOoQ9LecwIqJi TvSQ==
X-Gm-Message-State: AOAM531YtbguBBeZMY9SkE1a6lqqtbgNS3Mtspn6pBMIQ2l8bPuJWpLW fozKRxxCqadMMsf2TqPgszjxcA==
X-Google-Smtp-Source: ABdhPJxcnm18M1tnxyOStaUksdSZUyjyamKMY/CbNDfAlZVTImv6HvkayGHhbwEBhRhMrcSszZHP4A==
X-Received: by 2002:a17:90a:bb0c:: with SMTP id u12mr142570pjr.234.1614622270025; Mon, 01 Mar 2021 10:11:10 -0800 (PST)
Received: from node-1w7jr9qrfoxxa15gkpn9u8p31.ipv6.telus.net (node-1w7jr9qrfoxxa15gkpn9u8p31.ipv6.telus.net. [2001:569:7a71:1d00:a4e0:5ca2:b439:82fd]) by smtp.gmail.com with ESMTPSA id q64sm5219678pfb.6.2021.03.01.10.11.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Mar 2021 10:11:09 -0800 (PST)
From: Phil Hunt <phil.hunt@independentid.com>
Message-Id: <AFFDAA4C-5354-4578-9D89-95D52DD945E0@independentid.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A45971C-CF88-485A-A897-5C465E8307AC"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Subject: Re: [OAUTH-WG] Assessing the negative effects of proposed standards
Date: Mon, 1 Mar 2021 10:11:08 -0800
In-Reply-To: <305345e0-6901-30a4-8010-e0b174b12c2f@manicode.com>
Cc: Vittorio Bertola <vittorio.bertola@open-xchange.com>, IETF-Discussion Discussion <ietf@ietf.org>, oauth@ietf.org
To: Jim Manico <jim@manicode.com>
References: <CWXP265MB0566C4B21C45E760B1BFED7FC29A9@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM> <EF14E7AC-CA19-44EE-9EC6-D21A81ECA756@manicode.com> <1016085528.105908.1614610785506@appsuite-gw1.open-xchange.com> <305345e0-6901-30a4-8010-e0b174b12c2f@manicode.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/448hf0b2MrZqPB797OLrrsQXAjo>
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 18:11:16 -0000

I think the IETF should look at three issues:

1.  HTTP Re-direct flows in support of workflows (eg MFA sign-on flows) - HTTP redirect is the single most complex part of OAuth2 and drove a lot of the OAuth2 Threat Model and the subsequent drafts such as PKCE.  Right now, OAuth takes the blame because of its extensive recommendations and corrections (e.g. PKCE) to handle requirements not unique to OAuth2.

2.  Authentication of client applications - enabling the ability to identify a returning client or provide an asserted identity still needs to be solved.  Token Binding seemed like the solution, but that’s stalled. Now what?  OAuth Dynamic registration is an example of how complex things can get without being able to identify a returning entity positively.  Can we make this as easy as TLS has been for authenticating servers?

3.  YETA - OAuth has spawned a number of parallel efforts (IoT, OIDC, ... and now GNAP).  Are these new profiles making generational improvements to replace OAuth2 or are they just adding more options and complexity to the mix? I point to ongoing developer confusion on the purpose and differences between OIDC and OAuth2. It is very clear to me, but why not to developers at large?  Could it be they don’t want to care?  Developers are still asking “why can’t I just use basic auth”?   There is a debate that specialization (by eliminating options) leads to simplicity and focus. But when specialization drives  YETA, it is really just more complexity.  Again, this suggests options 1 and 2 need to be looked at before OAuth2 and its flavors can improve.   Is it time to work on bringing all of these together on top of a new HTTP workflow framework?

Cheers,

Phil Hunt
@independentid
phil.hunt@independentid.com




> On Mar 1, 2021, at 8:32 AM, Jim Manico <jim@manicode.com> wrote:
> 
> Vittorio,
> 
> I feel you are conflating OIDC with OAuth2. In delegation workflows, the AS/RS can be any company and the clients are approved registered clients. I use OAuth2 for many of my own consumer needs and there is an even distribution of use among many services. OAuth2 protects me. I no longer have to hand out my twitter credentials just because my conference website wants limited access to my twitter account. I can now give my conference website limited delagated access to my twitter account and cancel that relationship any time. For years I was forced to give up my banking credentials to services like Mint and that is no longer the case due to the OAuth2 financial extension (FAPI).
> 
> While OIDC is certainly centralizing identity to a few providers, a real problem, OAuth2 when used for delegation purposes does not have that same inherent risk.
> 
> Respectfully,
> 
> - Jim Manico
> 
> 
> 
> On 3/1/21 9:59 AM, Vittorio Bertola wrote:
>> 
>>> Il 01/03/2021 15:13 Jim Manico <jim@manicode.com> <mailto:jim@manicode.com> ha scritto:
>>> 
>>> 
>>> How does OAuth harm privacy?
>> I think you are analyzing the matter at a different level. 
>> 
>> If you start from a situation in which everyone is managing their own online identity and credentials, and end up in a situation in which a set of very few big companies (essentially Google, Apple and Facebook) are supplying and managing everyone's online credentials and logins, then [the deployment of] OAuth[-based public identity systems] is harming privacy. 
>> 
>> Centralization is an inherent privacy risk. If you securely and privately deliver your personal information to parties that can monetize, track and aggregate it at scale, then you are losing privacy. 
>> -- 
>> 
>> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
>> vittorio.bertola@open-xchange.com <mailto:vittorio.bertola@open-xchange.com> 
>> Office @ Via Treviso 12, 10144 Torino, Italy
> -- 
> Jim Manico
> Manicode Security
> https://www.manicode.com <https://www.manicode.com/>_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth