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

Denis <denis.ietf@free.fr> Fri, 17 July 2020 16:21 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 A473E3A0890 for <txauth@ietfa.amsl.com>; Fri, 17 Jul 2020 09:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 b_kPKP6CqPwS for <txauth@ietfa.amsl.com>; Fri, 17 Jul 2020 09:21:12 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30AC3A088C for <txauth@ietf.org>; Fri, 17 Jul 2020 09:21:10 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d85 with ME id 4GM8230074FMSmm03GM8kt; Fri, 17 Jul 2020 18:21:08 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 17 Jul 2020 18:21:08 +0200
X-ME-IP: 86.238.65.197
To: Francis Pouatcha <fpo@adorsys.de>, 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> <aa1381a2-5b11-f7c7-a547-cddb36732c0b@free.fr> <CAD9ie-t7ZFrODeXy=Xzvsv-6gvUY=KjW0ETf8vJYkW2p=G4boQ@mail.gmail.com> <CAOW4vyN26rnOFb+vsaxgaMzeBOsyeSUBougvjHuhQkHyYhnn2w@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <b8a83294-771f-c1d7-0956-d0a50accbbb3@free.fr>
Date: Fri, 17 Jul 2020 18:21:07 +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: <CAOW4vyN26rnOFb+vsaxgaMzeBOsyeSUBougvjHuhQkHyYhnn2w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------7B15785DB4717D0F8ED6F6FF"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/MYjTD7nO8vtP7xpdr2PTL4d7gvY>
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: Fri, 17 Jul 2020 16:21:16 -0000

Hello Francis and Dick,

The good news first: we are making some progress. We are now close to an 
agreement with steps (1) up to (3),
... except that the place where the user consent is captured is not 
mentioned/indicated.

If a RO needs to be involved and since a RO is directly associated with 
a RS, why can't it be directly queried
by the appropriate RS after step (2) or later on ?

Which information is supposed to be presented to the RO ?
Which information is supposed to be returned by the RO ?

Denis

> Hello Dick, Denis,
>
> here is an updated version of the diagram following Dick's advice to 
> collapse responses and some clarifications as raised by Denis:
>
> +----+  +------+  +---+  +---+  +---+
> |User|  |Client|  |RS |  |GS |  |RO |
> +----+  +------+  +---+  +-+-+  +-+-+
>   |(1) ServiceRequest      |      |
>   |-------->|       |      |      |
>   |         |(2) ServiceIntent:AuthZChallenge
>   |         |<----->|      |      |
>   |         |       |      |      |
>   |         |(3) AuthZRequest(AuthZChallenge)
>   |         |------------->|      |
>   |         |       |      |(4) ConsentRequest:Grant
>   |         |       |      |<---->|
>   |         |(5) GrantAccess(AuthZ)
>   |         |<-------------|      |
>   |         |       |      |      |
>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>   |         |<----->|      |      |
>   |(7) ServiceResponse     |      |
>   |<--------|       |      |      |
>   +         +       +      +      +
>
> Nomenclature of Arrows:
> ---> designate a request.
> <--- designates a response.
> <--> request with immediate response.
>
> Step, Action and Interaction:
> This diagram describes actions and not interactions:
> - Each step carries a number.
> - An action with immediate response is collapsed into a single step 
> (2, 4, 6).
> - An action with deferred response is represented by two steps (1&7, 3&5).
> - An action might be carried out using many interactions and might for 
> the purpose of transport involve more parties (see redirect 
> interaction bellow)
>
> (1) ServiceRequest
> This is the service request sent by the User to the Client. This can 
> be a simple file read request or a complex payment initiation request.
>
> (2) ServiceIntent:AuthZChallenge
> In order to discover authorization requirements, the Client sends 
> a ServiceIntent request to the RS. The response to a ServiceIntent 
> request is an AuthZChallenge.
> The content of an AuthZChallenge can be similar to the oAuth2 RAR.
> The content of the AuthZChallenge can be:
> - An identification challenge. Generally when the RS can not associate 
> the ServiceRequest with an RO.
> - An AuthZ exemption. Generally when the RS needs no further AuthZ to 
> fulfill the Client request.
> - Details on the requested AuthZ, including instructions on which GSs 
> the Client can approach for AuthZ; instructions on which attributes 
> are requested for each of these GSs.
>
> (3) AuthZRequest(AuthZChallenge)
> The Client sends an AuthZRequest to the GS including the 
> AuthZChallenge. This request can be similar to the oAuth2 PAR request.
>
> (4) ConsentRequest:Grant
> GS sends a consent request to RO. The way a GS connects with the RO to 
> collect RO's consent (Grant) is dependent on the interaction mode. 
> This is also valid for the nature of the Grant returned by the RO to 
> the GS.
> - In the case of a "redirect interaction", GS will use the transport 
> infrastructure provided by the Client to instruct the User to send the 
> RO to the GS authorization endpoint (in most cases, user and RO are 
> identical). In the case of oAuth2 AuthCode flow, the Grant provided by 
> the RO is stored by the GS (AS) at the AuthZ endpoint, then mapped to 
> an authCode that is transported by the User (User Agent) through the 
> Client to the token endpoint of the GS.
> - In the case of a "decoupled interaction", GS will directly contact 
> RO and collect consent in a direct interaction with the RO (see CIBA). 
> This diagram assumes GS can evaluate the AuthZChallenge to find out 
> how to locate the RO. As there is a direct interaction between the GS 
> and the RO, the form/nature of the Grant is left to the discretion of 
> the concrete interaction mode.
> - In the case of an "embedded interaction", GS will allow the Client 
> to directly collect the Consent (Grant) of the RO in a direct 
> interaction between the Client and the User (also assuming in most 
> cases, that user and RO are identical); and then send it to the GS in 
> exchange of the AuthZ. We say the interaction between GS and RO is 
> embedded in the communication with the Client.
>
> (5) GrantAccess(AuthZ)
> From evaluating the Grant provided by the client, the GS produces a 
> corresponding access token and returns it to the Client.
> Note that GS knowledge of the original or target RS is not necessary 
> for the issuance of the access token, unless GS is required to bind 
> the token to a target RS.
>
> (6) ServiceRequest(AuthZ):ServiceResponse
> Client uses the GS provided AuthZ to send the service request to RS. 
> Recall that AuthZ (token) can be, but must not be bound to an RS.
>
> (7) is 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 7.
>
> /Francis
>
> On Thu, Jul 16, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com 
> <mailto:dick.hardt@gmail.com>> wrote:
>
>     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 <denis.ietf@free.fr
>     <mailto:denis.ietf@free.fr>> wrote:
>
>         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/
>
>
>
>
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/