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

Denis <denis.ietf@free.fr> Wed, 08 July 2020 08:48 UTC

Return-Path: <denis.ietf@free.fr>
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 501A53A0CAE for <txauth@ietfa.amsl.com>; Wed, 8 Jul 2020 01:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 Zw4lpZBPOQNw for <txauth@ietfa.amsl.com>; Wed, 8 Jul 2020 01:48:06 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B473A0CB3 for <txauth@ietf.org>; Wed, 8 Jul 2020 01:48:05 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d33 with ME id 0Yo12300C4FMSmm03Yo1R9; Wed, 08 Jul 2020 10:48:04 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 08 Jul 2020 10:48:04 +0200
X-ME-IP: 86.238.65.197
To: David Waite <david@alkaline-solutions.com>
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>
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> <C4C9BFC0-4F12-489A-9EBC-420C610075CD@alkaline-solutions.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <48cbebbc-676e-66c4-0989-7f01fdcc71b6@free.fr>
Date: Wed, 8 Jul 2020 10:47:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <C4C9BFC0-4F12-489A-9EBC-420C610075CD@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="------------F49F6D6AC1DD6CB32DAA36E4"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/jeRC6acCYhAk8R4-Ltdh56NvPQE>
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 08:48:08 -0000

Hi David,

Comments are between the lines.

> On Jul 8, 2020, at 01:14, Denis <denis.ietf@free.fr 
> <mailto: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 user has the choice of its client.

This has nothing to do with "Both users and authorization servers may 
have a limited amount of trust in clients".

> 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

This is incorrect: "This might include internal details which a client 
*i**s unable to understand* including internal information in the case

> where the authorization and protected resource are part of the same 
> domain.

This is a typical case for OAuth. In GNAP, we envision multi-domain 
operations where bilateral relationships between ASs and RSs
will not be the rule any more.

> 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.

Access tokens are supposed to be protected by HTTPS between the client 
and the AS and between the client and the RS.
This solves the concern.

Denis

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