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

[Denis <[e-mail]>]

Hello Francis,

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

The draft defines a user as "the person interacting with the Client". 
The User consent is the very first property related to privacy principles.
It is mentioned in clause 5.2  "Consent and choice" from ISO 29100. 
Before the release of personal attributes to a RS, the consent of the 
person
holding these personal attributes must  be obtained. Unfortunately, 
since this stage is not mentioned in the draft, it is very unlikely that
implementers will even think to implement it.

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

No. A RO interacts with its RS. Before any access, the RO defines the 
authorization conditions at the RS.
Once it is done, any client that fulfils these authorization conditions 
will be granted an access.

> Clarification 2: Consent vs. AuthZ (Authorization)
> 1. Consent is given by RO to GS and used to produce an Authz.

No. There is no need for a RO to interact with a GS.

> 2. AuthZ is given by GS to Client and used by Client to access 
> Resource at RS interface on behalf of User.

Authz is a set of attributes released to a Client in an access token. 
There is no need to have any RO involvement in that process.

>
> 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 access tokens are considered to be opaque to the client, then the 
client can verify that the "Consent and choices"
formulated by the user (i.e. person) have indeed been taken into 
consideration. On the contrary, if access tokens are
considered to be opaque to the client, such assurance cannot be obtained 
by the client and hence the user.

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

A user is currently defined as a person. The case of a "client 
application" interacting with the system through a Client
should however also be addressed. Both a user and a client application 
are interacting with the system through a Client.

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

Your position is in contradiction with the response from the editor of 
this draft (Dick) who wrote:

    If the RO is a separate entity, then the GS knows the RO from the RS
    being queried.

In order to discover the RO, the GS must know who the the RS is. 
However, while being necessary, this is insufficient. The GS must
be able to authenticate the RO and to associate it with the RS and there 
is no reason why this information shall necessarily be made
publicly available. Hence, this is why prior relationships between GSs 
and RSs/ROs  are necessary and this makes the whole architecture
complicated whereas it can be quite simple when the RO only interacts 
with its RS.

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

A GS is not "working for" any RO. A GS when receiving an access token 
request does not even know whether it should contact or not a 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/...

If, prior to any access, authorization conditions are well defined and 
managed by the RO of the RS, then the RO does not need to be involved
in real time, in particular at the time of an access of a client.

Denis

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