Subject: [Txauth] Support of delegation

From: Denis <[email-masked]>
Date: Wed, 15 Jul 2020 18:16:11 +0200

*Support of delegation*

The charter is mentioning a "delegation process", but at this time it is 
unclear how the delegation of an operation
originating from one Client towards two or more resource servers (RSs) 
will be supported.

Here after is a proposal to support a delegation scheme constructed 
along "Privacy by Design" principles.
A key element of this scheme is the use of a "User Consent element" 
supported by the Client.

In order to support this proposed delegation scheme, (only) a sequence 
of delegation tokens is needed.

*+--------++------------+
|User||Resource|
||\| Owner (RO) |
+--------+ \+------------+
|\|
|\|
|\|
|\|
|\|
+-----------+ (2a) +---------------++----------+
||----->| Authorization |||
|| (2b) |Server (AS)|||
|Client|<-----||||
|| (1a) +---------------+||
||------------------------>| Resource |
|User|(1b)| Server 1 |
|Consent|<------------------------|(RS1)|
|element|(3a)|| (4a)+----------+
||------------------------>||------>||
|||| (4b)||
|User|(3b)||<------||
|Consent|<------------------------||| Resource |
|element|+----------+| Server 2 |
||(5a)|(RS2)|
||------------------------------------------->||
||(5b)||
||<-------------------------------------------||
+-----------++----------+

**
*

*DELEGATION CASES*

Two cases are being considered, whether RS1 and RS2 do not belong to the 
same service (Case A)
or whether they both belong to the same service (Case B).

The sequence of flows up to (3a) are the same as those described in an 
earlier email called :
"A model with a User Consent Element (with a clean figure)"

*Case A*

Let us suppose that RS1 is unable to fulfil the operation by its own and 
that it needs to contact another RS, i.e. RS2.
RS1 contacts RS2 (4a) and indicates the operation that it is willing to 
perform on RS2 (that operation may not be
exactly the same as the original operation indicated by the client).

In return (4b), RS2 informs RS1 about which kind of attributes are 
needed by RS2 for performing the requested operation
and from which Attributes Servers they may be obtained. RS2 also 
provides a temporary API address and an handle so that
the Client can subsequently make a call directly to an API from RS2. RS1 
forwards that information to the Client.

This information is marked to indicate that it shall be handled by the 
"User Consent element" from the Client.
The presentation of that information is up to the man machine interface 
from the Client. The user can see the new requested
operation by RS1 on RS2 and which kind of attributes are requested by 
RS2, as well as from which ASs. If the user consents
to release these attributes to RS2, the Client then contacts one or more 
appropriate Authorization Servers.

Once the Client has obtained the appropriate access tokens targeted to 
RS2, it presents all of them to RS2 (5a) in a single request.
Then RS2 is able to provide a response to the Client (5b).

_Some observations_:

The user consent is captured locally by the "User Consent element" from 
the Client. There are two /user consent/ phases:
one for RS1 and another one for RS2.

RS1 will know which kind of attributes types are requested by RS2, but 
will be unable to know which attribute values from which AS(s)
will be presented by the Client to RS2.

RS1 does see the flow (5b) since this flow is going directly from RS2 to 
the Client.

The "User Consent element" from the Client may use a cache of previous 
user consents and may present earlier choices
to the user for speeding the user consent process.

The relationships between RS1 and RS2 can change at any time but no AS 
needs to be informed on these relationships.

There is no protocol between any AS and any RO, including using 
"out-of-bands" means.

*Case B*

Let us now suppose that RS1 is unable to fulfil the operation by its own 
but that it knows that the requested operation can be fulfilled
thanks to the help of another RS /from the same service/.

In such a case, when returning the "authorization table" (see an earlier 
email called "Support of FIDO and data minimization by RSs")
in the exchange (1b) for the given requested operation, RS1 will include 
both its name and the name of the service.

If the user consents to request the inclusion of the name of this 
service into the access token(s) delivered to RS1, then this allows
to save the exchanges (5a) and (5b): in such a case, all the exchanges 
with the Client will be carried out through RS1.

If the user do not consent to request the inclusion of the name of this 
service into the access token(s) delivered to RS1, then the previous
case A will apply.

Denis

---

From: Justin Richer <[email-masked]>
Date: Wed, 15 Jul 2020 13:16:24 -0400

The primary delegation in mind is the delegation of rights from the resource owner to the client (in control of the user). Redelegation of rights from one RS down to another is a design consideration, but in my opinion that’s another layer of the protocol and process beyond the primary concern.

 — Justin

> On Jul 15, 2020, at 12:16 PM, Denis <[email-masked]> wrote:
> 
> 
> 
> Support of delegation
> 
> The charter is mentioning a "delegation process", but at this time it is unclear how the delegation of an operation 
> originating from one Client towards two or more resource servers (RSs) will be supported.
> 
> Here after is a proposal to support a delegation scheme constructed along "Privacy by Design" principles.
> A key element of this scheme is the use of a "User Consent element" supported by the Client.
> 
> In order to support this proposed delegation scheme, (only) a sequence of delegation tokens is needed.
> 
> 
>     +--------+                        +------------+
>     |  User  |                        |  Resource  |
>     |        |\                       | Owner (RO) |
>     +--------+ \                      +------------+
>         |       \                           |
>         |        \                          |
>         |         \                         |
>         |          \                        |
>         |           \                       |
>   +-----------+ (2a) +---------------+  +----------+
>   |           |----->| Authorization |  |          |
>   |           | (2b) |  Server (AS)  |  |          |
>   |  Client   |<-----|               |  |          |
>   |           | (1a) +---------------+  |          |
>   |           |------------------------>| Resource |
>   |   User    |            (1b)         | Server 1 |
>   |  Consent  |<------------------------|  (RS1)   |
>   |  element  |            (3a)         |          | (4a)  +----------+
>   |           |------------------------>|          |------>|                      |
>   |           |                         |          | (4b)  |          |
>   |   User    |            (3b)         |          |<------|                      |
>   |  Consent  |<------------------------|          |       | Resource |
>   |  element  |                         +----------+       | Server 2 |
>   |           |            (5a)                            |  (RS2)   |
>   |           |------------------------------------------->|          |
>   |           |            (5b)                            |          |
>   |           |<-------------------------------------------|          |
>   +-----------+                                            +----------+
> 
> 
> 
> DELEGATION CASES
> 
> Two cases are being considered, whether RS1 and RS2 do not belong to the same service (Case A) 
> The sequence of flows up to (3a) are the same as those described in an earlier email called :
> Case A
> Let us suppose that RS1 is unable to fulfil the operation by its own and that it needs to contact another RS, i.e. RS2. 
> RS1 contacts RS2 (4a) and indicates the operation that it is willing to perform on RS2 (that operation may not be 
> In return (4b), RS2 informs RS1 about which kind of attributes are needed by RS2 for performing the requested operation 
> and from which Attributes Servers they may be obtained. RS2 also provides a temporary API address and an handle so that
> the Client can subsequently make a call directly to an API from RS2. RS1 forwards that information to the Client.
> 
> This information is marked to indicate that it shall be handled by the "User Consent element" from the Client. 
> The presentation of that information is up to the man machine interface from the Client. The user can see the new requested 
> operation by RS1 on RS2 and which kind of attributes are requested by RS2, as well as from which ASs. If the user consents 
> to release these attributes to RS2, the Client then contacts one or more appropriate Authorization Servers. 
> 
> Once the Client has obtained the appropriate access tokens targeted to RS2, it presents all of them to RS2 (5a) in a single request. 
> Some observations:
> The user consent is captured locally by the "User Consent element" from the Client. There are two user consent phases: 
> RS1 will know which kind of attributes types are requested by RS2, but will be unable to know which attribute values from which AS(s) 
> RS1 does see the flow (5b) since this flow is going directly from RS2 to the Client.
> 
> The "User Consent element" from the Client may use a cache of previous user consents and may present earlier choices 
> The relationships between RS1 and RS2 can change at any time but no AS needs to be informed on these relationships.
> 
> There is no protocol between any AS and any RO, including using "out-of-bands" means. 
> 
> 
> Case B
> 
> Let us now suppose that RS1 is unable to fulfil the operation by its own but that it knows that the requested operation can be fulfilled 
> thanks to the help of another RS from the same service.
> 
> In such a case, when returning the "authorization table" (see an earlier email called "Support of FIDO and data minimization by RSs") 
> in the exchange (1b) for the given requested operation, RS1 will include both its name and the name of the service. 
> 
> If the user consents to request the inclusion of the name of this service into the access token(s) delivered to RS1, then this allows 
> to save the exchanges (5a) and (5b): in such a case, all the exchanges with the Client will be carried out through RS1.
> 
> If the user do not consent to request the inclusion of the name of this service into the access token(s) delivered to RS1, then the previous 
> case A will apply.
> 
> Denis
> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Dick Hardt <[email-masked]>
Date: Wed, 15 Jul 2020 10:19:16 -0700

+1

On Wed, Jul 15, 2020 at 10:17 AM Justin Richer <[email-masked]> wrote:

> The primary delegation in mind is the delegation of rights from the
> resource owner to the client (in control of the user). Redelegation of
> rights from one RS down to another is a design consideration, but in my
> opinion that’s another layer of the protocol and process beyond the primary
> concern.
>
>  — Justin
>
> *    +--------+                        +------------+     |  User
> |                        |  Resource  |     |
> |\                       | Owner (RO) |     +--------+ \
>           +------------+         |       \                           |
>         |        \                          |         |
> \                         |         |          \                        |
>         |           \                       |   +-----------+ (2a)
> +---------------+  +----------+   |           |----->| Authorization |
> |          |   |           | (2b) |  Server (AS)  |  |          |   |
> Client   |<-----|               |  |          |   |           | (1a)
> +---------------+  |          |   |           |------------------------>|
> Resource |   |   User    |            (1b)         | Server 1 |   |
> Consent  |<------------------------|  (RS1)   |   |  element  |
> (3a)         |          | (4a)  +----------+   |
> |------------------------>|          |------>|          |   |
> |                         |          | (4b)  |          |   |   User
> |            (3b)         |          |<------|          |   |  Consent
> |<------------------------|          |       | Resource |   |  element
> |                         +----------+       | Server 2 |   |
> |            (5a)                            |  (RS2)   |   |
> |------------------------------------------->|          |   |
> |            (5b)                            |          |   |
> |<-------------------------------------------|          |
> +-----------+                                            +----------+ *
>
> *DELEGATION CASES*
>
> In return (4b), RS2 informs RS1 about which kind of attributes are needed
> by RS2 for performing the requested operation
> and from which Attributes Servers they may be obtained. RS2 also provides
> a temporary API address and an handle so that
> operation by RS1 on RS2 and which kind of attributes are requested by RS2,
> as well as from which ASs. If the user consents
> *Some observations*:
> the Client. There are two *user consent* phases:
> thanks to the help of another RS *from the same service*.
>
> If the user consents to request the inclusion of the name of this service
> into the access token(s) delivered to RS1, then this allows