Re: [Txauth] A model with a User Consent Element

[David Pyke <[e-mail]>]

This is frequently done in healthcare, with the User Consent Element 
holding a URI to a fetchable document or OID that outlines consent 
requirements or provisions.  If the URI points to a (I)ACP, it can be 
computable (XACML or other) consent that can be ingested automagically.

On 2020-07-09 6:19 a.m., Denis wrote:
>
> 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
>
>
-- 

*David Pyke*

Manager, Strategic Consulting

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Logo <http://www.readycomputing.com/>

LinkedIn icon <https://www.linkedin.com/company/ready-computing> Twitter 
icon <https://twitter.com/ready_computing?lang=en> Youtbue icon 
<https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>

	

Office: [phone] x5001

[e-mail] <mailto:[e-mail]>_

_www.readycomputing.com <http://www.readycomputing.com/>_

150 Beekman Street, Floor 3, New York, NY 10038


The information in this e-mail communication together with any 
attachments is intended only for the person or entity to which it is 
addressed and may contain confidential and/or privileged material. If 
you are not the intended recipient of this communication, please notify 
us immediately. Any views expressed in this communication are those of 
the sender, unless otherwise specifically stated. Ready Computing does 
not represent, warrant or guarantee that the integrity of this 
communication has been maintained or the communication is free of 
errors, virus or interference.


-- 
This is not a secure transmission. The information contained in this 

transmission is highly prohibited from containing privileged and 

confidential information, including patient information protected by 

federal and state privacy laws. It is intended only for the use of the 

person(s) named above. If you are not the intended recipient, you are 

hereby notified that any review, dissemination, distribution, or 

duplication of this communication is strictly prohibited. If you are not
 
the intended recipient, please contact the sender by reply email and 

destroy all copies of the original message.