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

On Mon, Jul 20, 2020 at 2:05 AM Denis <denis.ietf@free.fr> wrote:

> Hi Dick,
>
> On Fri, Jul 17, 2020 at 9:21 AM Denis <denis.ietf@free.fr> 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.

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

If the RO is a separate entity, then the GS knows the RO from the RS being
queried. 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.

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

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

>
> Denis
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
ᐧ