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

[Denis <[e-mail]>]

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.

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

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

> 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 model you propose may be suited for an enterprise environment but is 
not scalable over the Internet.
What is needed is an access control model usable over the Internet with 
millions of RSs and thousands of ASs/GSs.

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

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

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

Denis

>
>     Denis
>
>
>     -- 
>     Txauth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/txauth
>
> ᐧ