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

Dick Hardt <dick.hardt@gmail.com> Tue, 11 August 2020 23:38 UTC

Return-Path: <dick.hardt@gmail.com>
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 48A153A0D5D for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 16:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6C_tvfddmcxd for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 16:38:12 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 60E523A0DF6 for <txauth@ietf.org>; Tue, 11 Aug 2020 16:38:12 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id s9so189254lfs.4 for <txauth@ietf.org>; Tue, 11 Aug 2020 16:38:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8TTN9YNBJ0oqd+rcayvS0m1YtI4Ye4rJVX/Y3cyNIcg=; b=apfgtfn+By+1kZrRlNwtM8hyGoTsBp2Vl2Q1zLcCKQM53SwiS5KBvbK32tAzHCY+IX t3645FPnU5EnoAGHuYM2f51/dj8NGqHrA6tsT3a+2FgjWy1GVIz5Fe5jn49rJ7hZYwxa vZluKRvz10OoOAubrGl+ZMhah6koGlKV2JctTaVD6t0AyOtEzCySSP5uNHz4Q3MP99xQ pX7Bj4NKnzoWtqfSmEzWUl6rztQXCvfNPIbjmypCro84NVIYTPUQCQLuTiua98gpPFbW GhuRVZzXwQTOVCz1SSP2PDwqaQ3w0dL5+mQn8slx3hTbTzMcuj0bWJbzA4XjUpwyOHIK 4W4Q==
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=8TTN9YNBJ0oqd+rcayvS0m1YtI4Ye4rJVX/Y3cyNIcg=; b=f53TeyjzZ5wf7ufWipSSbDfpvmTWUfC2hhAb4DtYnVws940vTZvdKg0hTmO7vsP4MG X+MPXp/K2meLLD8Pp3ZLmtqpLvuhMVCXqfhoAze8e3kl+FRWrmZG9rtFrYBeQmErXM4y rT7yG3vIq4KRJde3pSC0pHx703gQdu8PHKkdru4y1Ls9+YZyV6OYZwvqWmDO9NfrObgG 7I2DYVjBaIKnUjcdssDVpuUH/zGAJkh0wLoZW9bFmjYddB2htF+M8e+YTIuQdfcYy7go Y6uqMUL3i5cN2ETET10/UHK3hD2qLpQ9oQlMvOTwMIkkVGVq2ltrkllsUnNkmT7aEiuU cuxA==
X-Gm-Message-State: AOAM532ZeLz6Ye1t/ekVJe9fUMIbHzPcsd6hZjGJjz7Vdq8IqrnYShUT cHkbBxJajIDDkU81HLxvyaJkVdcp+NVBosY/Kts=
X-Google-Smtp-Source: ABdhPJz2CtxHi70n0LAFrX9cflNTZmPzUOwjcfHlaAmIH/LDEgwT1dWO1LKcVMSi5oPq7N7ExJe/RA5sEOgthV9bJZ4=
X-Received: by 2002:a19:70c:: with SMTP id 12mr4278146lfh.207.1597189090381; Tue, 11 Aug 2020 16:38:10 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAOW4vyOrXstAvc3eKbsUh+gOPT-79nevR8nT5FyKTe+aAQ1pSw@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 11 Aug 2020 16:37:34 -0700
Message-ID: <CAD9ie-sZbxBKuLgC3Bu+yzJATOETdto=S83B6FOmC3gFJWz1jw@mail.gmail.com>
To: Francis Pouatcha <fpo@adorsys.de>
Cc: Justin Richer <jricher@mit.edu>, Denis <denis.ietf@free.fr>, Benjamin Kaduk <kaduk@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005f11eb05aca290ad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/PLMKI0dcguCuUo_kpwJ7LKJaSys>
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: Tue, 11 Aug 2020 23:38:14 -0000

Hi Francis, responses inline ...

On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de> wrote:

> Hello Dick,
>
> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <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. 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.


> 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.

> ᐧ