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

Warren Parad <wparad@rhosys.ch> Mon, 01 March 2021 20:43 UTC

Return-Path: <wparad@rhosys.ch>
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 3A61E3A229C for <oauth@ietfa.amsl.com>; Mon, 1 Mar 2021 12:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
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 ZV-RBsbBwwsz for <oauth@ietfa.amsl.com>; Mon, 1 Mar 2021 12:43:37 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 2CFA33A229A for <oauth@ietf.org>; Mon, 1 Mar 2021 12:43:37 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id o9so4368489iow.6 for <oauth@ietf.org>; Mon, 01 Mar 2021 12:43:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gOk5N7v4kY47arrsk26qbBix/EqtlIyx6t3sg6jiVi8=; b=DHFbHeurT2GyVEpLyRUOXTgnYLWLFC0r24uTVhVqavBSl8Xp5vJX3CiA40rpyvu0Jo h4O9qKtNEi5eM+5p1ACEgr5/Mn/Ox9vvWVMJ6km9gsO/pX8FmjGr38X9AixRISdQO1Bi NaI+mQZCxevTAzkv26JXJR5yb/Z+EgAYH/kMZW83kZHFxrGyoN/3lUyYV5nnCB0m7VUg t5VQuxK82MXiBAF+3+JbpdtViEGOB3DWPJ9MQYWJ1IkieeiD3DhdvvyNo+NElM1IknGw VwurUcjDXbL82KNQBhEX4KC7O75yaJzpWBPgzMdI9+vFQeKmYQZ/9OofHqXaEecVjKYI nzjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gOk5N7v4kY47arrsk26qbBix/EqtlIyx6t3sg6jiVi8=; b=Mrl6fcGH7E7ycpANGz+AdNRWDN3aF8HrW1/u+C9k6A8JO3tjmp8oeHqdksdakTrHeo aOMmgMH5BScvzvZl/gq+QeNy87wDWCX7zCMXD2pgFedEWPD/lKQYyrGY13vhCPlzSZdz VWdNKsBuiCLktvQZ0ysnMi6DRTNAymO4Y0qoUrcIIbRdGQK4hFvpuICAfu8dgUXjb3hk 0afYywFxIgiPS9C26aWH6GWFGZf2Plc3fzvV6cSdmlPxN9kjM0v5X2+xoL+3a9NcGOAD JDuAuug6kH/RMi/WPzhp3S8ngQTWxp8m3DaTN74kgwtUYOmQYhJMe0Svl/yh+pDLHJ8w AKjA==
X-Gm-Message-State: AOAM531yhZACctpVbO0vvs8qkGKrFUN3olKkDWmRa8QILqTiF5Djf9d0 Xn7t+41xtDesILemhE/dBSRI/aZhjCjEDpOhsbtH
X-Google-Smtp-Source: ABdhPJyocwrl0k2bTQlBB70ecD0bPHz0n8L+N6AIdb1azbjvjVlx1cLieYa9XVpcvgaV5tPoC8z6ax9azACuhZU8yfU=
X-Received: by 2002:a02:ca13:: with SMTP id i19mr10117793jak.47.1614631414203; Mon, 01 Mar 2021 12:43:34 -0800 (PST)
MIME-Version: 1.0
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> <AFFDAA4C-5354-4578-9D89-95D52DD945E0@independentid.com> <CAMm+LwharMP-YzNwhFdWq7t-+PQuaVxMrPZUAcB39Xseh42RUA@mail.gmail.com>
In-Reply-To: <CAMm+LwharMP-YzNwhFdWq7t-+PQuaVxMrPZUAcB39Xseh42RUA@mail.gmail.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Mon, 1 Mar 2021 21:43:23 +0100
Message-ID: <CAJot-L0mpOW=xb+AuFXYOg6L1rGBDr1jBj2yOFryrkiP7698jg@mail.gmail.com>
To: Phillip Hallam-Baker <ietf@hallambaker.com>
Cc: Phil Hunt <phil.hunt@independentid.com>, oauth <oauth@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e31e4e05bc7fab82"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/r_CBZsb5q5SMApg_HalB2crBqvc>
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 <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: Mon, 01 Mar 2021 20:43:39 -0000

>
> 1) Disclosure of an identifier allows a service attack using that
> identifier.

Sure, would you be able to say more about this though, I'm not sure I'm
fully grasping the consequence here.

2) Linking separate uses of an identifier allows a profile to be
> constructed of the individual that can be used against the interest of the
> individual.

But isn't the user aware that the AS is sharing with the client the same
identifier and therefore will be tracked. Isn't it their prerogative if
they want to be and then decide whether to do that or not? There are lots
of cases I want the different clients to know how to track me and other
cases where I don't want that. It would just seem to be of poor design that
this decision is not provided as a fundamental property of the AS being
used rather than an aspect of OAuth, OIDC, or anything else, right?

Two parties that collude may always be able to figure out if an entity is
the same identity in those clients, it sounds like we are saying there is
something that could have been done to actively prevent that. But I'm not
following what that is.

I also find the US banking system of routing number + account
Id deplorable, but I don't see what that has to do with our discussion.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Mon, Mar 1, 2021 at 9:13 PM Phillip Hallam-Baker <ietf@hallambaker.com>
wrote:

> Lets take a step back. There are two separate sets of concerns related to
> 'privacy'
>
> 1) Disclosure of an identifier allows a service attack using that
> identifier.
>
> 2) Linking separate uses of an identifier allows a profile to be
> constructed of the individual that can be used against the interest of the
> individual.
>
> The reason I insist on this distinction is that privacy issues of the
> first type are a consequence of crappy protocol design. There is absolutely
> no reason why giving someone my bank details so they can send a payment TO
> me should give them the ability to withdraw money from my account. But it
> does and the banks will smugly gaslight that it just isn't possible to fix
> this elementary flaw in their information architectures. And you can guess
> where it came from if you hear the question being asked in the relevant
> Senate hearing of the form, 'Mr CEO, you say that it would be impossible to
> make this change, what size of penalty per loss are we going to have to
> impose on your bank to make it cheaper for you to fix it than to claim it
> can't be done?'
>
> It should be possible for Madonna or Lewis Hamilton to put their personal
> contact info on their Web sites without ending up being spammed to
> oblivion. It is just a question of access control.
>
>
> The second is a really difficult problem but authentication is only one
> small part of it. I can turn out a public key authentication scheme that
> allows Alice to surf the web at Bob and Carol's site without them being
> able to tell its the same person from the identifier easily enough. But all
> bets are off if Bob and Alice collude.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>