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

[Denis <[e-mail]>]

Hi Justin,

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

Token opacity is considered as a dogma in OAuth 2.0. More explanations 
why access tokens should not be opaque in GNAP.

Token introspection mandates a dialogue from the RS to the AS which 
allows the AS to know which RS
got a given access token. So token introspection allows the AS to trace 
the client. This should be avoided.
Using NON-OPAQUE access tokens solves the issue both for the RSs and for 
the clients. This means that
access tokens used for GNAP shall include a version number or a format 
identifier.

Applying a "security by design" approach leads to specific design 
requirements. The key question is whether
this BoF prefers a "Privacy by design" approach or /implicitly /a "Big 
Brother by design" approach.

Denis

>
>  — Justin
>
>> On Jul 6, 2020, at 3:17 PM, Denis <[e-mail] 
>> <mailto:[e-mail]>> 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 <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>     **eThis is a new thread: a proposal for a RS authorization
>>>     algorithmand 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 ANDand ORconditions.
>>>
>>>     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 U2For 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 OROperation 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
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>> -- 
>> Txauth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth
>