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

Denis <denis.ietf@free.fr> Thu, 16 July 2020 16:57 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB6A3A0C80 for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 09:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.629
X-Spam-Level:
X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY7b6KpyEezk for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 09:57:29 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51053A0C7F for <txauth@ietf.org>; Thu, 16 Jul 2020 09:57:28 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d11 with ME id 3sxR2300U4FMSmm03sxSz3; Thu, 16 Jul 2020 18:57:26 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 16 Jul 2020 18:57:26 +0200
X-ME-IP: 86.238.65.197
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org, Dick Hardt <dick.hardt@gmail.com>
References: <CAOW4vyPqjcWz7njW9cVb6wejY+KaASnskefSpwMqCPs+3WPmfg@mail.gmail.com> <CAD9ie-vV4oh9Qk3Y0sPeewo4jby_S6a=HKTZnoqByxJ6tCHJ+Q@mail.gmail.com> <CAOW4vyOQYvHBBPjMSNx9=S66_JY4RVcVi2DiqL8OjXUyvzxg=w@mail.gmail.com> <CAD9ie-tou5mTnWVguNygj-D6xUdTRjqvxi-+jhC6NbDFY8ZVJQ@mail.gmail.com> <CAOW4vyM0LycEf8q1T4jF=1g8aFyeLw1b4z9emNKWOG=+4iGgzw@mail.gmail.com> <CAM8feuSWeianPu=BD0WVTv5oB+U4ZkjhtKjnAG9RFk15VqJqWA@mail.gmail.com> <CAOW4vyNTXso=tusCrzDVgM63xH4hDsx6epO6tAhh1YekbWBA0A@mail.gmail.com> <f00c75a5-f930-81a6-a50e-2eeffedac691@free.fr> <CAOW4vyOHO1We4UpCPJBKYvj22rsFd1EN6fAXw8w6YOYTUDhF=g@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <aa1381a2-5b11-f7c7-a547-cddb36732c0b@free.fr>
Date: Thu, 16 Jul 2020 18:57:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <CAOW4vyOHO1We4UpCPJBKYvj22rsFd1EN6fAXw8w6YOYTUDhF=g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------BD9FDD90F2EB8A97F86F4964"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/nucL_ROrrr03HhgX1a1Jkx_hOKc>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2020 16:57:32 -0000

Hello Francis,

> Hello Denis,
>
> On Thu, Jul 16, 2020 at 8:45 AM Denis <denis.ietf@free.fr 
> <mailto:denis.ietf@free.fr>> 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
>>     <fabien.imbault@gmail.com <mailto:fabien.imbault@gmail.com>> 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=40adorsys.de@dmarc.ietf.org
>>         <mailto:40adorsys.de@dmarc.ietf.org>> 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
>>             Txauth@ietf.org <mailto:Txauth@ietf.org>
>>             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/