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

Fabien Imbault <fabien.imbault@gmail.com> Wed, 19 August 2020 10:31 UTC

Return-Path: <fabien.imbault@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 D8A113A120E for <txauth@ietfa.amsl.com>; Wed, 19 Aug 2020 03:31:25 -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 0ugyzZxg2VV6 for <txauth@ietfa.amsl.com>; Wed, 19 Aug 2020 03:31:23 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 D840D3A1751 for <txauth@ietf.org>; Wed, 19 Aug 2020 03:31:22 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id g19so24173854ioh.8 for <txauth@ietf.org>; Wed, 19 Aug 2020 03:31:22 -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=v7aHHa4zC/6TQl+/qhpGkC+L6aE4aeAEqHZeTz1Hkio=; b=taZmmO+r54aRmu/aY4w/xMRoo/Oe2j37f+TlRJWsO0EYHzd6FkLB4JK39ODf1GXXlf xS+FBEkhrBESyIDJNnpo6oWB1SPMxYRfcZWGC6TCovZ5udBtkDDy8BvghfBk9SP3cuIE I1UJR2MzNQ2TVdF4IjwFLDEWElbtnNB8zDXc5jAsYhikDQFe/u2K03q3X+1l6hG8a+Pj i0kYiqbmbxdIKfBidrIJaix4PS+5IPbyOEL4uNF1CknNazFRXg5GUuwnh1ZUDWRIxDYe 4DzGVI7O/xIDcsHGxxTictSMoiu0oit4dyP6xtEK/stxgDKckPOLf7K42FnUWKZDdq/n jyvA==
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=v7aHHa4zC/6TQl+/qhpGkC+L6aE4aeAEqHZeTz1Hkio=; b=ZxiBIaO6yvvbk0d87wxXCeeriA1/WXjoV4A44QPxJairL47z3dviHwvLa5eyeLjv7E iEnvMlyS7Sao+XEHazUUL/exBCdchN+BOO4Uo+pl6kKViZarm0eqUZIlpVYxUC54Ox39 BsmXQYsrYSwfGYnUTgdnluV7tNrSvQxPG7unGRJOQndUzwtd1TrSeKP7z43mxRFyupfH DtwVCTUjGaQzaHUDEzOjWbqSG63xNwAvcGbzlPns1fgBi+AGnNa7w02G83rtYPjxMGCK mHUsKITsW5PDsSqWehpnRWYM1/2mjtcGaR78eh4ChxtDpHZ7a3jaYoPNm7znnifzYuF3 sHpA==
X-Gm-Message-State: AOAM5321JapxJih8a4O4YBYiXr65QPPlS7vbk5uUXKVL0E9kNsNGpzY3 HkedGCWTm/ySrtoa5WWe7P3Zo17qkxNq4FPK56Q=
X-Google-Smtp-Source: ABdhPJyr0v/+35fsLQwijSxW0e76YdI/5mMBY2/KcNu6eprZpaPQ7rfXEcq8DVu1kADyazOtLZ8zWmynv0TBP4iY/So=
X-Received: by 2002:a6b:e70d:: with SMTP id b13mr19904894ioh.141.1597833080461; Wed, 19 Aug 2020 03:31:20 -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> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <CAD9ie-s5_tOZhE57tj1b+XaqDw+D43n_wStOPSmi7cioG2Z+gw@mail.gmail.com> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <CD0AE256-7868-4B00-9235-300CB55506BC@mit.edu> <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> <CAOW4vyNry6KW15jgkyEe=QAjgsPUYUgpzKOey1JADOFkmFQsNg@mail.gmail.com> <CAD9ie-uXEY_tneOuMRNjjicQkM9sMhjiT7+RqWvvXTEcnS3x+A@mail.gmail.com>
In-Reply-To: <CAD9ie-uXEY_tneOuMRNjjicQkM9sMhjiT7+RqWvvXTEcnS3x+A@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Wed, 19 Aug 2020 12:31:08 +0200
Message-ID: <CAM8feuQN4HTsoshsd7NfK_aZtn=KVVG0Mpeqj8B+GVavxSmD0g@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>, Denis <denis.ietf@free.fr>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="0000000000002bdf5105ad388102"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/D3amQmouhOpuhPKhz9GMj0bA9rM>
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, 19 Aug 2020 10:31:26 -0000

Just wondering if that might be a way to compose the generic
transaction/continuation pattern (XYZ style, layer 1) from a lower-level
GS-API (layer 0).
Fabien

On Thu, Aug 13, 2020 at 9:28 PM Dick Hardt <dick.hardt@gmail.com> wrote:

> Hi Francis
>
> I have come to a similar conclusion. I'll be posting my thoughts in a
> concrete proposal and am keen to hear how it fits into how your mental
> model.
>
> /Dick
> ᐧ
>
> On Thu, Aug 13, 2020 at 12:00 PM Francis Pouatcha <fpo=
> 40adorsys.de@dmarc.ietf.org> wrote:
>
>> Lots of mails, so I will summarize my opinion in this single mail:
>>
>> We are dealing with different levels of abstraction here, this is why we
>> are always falling back to wording battles.
>>
>> oAuth2/OIDC vs. GNAP
>> AS vs. GS/DS/IS
>> Entity vs. Roles
>> User (human) vs. Requestor
>> Client vs (Orchestrator/Requesting Party/Negotiator...)
>> front-channel & back-channel
>>
>> To direct the discussion, we have to agree on the level of abstraction at
>> which we want a certain discussion to take place.
>>
>> Abstraction Level-0: GNAP
>>
>> Level-0 deals with roles (participants) and messages (request/responses).
>> Level-0 does not consider entities (users) or the nature of any other
>> participants, neither Level-0 deals with the way a message is transported
>> (synchronous/asynchronous) or the type of interaction used to materialize
>> the message (front-channel, back-channel). The purpose of this abstraction
>> layer is to provide a common understanding of the core elements of the
>> protocol.
>>
>> Level-0 can still provide some basic definition of messages including
>> information schema as long as we are not limiting the protocol with
>> constraints from lower layers.
>>
>> Level-0 is ideal to address some fundamental privacy and confidentiality
>> matters that will be materialized in lower layers.
>>
>> Abstraction Level-1: OAuth2 / OIDC / [SSI/DiD/VC]
>> Instantiation of Level-0 for a constrained application space. This is why
>> we will meet the world Client, User, RO, AS, .... here roles defined in
>> Level-0 will be mapped to entities, interaction will be used to materialize
>> messages defined in Level-0.
>> The protocol mapping at this layer also takes into consideration that
>> some of those participants are human or only pieces of software, running on
>> the user device or on a server with consequences on the protocol design.
>>
>> Abstraction Level-2: Trust Frameworks like IAM / PSD2,FAPI / ....
>>
>> In Summary:
>> Level-0: Roles, Messages
>> Level-1: Entities, Interactions
>> ...
>>
>> And if it happens we want to define GNAP at Level-1 (instead of 0), let
>> declare it as such and limit the application space before we proceed with
>> further discussions.
>>
>> Best regards.
>> /Francis
>>
>>
>>
>>
>> On Thu, Aug 13, 2020 at 1:30 PM Denis <denis.ietf@free.fr> wrote:
>>
>>>  Justin,
>>>
>>> Your response does not address my point. I am talking of two different
>>> channels with the RS, i.e. not with the AS.
>>>
>>> Denis
>>>
>>> Denis, I want to focus on one point here:
>>>
>>> In OAuth 2.0, the user consent is performed by the AS using an authorize
>>> endpoint where the user consent is solicited and captured.
>>>
>>> Since a user, with no prior experience, shall first connect to a RS to
>>> perform an operation, the user consent shall be performed by the RS,
>>> instead of the AS. This means that we should define a "consent"
>>> endpoint at the RS.
>>>
>>>
>>> One of my goals with XYZ’s design was to be able to separate the
>>> interaction with the user from the web-based flows for the delegation
>>> protocol, and that aspect is enshrined in the GNAP charter as well.
>>>
>>> It points to the reality that there are two different aspects of the
>>> traditional AS that we might need to talk about separately now. One deals
>>> with delegation, issuing tokens, returning data directly to the client (not
>>> through a separate API, since that’s the RS), and other back-channel stuff.
>>> The other aspect deals with interacting with the user and/or resource
>>> owner.
>>>
>>> We already saw bits of this in OAuth 2: the AS is defined by the pair of
>>> the token endpoint and authorization endpoint, each filling the respective
>>> roles above. What if we formally separate these? Strawman names:
>>>
>>> Delegation Server (DS) - handles the back-channel stuff
>>>
>>> Interaction Server (IS) - handles the front-channel stuff
>>>
>>>
>>>  — Justin
>>>
>>>
>>> --
>>> TXAuth mailing list
>>> 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/
>> --
>> TXAuth mailing list
>> TXAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>