Re: [GNAP] Terminology

Denis <denis.ietf@free.fr> Tue, 11 August 2020 17:25 UTC

Return-Path: <denis.ietf@free.fr>
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 BD7183A084C for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 10:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 TyY5iOBN2zVS for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 10:25:12 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3477B3A0847 for <txauth@ietf.org>; Tue, 11 Aug 2020 10:25:11 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d06 with ME id EHR42300A2bcEcA03HR5eB; Tue, 11 Aug 2020 19:25:09 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 11 Aug 2020 19:25:09 +0200
X-ME-IP: 90.79.51.120
To: Mike Jones <Michael.Jones@microsoft.com>, Tom Jones <thomasclinganjones@gmail.com>, Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>, Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, Fabien Imbault <fabien.imbault@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>
References: <DM6PR00MB0684496FAFF843EF4286B0ECF5451@DM6PR00MB0684.namprd00.prod.outlook.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <63a40d80-e7b3-4016-d92c-f1889fe62dfe@free.fr>
Date: Tue, 11 Aug 2020 19:25:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <DM6PR00MB0684496FAFF843EF4286B0ECF5451@DM6PR00MB0684.namprd00.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------169998FF4A838E80D85F2C33"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/fYBWGnAbXHXnuqbiWzber9B_5Mo>
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: Tue, 11 Aug 2020 17:25:16 -0000

To all,

We are circling around. In order to progress about the terminology, I 
propose the following:

1° Adopt the ISO rule for a definition:

    The definition shall be written in such a form that it can replace
    the term in its context.
    It shall not start with an article (“the”, “a”) nor end with a full
    stop.
    A definition shall not take the form of, or contain, a requirement.

2° Propose at the same time a term AND its definition.

3° If you don't like a term or its definition proposed by someone else, 
this is fine ... but only as long as
you have a counter proposal for either the term and/or its definition. 
As an example, only stating that
" "client" can be confusing" would not be a valid proposal.

Terms and definitions are used in the context of RFCs issued by a WG and 
it is fine using terms
already used by other RFCs issued by another WG as long as we clearly 
define them.

Denis

> One of the things that people hated about OAuth was it invented new 
> terminology that wasn’t in common use.  But for better or for worse, 
> the terms Client, Authorization Server, and Protected Resource are now 
> widely understood.
>
> Let’s not make people similarly hate GNAP by inventing even more novel 
> terms, when existing terms will fit the bill.  Client wasn’t a perfect 
> choice but adding “Orchestrator” to the vocabulary menagerie would 
> definitely make things worse.
>
>                                          -- Mike
>
> *From:* TXAuth <txauth-bounces@ietf.org> *On Behalf Of *Tom Jones
> *Sent:* Tuesday, August 11, 2020 8:44 AM
> *To:* Dave Tonge <dave.tonge@moneyhub.com>
> *Cc:* Francis Pouatcha <fpo@adorsys.de>de>; Justin Richer 
> <jricher@mit.edu>du>; Dick Hardt <dick.hardt@gmail.com>om>; Benjamin Kaduk 
> <kaduk@mit.edu>du>; Fabien Imbault <fabien.imbault@gmail.com>om>; Denis 
> <denis.ietf@free.fr>fr>; txauth@ietf.org
> *Subject:* Re: [GNAP] Terminology
>
> the term "orchestator" does not match any use case i have.
>
> Let's be clear that there are four entities to a single transaction in 
> the real world sense of things. (and others that support the  
> transaction.)
>
> Then we can focus on the end point roles. I will focus on the data 
> privacy issues, API's have the same parties with different terminology.
>
> 1. the subject of the data to be transferred.
>
> 2. the user of a grant from the subject to act as delegate. (see 
> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the 
> user)
>
> 3. the site that has a repository of user data with legal obligations 
> to protect that data (the GDPR) (role resource server.)
>
> 4 the site that wants either access to the data, or some privacy 
> preserving statement about the existence and content of the data. 
> (role of client, vendor, PISP, etc.)
>
> 5. some sorts of facilitator sites for allowing access (roles like 
> authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been 
> left out of OAUTH for good reason.
>
> This is a note supporting the separation of roles from legal 
> entities.  BTW, I firmly believe that the legal entity also needs to 
> be ID'd by the transaction.
>
> Peace ..tom
>
> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <dave.tonge@moneyhub.com 
> <mailto:dave.tonge@moneyhub.com>> wrote:
>
>     Hi all
>
>     I agree that "client" can be confusing. I would be in support of
>     alternative terminology.
>
>     We can always have some wording that explains that an
>     "Orchestrator" in GNAP plays a similar role to "Client" in OAuth.
>
>     Dave
>
>     On Tue, 11 Aug 2020 at 07:52, Fabien Imbault
>     <fabien.imbault@gmail.com <mailto:fabien.imbault@gmail.com>> wrote:
>
>         Hi Francis,
>
>         I like your proposal, seems much more intuitive.
>
>         Fabien
>
>         Le mar. 11 août 2020 à 04:17, Francis Pouatcha <fpo@adorsys.de
>         <mailto:fpo@adorsys.de>> a écrit :
>
>             Hello Denis, Justin, Dick, Fabien,
>
>             In this post
>             (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/)
>             i suggested we use the word "Orchestrator" to designate
>             the piece of software that orchestrate interaction between
>             "Requestor" (a.k.a. User), AS and RS to obtain the
>             protected resource.
>
>             We are turning around the same topic. As soon as we go
>             beyond the original oAuth protocol, the word 'Client'
>             becomes confusing.
>
>             In the same response, I suggest we talk about "roles" and
>             not "entities".
>
>             Best regards.
>
>             /Francis
>
>             On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt
>             <dick.hardt@gmail.com <mailto:dick.hardt@gmail.com>> wrote:
>
>                 I still think that client was the right name in OAuth
>                 2, as the client wanted to do a client-server
>                 interaction, so the client used OAuth 2 to get an
>                 access token to interact with the "server".
>
>                 I do agree that it is not the best term in GNAP.
>                 Primarily because GNAP is a combination of the client
>                 from OAuth 2, and the relying party from OIDC.
>
>                 /Dick
>
>                 ᐧ
>
>                 On Thu, Aug 6, 2020 at 12:50 PM Justin Richer
>                 <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>
>                     On Aug 6, 2020, at 12:53 PM, Dick Hardt
>                     <dick.hardt@gmail.com
>                     <mailto: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
>
>                                             -- 
>                                             Txauth mailing list
>                                             Txauth@ietf.org
>                                             <mailto:Txauth@ietf.org>
>                                             https://www.ietf.org/mailman/listinfo/txauth
>
>                                         -- 
>                                         TXAuth mailing list
>                                         TXAuth@ietf.org
>                                         <mailto:TXAuth@ietf.org>
>                                         https://www.ietf.org/mailman/listinfo/txauth
>
>                                 -- 
>                                 TXAuth mailing list
>                                 TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>                                 https://www.ietf.org/mailman/listinfo/txauth
>
>                 -- 
>                 TXAuth mailing list
>                 TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>                 https://www.ietf.org/mailman/listinfo/txauth
>
>
>             -- 
>
>             Francis Pouatcha
>
>             Co-Founder and Technical Lead
>
>             adorsys GmbH & Co. KG
>
>             https://adorsys-platform.de/solutions/
>
>         -- 
>         TXAuth mailing list
>         TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>         https://www.ietf.org/mailman/listinfo/txauth
>
>     *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.**
>
>
>     -- 
>     TXAuth mailing list
>     TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/txauth
>