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

[Denis <[e-mail]>]

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.

Since the second sentence is using the wording "often required" there is 
no requirement to get the User consent.

The second sentence does not consider the possibility to get the User 
consent in a place different from the GS.

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.

>>         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".

>>
>>>             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 ???

>>     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.

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.

> 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.

>>>             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.

> 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.

> 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

> 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".

>
> 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.

> 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.

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).

>>>         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.

>>     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.

Denis

>
> /Dick