Re: [Txauth] Support of delegation

[Dick Hardt <[e-mail]>]

+1

On Wed, Jul 15, 2020 at 10:17 AM Justin Richer <[e-mail]> 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
>
> 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
>
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>