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

[Francis Pouatcha <[e-mail]>]

Hello Fabian,

On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault <[e-mail]>
wrote:

> Hi,
>
> That's interesting, however the important logic is actually implemented
> within (5). And so for the reader, it might be quite difficult to
> understand what we're after (compared to oauth2 for instance). So in my
> view, this kind of schema has its place, but not at the start of the
> document where we should primarily be concerned about explaining why
> someone should read the document.
>
> It's also not easy to understand :
> - why we sometimes use different labels between requests and responses
> (for instance, 5 and 6)
>
Will need support in drafting the correct terms. The main purpose of this
diagram is to help sharpen the definition of terms and verbs used in the
draft.

- sometimes we use "grant" and sometimes "authZ", and it doesn't seem very
> clear what is the difference in use
>
IMO: the granting is the process of given permission.
- RO can grant his Consent to the User or Client
- GS can turn the RO Grant into an AuthZ.
- Client can use AuthZ to access a Resource.

A terminology section would be great to clarify.
>
Yes. There is a terminology section in there. We need to bring the wissing
words into the list and sharpen those already there.

>
> If I understand correctly your remark in 5, you think the request/response
> scheme (as in XYZ) may be misleading.
>
No. XYZ does IMO exactly  that. Just try to be more abstract for a better
description of the models.


> On the contrary, I think it allows support rich interaction scenarios (and
> especially the ones you describe) with greater flexibility.
>
Flexibility shall not be put ahead of formal correctness.


> For instance, some would disagree with the assertion that the goal is for
> the GS to gather consent (see discussion on putting that on client side). A
> fixed interaction schema has the downside of not permitting other setups.
>
This discussion is the result of the lack of sharp terminology. Most of the
time mixing up gathering consent (the act) and the way consent is gathered
and transported from RO to GS (the interaction).
/Francis


> Fabien
>
> On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha <fpo=
> [e-mail]> wrote:
>
>> Hello Dick,
>>
>>
>>>>>
>>>>>>
>>>>>> 2. Abstract Protocol Flow
>>>>>>
>>>>>> I am missing an abstract protocol flow like the one defined in
>>>>>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>>>>>
>>>>>
>>>>> That's an interesting point. GNAP also has identity claims, so the
>>>>> abstract flow is somewhat different (there is no Authorization Grant from
>>>>> the RO), and not all steps always happen. (there may not be steps (E) and
>>>>> (F) with a Resource Server)
>>>>>
>>>>> Would you elaborate on what you think would be useful here, that is
>>>>> not in the specific flows?
>>>>>
>>>> A diagram that generalizes the steps, independently of interaction mode
>>>> is essential for the reader's navigation of the rest of the document. This
>>>> is what #section-1.2 of RFC6749 does. I hope we can produce a similar
>>>> diagram.
>>>>
>>>> A subsection of
>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>>> could be defined for this.
>>>>
>>>
>>> Interaction modes are one dimension where the steps could be
>>> generalized, but some steps are optional. For example, the User may not
>>> interact with the GS, and the GS may interact with the RO. The Client may
>>> only want claims, and there would be no step of the Client calling the RS.
>>>
>>> A generalized diagram would need to include all optional steps so that
>>> it did not mislead a reader into thinking the diagram included all general
>>> steps, but it does not seem that is what you are asking for as you wrote:
>>>
>>> A subsection of
>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>> could be defined for this."
>>>
>>> Perhaps you can share how you think the diagram would look?
>>>
>> find below my proposal of an abstract sequence diagram.
>>
>> +----+  +------+  +---+  +---+  +---+
>> |User|  |Client|  |RS |  |GS |  |RO |
>> +----+  +------+  +---+  +-+-+  +-+-+
>>   |(1) Service Request     |      |
>>   |-------->|       |      |      |
>>   |         |(2) Service Intent   |
>>   |         |------>|      |      |
>>   |         |(3) AuthZ Challenge  |
>>   |         |<------|      |      |
>>   |         |(4) AuthZ Request    |
>>   |         |------------->|      |
>>   |         |       |      |(5) Consent Request
>>   |         |       |      |----->|
>>   |         |       |      |(6) Grant Consent
>>   |         |       |      |<-----|
>>   |         |(7) Grant Access (Token)
>>   |         |<-------------|      |
>>   |         |(8) Service Request (Token)
>>   |         +------>+      |      |
>>   |         |(9) Service Response |
>>   |         |<------|      |      |
>>   |(10) Service Response   |      |
>>   +<--------|       |      |      |
>>   +         +       +      +      +
>>
>> (1) Service Request: This is the service request sent by a User to the
>> Client. This can be a simple file read request or even a complex payment
>> initiation request.
>>
>> (2) Service Intent: In order to discover authorization requirements, the
>> Client sends a service intent to the RS.
>>
>> (3) AuthZ Challenge: The response to a service intent request is
>> generally an AuthZ Challenge. The content of this AuthZ Challenge, can be
>> an identification challenge, an AuthZ exemption, or details on requested
>> AuthZ. The content AuthZ Challenge can be similar to the oAuth2 RAR.
>>
>> (4) AuthZ Request : the Client sends an AuthZ Request to the GS including
>> the AuthZ Challenge. This request can be similar to the oAuth PAR request.
>>
>> (5) Requests Consent : GS sends consent request to RO.
>> Remark: The abstract protocol flow does not display a response of the
>> request (4) to the Client. This is IMO a general misunderstanding. This
>> protocol wants the GS to collect a consent from the RO.
>> - In the case of a "redirect interaction", GS will use transport
>> infrastructure provided by the Client to instruct the User to send the RO
>> to the GS (in most cases, user and RO are identical).
>> - In the case of a "decoupled interaction", GS will directly contact RO
>> and collect consent in a direct interaction with the RO (see CIBA).
>> - In the case of an "embedded interaction", GS will allow the Client to
>> directly collect the Consent of the RO in a direct interaction with the
>> User.
>>
>> (6) Grant Consent : RO return a Consent Grant to GS.
>>
>> (7) Grant Access : GS produces the corresponding access token and returns
>> it to Client.
>>
>> (8) Service Request : Client uses the access token to send the service
>> request to RS.
>>
>> (9) and (10) are self explaining...
>>
>> One of our upcoming exercises will be to challenge this abstract protocol
>> flow with existing interactions (and if possible associated use cases) to
>> see if we are missing something. After an agreement on the abstract
>> protocol flow we can make sure each interaction provides a mapping to step
>> 1 to 10.
>>
>> I will strip the rest of the post here. And bring further responses in
>> separate mails.
>>
>> Best regards.
>> /Francis
>>
>>> ᐧ
>>>
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead
>> adorsys GmbH & Co. KG
>> https://adorsys-platform.de/solutions/
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>

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