Re: [Txauth] Support of FIDO and data minimization by RSs

David Waite <david@alkaline-solutions.com> Wed, 08 July 2020 07:35 UTC

Return-Path: <david@alkaline-solutions.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FD03A0C05; Wed, 8 Jul 2020 00:35:04 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.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 LDBHngmdP2d3; Wed, 8 Jul 2020 00:35:02 -0700 (PDT)
Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DB83A0C06; Wed, 8 Jul 2020 00:35:02 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 34ECA38486F; Wed, 8 Jul 2020 07:35:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1594193701; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9X1DGIQ06ox3vyszEmsXkTftGdx89u4GHRyX8Rx+zBA=; b=rj3BZ0xYz7c3oTldR8wHZUorc8VK9y1YMjV5WXX7Tqk9FUdwxs70z87ptHX4daAtU+hrzU DrovXGjhMG3v8pJxpVvkoGya4CjZk/CKUysfkx6rA0I05vVSlbOWkZL3xmG2HKzjwYumjT lwUey7Np7fTxgNHIujDeAUAXfQvsZ60=
From: David Waite <david@alkaline-solutions.com>
Message-Id: <C4C9BFC0-4F12-489A-9EBC-420C610075CD@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_900D127E-FE32-4A09-93FB-08A569E8952B"
Mime-Version: 1.0
Date: Wed, 8 Jul 2020 01:34:58 -0600
In-Reply-To: <c9fd6fc8-12cb-998b-d001-00eb9abcf866@free.fr>
Cc: Dick Hardt <dick.hardt@gmail.com>, "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, The IESG <iesg@ietf.org>
To: Denis <denis.ietf@free.fr>
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr> <CAD9ie-uHo1hNs6Y767NHyNj1TxmfzcbDk-6iZxBT0QWtqpe+Fg@mail.gmail.com> <c91a9ecf-0f8c-a62d-aa4f-66e15cc6fba2@free.fr> <46705E7E-D657-4CF1-80DA-0ADDFD6D8B41@mit.edu> <85b03911-d1c6-127f-2480-bfab4b94ffe2@free.fr> <CAD9ie-tnj1ufCmiZ2MHHKPZ9kM7YQzoNMo4YErcu_coUX_35+g@mail.gmail.com> <c9fd6fc8-12cb-998b-d001-00eb9abcf866@free.fr>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1594193701; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9X1DGIQ06ox3vyszEmsXkTftGdx89u4GHRyX8Rx+zBA=; b=ileXKOM1VYlmw7jDKDWoJiccM99kny0IKZxg/iepJijm3eun6oyK0UZeA3l8CsIr6qISov 246GSZRIqBpTkuEcx6Zz3KX33sdMsg6bqUoAKDDNEtqd/2YK0kByjKeJ6F/LDrUe/2Dw7a r0x1bnxaD8rKLXT9ju+twcV+RoXjufA=
ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1594193701; a=rsa-sha256; cv=none; b=ZuxDsoWXfy4f/69qQWyDnUHIOoQirQB9LOKys0RRB8R70GGeeGd1EQkbCsxu87Pna848nK za0/vnbY9Squpvz+Atf8cy8pWoy85iYXc+LEICT7k48gWhmZRcZzeMsX9bHARadm5X4Zb6 oUJU38/hkEAHgtuuQNEjGVruS1SCu+E=
ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/1mxQY8shibqh95oWGtiJ1J97Bnk>
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 07:35:04 -0000


> On Jul 8, 2020, at 01:14, Denis <denis.ietf@free.fr> wrote:
> 
> Hi Dick,
> 
>> Denis: you seem to keep implying that other architectures don't preserve privacy. A couple counterpoints:
>> 
>> Token opacity helps privacy in another dimension -- the client does not see the information about the user.
> The client is not an adversary to the user.
> 
Both users and authorization servers may have a limited amount of trust in clients, which is a reason we have scopes to limit authorization and why we have consent to limit exposure of user data in the form of claims within the OpenID Connect extension.

The access token is a message about the client from the authorization server to the protected resource, about the authorization. This might include internal details which a client should not know, including internal information in the case where the authorization and protected resource are part of the same domain.

>> Many OAuth developments have self contained tokens. There is no token introspection call. 
>> This, coupled with opaque tokens, is more privacy preserving than the client being able to peek in a token.
> When an access token contains personal information about a user, that user has the right to see that personal information.
> 
However that does not mean that data has to be exposed to all third party clients without user consent. The sensitive data may also not be personal data in which case the user does not have a right to see it, even under request. Finally, tokens may be issued to entities without equivalent rights, such as hardware devices.


-DW