Re: [GNAP] Terminology

[Fabien Imbault <[e-mail]>]

Thanks Dick. Assertions about the Grant Client could be cool ;-)

I think it's great that you list the terms you use in the spec, in section
1.5.

Fabien

On Sun, Aug 16, 2020 at 10:39 PM Dick Hardt <[e-mail]> wrote:

> Sorry Fabien, I had started this email and had not sent it.
>
> If we are successful, other ISO may build extensions on GNAP, just as
> OpenId Connect was built on top. Hopefully we will have created the right
> extension points so that it is straightforward. Here are some examples of
> other things that could be granted (I don't expect these to be worked on in
> this WG, or at least not anytime soon):
>
> - A grant of "digital money" from the Grant Server to the Grant Client.
> The GS is granting the funds to the GC with the User's authorization. This
> is not the same as authorizing a payment per the example in the wiki.
>
> - An assertion about the Grant Client made by the Grant Server,
> potentially with the User's authorization. This assertion could allow the
> GC to prove something about itself to a separate entity, or even a separate
> GS.
>
> /Dick
>
>
> On Wed, Aug 12, 2020 at 9:43 AM Fabien Imbault <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>>> 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 <[e-mail]> 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 <
>>>>>> [e-mail]> 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 <[e-mail]> *On Behalf Of *Tom Jones
>>>>>>> *Sent:* Tuesday, August 11, 2020 8:44 AM
>>>>>>> *To:* Dave Tonge <[e-mail]>
>>>>>>> *Cc:* Francis Pouatcha <[e-mail]>; Justin Richer <
>>>>>>> [e-mail]>; Dick Hardt <[e-mail]>; Benjamin Kaduk
>>>>>>> <[e-mail]>; Fabien Imbault <[e-mail]>; Denis <
>>>>>>> [e-mail]>; [e-mail]
>>>>>>> *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 <[e-mail]>
>>>>>>> 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 <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>> Hi Francis,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I like your proposal, seems much more intuitive.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fabien
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le mar. 11 août 2020 à 04:17, Francis Pouatcha <[e-mail]> 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 <[e-mail]>
>>>>>>> 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 <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt <[e-mail]>
>>>>>>> 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 <
>>>>>>> [e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>>>>> 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 <[e-mail]> 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 <[e-mail]> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>> --
>>>>>>> Txauth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> TXAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> TXAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> TXAuth mailing list
>>>>>>> [e-mail]
>>>>>>> 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
>>>>>>> [e-mail]
>>>>>>> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>