Re: [GNAP] Terminology

[Fabien Imbault <[e-mail]>]

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
>>>>>
>>>>>
>>>>
>>>
>>