Re: [GNAP] Terminology

Dick Hardt <dick.hardt@gmail.com> Thu, 06 August 2020 22:36 UTC

Return-Path: <dick.hardt@gmail.com>
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 483EA3A0A81 for <txauth@ietfa.amsl.com>; Thu, 6 Aug 2020 15:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 P2idRpwzztPc for <txauth@ietfa.amsl.com>; Thu, 6 Aug 2020 15:36:31 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAE43A0A47 for <txauth@ietf.org>; Thu, 6 Aug 2020 15:36:30 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id m15so26274654lfp.7 for <txauth@ietf.org>; Thu, 06 Aug 2020 15:36:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uM4rclI/x/NeFRbSSIr/K9GmRTFYiBjD0csyxExHR7M=; b=H5eHY4ra68kAxKFJQh7RRFR260ALak3aShG2lHAoGVcBAoJeTPYCBvycz6zD3M4D66 DO7fHRr51a/fdygyM8CzTH60vT2gh3LyLlkCu+4KpAycqDHUITzVQz6TIadCl8fDCtWw ID1aKbq1WFUj62ujRv1waLhsOa+cPz+3SBzC+4QuOWO8lkHxRoz9SEimIVJJ5XarwV+d 0/Vn+eshK0Me6NRCYTiJrGbA9Bf0EyE4mJjOU+CqyptaujVPgFs14Ng8xl2LPLcogXAb V+YlGj3q3lbLIrRYtcMZNKEZWP5XmtmSTgWZFagAuBr6Tdr+Kpf+j5rYdcmLPukLSodE 9cdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uM4rclI/x/NeFRbSSIr/K9GmRTFYiBjD0csyxExHR7M=; b=jAitHxPxvJnB0jShO+q3AY0NItP4ws5K79De+ZqdS+DhWg6h82dkgHteJyWdB81r9o vplyoAaPEAuIahhXuQP3TfFGdP7wcYAFqgWrL4OeVjK8xV7OZYmrcHQbnYYu/WIsb9Un 0B+12j4lnlPdkg6znllqwMvek3fjIlsSC2ZMq6AwV8dRVl9/eYuFGk1/0xlohDO1Bb2z ViuxX3ffh8EVniVUyHvqQWsutUaplJ9kpCF8vkH2U0eGcJhpgrpp+BOcQ02PfAlrXxC8 LpuNTkPare4y3Fj6QL6iOQMj9N1lMEHcM+gvqeAAywm772TCeLfeRFSfsGle5phit++D q39w==
X-Gm-Message-State: AOAM530/ceaAXm+1eODoy8gm9TvKEa8WoQPUswUZ06Gqi03ZvpgB7s1j phinbYKmXC8zu87GgUb2fyDNGnkl/BBiE1j9siE=
X-Google-Smtp-Source: ABdhPJx++A+zDIjgYjAyR3xMfdnDW5gye3e2aClCoWaXbYU42ahKSrdEHCjEEeRAJlQcNj2bnxfc8nnL1twLWCj1UYo=
X-Received: by 2002:ac2:4a9d:: with SMTP id l29mr4861645lfp.23.1596753388373; Thu, 06 Aug 2020 15:36:28 -0700 (PDT)
MIME-Version: 1.0
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> <00EFDCE5-513D-449A-A1B6-BE1905E3D8A3@mit.edu>
In-Reply-To: <00EFDCE5-513D-449A-A1B6-BE1905E3D8A3@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 6 Aug 2020 15:35:52 -0700
Message-ID: <CAD9ie-vzdoWVRq+QCf+KK+__JGaYc-q2nU8Yhd7zK-0CtJNLDw@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, Denis <denis.ietf@free.fr>, Benjamin Kaduk <kaduk@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008211a105ac3d1ef9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/nSl3y9-G3bMT_h6AgSD3OWf_Y7s>
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 22:36:34 -0000

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> wrote:

> 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>
> 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> 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> 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> 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> 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
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txauth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>
>>>> --
>>>> TXAuth mailing list
>>>> TXAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>> --
>>> TXAuth mailing list
>>> TXAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>