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

Denis <> Fri, 24 July 2020 19:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BD773A090E for <>; Fri, 24 Jul 2020 12:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Status: No, score=-1.619 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, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MCtIRHX92qzi for <>; Fri, 24 Jul 2020 12:05:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2185E3A091C for <>; Fri, 24 Jul 2020 12:04:33 -0700 (PDT)
Received: from [] ([]) by mwinf5d67 with ME id 774X230012bcEcA0374X7n; Fri, 24 Jul 2020 21:04:32 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 24 Jul 2020 21:04:32 +0200
To: Dick Hardt <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Denis <>
Message-ID: <>
Date: Fri, 24 Jul 2020 21:04:33 +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: <>
Content-Type: multipart/alternative; boundary="------------9B01394042B761375535B355"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jul 2020 19:05:21 -0000

Hi Dick,

In order to send back a quick reply tonight, I will only respond to one 
of your questions:

    [Denis] How would be the data flow when access tokens from two GSs
    are needed by a RS ?

    [Dick] I don't know of a use case where two tokens would be needed
    by an RS. Would you elaborate?

I already described on the list the case of a student registering to a 
new University.

First, the student connects to the RS from the new University and opens 
an account
(at this time the student is using a pseudo and a private key to 
authenticate). He fills some forms
and indicate its citizenship, his home address and his graduation in his 
current university.

When he is finished, he indicates that he wants to perform a 
Registration operation.

 From the information gathered in the forms, the RS informs the client 
that it needs two access tokens:

  * one to demonstrate that his name and current home address are
  * another one to demonstrate that he got a graduation from its current

Depending upon the information captured in the forms, the RS also 
indicates which ASs/GSs are acceptable
and which kind of attributes are requested.

The user consent and choice is performed by the client and once approved 
by the student, two access tokens are separately requested.
Finally, two access tokens are presented to the RS while invoking a 
Registration operation.

Note that the start of the story is to open an account, e.g. using FIDO. 
The needs of the RS are only disclosed to the student once he has filled 
some forms
and indicated that he wanted to perform a Registration operation. Thus, 
the needs that are revealed by the RS are dependant both upon the operation
that the student is willing to perform and the information collected in 
the forms.


> Hi Denis, comments inserted ...
> On Fri, Jul 24, 2020 at 9:08 AM Denis < 
> <>> wrote:
>     Hi Dick,
>     draft-hardt-xauth-protocol-13 describes a solution without clearly
>     stating what the problem(s) to be solved is/are.
> I agree that the problem description is not as crisp as I would like 
> it to be. A challenge is that there is a broad spectrum of use cases 
> solved by OAuth 2, and OpenID Connect, as well as the new use cases 
> that are solved by GNAP.
> That is why I am suggesting we gather some use cases so we have a 
> common understanding of the problems that are in scope.
>     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.
> I have made no updates as we are in a quiet period prior to the WG 
> meeting next week when documents cannot be updated.
>     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 ?
> I view that as an advanced use case that would be covered in a 
> separate document.
>     Figure 4 shows only a single GS. How would be the data flow when
>     access tokens from two GSs are needed by a RS ?
> I don't know of a use case where two tokens would be needed by an RS. 
> Would you elaborate?
> The RS being able to accept tokens from two different GSes is covered, 
> but the Client is only using a token from one GS at a time.
>     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.
> I disagree. The use cases describe the problems we are looking to 
> solve. The data flows are part of the solution. For example, from my 
> understanding of your use case, you don't want the GS to have 
> visibility into the User's activity. Am I correct that this is one of 
> your requirements for your use case?
>     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).
> See above
>      *
>     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 <
>>     <>> 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 <
>>>         <>> 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
>>>>             < <>> 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
>>>>>                 < <>>
>>>>>                 wrote:
>>>>>                     Hi Dick,
>>>>>>                     On Fri, Jul 17, 2020 at 9:21 AM Denis
>>>>>>                     <
>>>>>>                     <>> 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 mailing list
> <>
> ᐧ