[Txauth] Support of delegation

Denis <denis.ietf@free.fr> Wed, 15 July 2020 16:16 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC693A0DF7 for <txauth@ietfa.amsl.com>; Wed, 15 Jul 2020 09:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.171
X-Spam-Level:
X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.459] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmIzeZegnizy for <txauth@ietfa.amsl.com>; Wed, 15 Jul 2020 09:16:24 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73B53A0DD8 for <txauth@ietf.org>; Wed, 15 Jul 2020 09:16:16 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d53 with ME id 3UGD2300L4FMSmm03UGENv; Wed, 15 Jul 2020 18:16:14 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 15 Jul 2020 18:16:14 +0200
X-ME-IP: 86.238.65.197
To: "txauth@ietf.org" <txauth@ietf.org>
From: Denis <denis.ietf@free.fr>
Message-ID: <7572576d-b5b4-dea5-3383-fbbf6cc10450@free.fr>
Date: Wed, 15 Jul 2020 18:16:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------59AA34BF6021139BCF28E8A1"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/BmLpn-ooTFlyn-nJHHZ9C397Lfc>
Subject: [Txauth] Support of delegation
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2020 16:16:26 -0000

*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