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

[Dick Hardt <[e-mail]>]

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.

I think the abstract sequence as proposed by Francis is a great addition,
and would clarify where consent is in the sequence.


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


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


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



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

Here is flow:

1) The Client requests access to an RS from the GS.
2) The GS queries the RS if access should be granted.
3) If access is granted, the GS creates an access token representing the
granted access, and returns it to the Client.
4) The Client presents the access token to the RS to show it has been
granted access.

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.

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.






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


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

/Dick