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

Justin Richer <jricher@mit.edu> Mon, 06 July 2020 19:55 UTC

Return-Path: <jricher@mit.edu>
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 0E4D93A09DE; Mon, 6 Jul 2020 12:55:03 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 03mp3T56oVIk; Mon, 6 Jul 2020 12:55:00 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C423A09EF; Mon, 6 Jul 2020 12:54:59 -0700 (PDT)
Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 066Js7qV018503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 15:54:54 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <46705E7E-D657-4CF1-80DA-0ADDFD6D8B41@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8ED051D4-D59D-4B38-912B-955E4BFD932E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 6 Jul 2020 15:54:54 -0400
In-Reply-To: <c91a9ecf-0f8c-a62d-aa4f-66e15cc6fba2@free.fr>
Cc: Dick Hardt <dick.hardt@gmail.com>, "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" <txauth@ietf.org>, 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>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/__HkZxsdHUbW6-_xg_EmP4wKe68>
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: Mon, 06 Jul 2020 19:55:03 -0000

I think removing the opacity of access tokens to clients is going to be a non-starter for most of this community. 

 — Justin

> On Jul 6, 2020, at 3:17 PM, Denis <denis.ietf@free.fr> wrote:
> 
> Hi Dick,
> 
> Congratulations ! You made a good guess (but the guess was easy): my approach is indeed privacy related.
> 
> Note: Since it is close to the end of the day in my time zone (and since it is the last day for comments to the charter), 
> I copy both the IESG and Roman so that they can know that GNAP should also consider a bridge with FIDO.
> 
> I have several goals:
> 1 - make a bridge with FIDO U2F (I will illustrate this with a specific scenario).
> 
> 2 - prevent every AS to know which RSs are going to be accessed or which kind of operation the client will be doing.
>     This is to prevent an AS to act as "Big Brother".
> 
> 3 - apply both "privacy by default" and "data minimization" (when the user authenticates it may authenticate using FIDO or 
>      by presenting one or more access tokens. Then after, the necessary attributes that are necessary to perform a given operation 
>     are only requested and released at the time they are indeed needed to perform the given operation (i.e. they are not released 
>     when the user logs on).
> 
> 4 - the proposed RS Authorization algorithm allows a great flexibility, in particular it supports FIDO and different attributes 
>      from different ASs may be requested by the RS.
> 
> 5 - the rules associated with the RS Authorization algorithm are making these rules only available at the time the client indicates 
>      which operation it is willing to perform (i.e. by default, they are not public).
> 
> 6 - access tokens are NOT OPAQUE to the clients so that every client can make sure that their content reflects what has been requested.
> A simple scenario to illustrate
> 
> A student wants to apply for a new university. He connects to the RS of the University. He first creates an account using FIDO.
> He then selects the button "Preliminary information for applying to the university". He is asked to enter two categories of information:
> citizenship information and
> prior graduations.
> The student can interrupt the preliminary registration procedure at any time and continue it at any time later on.
> 
> When the student is finished, it selects the button "Application to the university".
> The university RS "reads" the citizen ship of the student and let know to the student whether a paper form 
> and/or an electronic form of the identity of the student may be provided. Let us assume the later case and that 
> the student is a citizen from France. Then the university RS indicates which French banks or other French organisations 
> are trusted to provide an access token. The client checks whether this list fits one of the AS with which it has a relationship.
> 
> The university RS "reads" the prior graduations of the student and then let know to the student whether a paper form 
> and/or an electronic form of the last graduation of the student may be provided. Let us assume the later case and 
> that the student is from Yale University. Then the university indicates the address of the AS from Yale University.
> If the student is indeed from Yale University, he should be able to provide the requested access token.
> Such scenario which follows some privacy principles cannot be constructed "after the design" (it will not happen by magic or by accident)
> This is why the approach is called "privacy by design".
> 
> Denis
> 
>> Hi Denis
>> 
>> Would you provide some background on what you are trying to solve with this? I'm guessing it is privacy related. 
>> 
>> Perhaps a use case would help make it more concrete?
>> 
>> /Dick
>> 
>> 
>> On Mon, Jul 6, 2020 at 5:39 AM Denis <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> wrote:
>> eThis is a new thread: a proposal for a RS authorization algorithm and a way to support FIDO by RSs
>> 
>> In order to support the privacy principle of "data minimization" by RSs, only the attributes that are strictly necessary to perform 
>> an operation requested by a client should be requested by the RS.
>> 
>> When a client wants to authenticate, it will usually be informed by the RS on how to do it (see more details about two exceptions at the end of this email). 
>> Which conditions are needed to perform other operations will only be disclosed to authenticated users at the time they are willing to perform an operation.
>> 
>> Two categories of operations will be considered: authentication operations and other operations.
>> 
>> For the "authentication" operation, two cases will be supported:
>> 
>> -          FIDO U2F or
>> -          one or more attributes from one or more ASs.
>> In the second case, an access will be granted by a RS based on an mathematical expression which is formed using some combination of AND and OR conditions.
>> 
>> Examples of combinations:
>> 
>> Condition 1 AND Condition 2
>> Condition 1 OR Condition 2
>> (Condition 1 AND Condition 2) OR Condition 3
>> (Condition 1 OR Condition 2) AND Condition 3 
>> 
>> The following notation is being used for a Condition :
>> 
>> Condition x = { AS identifier + set of attributes types + optional scope identifier } 
>> 
>> The presence of the optional scope identifier allows to provide a backward compatibility with ASs from the OAuth 2.0. world: 
>> the optional scope identifier is only present when a bilateral relationship has been established between a RS and an AS prior 
>> to any access (and will continue to be maintained) using "out-of-bands" means. 
>> 
>> Each RS internally constructs an authorization table with the following content:
>> 
>> 1°  For the "authentication" operation : either FIDO U2F or a mathematical expression using conditions;
>> 2°  For any other operation : a mathematical expression using conditions.
>> An example is used to explain the concepts.
>> 
>> "Operation(s)/ Mathematical expression" pairs managed by the RO of a RS. 
>> 
>> Operation
>> 
>> Mathematical expression
>> 
>> Authentication
>> 
>> Condition 1 OR Condition 2
>> 
>> Operation A OR Operation Z
>> 
>> Condition 3 AND Condition 4
>> 
>> Conditions table:
>> 
>> Condition 1
>> 
>> FIDO U2F 1.2
>> 
>> -
>> 
>> -
>> 
>> Condition 2
>> 
>> AS 1
>> 
>> set 1 of attributes types
>> 
>>  
>> Condition 3
>> 
>> AS 4
>> 
>> set 2 of attributes types
>> 
>> scope identifier : 21
>> 
>> Condition 4
>> 
>> AS 9
>> 
>> set 3 of attributes types
>> 
>> -
>> 
>> Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions 
>> used in that mathematical expression. The user may then decide whether the set of attributes types which are indicated for a given AS 
>> are appropriate to him or not and then select that AS if it has a relationship with it.
>> 
>> In this example, one mathematical expression for the combination of conditions using AND and OR operators is "Condition 3 OR Condition 4", 
>> which means that some types of attributes from AS 4 AND some other types of attributes from AS 9 are both needed by RSx to perform on RSx 
>> either the Operation A or the Operation Z.
>> 
>> In this example, RS 1 and AS 4 have established a bilateral relationship (and have agreed to define and use scope identifiers) 
>> whereas RS 1 and AS 9 have not established any bilateral relationship prior to the exchange. 
>> 
>> The user makes up his mind whether the attributes requested by AS 1 and AS 9 are reasonable and if so, requests two access tokens: 
>> one to AS 4 and another one to AS 9.
>> 
>> For AS 4, the client shall use the scope identifier with the value 21.
>> For AS 9, the client shall use the set 3 of attributes types indicated in the Condition 4.
>> 
>> In order to save one exchange, a RS could publicly publish how its clients can authenticate. 
>> However,  it is also possible to consider no guidance at all: in such a case, using "out-of-bands" means, the clients should know how to authenticate.
>> 
>> Denis 
>> 
>> -- 
>> Txauth mailing list
>> Txauth@ietf.org <mailto:Txauth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> -- 
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth