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

From: Denis <[email-masked]>
Date: Mon, 6 Jul 2020 14:39:34 +0200

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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 6 Jul 2020 09:21:28 -0700

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 <[email-masked]> wrote:

> This is a new thread: a proposal for a RS authorization algorithm and a
> 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).
> 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.
>
> -          FIDO U2F or
> -          one or more attributes from one or more ASs.
>
> mathematical expression which is formed using some combination of AND and
> OR conditions.
>
> *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
> 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.
>
> *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
>
> 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
> 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
> 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:
> 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.
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Denis <[email-masked]>
Date: Mon, 6 Jul 2020 21:17:37 +0200

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

> On Mon, Jul 6, 2020 at 5:39 AM Denis <[email-masked] 
> <mailto:[email-masked]>> 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
>     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.
>
>     mathematical expression which is formed using some combination of
>     ANDand ORconditions.
>
>     /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:
>     1°For the "authentication" operation : either FIDO U2For a
>     used in that mathematical expression. The user may then decide
>     whether the set of attributes types which are indicated for a
>     given AS
>     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
>     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:
>     For AS 9, the client shall use the set 3 of attributes types
>     indicated in the Condition 4.
>
>     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
>     [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Mon, 6 Jul 2020 15:54:54 -0400

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 <[email-masked]> 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.
> 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 
> 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)
>> Would you provide some background on what you are trying to solve with this? I'm guessing it is privacy related. 
>> 
>> On Mon, Jul 6, 2020 at 5:39 AM Denis <[email-masked] <mailto:[email-masked]>> 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 
>> 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.
>> 
>> 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.
>> 
>> 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;
>> Operation
>> Mathematical expression
>> Condition 1 OR Condition 2
>> 
>> Condition 3 AND Condition 4
>> 
>> Conditions table:
>> 
>> Condition 1
>> 
>> FIDO U2F 1.2
>> 
>> -
>> 
>> -
>> 
>> Condition 2
>> 
>> AS 1
>> 
>> 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 
>> 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: 
>> 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
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> -- 
> Txauth mailing list
> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Mon, 6 Jul 2020 13:26:47 -0700

Hi Denis

Thanks for writing up the scenarios, that helps me ensure we are talking
about the same thing. They are similar to scenarios that have been
discussed by the digeriti for what seems forever!

To elaborate on my other email, I do think GNAP should support
implementations that need "privacy by design". I don't think that is
applicable to all the use cases, and would overly restrict the use cases
that many participants want to solve with GNAP.

I think the resulting GNAP document should have a Privacy Considerations
section and/or a separate Privacy document, to assist implementers in
dealing with potential privacy issues.

Perhaps if we had a privacy related milestone you would feel your concerns
will be addressed by the WG?

On Mon, Jul 6, 2020 at 12:17 PM Denis <[email-masked]> wrote:

> *Note*: Since it is close to the end of the day in my time zone (and
> 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:
>
> 2 - prevent every AS to know which RSs are going to be accessed or which
> kind of operation the client will be doing.
> 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
> 5 - the rules associated with the RS Authorization algorithm are making
> these rules only available at the time the client indicates
> 6 - access tokens are NOT OPAQUE to the clients so that every client can
> make sure that their content reflects what has been requested.
>
>    - citizenship information and
>    - prior graduations.
>
> 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.
> Such scenario which follows some privacy principles cannot be constructed "*after
> the design"* (it will not happen by magic or by accident)
>> 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:
>>

---

From: Denis <[email-masked]>
Date: Tue, 7 Jul 2020 14:26:18 +0200

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 <[email-masked] 
>>     2 - prevent every AS to know which RSs are going to be accessed
>>     or which kind of operation the client will be doing.
>>     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 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:
>>
>> The student can interrupt the preliminary registration procedure at 
>> any time and continue it at any time later on.
>>
>>     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
>>> Would you provide some background on what you are trying to solve 
>>> with this? I'm guessing it is privacy related.
>>>
>>>     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.
>>>
>>>     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.
>>>
>>>     The presence of the /optional/ scope identifier allows to
>>>     provide a backward compatibility with ASs from the OAuth 2.0.
>>>     world:
>>>     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:

---

From: Dick Hardt <[email-masked]>
Date: Tue, 7 Jul 2020 16:20:43 -0700

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.

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.

ᐧ

On Tue, Jul 7, 2020 at 5:26 AM Denis <[email-masked]> wrote:

> 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
> this BoF prefers a "Privacy by design" approach or *implicitly *a "Big

---

From: Denis <[email-masked]>
Date: Wed, 8 Jul 2020 09:14:43 +0200

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.

> 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 <[email-masked] 
>>     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.
>
>     this BoF prefers a "Privacy by design" approach or /implicitly /a
>     "Big Brother by design" approach.
>
>     Denis
>
>>
>>      — Justin
>>
>>>     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:
>>>
>>>         2 - prevent every AS to know which RSs are going to be
>>>         accessed or which kind of operation the client will be doing.
>>>         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).
>>>
>>>         5 - the rules associated with the RS Authorization algorithm
>>>         are making these rules only available at the time the client
>>>         indicates
>>>         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 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:
>>>
>>>     The student can interrupt the preliminary registration procedure
>>>     at any time and continue it at any time later on.
>>>
>>>         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
>>>         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.
>>>
>>>     constructed "/after the design"/ (it will not happen by magic or
>>>     by accident)
>>>>     Would you provide some background on what you are trying to
>>>>     solve with this? I'm guessing it is privacy related.
>>>>
>>>>         In order to support the privacy principle of "data
>>>>         minimization" by RSs, only the attributes that are strictly
>>>>         necessary to perform
>>>>         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.
>>>>
>>>>         In the second case, an access will be granted by a RS based
>>>>         on an mathematical expression which is formed using some
>>>>         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
>>>>         Each RS internally constructs an /authorization table/ with
>>>>         the following content:
>>>>
>>>>         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
>>>>         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
>>>>         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:
>>>>         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

---

From: David Waite <[email-masked]>
Date: Wed, 8 Jul 2020 01:34:58 -0600

> On Jul 8, 2020, at 01:14, Denis <[email-masked]> 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.
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 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 where the authorization and protected resource are part of the same domain.

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

---

From: Denis <[email-masked]>
Date: Wed, 8 Jul 2020 10:47:58 +0200

Hi David,

Comments are between the lines.

> On Jul 8, 2020, at 01:14, Denis <[email-masked] 
> 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.

>>> This, coupled with opaque tokens, is more privacy preserving than 
>>> the client being able to peek in a token.
>>
> 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
>