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

[Denis <[e-mail]>]

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?