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

Justin Richer <jricher@mit.edu> Fri, 14 August 2020 14:28 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 53CD73A0C7C for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 07:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=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 mKJaV_t64LbZ for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 07:28:30 -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 29C833A0C5E for <txauth@ietf.org>; Fri, 14 Aug 2020 07:28:29 -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 07EESLSA002254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Aug 2020 10:28:22 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <305ADCDA-DB5F-47D3-9F8B-25D8E8E6C2CD@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_54F77929-EE5C-40DA-8430-654209820622"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Fri, 14 Aug 2020 10:28:21 -0400
In-Reply-To: <CAM8feuTno-e7qdzt8Td70UWWFUduAkntis9usu+VaAZHJWG48Q@mail.gmail.com>
Cc: Dave Tonge <dave.tonge@moneyhub.com>, Dick Hardt <dick.hardt@gmail.com>, Francis Pouatcha <fpo@adorsys.de>, Denis <denis.ietf@free.fr>, "txauth@ietf.org" <txauth@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
To: Fabien Imbault <fabien.imbault@gmail.com>
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> <CAM8feuS0K3OTmNY6fzYKOtZeh1_6r_+UhW3uBzT96agw56akRA@mail.gmail.com> <CAD9ie-t8DEZYMOn5Pvx0e6GCyoz7+s=wWk5Bz12=22KWjJ72Tw@mail.gmail.com> <CAP-T6TQ-nU3O5BUfK7yuh-OmaBGRWKEEYd6hzgqhH2FKknxk7A@mail.gmail.com> <CAM8feuTno-e7qdzt8Td70UWWFUduAkntis9usu+VaAZHJWG48Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/M_2TClaBxDKjuTHsHIVA9SVNXjc>
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: Fri, 14 Aug 2020 14:28:32 -0000

I think the roles are linked, but so are the roles of the AS and RS (since the RS needs to trust and understand what the AS issues, ultimately). But by talking about them as separate roles, we can talk about ways to connect them, much the way that separating the AS from the RS (which were both just the “server” in OAuth 1) let us talk about JWTs and token introspection as methods for connecting the two.

And the thing is, people are already deploying the token-issuing portions and the interactive portions separately. For example these all point towards that:

https://github.com/ietf-wg-gnap/general/wiki/Decomposed-Grant-Server <https://github.com/ietf-wg-gnap/general/wiki/Decomposed-Grant-Server>

https://github.com/ietf-wg-gnap/general/wiki/Three-Client-server-use-cases-built-along-%22Privacy-by-Design%22.-Contribution-from-Denis <https://github.com/ietf-wg-gnap/general/wiki/Three-Client-server-use-cases-built-along-%22Privacy-by-Design%22.-Contribution-from-Denis>

https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Servers-in-a-single-flow <https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Servers-in-a-single-flow>


Additionally, this is similar to how Google deploys OAuth 2 today, with the user interactive portion and the token-issuing portion in separate trust domains. We can label these parts separately without defining a single method of connecting them, and importantly without assuming they’ll be in the same box for someone’s deployment. 

 — Justin

> On Aug 14, 2020, at 2:29 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
> 
> Thanks, that's an important use case. Should add DID also. 
> 
> This raises additional questions related to claim aggregation though, in case you have contradictory information.
> 
> Le ven. 14 août 2020 à 03:39, Dave Tonge <dave.tonge@moneyhub.com <mailto:dave.tonge@moneyhub.com>> a écrit :
> > I agree with clearly separating the GS interaction with the Client from the interaction with the User. 
> 
> > I'm having a hard time viewing those as two different roles. They are two different interactions. Just as the client interaction with the AS is different from the client interaction with the GS.
> 
> I also struggle to see these as different roles - they seem to be fundamentally linked, 
> However what I think does need to be taken into consideration is that there may be multiple Grant Servers involved in a user flow (I've added a new use case to describe some of these flows: https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Servers-in-a-single-flow <https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Servers-in-a-single-flow>)
> 
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
>