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

[Francis Pouatcha <[e-mail]>]

Hello Denis,


>>> 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.
>>
> There is nothing like a User consent. It is essential for further
discussions to use the correct keywords.

Clarification 1: User vs. RO
1. User interacts with Client
2. RO interacts with GS

Clarification 2: Consent vs. AuthZ (Authorization)
1. Consent is given by RO to GS and used to produce an Authz.
2. AuthZ is given by GS to Client and used by Client to access Resource at
RS interface on behalf of User.

Modified Question: where, when and how the "RO" Consent is captured?

Answer:
how: Consent is given by the RO to the GS.
where: Depend of interaction mode.
when: before step (5).

>
>> 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.
>>
> [Denis] These two major points are still left unanswered at this time.
>
I do not understand the question.

>
>>
>>> 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 ?
>>
> In all circumstances. Can you name a situation where this is not the case?
>
> [Denis] This is quite easy. The final decision is always taken by the RS.
> If a Client presents access tokens issued by ASs trusted by the RS
> that contain appropriate attributes to perform the requested operation,
> then the operation is allowed.
>
We should be using GS instead of AS to avoid confusion.

> If really a human RO needs to be involved for whatever reason, it is
> possible to get its involvement when the Client connects to the RS.
> However such involvement does not need to be formalized by a protocol. It
> can be application specific.
>
Client has no Relationship with the RO.

There is no reference to a human here. User, Client, RS, GS, RO are all
roles. Nothing states the type of participants they are.

> How can the GS identify which RO to query ?
>>
> There is supposed to be a preexisting relationship between GS and RO, If
> not RO will have to register with GS in the first interaction (onboarding).
>
> How can the GS identify how to connect with RO?
> GS must evaluate the RS provided info in step (3)
> AuthZRequest(AuthZChallenge) to decide how to contact the RO. This is where
> selection of interaction mode takes place.
>
> [Denis] This means that a GS must have prior relationships with the RSs
> and ROs.
>
No. Evaluating an AuthZChallenge to discover the RO:
- does not assume GS knows RS.
- does not presume RS knows GS.

But:
- GS will generally have to know RO, as RO delegates the work to produce
authorizations on his behalf to GS.
- RS will generally have to know RO, as RO custodies his Resources with RS
and trusts RS to only release it to authorized parties.

How do you establish a contract without contracting parties knowing each
other?

> While this should not be prevented for backward compatibility with OAuth
> 2.0,
> this should not be the single case. Prior relationships between ROs and
> GSs is a door half-opened for Big Brother. If in addition the GS is able to
> know which operation
> is attempted by the client on which RSs, then it is a door wide-opened for
> Big Brother.
>
I do not understand this. GS is working for RO.

>
>>
>>> 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.
>>
>> 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 interacts with the Client.
> The RO interacts with the GS.
>
> In some use cases (where we use redirect interaction) we assume the person
> controlling the "User-Agent" is also the person
> controlling the "RO-Agent" and they reside on the same device. These are
> cases where we say User equals RO.
>
> [Denis] Sorry, I have difficulties to understand such a case. A person
> giving his consent to himself ?
>
We do not have people here, but roles.
RO is consenting
  - that the Client can access his Resource
  - on behalf of the User [optional].

So RO and User are different roles, even if they are sometimes assumed by
the same human/device/machine/...

>
>
-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/