Re: [GNAP] Terminology

Fabien Imbault <fabien.imbault@gmail.com> Thu, 13 August 2020 09: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 D76813A0AC7 for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 02:49:51 -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 OX90cDtrnyHr for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 02:49:46 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 F36C23A0AD9 for <txauth@ietf.org>; Thu, 13 Aug 2020 02:49:45 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id u126so6569036iod.12 for <txauth@ietf.org>; Thu, 13 Aug 2020 02:49:45 -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=EdL1gDqF1rCajRYHGhQahXB/+4gw0kfH8HT5zZJalFI=; b=ijC/BqFRCxJDIrnHEYLJJvbxYcYSpT5AGg6/zevjZUYI8WrhtQpYZniG+HMEBSgtjr wWoh3RwimRBb1De+UCJ8e+R9HsrP6foLq1DcPACfzxf7VRfSXBGlzaap1ewuj6wqfdcC WA7n/Sp8p5TAKSjBrM9lI9Kp2x9xJ6bko+yTyTw7YLEpzek0g4N+6iqPgrzXKLrMV1+U a64b6956jKXaQfk57grj2PkcecPUXl33SUwdSVwsPjPB20+rUIt7fCFufatSM5I5665m mYrYVtpN/ST2mdTZ3776k7zwJYG18cCMaOEcqCG9gMNd5pO/ftkcVYyctI6heoD7Glvn 6wzA==
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=EdL1gDqF1rCajRYHGhQahXB/+4gw0kfH8HT5zZJalFI=; b=QWan8q1eH0aauMzecSqfJAWZh3HuKNDSPDIoYDQJkKy4vG4RgkzPfscR9xWP/xMKmx aIlrdjaixas+YaUJ1DMFb6ONckQxPZ12VhWRj5Um5NvDuAuOHZ05d54iyA/3t1n0AiCf DNvGhtmgfxoau9+jrZ4kjcDnV2iPIViwj3zjcN3qptEQWtPKj0DrATitmAcTXEBL74jQ gc2UMfxsVSiAMWAb+ASc/4XmXK3DNK8kcIKYYjaZKE1u/gL+zI/TfwR8fmIMyF2X9Wkc BEj74UcyqZnWsJMWAOwPCkPfuErQiJmw/DlR+PbAg+sClv5hlZcp1xlV1fe1FaKhsJdY JY4g==
X-Gm-Message-State: AOAM533yHisirGLNCvCgQ1R82Pn4CYi7GzU2awjFIVwejaRO/qaMSuBm 7QpuMd2YFPzqxfa7pdtTNMMqjnkKmdiPA6WDPpI=
X-Google-Smtp-Source: ABdhPJwUnEu7wPi3bZYJsA3zIJ9jHVJ+ZfydHTWpjRNysEfuxSmqVvXYRuFungaY8ugq4KafiQPFsAW/ag5xC3l+iBk=
X-Received: by 2002:a6b:e70d:: with SMTP id b13mr3995011ioh.141.1597312184831; Thu, 13 Aug 2020 02:49:44 -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> <CAD9ie-srbdXNQMpZQvLCEEsB00gHKuScq7RM9Cw56yS24+Hi2Q@mail.gmail.com> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <CAD9ie-scGz1s=q=g=GSD9gL3X3O3rHG0ukQVPewZ6dMw5dDeHw@mail.gmail.com> <CAM8feuRiT4wk827M_o=TEEW9FtZk3PaBR1AFr2seT5GJ+ZoLKw@mail.gmail.com> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu>
In-Reply-To: <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Thu, 13 Aug 2020 11:49:32 +0200
Message-ID: <CAM8feuSVVfccaZC80bnGNq9H2xwxH++5PCkZ-mTtVVPy3t=uCA@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Dick Hardt <dick.hardt@gmail.com>, 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>, Denis <denis.ietf@free.fr>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005f556905acbf3945"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/ruY3BHu5zHozd4GHkOrLjwTbyqY>
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, 13 Aug 2020 09:49:52 -0000

Thanks a lot.

Terminology is hard and so I'm thankful for anyone that submits a
definition or provides constructive criticism ;-)
I think we shouldn't try to be perfect from the start (and probably never
will be). What matters is that we gradually try to clarify what we mean
within our context, and as much as possible, but be careful not use a usual
term in a completely different way (changes to well accepted terms should
be limited to the extreme).

In that sense, starting from the dictionary is a good idea, as per Dick's
proposal.

Two of the verb definitions fit quite well to our objectives, without
change.
to give or accord -> fits well with the token generation (accord) and
dispatch (give)
to agree or accede to -> fits well with the consent phase
(the other 2 definitions are irrelevant to our scope)

The original definition of grant (as a noun) is already enabling some
extensibility ("*something* granted, as a privilege or right, a sum of
money, or a tract of land"). That could come handy!
- privilege: pretty much what we expect from an identity claim
- right: what we expect from an access token
- sum of money:similar to the
https://github.com/ietf-wg-gnap/general/wiki/Payments use case.
- tract of land: a bit more alien (
https://www.lawinsider.com/dictionary/tract-of-land), but maybe related to
the "Signing contracts" example of the previous use case? Unsure about this
one, I tentatively propose something in the definition that comes
afterwards.

Probably a rewording is necessary, but it seems to cover a large part of
what we are looking for.

So here's what I would propose as a starting point:

*GRANT (verb)*



*to give or accordExample: to grant permission.to agree or accede
toExample: to grant consent.*
*Note: in the GNAP protocol, the act of granting generally involves
automated processes (by computers) and human interactions through a web
browser. *

*GRANT (noun)*
*something granted, as a privilege or right, a sum of money or as the
outcome of an obligation or a promise*
*Example 1: digital access token to a protected resource.*
*Example 2: privilege derived from an identity claim.*
*Example 3: a sum of money granted by the customer to a service provider,
as the result of a payment flow initiated at the retail store or via
ecommerce.*
*Example 4: access right to open and drive a car, from a car sharing
company (by contract) or from a relative (by promise). *

*Note: in the GNAP protocol, a grant is negotiated between a <Client> and a
grant server and usually involves the processing and exchange of identity
claims and/or access tokens.*

<Client> = term to be changed

Any feedback welcome.


Le mer. 12 août 2020 à 19:29, Justin Richer <jricher@mit.edu> a écrit :

> Fabien,
>
> There have been a number of additional applications that are getting
> discussed. One concrete example is a payments system as written up here:
>
> https://github.com/ietf-wg-gnap/general/wiki/Payments
>
> There was also a discussion in the first BoF about a use case where the
> interaction with the AS isn’t to gather consent or “log in to the client”
> as is typical, but instead to gather additional information needed for the
> client to complete the request at the API. This was framed with an example
> of collecting credit card payment details, but I think the concept of “I
> need the current user to come to a web page for a bit” generalizes to a lot
> of different things. It’s still delegation, between the user and the
> client, but it’s not a “grant” unless you really look at it funny.
>
> There’s not a lot being “granted” here, in my view of things, and that’s a
> part of why I am in favor of having a more precise definition for the term
> “grant” instead of using it as a blanket to cover everything within the
> protocol.
>
>  — Justin
>
> On Aug 12, 2020, at 12:43 PM, Fabien Imbault <fabien.imbault@gmail.com>
> wrote:
>
> Hi Dick,
>
> Maybe to make that discussion more concrete, what else do you imagine
> could be exchanged (beyond resource & idclaims)? A few examples?
>
> Cheers
> Fabien
>
>
>
> On Wed, Aug 12, 2020 at 6:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
>> What is being granted is whatever is being negotiated between the Grant
>> Server and the Grant Client -> Which fits into the name of the WG, Grant
>> Negotiation and Authorization Protocol, allows us to have names that are
>> specific and precise for the roles (Grant Server and Grant Client rather
>> than Requesting Party), and is usable by an extension that wants to
>> negotiate some new thing between the two roles.
>>
>> I introduced the term "Grant" in XAuth to mean what the client requested,
>> and what the "server" provided, which included both resource access and
>> identity claims. You are narrowly defining grant to ONLY mean "access to
>> something". Sometimes I think you just want to disagree with me. :)
>>
>> I'd be interested in hearing from others!
>>
>>
>>
>> In the current drafts, that is resource access and identity claims.
>>
>> ᐧ
>>
>> On Wed, Aug 12, 2020 at 8:58 AM Justin Richer <jricher@mit.edu> wrote:
>>
>>> What is being granted is access to something. This makes sense in terms
>>> of rights bound to an access token, but I would argue it makes less sense
>>> for things returned directly.
>>>
>>> Since you and I also disagree on whether returning things directly is an
>>> important distinction (even though both the XAuth and XYZ proposals make
>>> this distinction), it doesn’t surprise me that you’d want to extend the
>>> notion of “grant” to include anything and everything in the request and
>>> response.
>>>
>>> I am arguing for it being more specific and precise.
>>>
>>>  — Justin
>>>
>>> On Aug 11, 2020, at 6:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>
>>> 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>gt;; Dick Hardt <dick.hardt@gmail.com>om>; Benjamin Kaduk <
>>>>>> kaduk@mit.edu>gt;; Fabien Imbault <fabien.imbault@gmail.com>om>; Denis <
>>>>>> denis.ietf@free.fr>gt;; 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>