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

[Denis <[e-mail]>]

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.

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

Denis

>
> ᐧ
>
> On Tue, Jul 7, 2020 at 5:26 AM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>>
>