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

[Francis Pouatcha <[e-mail]>]

Hello Denis,

On Thu, Jul 16, 2020 at 8:45 AM Denis <[e-mail]> wrote:

> Hello  Francis,
>
> The first two steps of your scenario are nice, in particular the second
> one:
>
> (2) Service Intent: In order to discover *authorization requirements*,
> the Client sends a service intent to the RS.
>
> This means that the client first contacts the RS, instead of the GS.
>

> However, the third step is missing to disclose to the client these "*authorization
> requirements*", in particular which AS(s),
> it may contact, which attributes are requested and how/when/where the user
> consent is gathered.
>
The response (2) AuthZ Challenge carries the reference to the GS. Mean the
resource server instructs the Client on which GS to approach for
authorization.


> Unless the scenario is mandating all the RSs to trust one and only one GS
> and the client to have a relationship with that GS,
> the remaining steps of this scenario do not work.
>
Can you elaborate why it shall not work for many GSs?


>

> Step (5) mandates the GS to know who the owner of a given RS is
>
Step (5) mandates the GS to know the RO, as owner of the target Resource,
but not the RS (Resource Server). Resource not-equals RS.

, and thus mandates the client to disclose to the GS the identity of the
> RS.
>
No. Here there is no requirement from GS to know the RS.


> The consequence is the following : this scenario, *as well as the
> scenario described in draft-hardt-xauth-protocol-13*, allows the GS to
> act as Big Brother.
>
No.

RS will find a way to validate AuthZ produced by any GS. Means RS must
trust that very GS or trust somebody that trusts that very GS (e.g. CA).
GS must not know the RS but must understand the Resource and trust the
Resource Owner, so that GS can validate the RO Grant.

/Francis

>
> Denis
>
> 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/
>
>
>

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