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

[Denis <[e-mail]>]

Hi Dick,

The floor is yours.

Would you explain how you would handle the use case of a student 
registering to a new University ?

Would you also elaborate why in my explanations below, you think that 
"the University's registration system is the Client, not a Resource 
Server" ?

Denis

> Hi Denis
>
> I would think in your example below, that the 
> University's registration system is the Client, not a Resource Server.
>
> Have a good night's sleep!
>
>
>
> On Fri, Jul 24, 2020 at 12:04 PM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>         correct,and
>       * another one to demonstrate that he got a graduation from its
>         current University.
>
>     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.
>
>     Denis
>
>>     Hi Denis, comments inserted ...
>>
>>     On Fri, Jul 24, 2020 at 9:08 AM Denis <[e-mail]
>>     <mailto:[e-mail]>> 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 <[e-mail]
>>>         <mailto:[e-mail]>> 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
>>>>             <[e-mail] <mailto:[e-mail]>> 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
>>>>>                 <[e-mail] <mailto:[e-mail]>>
>>>>>                 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
>>>>>>                     <[e-mail]
>>>>>>                     <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>                         Hi Dick,
>>>>>>
>>>>>>>                         On Fri, Jul 17, 2020 at 9:21 AM Denis
>>>>>>>                         <[e-mail]
>>>>>>>                         <mailto:[e-mail]>> 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
>>>             [e-mail] <mailto:[e-mail]>
>>>             https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>>         -- 
>>         Txauth mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/txauth
>>
>>     ᐧ
>
>