From nobody Mon Mar 1 10:11:18 2021 Return-Path: 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 10FF53A20A1 for ; 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 Xmp3iqG5qqVK for ; Mon, 1 Mar 2021 10:11:13 -0800 (PST) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 968023A209F for ; Mon, 1 Mar 2021 10:11:13 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id s23so85208pji.1 for ; 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=LMGtZoGCv5o8OaIRI1xlG/uayyAGnh5nworiiKHBePLcntZ2TlgZld85XyOAXA7zCc WaO8KiBZp8h8bpkb0IA5sXfXdSU2E4Y+j08bWB+4sv5HnDClal61q1ypXTVWTyWEVtZf wsN252qDroI9PWwwbnwro6gJuIBmjq9N9bi3X19+je0TDpAV6sEPepRGe30Fyy+ZRLTN 2wPFpVX/v8FJkP8ZcSJZXqOQHvKT5RtKrm3kIODAa9TuPhN1IpTR3ogMIkyAJo9enrkL s7ewrhzIlJWRKJ2VihhLYqhxzBNRPCnzpzwzLwovZLbgcengzDmRQBhy+elfE4QSwOHJ 1jqA== X-Gm-Message-State: AOAM530cdY6SlqnxZT9HDE0ZTBtZ3g+IU5EWZSiGlPd87Dg5zQYtvR37 lZsrd/KkRS9R5PVTdK7fCP/0ROGwRcRSMt3h 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 Message-Id: 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\)) Date: Mon, 1 Mar 2021 10:11:08 -0800 In-Reply-To: <305345e0-6901-30a4-8010-e0b174b12c2f@manicode.com> Cc: Vittorio Bertola , IETF-Discussion Discussion , oauth@ietf.org To: Jim Manico References: <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: Subject: Re: [OAUTH-WG] Assessing the negative effects of proposed standards X-BeenThere: oauth@ietf.org 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 18:11:16 -0000 --Apple-Mail=_9A45971C-CF88-485A-A897-5C465E8307AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99s = 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=E2=80=99t want = to care? Developers are still asking =E2=80=9Cwhy can=E2=80=99t I just = use basic auth=E2=80=9D? 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 wrote: >=20 > Vittorio, >=20 > 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). >=20 > 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. >=20 > Respectfully, >=20 > - Jim Manico >=20 >=20 >=20 > On 3/1/21 9:59 AM, Vittorio Bertola wrote: >>=20 >>> Il 01/03/2021 15:13 Jim Manico = ha scritto: >>>=20 >>>=20 >>> How does OAuth harm privacy? >> I think you are analyzing the matter at a different level.=20 >>=20 >> 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.=20 >>=20 >> 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.=20= >> --=20 >>=20 >> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange >> vittorio.bertola@open-xchange.com = =20 >> Office @ Via Treviso 12, 10144 Torino, Italy > --=20 > Jim Manico > Manicode Security > https://www.manicode.com = _______________________________________________= > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9A45971C-CF88-485A-A897-5C465E8307AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99s = 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=E2=80=99t want to care?  Developers are = still asking =E2=80=9Cwhy can=E2=80=99t I just use basic auth=E2=80=9D? =   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




On Mar 1, 2021, at 8:32 AM, Jim Manico <jim@manicode.com> = wrote:

=20 =20

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> 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=20=

Office @ Via Treviso 12, 10144 Torino, Italy
--=20
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_9A45971C-CF88-485A-A897-5C465E8307AC--