Re: [GNAP] Terminology

Fabien Imbault <fabien.imbault@gmail.com> Thu, 06 August 2020 11:49 UTC

Return-Path: <fabien.imbault@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 D09583A0B41 for <txauth@ietfa.amsl.com>; Thu, 6 Aug 2020 04:49:05 -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 VW09clTqM0f1 for <txauth@ietfa.amsl.com>; Thu, 6 Aug 2020 04:49:03 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 5483A3A0A5F for <txauth@ietf.org>; Thu, 6 Aug 2020 04:49:03 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id a5so33984948ioa.13 for <txauth@ietf.org>; Thu, 06 Aug 2020 04:49:03 -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=zVEHwad+HSEyGurgeo/pSvBE7+xuGvFUaXkqdL7SDB0=; b=iCoBSmQwahOebV5cXKriRl6b5WauNVrXDfCMRK4zHnxtWLG609Py18GYO98yvBRi7H CBtsdL1PrsApFB9Zkz7N1fgt+NNn3iSxy/BZuUsyW9tHnSHlIzZst+DE344xVjv0Ud9r II+Myd6d+G2a/gG1+fBf5BWbX89Tf4WXrB/v3oEXGhHgxei0figmVB3jGa/h1y2yrdNb oXFLGOOJWrtgsGqR4w7jq64aoeK+m4koq5N0BYGY4Uvqvm5U9Q4N93mPfFHH13HYzMFT eOx6B9ld6mUg9mtrCyWmk8dpSeCw9myX8Uk9ipKzvvbSkIXDR38gy8IZZEaSNi9f65N/ asrQ==
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=zVEHwad+HSEyGurgeo/pSvBE7+xuGvFUaXkqdL7SDB0=; b=tvXG1vkDEwRg+M16XAgnAebrtscOhL/gFtm26kPeurpykrgukCb5i+Mb7NnPsOpHg1 a30LXzUwr9jNkvZ31w5j1QxyuJCLjmBfjBXDbZEbQ6q1tz3o/kwjQT8NdlhXjdb+dyhl KwkRNa4vhucDxmX5Fe4+MssKgKonolzuYG+X52Ekki9/k58TQ6ug0ua2DoC0dRfWYnRg DWWstz2lrObJe2J9Jckt/29LI3XdDo1pZbPiM8vdN7zh8G/0fPpWsFo0bck6vKkDJHsK 2G8O0ZqEHgWMRJwcAsReV2YAt8RE1Wcdgd0m9uHEndbL16Cg9dOBYX6ACcy0Imt7JcPq So7Q==
X-Gm-Message-State: AOAM532ux/0YjMudzWn1p63K6+h9uifVsOF3E3DmrbFMogC1l3E6s492 0JBOjH9E81FLdJitlwI2bN8/bl9Kx6RfF+LJ7BA=
X-Google-Smtp-Source: ABdhPJz6nFQ/Yr81/Gk+caUXm6Y751OpMAYbcryIBaIcA0bZRPHiN1YSwWeWNGIyKd5wfApJtpkJEIPKZabitFpPL7c=
X-Received: by 2002:a5d:8041:: with SMTP id b1mr9332639ior.74.1596714542574; Thu, 06 Aug 2020 04:49:02 -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>
In-Reply-To: <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Thu, 6 Aug 2020 13:48:51 +0200
Message-ID: <CAM8feuQpekZMpbMLSJG3ALvWKEHkR6jBHgeGwQGSzQtVucUQ8w@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Dick Hardt <dick.hardt@gmail.com>, Justin Richer <jricher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001e2f6c05ac3413ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/5uumqvIT0u-qZC9DUGQZS-5MB9w>
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 11:49:06 -0000

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
>