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

Francis Pouatcha <fpo@adorsys.de> Thu, 16 July 2020 03:28 UTC

Return-Path: <fpo@adorsys.de>
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 4185E3A0B39 for <txauth@ietfa.amsl.com>; Wed, 15 Jul 2020 20:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
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 CdpDL7WSr_CQ for <txauth@ietfa.amsl.com>; Wed, 15 Jul 2020 20:28:21 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2360B3A0B33 for <txauth@ietf.org>; Wed, 15 Jul 2020 20:28:20 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id r12so5291926wrj.13 for <txauth@ietf.org>; Wed, 15 Jul 2020 20:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2Bm9meF3dnM+lH5YVM74RKs0uOCUGea19ooSIkKaTvM=; b=QZRn/RtGEhZ9NE2+RCH8Q3nzDMaQ8+XLTNPIx3AQ8A7NONCLoGSQnidzUUI4TcMyVF 4bm8xeZ10lA7WaIVUEdTPgDnv3rcIC+Bkq1qQ1hRILb2zKzzR5sw7XKtPKZ2ndv9oxdT ZEeZlYeN39N5akLjCNCEqoshKwszNGOs+Z+GY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2Bm9meF3dnM+lH5YVM74RKs0uOCUGea19ooSIkKaTvM=; b=jz8TljWV8Y41dFPc7vwnI6tM1ho5+2DuQvP1BfZI7l8g9sdzb2ejxn9gVWBBTnskM3 TGmqShBegcU3dFCtDDhNaEtHlruYie21xCI2G1PXdQA1khDsGnj5kcqoFbaTcnBs9K6J Wmcjx7d7Zrd6yAZ/G2Yp/qbcQDY0lwLD56mLoRKUjMlQEetaRP79+nqOc9f/XpbueXfl c3vWdXvUcEpZIAtQ1nN0YM1rIUIdQbAeBrBgYh5AyyaDTSSiw4jNx28nej+X9hDOKa8F gdzx7ddQVNJyNz1fbM5eDMASEyIIBzEhB9pkD6HsGE++FUqL4fhNfAW+nQ8l5P9R5QaN szWg==
X-Gm-Message-State: AOAM531+N+FxcRg9MJBBS9Nd/lGbbYby+z9bPUTWQ06LlRTeDQbRq9+D s1Y/yk8/LtIG1IJoY8l/dkhmyRLz7gS31xaGytS7Pw==
X-Google-Smtp-Source: ABdhPJzCiq4tYw6+8PVs0GFSHnEjcODEoSX9/BOwxpqK26aaIoYV93d+x2wAtHWo1Xgy2wKcD/Bm7Ze0acB74C41Ix4=
X-Received: by 2002:adf:91e1:: with SMTP id 88mr2742120wri.89.1594870099470; Wed, 15 Jul 2020 20:28:19 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAD9ie-tou5mTnWVguNygj-D6xUdTRjqvxi-+jhC6NbDFY8ZVJQ@mail.gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Wed, 15 Jul 2020 23:28:08 -0400
Message-ID: <CAOW4vyM0LycEf8q1T4jF=1g8aFyeLw1b4z9emNKWOG=+4iGgzw@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>, txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000be006f05aa86a11c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/fG9Bge8dUGreiByQckz-mY7ImTY>
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 03:28:24 -0000

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/