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

Benjamin Kaduk <> Tue, 04 August 2020 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19DA83A1081 for <>; Tue, 4 Aug 2020 11:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xveQPajp5Fuc for <>; Tue, 4 Aug 2020 11:53:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 005BA3A109F for <>; Tue, 4 Aug 2020 11:53:20 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (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 <>
To: Denis <>
Cc: "" <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.