Re: [GNAP] Terminology

Justin Richer <jricher@mit.edu> Thu, 06 August 2020 19:50 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 C21543A0E45 for <txauth@ietfa.amsl.com>; Thu, 6 Aug 2020 12:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.885
X-Spam-Level:
X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, 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, T_KAM_HTML_FONT_INVALID=0.01, 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 6l46VSpIfKCd for <txauth@ietfa.amsl.com>; Thu, 6 Aug 2020 12:50:23 -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 3E59C3A0E44 for <txauth@ietf.org>; Thu, 6 Aug 2020 12:50:22 -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 076JoIq4024860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Aug 2020 15:50:18 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <00EFDCE5-513D-449A-A1B6-BE1905E3D8A3@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8ECF6E3A-D656-40A8-834B-DFF506A25A51"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 6 Aug 2020 15:50:17 -0400
In-Reply-To: <CAD9ie-v75OPo45zNj6=2555qEDfQCOqNcF0N3rRD5HTw2b+sRA@mail.gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, Denis <denis.ietf@free.fr>, Benjamin Kaduk <kaduk@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
To: Dick Hardt <dick.hardt@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> <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> <CAM8feuQpekZMpbMLSJG3ALvWKEHkR6jBHgeGwQGSzQtVucUQ8w@mail.gmail.com> <CAD9ie-v75OPo45zNj6=2555qEDfQCOqNcF0N3rRD5HTw2b+sRA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/BA2BlHidOPyMVE1bOUH8KMU_chg>
Subject: Re: [GNAP] Terminology
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, 06 Aug 2020 19:50:26 -0000

On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
> 
> The term client in OAuth came from the computer science definition of client-server interaction.

This, I would argue, is exactly why it’s a bad label for something that’s distinctly more specific in this context, and I would love to see GNAP adopt a more specific label for the role that we traditionally called “client” in OAuth.

 — Justin

> 
> The client is getting an access token so it can call a server, specifically, a resource server (to differentiate it from the authorization server).
> 
> The confusion in my experience usually stems from people working with software that is acting in multiple roles. IE, the software that is acting as a client in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software the user is using -- although it may not be acting as a client in the oauth context.
> 
> 
> 
> ᐧ
> 
> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <fabien.imbault@gmail.com <mailto:fabien.imbault@gmail.com>> wrote:
> Hi, 
> 
> To me, client has always been a strange word in the context of OAuth, as it has a meaning well defined both in everyday life (this client is a good customer) and in computer science (client-server interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any teaching experience shows that it does make the concepts hard to grasp for a majority of (clever) people.
> 
> As for the RO, previous discussions suggested Resource Controller (RC) also, which may be a bit more specific than manager. 
> 
> Fabien 
> 
> On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> wrote:
> Justin and Dick,
> 
> [Was:  "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]
> 
> So let us attempt to define new terms:
> initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
> In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:
> Resource Owner (RO): entity capable of granting access to a protected resource
> I propose to replace it with Resource Manager (RM):
> Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
> Denis
> 
>> I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.
>> 
>> Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified. 
>> 
>> For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".
>> 
>> /Dick
>> ᐧ
>> 
>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>> I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.
>> 
>> GNAP can do something similar, in my opinion. But what we can’t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth 2 and its terminology. We don’t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It’s going to be a delicate balance!
>> 
>>  — Justin
>> 
>>> On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch <mailto:wparad@rhosys.ch>> wrote:
>>> 
>>> I think that is fundamentally part of the question:
>>> 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 we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.
>>> 
>>> Food for thought.
>>> - Warren
>>> 
>>> 
>>> Warren Parad
>>> Founder, CTO
>>> Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>.
>>> 
>>> 
>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu <mailto:kaduk@mit.edu>> wrote:
>>> 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
>>> 
>>> -- 
>>> Txauth mailing list
>>> Txauth@ietf.org <mailto:Txauth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>> -- 
>>> Txauth mailing list
>>> Txauth@ietf.org <mailto:Txauth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>> 
>> -- 
>> TXAuth mailing list
>> TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> -- 
> TXAuth mailing list
> TXAuth@ietf.org <mailto:TXAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>