Re: [Txauth] A model with a User Consent Element (with a clean figure)

Denis <denis.ietf@free.fr> Mon, 13 July 2020 19:22 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 982F13A17D0 for <txauth@ietfa.amsl.com>; Mon, 13 Jul 2020 12:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.628
X-Spam-Level:
X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 T4ZYShdMKdqL for <txauth@ietfa.amsl.com>; Mon, 13 Jul 2020 12:22:20 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932333A17C2 for <txauth@ietf.org>; Mon, 13 Jul 2020 12:22:19 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d74 with ME id 2jNF2300J4FMSmm03jNGtF; Mon, 13 Jul 2020 21:22:17 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 13 Jul 2020 21:22:17 +0200
X-ME-IP: 86.238.65.197
To: Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt@gmail.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
References: <f7cdae74-ac8d-2069-db53-d4f8623c43de@free.fr> <ead88d07-83a6-07f7-4d78-0ee35f599d98@free.fr> <CAD9ie-tbzzUUUFKj3Vmr+Q0GkUbhy8C6nU05=TJaCWJoOzz7pg@mail.gmail.com> <325bc015-1547-c56c-c1fe-67a97165785d@free.fr> <CAD9ie-s57vKSNW-jiUfEVFiYR9FeBaVMsvYyCD_JoQ-GPMnOcw@mail.gmail.com> <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr> <CAD9ie-sQ3GAtbNm0t7ZDG-__zA5c6uaxWzXcDsp6q02J6R=3=Q@mail.gmail.com> <83DB69E6-F0ED-41A0-A4DA-B7AE4AB89579@mit.edu>
From: Denis <denis.ietf@free.fr>
Message-ID: <34dfca59-47f7-63e4-b25f-01648b0bd14b@free.fr>
Date: Mon, 13 Jul 2020 21:22: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
In-Reply-To: <83DB69E6-F0ED-41A0-A4DA-B7AE4AB89579@mit.edu>
Content-Type: multipart/alternative; boundary="------------651143750B8A37CDCFB98DC4"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/n6SKliuFT6MFqtHWywshbkjMTrE>
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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: Mon, 13 Jul 2020 19:22:25 -0000

Hi Justin,

You have perfectly understood the differences. The location where the 
user consent is gathered /i//n a uniform way/ using to the information 
released by the RS
is a fundamental element of the design.

> If I’m understanding Denis’s proposal, he’s saying that that “prior 
> step” is the lynchpin of the whole model, since interaction between 
> the client and the RS (and the user and the RS) is key to Denis’s 
> privacy model. Additionally, what happens *at* each step is different. 
> Consent is gathered at the client, not the GS in this diagram, for 
> example. The GS simply mints a token as specified by the client and 
> the RS.
>
> It’s for these reasons that, as long as I’ve been understanding 
> correctly, I’ve been saying that Denis’s model as proposed is pretty 
> different.

Indeed.

Denis

> But what I think isn’t that different is the different steps if you’re 
> willing to look at the boundaries around the boxes differently. For 
> example, what OAuth would call “the AS” might end up being a few 
> different boxes in GNAP that do different things. I had started down 
> that route with XYZ’s design allowing the interaction to be managed 
> separately.
>
> I think that the disconnect we’re seeing here might be caused by 
> vocabulary mismatches. If we aren’t meaning the same thing when we say 
> the same terms, it’s easy to get things mixed up with each other. 
> Since GNAP is just barely forming its vocabulary out of the legacy of 
> OAuth and kin, we have a chance to maybe draw the lines better and see 
> if that’s how we can get things to fit.
>
>  — Justin
>
>> On Jul 13, 2020, at 2:02 PM, Dick Hardt <dick.hardt@gmail.com 
>> <mailto:dick.hardt@gmail.com>> wrote:
>>
>>
>> I'm going to just address the first part of your response so that we 
>> can get clarity on that before diving into your later comments.
>>
>> The calls between your proposal and XAuth are not inverted, your 
>> proposal has a prior step. Step 1 in XAuth maps to Step 2 in your 
>> proposal, and Step 2 in XAuth is Step 3 in your proposal..
>>
>> Below are 2 diagrams showing the same steps, the first keeping the 
>> existing step labels for XAuth, the latter renaming the steps to 
>> correspond to your proposal. This looks pretty similar to your 
>> diagram. What am I missing?
>>
>> /Dick
>>
>> DIAGRAM 1 (steps start at 0)
>>         +--------+                           +------------+
>>         |  User  |                           |  Resource  |
>>         |        |                           | Owner (RO) |
>>         +--------+                           +------------+
>>             |      \                       /      |
>>             |       \                     /       |
>>             |        \                   /        |
>>             |         \                 /         |
>>         +--------+     +---------------+     +------------+
>>         | Client |---->|     Grant     |     |  Resource  |
>>         |        | (1) |  Server (GS)  | _ _ |   Server   |
>>         |        |<----|               |     |    (RS)    |
>>         |        |     +---------------+     |            |
>>         |        |-------------------------->|            |
>>         |        |           (2)             |            |
>>         |        |<--------------------------|            |
>>         |        |-------------------------->|            |
>>         |        |           (0)             |            |
>>         |        |<--------------------------|            |
>>         +--------+                           +------------+
>> DIAGRAM 2 (steps start at 1)
>>         +--------+                           +------------+
>>         |  User  |                           |  Resource  |
>>         |        |                           | Owner (RO) |
>>         +--------+                           +------------+
>>             |      \                       /      |
>>             |       \                     /       |
>>             |        \                   /        |
>>             |         \                 /         |
>>         +--------+     +---------------+     +------------+
>>         | Client |---->|     Grant     |     |  Resource  |
>>         |        | (2) |  Server (GS)  | _ _ |   Server   |
>>         |        |<----|               |     |    (RS)    |
>>         |        |     +---------------+     |            |
>>         |        |-------------------------->|            |
>>         |        |           (3)             |            |
>>         |        |<--------------------------|            |
>>         |        |-------------------------->|            |
>>         |        |           (1)             |            |
>>         |        |<--------------------------|            |
>>         +--------+                           +------------+
>> ᐧ
>>
>> On Mon, Jul 13, 2020 at 7:08 AM Denis <denis.ietf@free.fr 
>> <mailto:denis.ietf@free.fr>> wrote:
>>
>>     Hello Dick,
>>
>>     You wrote: "This looks pretty similar to your protocol drawing".
>>
>>     No. There is a fundamental difference with the sequencing of the
>>     flow of the exchanges where the (1) and (2) flows are inverted.
>>
>>     In your figure:
>>
>>         The Client makes calls to the GS (1)
>>         The Client makes calls to the RS (2)
>>
>>     while in my figure:
>>
>>         The Client makes calls to the RS (1)
>>         The Client makes calls to the AS (2)
>>
>>     In your figure, the first flow is with the GS, whereas in my
>>     figure the first flow is with the RS and there is a good reason
>>     for that:
>>     the client first contacts the RS to know what the RS expects. The
>>     client indicates in its first exchange to the RS whether it wants
>>     to authenticate
>>     or to perform another operation.  In the case of an
>>     authentication operation, the RS may respond to the client that
>>     is supports FIDO U2F
>>     or that it is willing the client to present some attribute(s)
>>     from one or more AS.
>>
>>     Then after the client has to figure out whether the user is using
>>     FIDO and if not whether the user has an account with one of the AS.
>>     In the later case, if there is a match then the client,/*after
>>     having received the user consent*/, may contact the appropriate
>>     AS to ask
>>     for some attribute(s).
>>
>>     The same fundamental difference applies with
>>     draft-richer-transactional-authz-06 (XYZ) where the first
>>     exchange is done with the AS:
>>     "The RC creates a transaction request and sends it to the AS".
>>
>>     This answers also in details to one of your comments:
>>
>>         What looks to be missing from your proposal is:
>>         A) The Client making a call to the RS to discover what it
>>         needs from a GS, and which GS to ask, prior to (1).
>>
>>     This is not missing since this is the foundation of the
>>     architecture. The discovery mechanism at the RS has been described
>>     in details in an earlier email with the following title: "Support
>>     of FIDO and data minimization by RSs".
>>
>>     The main figures are copied below (using ASCII):**
>>
>>     *+-----------------------------------+---------------------------------+
>>     +Operation+Mathematical expression+
>>     +-----------------------------------+---------------------------------+
>>     + Authentication+ Condition 1 OR Condition 2+
>>     +-----------------------------------+---------------------------------+
>>     + Operation A OR Operation Z+ Condition 3 AND Condition 4+
>>     +-----------------------------------+---------------------------------+
>>
>>     **Conditions table: **
>>
>>     +-------------+--------------+-----------------------------+----------+
>>     + Condition 1 + FIDO U2F 1.2 +++
>>     +-------------+--------------+-----------------------------+----------+
>>     + Condition 2 + AS 1+ set 1 of a attributes types + +
>>     +-------------+--------------+-----------------------------+----------+
>>     + Condition 3 + AS 2+ set 2 of a attributes types + Scope 21 +
>>      
>>     +-------------+--------------+-----------------------------+----------+
>>     + Condition 4 + AS 9+ set 3 of a attributes types-+ +
>>     +-------------+--------------+-----------------------------+----------+
>>     *
>>     According to the operation announced by the Client, the RS
>>     returns to the Client both the mathematical expression
>>     associated with that operation and the conditions included in
>>     that mathematical expression. The Client may then
>>     present that information to the user in order to obtain the user
>>     consent in a standardized manner.
>>
>>     Another comment you made is:
>>
>>         What looks to be missing from your proposal is:
>>         B) A mechanism for the Client to prove to the GS that it has
>>         gathered consent from the User.
>>
>>     The user consent should not be captured *by the GS*, since the GS
>>     would be in a position to apply a different consent decision
>>     without letting it know to the user (or to the client).
>>
>>     The user consent must be captured *by the Client* and the Client
>>     must be able to verify that this consent has indeed been followed
>>     by the AS.
>>
>>     The authorization data managed at the RS by the RO is used by the
>>     Client to query the consent of the user in a standardized manner.
>>     When, later on, the access token is returned to the Client by the
>>     AS, the Client (not the user) using that authorization data as
>>     well as
>>     the decision of the user is able to verify that the requested
>>     attributes (and no more) are indeed present into the access token.
>>
>>     This is why access tokens may *not* be considered to be opaque to
>>     the Clients.
>>
>>     In my earlier email copied below, six major differences with
>>     XAuth from 1) to 6) are listed.
>>
>>     Denis
>>
>>>     From
>>>     https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
>>>
>>>
>>>
>>>           1.1
>>>           <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1>.
>>>           Parties
>>>
>>>
>>>
>>>         The parties and their relationships to each other:
>>>             +--------+                           +------------+
>>>             |  User  |                           |  Resource  |
>>>             |        |                           | Owner (RO) |
>>>             +--------+                           +------------+
>>>                 |      \                       /      |
>>>                 |       \                     /       |
>>>                 |        \                   /        |
>>>                 |         \                 /         |
>>>             +--------+     +---------------+     +------------+
>>>             | Client |---->|     Grant     |     |  Resource  |
>>>             |        | (1) |  Server (GS)  | _ _ |   Server   |
>>>             |        |<----|               |     |    (RS)    |
>>>             |        |     +---------------+     |            |
>>>             |        |-------------------------->|            |
>>>             |        |           (2)             |            |
>>>             |        |<--------------------------|            |
>>>             +--------+                           +------------+
>>>
>>>
>>>     The lines without arrows represent relationships.
>>>     The User trusts the Client
>>>     The User trusts the GS
>>>     The RO trusts the GS to issue access tokens for the RS
>>>     The RS trusts the tokens issued by the RS
>>>     The RO controls the RS
>>>
>>>     The Client makes calls to the GS (1)
>>>     The Client makes calls to the RS (2)
>>>
>>>     This looks pretty similar to your protocol drawing.
>>>
>>>     What looks to be missing from your proposal is:
>>>
>>>     A) The Client making a call to the RS to discover what it needs
>>>     from a GS, and which GS to ask, prior to (1).
>>>     B) A mechanism for the Client to prove to the GS that it has
>>>     gathered consent from the User.
>>>
>>>     The current protocol does not require the GS to interact with
>>>     either the User, the RO, or the RS -- which looks to me to meet
>>>     your privacy goals.
>>>
>>>     ᐧ
>>>
>>>     On Fri, Jul 10, 2020 at 6:06 AM Denis <denis.ietf@free.fr
>>>     <mailto:denis.ietf@free.fr>> wrote:
>>>
>>>         Hi Dick,
>>>
>>>>         Hi Denis, thanks for sharing the model. I don't fully
>>>>         understand what is going on, questions inserted:
>>>         Responses are inserted.
>>>>
>>>>         FWIW: having paragraphs start with the step number (1), (2)
>>>>         etc. would make it easier to map between the description
>>>>         and the diagram.
>>>>
>>>>         On Thu, Jul 9, 2020 at 3:26 AM Denis <denis.ietf@free.fr
>>>>         <mailto:denis.ietf@free.fr>> 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)
>>>>
>>>>         Which party has the client authenticated to? The client
>>>>         authenticating with FIDO is confusing to me. FIDO is
>>>>         usually how a user authenticates.
>>>
>>>         If the user has previously opened a user account with the RS
>>>         using FIDO, then the client may be authenticated by the RS
>>>         using FIDO.
>>>         In such a case, the user is already known to the RS under a
>>>         pseudonym specific to the RS. It may (or may not) have
>>>         previously presented access tokens
>>>         to that RS.
>>>
>>>>         contacts the RS and after some dialogue with the RS selects
>>>>         an operation
>>>>         How does the client know which RS to contact?
>>>
>>>         For a private usage, the user may use DuckDuckGo, while for
>>>         business he may use an application from his company which
>>>         lists various services
>>>         available in the context of his job or his position. Some
>>>         services may be freely available to all the employees of the
>>>         company with any authentication,
>>>         e.g. the phone book of the employees may be freely available
>>>         on the intranet of the company, while some other services
>>>         may require the user
>>>         to authenticate to the AS from the company.
>>>
>>>>         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.
>>>>
>>>>         (1a) and (1b) are not labeled. There is only (1)
>>>
>>>         (1a) is the first exchange for (1) with the arrow from left
>>>         to right, while (1b) is the response with the arrow from
>>>         right to left.
>>>         The same applies to the other exchanges i.e. (2) , (3) and (4).
>>>
>>>>
>>>>             This information is specifically marked to indicate
>>>>             that it shall be handled by the "User Consent element"
>>>>             from the Client.
>>>>
>>>>         Why? What is the significance of this? Which information is
>>>>         marked?
>>>
>>>         In the response, a specific identifier or a magic number is
>>>         used to indicate the start and the length of the information
>>>         block
>>>         to be sent to the "User Consent element" supported by the
>>>         Client.
>>>
>>>>         The presentation of that information is up to the man
>>>>         machine interface supported by the "User Consent element"
>>>>         from the Client.
>>>>
>>>>
>>>>         Which information?
>>>
>>>         The attributes that are needed by the RS for performing a
>>>         requested operation and from which Attributes Servers they
>>>         may be obtained.
>>>
>>>>
>>>>             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).
>>>>
>>>>         How does the client know which AS(s) to contact?
>>>
>>>         For each AS trusted by the RS to perfom a given operation,
>>>         the RS should indicate a user-friendly name and a URL of the
>>>         AS.
>>>
>>>>             The user consent is hence captured locally by the
>>>>             Client (i.e. there is no dialogue with any AS nor any RS).
>>>>
>>>>
>>>>         No dialogue with who? The client is calling the AS is it not?
>>>
>>>         For the user consent, there is no external call since it is
>>>         handled locally. Afterwards, there is a call to the AS(s)
>>>         selected by the user.
>>>
>>>>
>>>>             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).
>>>>
>>>>
>>>>         So the RS must trust the AS that issued the tokens. And the
>>>>         AS must trust the Client to have gathered consent.
>>>         Theses two assertions are correct.
>>>>         And the AS must have a relationship with the user.
>>>
>>>         Only when the user chooses one AS while giving its consent,
>>>         then the user must have a relationship with the selected AS.
>>>
>>>>         It is unclear what role the RO is playing in this though.
>>>>         The RO and RS look to be the same entity from all the other
>>>>         parties.
>>>
>>>         A RO, as indicated on the figure, has only a relationship
>>>         with one RS: it has no relationship with any AS.
>>>         The RS trusts the AS but the AS does not know which RSs are
>>>         trusting it.
>>>
>>>>
>>>>         From my current understanding, at a high level, this looks
>>>>         like it is supported by GNAP with the addition of the
>>>>         discovery step (1).
>>>
>>>         Well, it is fairly different :
>>>
>>>             1) The first major difference is that there is no arrow
>>>             between the RO and the AS. No protocol or "out-of-bands"
>>>             means are necessary.
>>>
>>>             2) The second major difference is that there is no arrow
>>>             between the AS and the RS. No protocol is necessary.
>>>
>>>             3) The third major difference is that the AS does not
>>>             know any RS. Note: for backward compatibility reasons,
>>>             an exception might exist for "old" Auth 2.0 ASs.
>>>
>>>             4) The fourth major difference is that the XAuth spec.
>>>             is rather vague to describe when and by who the user
>>>             consent is captured:
>>>                 XAuth states on page 4: "User consent is /often
>>>             /required at the GS". In that case, the GS is able to
>>>             act as Big Brother. No other case is described.
>>>
>>>             5) The fifth major difference is that the data that is
>>>             transferred to a "User Consent Element" to capture the
>>>             user consent. That data can be standardized.
>>>                 Moreover, it will also be possible to standardize
>>>             the dialogue between the RO and the RS. The RO will then
>>>             be able to manage remotely the authorization tables.
>>>                 See my email sent on June 6, with the following
>>>             subject: "Support of FIDO and data minimization by RSs".
>>>
>>>             6) Another difference is the following: since there is
>>>             no interaction between the RO and the AS,
>>>             "authorizations from the RO" as described in XAuth do
>>>             not exist. 
>>>
>>>>         There have been a number of proposals for doing this
>>>>         discovery, and perhaps now there are enough use cases to
>>>>         look at standardizing something.
>>>>         No interaction is needed between the AS and the User as the
>>>>         Client is providing enough "information" in the user object
>>>>         of the Grant Request
>>>>         to satisfy the AS releasing the access tokens.
>>>         Not sure I understand correctly this last sentence.
>>>>
>>>>         Perhaps as I understand the model in more detail I will
>>>>         understand what is missing from GNAP (besides the discovery
>>>>         step).
>>>
>>>         It would be hard to say "what is missing" from XAuth since
>>>         the foundations are not the same.
>>>
>>>         In order to compare different architectures, there is the
>>>         need to start with the trust relationships.
>>>         Unfortunately, the word "trust" is absent in the main body
>>>         of draft-hardt-xauth-protocol-12. Hence,
>>>         the description of the trust relationships is missing.
>>>
>>>         Denis
>>>
>>>>
>>>>         /Dick
>>>>
>>>>         (I've skipped reviewing the delegation use case below until
>>>>         I understand the simple use case)
>>>>
>>>>
>>>>             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
>>>>
>>>>             -- 
>>>>             Txauth mailing list
>>>>             Txauth@ietf.org <mailto:Txauth@ietf.org>
>>>>             https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>         ᐧ
>>>
>>>
>>
>>     -- 
>>     Txauth mailing list
>>     Txauth@ietf.org <mailto:Txauth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/txauth
>>
>> -- 
>> Txauth mailing list
>> Txauth@ietf.org <mailto:Txauth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/txauth
>