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

Justin Richer <jricher@mit.edu> Thu, 13 August 2020 18:01 UTC

Return-Path: <jricher@mit.edu>
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 1A0703A0FF4 for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 11:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 YA5xnusWmD7q for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 11:01:16 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665653A0FDF for <txauth@ietf.org>; Thu, 13 Aug 2020 11:01:14 -0700 (PDT)
Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07DI1BGw026286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 14:01:11 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <B4BBB603-148A-47A8-B3E3-377CAEA1306F@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D8818BF3-ACBB-49E5-803B-059A546E2146"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Thu, 13 Aug 2020 14:01:11 -0400
In-Reply-To: <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
To: Denis <denis.ietf@free.fr>
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>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/hg1juoIlK5jUyU0rUu8_NO4BOkU>
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: Thu, 13 Aug 2020 18:01:18 -0000

So what I’m saying is that what you’re defining as part of the RS was (in Oauth) defined as a function of the AS. As such, I contend that it needs to be its own separate functional role, neither AS nor RS.

That way it could be fulfilled by an entity either closely tied to the AS or closely tied to the RS, as appropriate. It would give us more flexibility to talk about the patterns.

 — Justin

> On Aug 13, 2020, at 1:29 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
>> 
>