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

Benjamin Kaduk <kaduk@mit.edu> Tue, 04 August 2020 18:53 UTC

Return-Path: <kaduk@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 19DA83A1081 for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 11:53:23 -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, RCVD_IN_DNSWL_BLOCKED=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 xveQPajp5Fuc for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 11:53:21 -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 005BA3A109F for <txauth@ietf.org>; Tue, 4 Aug 2020 11:53:20 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 074IrDT3004981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Aug 2020 14:53:15 -0400
Date: Tue, 4 Aug 2020 11:53:13 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Denis <denis.ietf@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Message-ID: <20200804185313.GT92412@kduck.mit.edu>
References: <c5f40413-93b8-2e8c-0a3e-14a07cd27ad0@free.fr> <ECF217AE-1D67-4EAE-AE51-531F6EE6E222@mit.edu> <583aedda-ae41-1f3e-6623-671f2197614c@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/uDEaXIa1tLTsb53T9TVqkkOkglM>
Subject: Re: [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, 04 Aug 2020 18:53:23 -0000

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
> 
> Since you replied in parallel, I will make a response similar to the one 
> I sent to Dick.
> 
> > Hi Denis,
> >
> > I think there’s still a problem with the terminology in use here. What 
> > you describe as RS2, which might in fact be an RS unto itself, is a 
> > “Client” in OAuth parlance because it is /a client of RS1/. What you 
> > call a “client” has no analogue in the OAuth world, but it is not at 
> > all the same as an OAuth client. I appreciate your mapping of the 
> > entities below, but it makes it difficult to hold a discussion if we 
> > aren’t using the same terms.
> >
> > The good news is that this isn’t OAuth, and as a new WG we can define 
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn’t just re-use existing terms with new definitions, 
> > but we’ve got a chance to be more precise with how we define things.
> 
> In the ISO context, each document must define its own terminology. The 
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as 
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben