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

[Tom Jones <[e-mail]>]

David: Kantara has been working on standardizing the health care model you
describe. Where clients are known, this model works. I would suggest that
the model requires federation of some sort to assess the parties to a
transaction, and so is fundamentally different from the more typical oauth
model where the client must be considered to be an adversary.

I doubt that a common protocol can be enabled for both models. But I am
open to hearing that both models can share message formats. That would be a
good start.

thx ..Tom (mobile)

On Thu, Jul 9, 2020, 8:25 AM David Pyke <david.pyke=
[e-mail]> wrote:

> 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
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> [image: Logo] <http://www.readycomputing.com/>
>
> [image: LinkedIn icon] <https://www.linkedin.com/company/ready-computing> [image:
> Twitter icon] <https://twitter.com/ready_computing?lang=en> [image:
> Youtbue icon] <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>
>
> Office: [phone] x5001
>
> * [e-mail] <[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. --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>