Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11

Denis <denis.ietf@free.fr> Fri, 24 July 2020 16:08 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 1DCFA3A0EAC for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 09:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.629
X-Spam-Level:
X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 EHouRrndzHkE for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 09:08:03 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D52D3A0E9C for <txauth@ietf.org>; Fri, 24 Jul 2020 09:08:02 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d14 with ME id 747w2300R2bcEcA0347x72; Fri, 24 Jul 2020 18:08:00 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 24 Jul 2020 18:08:00 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt <dick.hardt@gmail.com>
Cc: txauth@ietf.org
References: <CAOW4vyPqjcWz7njW9cVb6wejY+KaASnskefSpwMqCPs+3WPmfg@mail.gmail.com> <f00c75a5-f930-81a6-a50e-2eeffedac691@free.fr> <CAOW4vyOHO1We4UpCPJBKYvj22rsFd1EN6fAXw8w6YOYTUDhF=g@mail.gmail.com> <aa1381a2-5b11-f7c7-a547-cddb36732c0b@free.fr> <CAD9ie-t7ZFrODeXy=Xzvsv-6gvUY=KjW0ETf8vJYkW2p=G4boQ@mail.gmail.com> <CAOW4vyN26rnOFb+vsaxgaMzeBOsyeSUBougvjHuhQkHyYhnn2w@mail.gmail.com> <b8a83294-771f-c1d7-0956-d0a50accbbb3@free.fr> <CAD9ie-soUmghr-qxWFRhHkX3rx3qaf3wBqxkwRZ=ZfQaSoDwbw@mail.gmail.com> <df110f7d-7928-4dd2-9c09-4b169860623a@free.fr> <CAD9ie-tLpufcTACXxzCER7t=eebnPhNN9VGbyuRgQOHzQ8=Ctg@mail.gmail.com> <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr> <CAD9ie-uXgLrkvEJ5txkR2Un9NJ-yfYy0AhE9gZaKvAF8qjqWFw@mail.gmail.com> <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr> <CAD9ie-uL_rm73imCe5kMZWd_HvZPQcC_zx3HphHeNXK5JqxNwg@mail.gmail.com> <c35d8330-780c-231c-2d03-afcc4a671187@free.fr> <CAD9ie-t1YD+Dx5ssgUoJrGk-PRQF2aiF3Eqgi7Hi0Cm+sOb31Q@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <d983678a-4f32-b4ad-ba2b-f7e563819356@free.fr>
Date: Fri, 24 Jul 2020 18:07:58 +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-t1YD+Dx5ssgUoJrGk-PRQF2aiF3Eqgi7Hi0Cm+sOb31Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------5575EDBC1B6F6485968D4F72"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/CU_jM8FNv4ojkwhCyPnxbKCxoPg>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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: Fri, 24 Jul 2020 16:08:09 -0000

Hi Dick,

draft-hardt-xauth-protocol-13 describes a solution without clearly 
stating what the problem(s) to be solved is/are.

At the moment, draft-hardt-xauth-protocol-13 includes a single figure on 
page 4 and from previous discussions I understood that
it is no more up-to-date since the first data flow is now a contact with 
a RS. The reason(s) for the GS to contact a RO has still not
been explained (since the inputs and outputs are not described). The 
discovery information made available at various steps at the RS
is not described.

Figure 4 shows only a single RS. Is the relaying of one operation by 
that RS to a second RS in the scope of this document ?
If yes, how is it handled ?

Figure 4 shows only a single GS. How would be the data flow when access 
tokens from two GSs are needed by a RS ?

What we need first is not a set of "use cases" but a clear model with a 
data flows and a list of its properties/characteristics.
Then after, we can understand much better which use cases can/will be 
supported. For example, shall a RS (or its RO) have
prior relationships with the GS ? What is the difference/implications 
when it has or it hasn't ?

In order to have a fair comparison, we should try to list model 
properties/characteristics.

At the moment, the model I have described including the data flows is 
clear. The discovery information made available by a RS is clear.
I have not listed all its properties/characteristics of that model, but 
I am pretty sure that you already have a flavour of it.

In the mean time, it would be nice if you could show using two figures:

  * the case of the relaying of one operation by one RS to a second RS
    (if it is in the scope of your document),
  * the case where access tokens from two GSs are needed by one RS (if
    it is in the scope of your document).

Denis

> Hi Denis
>
> I think it would be useful to take a step back and for you to describe 
> your use case.
> After that, we can explore the different ways that your use case can 
> be addressed.
>
> Looking at your previous communication, it describes the solution, and 
> the justification,
> but it is not clear what use cases you are needing to solve.
>
> /Dick
>
>
> ᐧ
>
> On Wed, Jul 22, 2020 at 9:34 AM Denis <denis.ietf@free.fr 
> <mailto:denis.ietf@free.fr>> wrote:
>
>     Hello Dick,
>
>     I have identified the reason of the major difference between our
>     two approaches.
>
>     Access control may be performed using either ACLs (Access Control
>     Lists) or Capabilities.
>
>     _Note _: a capability identifies a resource and an allowed
>     operation that can be performed on that resource.
>
>     You are advocating a Capabilities approach while I am advocating
>     an ACL approach.
>
>     The capabilities approach allows the GS to trace every operation
>     performed by the users on any RS known by a GS.
>     The management of these capabilities is made via the GS or at the
>     GS by the various ROs. If the management is made
>     via the GS, then a trusted communication channel needs to be
>     established with every RO. If the management is made
>     at the GS, then an authentication mechanism needs to be
>     established with every RO. In the last case, the GS has the
>     ability to know all the capabilities of the users whether they are
>     used or not. The less that can be said is that this model
>     is not privacy friendly.
>
>     With the ACL approach, a RO directly manages an ACL placed in
>     front of each RS. The AccessControl Decision Function
>     (ADF) at the RS is able to keep track from prior decisions. The GS
>     is kept ignorant of the content of these ACLs and only
>     delivers to its clients attributes that are placed into access
>     tokens. Such a model may be privacy friendly.
>
>     Other comments are between the lines prefixed with [Denis].
>
>>
>>     On Tue, Jul 21, 2020 at 11:26 AM Denis <denis.ietf@free.fr
>>     <mailto:denis.ietf@free.fr>> wrote:
>>
>>         Hello Dick,
>>
>>         Thank you for your feedback. Comments are between the lines.
>>
>>>         comments inserted ...
>>>
>>>         On Tue, Jul 21, 2020 at 6:03 AM Denis <denis.ietf@free.fr
>>>         <mailto:denis.ietf@free.fr>> wrote:
>>>
>>>             Hello Dick,
>>>
>>>             I duplicate the most important comment at the beginning
>>>             of this email:
>>>
>>>                 You are considering using an access control model to
>>>                 build a**workflow model.
>>>                 **
>>>                 While it may be interesting to define a workflow
>>>                 model, this should be considered
>>>                 as a separate and different work item.
>>>
>>>             See the other comments between the lines.
>>>
>>>>             On Mon, Jul 20, 2020 at 2:05 AM Denis
>>>>             <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> wrote:
>>>>
>>>>                 Hi Dick,
>>>>
>>>>>                 On Fri, Jul 17, 2020 at 9:21 AM Denis
>>>>>                 <denis.ietf@free.fr <mailto:denis.ietf@free.fr>>
>>>>>                 wrote:
>>>>>
>>>>>                     Hello Francis and Dick,
>>>>>
>>>>>                     The good news first: we are making some
>>>>>                     progress. We are now close to an agreement
>>>>>                     with steps (1) up to (3),
>>>>>                     ... except that the place where the user
>>>>>                     consent is captured is not mentioned/indicated.
>>>>>
>>>>
>>>>                 This major question which is currently left
>>>>                 unanswered is where, when and how the user consent
>>>>                 is captured.
>>>>
>>>>
>>>>             When is covered, per the sequence. How and where are
>>>>             out of scope of what I drafted.
>>>
>>>             It is clear that the "User consent and choice" is not
>>>             currently addressed in the draft, but it should.
>>>             The support of the "User consent and choice" has strong
>>>             implications not only in the sequences of the exchanges
>>>             but also by which entity it should be performed.
>>>
>>>         "consent" is in the latest draft 7 times.
>>
>>         "Consent" is present 5 times. The User consent is different
>>         from the RO consent (when/if it is required).
>>
>>             The server acquires consent and authorization from the
>>             user *and/**or resource owner **if required.*
>>
>>             User consent is *often required* at the GS. GNAP enables
>>             a Client and  GS to negotiate the interaction mode for
>>             the GS to obtain consent.
>>
>>             The GS *may *require explicit consent from the RO or User
>>             to provide these to the Client.
>>
>>         The User consent is not an alternative to the RO consent. So
>>         using "and/or" in the first sentence is incorrect.
>>
>>
>>     My language is sloppy there. Consent is always from the RO. The
>>     User may be the RO.
>
>     [Denis] No. Once again: The "/User consent/" is different from
>     what you call the "/RO consent/" (when/if it is required).
>     The "RO consent" is not in fact a consent but the release of a
>     capability to a client by one of the many R0s with which
>     the GS has relationships.
>
>>         Since the second sentence is using the wording "often
>>         required" there is no requirement to get the User consent.
>>
>>     User consent may not be required. There may not be a User. The
>>     consent may have been gathered previously.
>
>     [Denis] In order to follow the privacy principles, a "User
>     consent" phase is required. The User is a natural person.
>     A Client is called either by a User (i.e. a natural person) or by
>     a Client application.
>
>>         The second sentence does not consider the possibility to get
>>         the User consent in a place different from the GS.
>>
>>     Agreed. But we do agree that the GS gets the consent, either
>>     directly from the RO, or from the Client (in your example).
>
>     [Denis] No. I disagree. In an ACL based systems, the GS does not
>     need to ask or receive any consent.
>     The client selects the set of attributes that it wants to be
>     inserted into an access token.
>     If the GS has the requested attributes, then it provides them,
>     otherwise it returns an error to the Client.
>
>>         IMO, the User consent should be captured by the Client, i.e.
>>         not by the GS.
>>         The information used to obtain the User consent should be
>>         standardized (... and it can be standardized).
>>
>>>         I think the abstract sequence as proposed by Francis is a
>>>         great addition, and would clarify where consent is in the
>>>         sequence.
>>
>>         The current sketch does not illustrate the place the User
>>         Consent is captured, in particular by the Client.
>>
>>     It is an abstraction. The GS receives the consent. How consent is
>>     gathered is a detail that is dependent on the use case.
>
>     [Denis] I really wonder whether there is really a "consent" to be
>     received by the GS in both cases (i.e. ACLs or Capabilities).
>
>       * For ACLs, the consent needs to be done by the Client.
>       * For Capabilities, the current description is not clear since
>         the inputs and the outputs for this "consent" phase
>         are not currently described in the draft.
>
>>>>                 Another important point to consider and to explain
>>>>                 is related to the assurances that the user can
>>>>                 obtain about
>>>>                 the respect of his choices. This point is currently
>>>>                 left unanswered in draft-hardt-xauth-protocol-13.
>>>>
>>>             This point is equally important: such assurance can only
>>>             be obtained if the access token returned to the client
>>>             is not considered to be opaque to the client. This is a
>>>             necessary condition but not the single condition:
>>>             the Client must also be in a position to
>>>             capture/memorize the "User consent and choice" of the
>>>             user in order to be able
>>>             to verify it afterwards using the content of the access
>>>             token(s).
>>>
>>>
>>>         We disagree on this being a requirement for all use cases.
>>>         It may be in some.
>>
>>         OK. Then this means that there will be no sentence in the
>>         draft such as :
>>         "access tokens returned to the client are not considered to
>>         be opaque to the client".
>>
>>
>>     For OAuth use cases, which GNAP supports, the access token is
>>     opaque to the Client. As you have noted, there are use cases
>>     where the access token is NOT opaque.
>
>     [Denis] Wait a second. There is no requirement to support all
>     OAuth use cases.
>     I believe that there is a requirement to support OAuth 2.0 ASs,
>     while the clients may be different
>     and hence GNAP clients do not need to inherit of the limitations
>     of OAuth 2.0 clients.
>
>>>>
>>>>>                     If a RO needs to be involved and since a RO is
>>>>>                     directly associated with a RS, why can't it be
>>>>>                     directly queried
>>>>>                     by the appropriate RS after step (2) or later on ?
>>>>>
>>>>>
>>>>>                 Good question. Perhaps you can expand on a use
>>>>>                 case where that would be useful?
>>>>
>>>>                 Before I expand, would you be able to explain first
>>>>                 under which circumstances a RO needs to be queried
>>>>                 by a GS ?
>>>>                 How can the GS identify which RO to query ?
>>>>
>>>>             If the User is the RO, then the GS knows who to query.
>>>
>>>             I still have difficulties to understand what you mean here.
>>>             How could a GS know that "the User is the RO" ?  If "the
>>>             User is the RO", why does the GS needs to query the User ?
>>>
>>>
>>>         To get consent?
>>
>>         To get a "RO consent" to himself ???
>>
>>
>>     The GS needs consent from the RO. If the RO is the User, then
>>     consent from the RO is equivalent to consent from the User.
>
>     [Denis] See above.
>
>>
>>>>             If the RO is a separate entity, then the GS knows the
>>>>             RO from the RS being queried.
>>>
>>>              ... and this gives the ability for the GS to log/trace
>>>             all the RSs accessed by a given User and at which
>>>             instant of time the access token has been granted.
>>>
>>>>             An example is a user would like access to an enterprise
>>>>             asset where a workflow is started to gain approval, and
>>>>             an administrator or manager provides consent.
>>>
>>>             Thanks for this example. I finally understand what you
>>>             have in mind: you are considering using an access
>>>             control model to build a *workflow model*.
>>>             While it may be interesting to define a workflow model,
>>>             this should be considered as a *separate and different
>>>             work item*.
>>>
>>>
>>>         The actual workflow is out of scope.
>>
>>         I am glad you agree with this. But this means that your
>>         example was not appropriate to illustrate your point.
>>
>>
>>     It illustrates a use case where the RO and User are not the same
>>     party, and why the GS needs to query the RO, which was your
>>     question if I understood it correctly.
>
>     [Denis] Since the inputs and the outputs for this "RO consent"
>     phase are not currently described in the draft, the point is still
>     unsolved.
>
>>         As soon as there is a RO consent obtained at the GS, the
>>         major problem is that the GS is able to act as Big Brother.
>>         If a RO consent is performed at the RS, then the GS will not
>>         know who the RS is: it is then unable to act as Big Brother,
>>         even if it would enjoy to play that role.
>>
>>     In an enterprise use case, the GS's knowledge of who is accessing
>>     which RS is a feature.
>
>     Do you mean that it is "normal" in an enterprise that a single
>     point of control is able to trace all their actions ?
>     From a security point of view, a single point of failure will have
>     dramatic consequences.
>
>>     In your use cases, it seems that the RO is the User.
>
>     I do hope that you have finally understood that, in my use case,
>     the RO is **not** the User.
>
>>     The GS knows the User is wanting to let a Client access
>>     something. If the access token is generic, and could be presented
>>     to any RS that provides a standardized function,
>>     then the GS does not know which RS is being accessed by a Client
>>     for the User. This seems to meet your privacy objectives. If not,
>>     what is wrong?
>
>     For security reasons, an access token needs to be targeted (which
>     does not necessarily mean that an identifier of the RS shall be
>     included into the access token).
>
>>>         if the admin grants access, then the access granted to the
>>>         client changes.
>>>
>>>             The model you propose may be suited for an enterprise
>>>             environment but is not scalable over the Internet.
>>>
>>>         It is one of the use cases we are working to address.
>>>
>>>             What is needed is an access control model usable over
>>>             the Internet with millions of RSs and thousands of ASs/GSs.
>>>
>>>         I agree the model should also scale to internet scale.
>>
>>         Fine. Another point on which we are in agreement.
>>
>>         The model can scale to the Internet based on the following
>>         assumptions:
>>
>>             The flow starts with the steps (1) to (4) as illustrated
>>             by Francis, i.e. the flow starts with a contact with a RS.
>>
>>         *+----+  +------+  +---+  +---+  +---+
>>         |User|  |Client|  |RS |  |GS |  |RO |
>>         +----+  +------+  +---+  +-+-+  +-+-+
>>           |(1) Service Request     |      |
>>           |-------->|       |      |      |
>>           |         |(2) Service Intent   |
>>           |         |------>|      |      |
>>           |         |(3) AuthZ Challenge  |
>>           |         |<------|      |      |
>>           |         |(4) AuthZ Request    |
>>           |         |------------->|      |*
>>
>>         The GS/AS does not need to have any prior relationship with
>>         ROs and/or RSs.
>>
>>         Furthermore, it is possible to prevent the GS to act as Big
>>         Brother when the identity of the RS is not disclosed to the GS.
>>
>>
>>     What happens after (4) above?
>
>     [Denis] The key point is that we first need to agree on the first
>     four exchanges. Do we ?
>
>     The fifth exchange is different whether ACLs or Capabilities are
>     being used.
>
>>>>>                     Which information is supposed to be presented
>>>>>                     to the RO ?
>>>>>                     Which information is supposed to be returned
>>>>>                     by the RO ?
>>>>>
>>>>>
>>>>>                 Just like how the user authenticates to an AS, how
>>>>>                 the AS and RO communicate is out of scope.
>>>>
>>>>                 At the moment, the usefulness of a dialogue between
>>>>                 a GS and a RO has not been explained, nor demonstrated.
>>>>                 The question is about the functionality of that
>>>>                 dialogue in terms of input and output information
>>>>                 (and not about
>>>>                 the design of a protocol or of a user interface).
>>>>                 Anyway, AFAIU a dialogue between a GS and a RO is
>>>>                 optional.
>>>>
>>>>
>>>>             See enterprise example above.
>>>
>>>             It is not an access control example, but a workflow example.
>>>
>>>             Access  control has been defined a long time ago and the
>>>             last edition of the model has been confirmed in year
>>>             1996: ISO/IEC 10181-3: 1996.
>>>             "Information technology — Open Systems Interconnection —
>>>             Security frameworks for open systems: Access control
>>>             framework — Part 3".
>>>
>>>             Two major functions have ben defined: an AccessControl
>>>             Enforcement Function (AEF) and an AccessControl Decision
>>>             Function(ADF).
>>>
>>>                 AccessControl Enforcement Function (AEF):
>>>                 A specialized function that is part of the access
>>>                 path between an initiator and a target on each
>>>                 access request and enforces the decision made by the
>>>                 ADF.
>>>
>>>                 AccessControl Decision Function (ADF) :
>>>                 A specialized function that makes access control
>>>                 decisions by applying access control policy rules to
>>>                 an access request, ADI (of initiators, targets,
>>>                 access requests,
>>>                 or that retained from prior decisions), and the
>>>                 context in which the access request is made.
>>>
>>>             The role of the RO is to define the "access control
>>>             policy rules" at the RS according to thecontext in which
>>>             the access request is made.
>>>
>>>         I'm pretty familiar with access control systems. :)
>>>
>>>         I would say that the access control is happening at the RS.
>>>         The client presents a token when accessing an API.
>>>         The RS uses the token, and any policy required, to make an
>>>         access decision.
>>
>>         Fine. It looks like we are in agreement. Unfortunately, this
>>         is not the case just below.
>>
>>>         Here is flow:
>>>
>>>         1) The Client requests access to an RS from the GS.
>>
>>         No. We are no more in agreement. This is different from the
>>         flow drawn by Francis.
>>
>>     My bad. Typo. I meant RO.
>>
>>>         2) The GS queries the RS if access should be granted.
>>
>>          No. The GS should not be forced to have a flow with the RS.
>>
>>     Same mistake as above, I meant RO.
>>
>>>         3) If access is granted, the GS creates an access token
>>>         representing the granted access, and returns it to the Client.
>>
>>         This model is by no way conformant to ISO/IEC 10181-3: 1996
>>
>>     I'm unclear on why, or why it is even relevant.
>>
>>>         4) The Client presents the access token to the RS to show it
>>>         has been granted access.
>>
>>         No. The client presents a token when accessing an API. The RS
>>         uses the token, and any policy required, to make an access
>>         decision.
>>         The token never contains an information like "Please grant an
>>         access to the holder of this token".
>>
>>     Let me provide more clarity in the sentence:
>>
>>     The Client presents the access token to the RS, to show the RS
>>     that the Client has been granted access to a resource at the RS
>>     by the GS.
>
>     [Denis] This time, please consider both the ACLs approach and the
>     Capabilities approach.
>
>>>         A couple advantages of this model:
>>>         - that the RS does not need to know much, if anything about
>>>         the Client.
>>>         - the access token MAY be self contained so that the Client
>>>         does not need to query the GS on each access.
>>
>>         There are so many disadvantages that I will not list them.
>>
>>     Darn: I clearly was not firing on all cylinders when I typed this
>>     out. Let me correct:
>>
>>>     - the access token MAY be self contained so that the RS does not
>>>     need to query the GS on each access to the RS by the Client.
>
>     [Denis] A few comments in the case of a capability approach:
>
>         - for each GS, the RS needs to locally manage which
>         operation(s) is/are allowed to it.
>
>         - the GS needs to establish a trusted communication channel or
>         an authentication mechanism with each RO
>            (which is associated with an explicit RS identifier).
>
>         - the GS could play the role of the RO and hence be in a
>         position to issue any capability for any RS (without a "RO
>         consent").
>
>            The target of an attack will clearly be the GS.
>
>>>         I would not say that GNAP is an access control protocol, as
>>>         how the RS uses the token to determine access is out of scope.
>>
>>         This is where we have a major discrepancy: how the RS uses
>>         the token to determine access is *within* the scope.
>>
>     [Denis] Do you agree or disagree ?
>>
>>         The RS announces in advance to the client what it needs so
>>         that the client can perform a a given operation and if the
>>         client supplies the requested attributes
>>         obtained from some GS/AS(s) trusted by the RS, then access to
>>         that RS is granted by the RS. If the RS cannot perform the
>>         requested operation on its own,
>>         then the client should be informed about some requested
>>         attributes that need to be obtained from some GS/AS(s)
>>         trusted by the next RS(s) in a chain
>>         for subsequent operations. The User consent should also be
>>         obtained before performing the chaining operation.
>>
>>         Chaining operations between RSs over the Internet is within
>>         the scope (... and may be achieved).
>>
>     [Denis] Do you agree or disagree ?
>
>     Denis
>
>>>>>                 For many use cases, the User is the RO, and the
>>>>>                 interaction is through a user interface, not a
>>>>>                 machine protocol.
>>>>
>>>>                 Wait a second. You wrote "the User is the RO". The
>>>>                 User is attempting to make an access to a RS by
>>>>                 using a Client.
>>>>                 _That_ User is not the RO of the RS.
>>>>
>>>>             The user being the RO is the initial use case for OAuth.
>>>
>>>             OAuth 2.0 is no more mandating such a case.
>>>
>>>
>>>         I don't know what you mean by that.
>>
>>         Copy and paste from draft-ietf-oauth-security-topics:
>>
>>             OAuth initially assumed a static relationship between
>>             client, authorization server and resource servers.  (...)
>>             With the increasing adoption of OAuth, this simple model
>>             dissolved and, in several scenarios, was replaced
>>             by a dynamic establishment of the relationship between
>>             clients on one side and the authorization and
>>             resource servers of a particular deployment on the other
>>             side.
>>
>>             This way, the same client could be used to access
>>             services of different providers (in case of standard APIs,
>>             such as e-mail or OpenID Connect) or serve as a frontend
>>             to a particular tenant in a multi-tenancy environment.
>>
>>
>>     This sentence does not mention the RO or the Client. I'm confused
>>     what we are talking about
>>
>>>>             A client application would like access to the user's
>>>>             photos at a photo sharing site. The resource is the
>>>>             user's photos. The user is the owner of that resource.
>>>
>>>             If the user has already pre established the access
>>>             control policy rules so that it can access to his own
>>>             photos
>>>             then he does not need to grant in real time any
>>>             additional authorization.
>>>
>>>         I don't understand what you are trying to say. The photo
>>>         sharing example was a driving use case for the creation of
>>>         OAuth.
>>
>>         We would need to revisit the original scenario and consider
>>         if it can be addressed in a different way than the original way.
>>
>>     The use case is the same. Is there a different solution you are
>>     proposing?
>
>
>     -- 
>     Txauth mailing list
>     Txauth@ietf.org <mailto:Txauth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/txauth
>