[Txauth] A model with a User Consent Element

[Denis <[e-mail]>]

This is a new thread.

Preamble: This model is quite different from the XAuth model.
In particular, a RO has no relationship with any AS and a Client does 
not need to be associated with any AS prior to any access to a RS.

A key point of this model is that the user's consent is handled locally 
by the Client and hence no AS nor RS is handling a man machine interface
for the user consent. This allows to support locally the user consent 
for multiple ASs while keeping all ASs ignorant about the choices of the 
user
made for accessing a particular RS.
*

**+--------++------------+
|User||Resource|
||| Owner (RO) |
+--------++------------+
|\|
|\|
|\|
|\|
+-----------++---------------++------------+
||---->| Authorization |||
|| (2) |Server (AS)|||
||<----||||
|Client|+---------------+||
||-------------------------->|Resource|
|User|(1)|Server|
|Consent|<--------------------------|(RS)|
|element|||
||-------------------------->||------>
||(3)||(4)
||<--------------------------||<------
+-----------++------------+
*
The flow of operations is as follows:

The Client (which may have been previously authenticated using FIDO) 
contacts the RS and after some dialogue with the RS selects an operation
that it wants to perform on the RS (1a). Note that it may also indicate 
directly the operation that it wants to perform on the RS without any 
prior dialogue.
In return (1b), the RS informs the Client about which attributes are 
needed by the RS for performing the requested operation and from which 
Attributes Servers
they may be obtained.

This information is specifically 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 
supported by the "User Consent element" from the Client.

The user can see which attributes are requested by the RS for performing 
the requested operation and, if it consents, the Client contacts one or 
more
appropriate Authorization Servers (2a). The user consent is hence 
captured locally by the Client (i.e. there is no dialogue with any AS 
nor any RS).

When the Client got the access tokens from these authorization servers 
(2b), it sends all of them in a single request to the RS (3a).

End of the story for a simple access


Start of a subsequent story for a delegation case

Let us now suppose that the RS is unable to fulfil the request by its 
own and that it needs to contact another RS. RS1 contacts RS2 (4a) and 
indicates the operation
that it wants to perform on RS2 (that operation may not be the same as 
the original operation). In return (4b), RS2 informs RS1 about which 
attributes are needed
by RS2 for performing the requested operation and from which Attributes 
Servers they may be obtained. 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 which attributes are 
requested by RS2 for performing the new requested operation and, if it 
consents, the Client contacts one or more
appropriate Authorization Servers. The user consent is hence captured 
locally by the "User Consent element" from the Client. (i.e. there is no 
dialogue with any AS, nor RS1, nor RS2).

When the Client got the access token(s) from the authorization 
server(s), it sends all of them in a single request to RS1. RS1 then 
forwards the additional access token(s) to RS2.


Some observations:

The user nor the Client are linked with any particular AS. A user may 
use today an AS of the Bank of America and may change tomorrow to the 
Bank of Missouri.
As soon as he will be registered with the Bank of Missouri, he will be 
able to get access tokens from the AS of the Bank of Missouri. The AS of 
Bank of America
has not been able to know where its access tokens have been used. This 
will be the same for AS of the Bank of Missouri. There is no need for 
any direct dialogue
between any AS and any RS at the time a client is making an access. 
There is no need for any RO to contact any AS.

This model has been constructed following a "Privacy by Design" approach.

Denis