Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Denis <denis.ietf@free.fr> Wed, 12 August 2020 14:14 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 F35123A12B6 for <txauth@ietfa.amsl.com>; Wed, 12 Aug 2020 07:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.632
X-Spam-Level:
X-Spam-Status: No, score=-1.632 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.212, NICE_REPLY_A=-0.949, 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 X6GAkYY5YGYo for <txauth@ietfa.amsl.com>; Wed, 12 Aug 2020 07:14:16 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6118E3A12A9 for <txauth@ietf.org>; Wed, 12 Aug 2020 07:14:15 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d31 with ME id EeED230012bcEcA03eEDcu; Wed, 12 Aug 2020 16:14:13 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 12 Aug 2020 16:14:13 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt <dick.hardt@gmail.com>, Francis Pouatcha <fpo@adorsys.de>
Cc: Justin Richer <jricher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
References: <c5f40413-93b8-2e8c-0a3e-14a07cd27ad0@free.fr> <ECF217AE-1D67-4EAE-AE51-531F6EE6E222@mit.edu> <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <CAJot-L2hykst2vFxcwLn_auDMMaw7psVwsKFHKhQp9DA49ydWg@mail.gmail.com> <A4DC7B4E-FD34-454F-9396-B971CF5D57A4@mit.edu> <CAD9ie-tKEp+PV3F4p84Zbu7Kd1dQutawnzHybt8cmg-XniLYLQ@mail.gmail.com> <CAOW4vyN4ifCXmk1XAyGK4cEfY1jTp6+AWOL-uNjEpVcp0Ku0UQ@mail.gmail.com> <CAD9ie-ugjNevqKAPWFjKqGMMpCvX6yyC=M4bs9naenJf-k9uqg@mail.gmail.com> <CAOW4vyOrXstAvc3eKbsUh+gOPT-79nevR8nT5FyKTe+aAQ1pSw@mail.gmail.com> <CAD9ie-sZbxBKuLgC3Bu+yzJATOETdto=S83B6FOmC3gFJWz1jw@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr>
Date: Wed, 12 Aug 2020 16:14:10 +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: <CAD9ie-sZbxBKuLgC3Bu+yzJATOETdto=S83B6FOmC3gFJWz1jw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------55A4BFE1C6E2ADCF0DBEA293"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/baNWE3ahnYRmIwTqCYge8H4h5m0>
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)
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: Wed, 12 Aug 2020 14:14:18 -0000

Hi Dick,

> Hi Francis, responses inline ...
>
> On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de 
> <mailto:fpo@adorsys.de>> wrote:
>
>     Hello Dick,
>
>     On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com
>     <mailto:dick.hardt@gmail.com>> wrote:
>
>         Hi Francis
>
>         The user is an entity, not a role in the protocol in how I am
>         defining roles, so steps (1) and (7) are confusing to me on
>         what is happening.
>
>     "Requestor" is the role (*was* User). So the UML participant
>     refers to the role "Requestor"
>
>
> I still don't understand what is happening in (1) and (7)
>
>
>
>         I also think that (2) could be an extension to GNAP, rather
>         than part of the core protocol.
>
>     If you make it an extension, you hide. It shall rather be an
>     optional, integral part of the protocol.
>
>
> Most deployments today accomplish (2) by the developer reading RS 
> documentation. I'm in favor of showing that step in an abstract diagram.

[Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag 
förstår inte svenska. Jeg forstår ikke norsk.

One of the goals is for any Client to access any RS without the need to 
read any documentation.

> But it is not clear to me what the requirements for (2), and they may 
> vary radically across use cases, so putting it in the core document 
> seems to be getting ahead of ourselves.

[Denis] I can only reinsist on earlier explanations given about the 
Client-server use cases built along "Privacy by Design" since they are 
fundamental.

    Taking into consideration both the "data minimization" principle and
    the "user participation" principle when a user first authenticates
    to a RS leads to the following:

    1) When accessing a RS for the first time, the user should be
    informed of the authentication means proposed by the RS. The user
    should be able to use a dialog box
    where some choices are presented by the RS. The user should be able
    to locally make his own choices and to indicate his consent to its
    Client.

    2) When a user chooses to perform one operation on a RS, the RS
    should limit the data to be collected from the user to only what is
    strictly necessary
    to perform that operation. That data consists of specific types of
    attributes that need to be guaranteed by one or more ASs. The user
    should be able
    to use a dialog box where some ASs choices are proposed by the RS.
    The user should be able to locally make his own choices and to indicate
    his consent to its Client.

    It is important to notice that the choices that will be proposed to
    a user may depend upon previous personal information voluntarily
    released by that user.
    This means that the choices proposed by the RS may be tailored for
    the user. Furthermore, the proposed choices may only be disclosed to
    already authenticated users.

Denis

>     In some open banking designs,
>     - the "Orchestrator/Negotiator/Client" will not know the AS to
>     talk to unless the call (2).
>
>
> Have you put these use cases in the wiki?
>
>     - the request (2) might result in an exemption, meaning no need
>     for further authorization, allowing to skip (3, 4, 5) and even (6).
>
>
> Agreed.
>
> ᐧ