Re: [GNAP] Terminology

Dick Hardt <dick.hardt@gmail.com> Tue, 11 August 2020 22:09 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 665CA3A0EF4 for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 15:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, 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 qQikxaARBxYO for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 15:09:39 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 303B03A0EB7 for <txauth@ietf.org>; Tue, 11 Aug 2020 15:09:32 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id t23so37852ljc.3 for <txauth@ietf.org>; Tue, 11 Aug 2020 15:09:32 -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=Oelk2jTKa9WSonaVzlqTrJRLBYujcpB3nHMmjXrgwYI=; b=Zsn4g/7YnBObIS0n4ZTfHkhQa/lfLziioDQofaIH2KE6Ql+HZ3Oz8bes6fgy6X6Mwu wDVdrdD24gyO+G20DpCoWdHteaSFJ376wiMYX8CuxJSTVCAK8wlPh6BvohTYR8gWCYko y3S3EmAUSsg1Cf/wUit8OmlKgAEB5U19WFcxLx8fq91nXsBu0HGxkmVovisNJjo/EIUW sxBBOHP/fdV5FhUcqoCcWgKxpMXN5O0KAvbqRzaQS2kM2kKpDz3MSHfZrdOyDGHy+Ety Yaa/5L7pnZC6VfeS4+0F966GMhtWpAWCbwmfBH1Jwl7jAi4FteQUEqt688J36x57SkL6 5XMg==
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=Oelk2jTKa9WSonaVzlqTrJRLBYujcpB3nHMmjXrgwYI=; b=pL4nBADGR/g86MJ1b+xE6WcMcZCzl15BHxwilyqkpSVEn631QE3k5ogJXtTMU6Bnm4 LyujL6DeT0mvZ8vepOCCwn3GuA9HTTp1LU/1bfNM+IgxQSMdRX7XdgwluIn6TWydn360 APQecgwxhJk3FJ9Iz1Xm+GSYSta18O7TTEGP2w3/zt7c5Dwh/M1p7kXriLCZ5VS8aCK5 NJHVWgdGxZjT6nLcM3FxX2SndoaYTtqhtFn+914eoK8oNvatnEXRbTiYH1OSVzEEBliF cn3nMUyE33/D1d7MPdHNT/Mv/NQroJrCVadMDi2pLeifdSJohk8MjMUFSSeDvJ+bQ+Ve wSQA==
X-Gm-Message-State: AOAM533lzKvBz/mCS2tmLB7yONiDf17Zhd2NSrvwLyWtQlZDVw8Qn4e5 f/4vqyT+oCad5tCvxYRmNN1VBsyycfKG5uB3OnM=
X-Google-Smtp-Source: ABdhPJxy313SynA5LKgOKm3HAc+uNKOv3P16oaoDhCm5Ka76CoSlL/utJZAqsjZpKy8I/CZ/1Fv7YNuXwFFGDsv9Dn0=
X-Received: by 2002:a2e:b0db:: with SMTP id g27mr4091372ljl.69.1597183770081; Tue, 11 Aug 2020 15:09:30 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR00MB0684496FAFF843EF4286B0ECF5451@DM6PR00MB0684.namprd00.prod.outlook.com> <CAD9ie-u7xbmDvszc4nhgL7PTi+q92wVXDhf5-UsqYWhkdfFf_w@mail.gmail.com> <AA0A1BCB-A128-4C45-B137-FCCB4ECC0B4A@mit.edu> <CAD9ie-ut3B1Hys-8w8FqQ6W+F017V5nZKmu7jyjWgP-PBGYwrg@mail.gmail.com> <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu>
In-Reply-To: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 11 Aug 2020 15:08:53 -0700
Message-ID: <CAD9ie-srbdXNQMpZQvLCEEsB00gHKuScq7RM9Cw56yS24+Hi2Q@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Mike Jones <Michael.Jones@microsoft.com>, Tom Jones <thomasclinganjones@gmail.com>, Dave Tonge <dave.tonge@moneyhub.com>, Francis Pouatcha <fpo@adorsys.de>, Benjamin Kaduk <kaduk@mit.edu>, Fabien Imbault <fabien.imbault@gmail.com>, Denis <denis.ietf@free.fr>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000041bfe105aca153bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/LhiEkLAzWMwB1VbCnlVuk3DWPZM>
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 22:09:52 -0000

A grant is whatever the client is asking from the server. Currently we have
access to resources and identity claims. It could contain anything else an
extension adds that a client may request from a server.

Given the definition of grant that I included, why is grant not the right
term to use for this?


On Tue, Aug 11, 2020 at 1:35 PM Justin Richer <jricher@mit.edu> wrote:

> I did not say the term “grant” was problematic, I said that your
> definition of it was problematic. Namely, the desire to lump in claims
> about the user into the definition of the “grant”.
>
>  — Justin
>
> On Aug 11, 2020, at 3:49 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> I agree that orchestrator may be a role in the protocol -- it is not a
> role in XYZ or XAuth today.
>
> Justin: would you explain why you think the term "grant" is problematic?
> It is in the WG name!
>
> The client is receiving more than access to resources from the GS, it is
> also receiving claims, so "client of the resource" is too limiting.
>
> Reading the definition of grant[1], it fits as a verb of what the GS is
> doing, and fits as a noun of what the GS provides to the client.
>
> A Grant Server is an Authorization Server in OAuth, and an OpenID Provider
> in OpenID Connect.
> The Grant Client is a Client in OAuth, and a Relying Party in OpenID
> Connect.
>
> Having new terms (GS and GC) in GNAP, separating the roles from OAuth and
> OpenID Connect.
> It is straightforward to know what a GC and GS do when you understand
> that a grant is a combination of resource access (from OAuth) and claims
> (from OpenID Connect).
>
> /Dick
>
> [1] https://www.dictionary.com/browse/grant
> verb (used with object)
> to bestow or confer, especially by a formal act:to grant a charter.
> to give or accord:to grant permission.
> to agree or accede to:to grant a request.
> to admit or concede; accept for the sake of argument:I grant that point.
> SEE MORE
> noun
> something granted, as a privilege or right, a sum of money, or a tract of
> land:Several major foundations made large grants to fund the research
> project.
> the act of granting.
>
>
> [1]
>
>
>
> On Tue, Aug 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
>
>> I agree that “orchestration” is separate from what the classical “client”
>> in OAuth is doing — but the term “orchestrator” fits with the “user agent”
>> concept that’s been brought up here before, so I’m inclined to believe it
>> can be a separate role from the client.
>>
>> I personally think that “grant client” is confusing as it is not a
>> “client of the grant” but rather a “client of the resource”.
>>
>> I also think it’s problematic to lump in user claims with a “grant” and
>> that’s just going to muddle everything.
>>
>>  — Justin
>>
>> On Aug 11, 2020, at 3:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>> I echo Mike's comments on preserving names when possible. The shift from
>> "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many.
>>
>> I also echo Tom's comments about separating Entities from Roles.
>>
>> Orchestration[1] in my opinion is not what the "client" is doing.
>>
>> Below is a stab at separating the entities and the roles
>>
>> /Dick
>>
>> *Tl;dr: *
>> - Client -> Grant Client
>> - added Relying Party, Claims Issuer, and Grant Server Operator as
>> entities
>>
>> *Roles* - parties to the protocol
>> Grant Client (GC), Grant Server (GS), Resource Server (RS)
>>
>> *Entities* - parties to a Trust Framework
>> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server Operator
>> (GSO), Resource Owner (RO)
>>
>> *Grant *- may contain claims and/or access to resources
>>
>> *#Protocol Roles*
>>
>> *Grant Client* (GC)
>> - used by User
>> - operated / provided by RP
>> - requests Grants from the GS
>> - access resources at an RS
>> - consumes Claims
>>
>> *Grant Server* (GS)
>> - operated by GSO
>> - may interact with the User
>> - may interact with the RO
>> - accepts grant requests from GCs
>> - issues grants to GCs
>> - may issue claims
>>
>> *Resource Server* (RS)
>> - manages access to resources for the RO
>> - provides access to resources for the GC
>> - accepts access granted by the GS
>>
>> *#Legal Entities*
>>
>> *User*
>> - uses Grant Client
>> - may interact with the Grant Server
>> - may also be a RO
>> - trusts RP, Issuer, GSO
>>
>> *Relying Party* (RP)
>> - provides Grant Client to the User.
>> - may trust Issuers, GSOs, and ROs
>>
>> *Claims Issuer* (Issuer)
>> - issues claims to RP
>> - may use GS or RS to issue claims
>>
>> *Grant Server Operator* (GSO)
>> - operates the GS
>> - trusted by User, RP, and RO
>> - may also be an Issuer
>>
>> *Resource Owne*r (RO)
>> - owns resources at the RS
>> - trusts GSO to control access to the resources
>> - may be same entity as the User
>> - may also be an Issuer
>>
>> [1] https://en.wikipedia.org/wiki/Orchestration_(computing)
>>
>> Orchestration (computing)
>> From Wikipedia, the free encyclopedia
>> Jump to navigation
>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#mw-head>Jump to
>> search
>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#searchInput>
>> In system administration
>> <https://en.wikipedia.org/wiki/System_administration>, *orchestration* is
>> the automated configuration
>> <https://en.wikipedia.org/wiki/Configuration_management>, coordination,
>> and management of computer systems and software
>> <https://en.wikipedia.org/wiki/Software_deployment>.[1]
>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-Erl-1>
>> A number of tools exist
>> <https://en.wikipedia.org/wiki/Category:Orchestration_software> for
>> automation of server configuration and management, including Ansible
>> <https://en.wikipedia.org/wiki/Ansible_(software)>, Puppet
>> <https://en.wikipedia.org/wiki/Puppet_(software)>, Salt
>> <https://en.wikipedia.org/wiki/Salt_(software)>, Terraform
>> <https://en.wikipedia.org/wiki/Terraform_(software)>,[2]
>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-2>
>>  and AWS CloudFormation
>> <https://en.wikipedia.org/wiki/AWS_CloudFormation>.[3]
>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-3>
>> Usage[edit
>> <https://en.wikipedia.org/w/index.php?title=Orchestration_(computing)&action=edit&section=1>
>> ]
>> Orchestration is often discussed in the context of service-oriented
>> architecture
>> <https://en.wikipedia.org/wiki/Service-oriented_architecture>,
>> virtualization <https://en.wikipedia.org/wiki/Platform_virtualization>,
>> provisioning <https://en.wikipedia.org/wiki/Provisioning>, converged
>> infrastructure <https://en.wikipedia.org/wiki/Converged_Infrastructure> and
>> dynamic datacenter <https://en.wikipedia.org/wiki/Datacenter> topics.
>> Orchestration in this sense is about aligning the business request with the
>> applications, data, and infrastructure.[4]
>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-4>
>> In the context of cloud computing
>> <https://en.wikipedia.org/wiki/Cloud_computing>, the main difference
>> between workflow automation
>> <https://en.wikipedia.org/wiki/Workflow_automation> and orchestration is
>> that workflows are processed and completed as processes within a single
>> domain for automation purposes, whereas orchestration includes a workflow
>> and provides a directed action towards larger goals and objectives.[1]
>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-Erl-1>
>> In this context, and with the overall aim to achieve specific goals and
>> objectives (described through quality of service
>> <https://en.wikipedia.org/wiki/Quality_of_service> parameters), for
>> example, meet application performance goals using minimized cost[5]
>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-sc2011workflow-5> and
>> maximize application performance within budget constraints.[6]
>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-ipdps2013scaling-6>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>>
>>> 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>
>>> 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>
>>> 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> 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> 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> 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
>>>
>>>
>>>
>>> --
>>> TXAuth mailing list
>>> 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
>>> 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
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>
>