Re: [Txauth] Support of delegation

[Justin Richer <[e-mail]>]

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