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

[Denis <[e-mail]>]

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.

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.

Step (5) mandates the GS to know who the owner of a given RS is, and 
thus mandates the client to disclose to the GS the identity of 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.

Denis

> Hello Fabian,
>
> On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault 
> <[e-mail] <mailto:[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]
>     <mailto:[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] <mailto:[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/
>