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

[Dick Hardt <[e-mail]>]

Hi Francis

Thanks for drafting the sequence diagram and descriptions! I really like
where. you are going with it.

As our objective is to provide an abstraction,  what do you think of
collapsing steps 2&3, 5&6, and 8&9 in the diagram?

Per the discussion to your post, there is also some tuning of the
descriptions of each step. I would also add in which steps are optional.

Referencing other parts of the document would be useful, as this
abstraction is intended to be a high level guide to the protocol, so adding
other top level sections to the document, even if they are thin, would help
the reader in grasping the possible flows.

/Dick

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

> Hello Francis,
>
> 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.
>
> This information was not mentioned in your description.
>
>
>> 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?
>
> Your answer above mentions : "which GS to approach for authorization". It
> uses the singular whereas it should use the plural.
>
> In addition, indicating only which GS*s* (plural) is insufficient, since
> the RS also needs to indicate to the Client which attributes
> are requested for each of these GSs.
>
> Your description is also silent to explain how/when/where the user consent
> is gathered.
>
>
>>
> 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.
>
> In your are using the terminology of RFC 6749, then page 5 states:
>
> In OAuth, the client requests access to resources controlled by the
> resource owner and hosted by the resource server.
>
> In order to make sure that the right RO is in charge of the appropriate
> RS, the GS needs to maintain a mapping between the RS and the RO.
> The client does not know who the ROs are.
>
>
>
>> 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.
>
> If the GS is in a position to know when a client is attempting to make an
> access to a given RS, then it can maintain logs of these events.
>
> RS will find a way to validate AuthZ produced by any GS.
>
> No. A RS trusts some GSs for some kinds of attributes. It does not trust
> all the GSs that might exist in the world.
>
> Means RS must trust that very GS or trust somebody that trusts that very
> GS (e.g. CA).
>
> Trust relationships are not necessarily transitive (nor bilateral).
>
> GS must not know the RS but must understand the Resource and trust the
> Resource Owner, so that GS can validate the RO Grant.
>
> It would be interesting if you could elaborate on the last part of this
> sentence :
> "[GS] must understand the Resource and trust the Resource Owner, so that
> GS can validate the RO Grant".
>
> Denis
>
>
> /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/
>
>
>