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 >
- [Txauth] Revisiting the photo sharing example (a … Denis
- Re: [Txauth] Revisiting the photo sharing example… Dick Hardt
- Re: [Txauth] Revisiting the photo sharing example… Justin Richer
- Re: [Txauth] Revisiting the photo sharing example… Tom Jones
- Re: [Txauth] Revisiting the photo sharing example… Denis
- Re: [Txauth] Revisiting the photo sharing example… Denis
- Re: [Txauth] Revisiting the photo sharing example… Justin Richer
- Re: [Txauth] Revisiting the photo sharing example… Dick Hardt
- Re: [Txauth] Revisiting the photo sharing example… Dick Hardt
- Re: [Txauth] Revisiting the photo sharing example… Benjamin Kaduk
- Re: [Txauth] Revisiting the photo sharing example… Warren Parad
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault
- Re: [GNAP] Revisiting the photo sharing example (… Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] Revisiting the photo sharing example (… Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- [GNAP] Terminology Denis
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Francis Pouatcha
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] Terminology Dave Tonge
- Re: [GNAP] Terminology Tom Jones
- Re: [GNAP] Terminology Mike Jones
- Re: [GNAP] Terminology Denis
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Francis Pouatcha
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] Terminology Dave Tonge
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] Terminology Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Tom Jones
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Tom Jones
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dave Tonge
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault
- Re: [GNAP] Terminology Denis
- [GNAP] User consent Denis
- [GNAP] User consent Denis
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] Terminology - into Github Issues Francis Pouatcha
- Re: [GNAP] Terminology - into Github Issues Denis
- Re: [GNAP] User consent Francis Pouatcha
- Re: [GNAP] User consent Tom Jones
- Re: [GNAP] User consent Denis
- Re: [GNAP] User consent Denis
- Re: [GNAP] User consent Francis Pouatcha
- Re: [GNAP] Terminology Tom Jones
- Re: [GNAP] Terminology - into Github Issues Fabien Imbault
- Re: [GNAP] Terminology - into Github Issues Warren Parad
- Re: [GNAP] User consent Dick Hardt
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] User consent Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault