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

Denis <denis.ietf@free.fr> Mon, 13 July 2020 20:06 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 D35AC3A07E0 for <txauth@ietfa.amsl.com>; Mon, 13 Jul 2020 13:06:44 -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 6ieVSY-3l39I for <txauth@ietfa.amsl.com>; Mon, 13 Jul 2020 13:06:40 -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 380913A00B3 for <txauth@ietf.org>; Mon, 13 Jul 2020 13:06:39 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d74 with ME id 2k6d230014FMSmm03k6dCa; Mon, 13 Jul 2020 22:06:37 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 13 Jul 2020 22:06:37 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, "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> <34dfca59-47f7-63e4-b25f-01648b0bd14b@free.fr> <CAD9ie-uZiG8C-_AjK6R0ksmnzsNYZgU_9JNaiEtZw7OR20PB5A@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <329996ce-ffa0-9713-b2ff-2a9722a24cf1@free.fr>
Date: Mon, 13 Jul 2020 22:06:34 +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: <CAD9ie-uZiG8C-_AjK6R0ksmnzsNYZgU_9JNaiEtZw7OR20PB5A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A7002511349A222A2531E6CE"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/fQ8U7pF2WYwBjibmI53QHztnEuw>
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 20:06:45 -0000

Dick,

You wrote: "I don't understand what is missing". The response is in my 
previous email.
The *user consent* is always requested by the Client and hence it is 
never requested by the GS/AS.

Two other important points:

1° At the first exchange, the RS discloses the elements of an 
authorization table
      that are directly dependent upon the operation that the client is 
willing to perform.

2° I propose a way to integrate FIDO, since FIDO allows to support the 
user's authentication phase
      by disclosing only a pseudonym unique to the RS.

Denis


> I get that the Client<->RS step is critical to the use case, as is the 
> User not interacting with the GS, but there are other use cases where 
> the User does not interact with the GS, for example 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-2.3., 
> but Denis's use case should not be the only use case.
>
> So it seems that GNAP can support Denis's use case by defining the 
> initial Client<->RS interaction, and the information in the user 
> object of the Grant Request to be what the GS needs to issue access 
> tokens, which was what I suggested earlier.
>
> I don't understand what is missing, besides the details of the 
> Client<->RS interaction, and what is in the Grant Request.
>
>
> On Mon, Jul 13, 2020 at 12:22 PM Denis <denis.ietf@free.fr 
> <mailto:denis.ietf@free.fr>> wrote:
>
>     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
>>
>
>     -- 
>     Txauth mailing list
>     Txauth@ietf.org <mailto:Txauth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/txauth
>