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

[Dick Hardt <[e-mail]>]

On Tue, Jul 21, 2020 at 11:26 AM Denis <[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]> 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]> wrote:
>>
>>> Hi Dick,
>>>
>>> On Fri, Jul 17, 2020 at 9:21 AM Denis <[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.


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


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


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


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



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


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


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

In your use cases, it seems that the RO is 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?



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


> 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 Access Control Enforcement Function
>> (AEF) and an Access Control Decision Function(ADF).
>>
>> Access Control 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.
>> Access Control 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 the context 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.


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



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