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

[Dick Hardt <[e-mail]>]

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]> wrote:

> This 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>