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

Francis Pouatcha <fpo@adorsys.de> Wed, 12 August 2020 02:14 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 D68B63A0E8E for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 19:14:55 -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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 (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 1iVTg0aWyFgI for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 19:14:54 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 BFCE83A0C3A for <txauth@ietf.org>; Tue, 11 Aug 2020 19:14:53 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id 184so503587wmb.0 for <txauth@ietf.org>; Tue, 11 Aug 2020 19:14:53 -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=4fteMTPTV0fxDuc/Iv5CXXlSLEa/GFEj0U06JNkAXlA=; b=PHeuZUj51Ct1eSG6vpujO1gTW7Y2jSrg3hkWdhjavSjL3+vxVS4/IY4ytBDv+g3dqN RZ6aYGteH/4RRLSHVT7oyeSPMAqzmyEgxUUKg2d8Q64aFpkUGYOGFCZKKedChvWOOOsu s/AhcVvnTTq4ETuThyMxFFDGIARrcA6VW+Bbg=
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=4fteMTPTV0fxDuc/Iv5CXXlSLEa/GFEj0U06JNkAXlA=; b=PfcZoe5COrlwcjvbP5YRuA0hD1nCh+VjQ/T90tUDfLOSA5tOSzj9puxVWY6vgyvXF3 wOOa+cB0MQ6XGQMHpDU+BIgD8Scdo+G1tDLHLNcd5SjCCWDR1uHuv2EJvdIvIfq9G9j/ Xk+OnfZk3XV167bHhBxr24iOtdDCY03J9CHcSEg8DBubz22GHcLZq/22GBDIqIvrIQ+K 4kYjpYDGt3PzJWVyZ6tKB4Mwyt1NchXTZ0yC5k8Sb0itfuoxV//LNxnBOSJuElQCYRsN NyXbkCqGIJYTZ4p9804Eg7NOqit8CzXyjl11NM0Nicoby7DXl9XFo0W2+INWYXjLKMf5 vYdQ==
X-Gm-Message-State: AOAM531mfe3sdBU2WCTVg0Ax/rypZsz/61vuoG8XFNyUDfmVriKkE+8e DeudzGpubEi6tGL+uYHbzf1jc96J8FuVKC8Nx6iQmw==
X-Google-Smtp-Source: ABdhPJwwt+TZB6L2b+2Dim/Vs+OxBIvVPSaZNipft9Qzqey08O2jf/5M8DHpEaogYGjlsLufOaWiQ96ExalHxEL09jg=
X-Received: by 2002:a7b:c3d4:: with SMTP id t20mr6198296wmj.8.1597198491964; Tue, 11 Aug 2020 19:14:51 -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> <CAD9ie-sZbxBKuLgC3Bu+yzJATOETdto=S83B6FOmC3gFJWz1jw@mail.gmail.com>
In-Reply-To: <CAD9ie-sZbxBKuLgC3Bu+yzJATOETdto=S83B6FOmC3gFJWz1jw@mail.gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Tue, 11 Aug 2020 22:14:41 -0400
Message-ID: <CAOW4vyOoBVihSc9FvDJyU49DfvYdeL1UfNVgPS6CfYOUKBSFzQ@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
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="000000000000bff46e05aca4c02a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/iMRioZp-kUrj7b1uSbKBTl9rrTQ>
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 02:14:56 -0000

Hello Dick,

I will use the university registration use case as an example to illustrate
steps (1) and (7).

+-----------+      +--------------+  +-----------+  +----+
 +---------------------+
| Requestor |      | Orchestrator |  | RS        |  | GS |  | Resource
Controller |
| is UNIV-1 |      |  is UNIV-1   |  | is UNIV-0 |  | or |  |         is
      |
|   Staff   |      | Registr. App |  | Server    |  | AS |  |       Student
     |
+-----------+      +--------------+  +-----------+  +----+
 +---------------------+
  |(1) RegisterStudent(StudentId)          |           |                |
  |---------------------->|                |           |                |
  |                       |(2) RequestRecordIntent(RecordType,StudentId,
  |                       |     OrchestratorId):AuthRequest[RecordType,
StudentId]
  |                       |<-------------->|           |                |
  |                       |                |           |                |
  |                       |(3) AuthZRequest(RecordType,StudentId
,OrchestratorId)
  |                       |--------------------------->|                |
  |                       |                |           |(4)
ConsentRequest(RecordType,
  |                       |                |           |
 OrchestratorId):Consent
  |                       |                |           |<-------------->|
  |                       |(5) AuthZ[RecordType,StudentId,OrchestratorId]
  |                       |<---------------------------|                |
  |                       |                |           |                |
  |                       |(2) RequestRecord(RecordType,StudentId
,OrchestratorId)
  |                       |     :RecordOf[StudentId]   |                |
  |                       |<-------------->|           |                |
  |(7) Registered         |                |           |                |
  |<----------------------|                |           |                |
  +                       +                +           +                +

Step (1) is the initial service request "RegisterStudent" sent by
the university staff to the University registration application.

Step (7) is the response to step (1), the notification of the university
staff that the registration was successful.

Best regards
/Francis


On Tue, Aug 11, 2020 at 7:38 PM Dick Hardt <dick.hardt@gmail.com> wrote:

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


-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/