Subject: Re: [GNAP] Terminology

From: Mike Jones <[email-masked]>
Date: Tue, 11 Aug 2020 16:33:21 +0000

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 <[email-masked]> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <[email-masked]>
Cc: Francis Pouatcha <[email-masked]>; Justin Richer <[email-masked]>; Dick Hardt <[email-masked]>; Benjamin Kaduk <[email-masked]>; Fabien Imbault <[email-masked]>; Denis <[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Francis,

I like your proposal, seems much more intuitive.

Fabien

Le mar. 11 août 2020 à 04:17, Francis Pouatcha <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
On Aug 6, 2020, at 12:53 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]
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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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/. 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Denis <[email-masked]>
Date: Tue, 11 Aug 2020 19:25:02 +0200

To all,

We are circling around. In order to progress about the terminology, I 
propose the following:

1° Adopt the ISO rule for a definition:

    The definition shall be written in such a form that it can replace
    the term in its context.
    It shall not start with an article (“the”, “a”) nor end with a full
    stop.
    A definition shall not take the form of, or contain, a requirement.

2° Propose at the same time a term AND its definition.

3° If you don't like a term or its definition proposed by someone else, 
this is fine ... but only as long as
you have a counter proposal for either the term and/or its definition. 
As an example, only stating that
" "client" can be confusing" would not be a valid proposal.

Terms and definitions are used in the context of RFCs issued by a WG and 
it is fine using terms
already used by other RFCs issued by another WG as long as we clearly 
define them.

Denis

> 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 <[email-masked]> *On Behalf Of *Tom Jones
> *Sent:* Tuesday, August 11, 2020 8:44 AM
> *To:* Dave Tonge <[email-masked]>
> *Cc:* Francis Pouatcha <[email-masked]>; Justin Richer 
> <[email-masked]>; Dick Hardt <[email-masked]>; Benjamin Kaduk 
> <[email-masked]>; Fabien Imbault <[email-masked]>; Denis 
> <[email-masked]>; [email-masked]
> *Subject:* Re: [GNAP] Terminology
>
> 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.
>
> 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
>
>     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
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Francis,
>
>             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.
>
>             On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt
>             <[email-masked] <mailto:[email-masked]>> 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
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>                     On Aug 6, 2020, at 12:53 PM, Dick Hardt
>                     <[email-masked]
>                     <mailto:[email-masked]>> 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
>                         <[email-masked]
>                         <mailto:[email-masked]>> 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
>                             <[email-masked]
>                             <mailto:[email-masked]>> wrote:
>
>                                 Justin and Dick,
>
>                                 [Was:  "Revisiting the photo sharing
>                                 example (a driving use case for the
>                                 creation of OAuth)"]
>
>                                     *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
>
>                                     *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 <[email-masked]
>                                     <mailto:[email-masked]>> 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
>                                             <[email-masked]
>                                             <mailto:[email-masked]>>
>                                             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
>                                             <[email-masked]
>                                             <mailto:[email-masked]>> 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
>                                                 [email-masked]
>                                                 <mailto:[email-masked]>
>                                 [email-masked] <mailto:[email-masked]>
>                 [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     *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
>     [email-masked] <mailto:[email-masked]>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 11 Aug 2020 12:25:16 -0700

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 <[email-masked]>
wrote:

> 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.
>
>
>
> *Cc:* Francis Pouatcha <[email-masked]>; Justin Richer <[email-masked]>;
> Dick Hardt <[email-masked]>; Benjamin Kaduk <[email-masked]>; Fabien
> Imbault <[email-masked]>; Denis <[email-masked]>;
> [email-masked]
> 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.
>
> 3. the site that has a repository of user data with legal obligations to
> protect that data (the GDPR) (role resource server.)
>
> preserving statement about the existence and content of the data. (role of
> client, vendor, PISP, etc.)
>
> 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 <[email-masked]>
> wrote:
>
> Hi all
>
>
>
> 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 <[email-masked]>
> wrote:
>
> Hi Francis,
>
>
>
> Le mar. 11 août 2020 à 04:17, Francis Pouatcha <[email-masked]> a écrit :
>
> 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.
>
>
>
> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <[email-masked]> 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 <[email-masked]> wrote:
>
> On Aug 6, 2020, at 12:53 PM, Dick Hardt <[email-masked]> wrote:
>
>
>
> 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 <[email-masked]>
> 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 <[email-masked]> wrote:
>
> Justin and Dick,
>
>
>
> *initiating application (IA)*: application by means of which a user
> initiates interactions with RS(s) and AS(s)
>
> *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 <[email-masked]> 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 <[email-masked]> wrote:
>
>
>
> 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 <[email-masked]> wrote:
>
> Hi Denis,
>
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> *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,
> 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
> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Tue, 11 Aug 2020 15:31:12 -0400

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 <[email-masked]> 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.
> 
> Tl;dr: 
> Roles - parties to the protocol
> 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
> Grant Server (GS)
> Resource Server (RS)
> #Legal Entities
> User
> Relying Party (RP)
> Claims Issuer (Issuer)
> Grant Server Operator (GSO)
> - operates the GS
> Resource Owner (RO)
> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) <https://en.wikipedia.org/wiki/Orchestration_(computing)>
> 
>  <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 <[email-masked] <mailto:[email-masked]>> wrote:
> From: TXAuth <[email-masked] <mailto:[email-masked]>> On Behalf Of Tom Jones
> To: Dave Tonge <[email-masked] <mailto:[email-masked]>>
> Cc: Francis Pouatcha <[email-masked] <mailto:[email-masked]>>; Justin Richer <[email-masked] <mailto:[email-masked]>>; Dick Hardt <[email-masked] <mailto:[email-masked]>>; Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>; Fabien Imbault <[email-masked] <mailto:[email-masked]>>; Denis <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> 2. the user of a grant from the subject to act as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation <https://wiki.idesg.org/wiki/index.php/Delegation> for how to enable the user)
> 
> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi all
> 
>  
> 
> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Francis,
> 
>  
> 
> Le mar. 11 août 2020 à 04:17, Francis Pouatcha <[email-masked] <mailto:[email-masked]>> a écrit :
> 
> In this post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/ <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. 
> 
>  
> 
> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Aug 6, 2020, at 12:53 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
> 
> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi, 
> 
>  
> 
> On Thu, Aug 6, 2020 at 1:00 PM Denis <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Justin and Dick,
> 
>  
> 
> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Aug 4, 2020, at 3:32 PM, Warren Parad <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Denis,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>  
> 
> -- 
> TXAuth mailing list
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>  
> 
> -- 
> TXAuth mailing list
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>  
> 
> -- 
> TXAuth mailing list
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
>  
> 
> --
> 
> Francis Pouatcha
> 
> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>
> -- 
> TXAuth mailing list
> https://www.ietf.org/mailman/listinfo/txauth <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. 
> 
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 11 Aug 2020 12:49:08 -0700

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 <[email-masked]> 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”.
>
> search
> <https://en.wikipedia.org/wiki/Orchestration_(computing)#searchInput>
> In system administration
> <https://en.wikipedia.org/wiki/Configuration_management>, coordination,
> and management of computer systems and software
> architecture <https://en.wikipedia.org/wiki/Service-oriented_architecture>
> , virtualization <https://en.wikipedia.org/wiki/Platform_virtualization>,
> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-sc2011workflow-5> and
>> Dick Hardt <[email-masked]>; Benjamin Kaduk <[email-masked]>;
>> Fabien Imbault <[email-masked]>; Denis <[email-masked]>;
>> [email-masked]
>> the real world sense of things. (and others that support the  transaction.)
>>
>> We are turning around the same topic. As soon as we go beyond the
>> original oAuth protocol, the word 'Client' becomes confusing.
>>
>>
>>
>> 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
>>
>> ᐧ
>>
>>
>>
>> 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.
>>
>>
>>
>> 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”.
>>
>>
>>

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 11 Aug 2020 16:31:10 -0400

In GNAP the "Grant Client" is orchestrating/negotiating a grant on behalf
of the Requestor. He is not the "Client" of the "Grant". The real client is
the Requestor.

We can assign this client the role of a "Negotiator" (if the word
"Orchestrator" does not fit).

Best regards
/Francis

On Tue, Aug 11, 2020 at 3:49 PM Dick Hardt <[email-masked]> 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!
>
>> I personally think that “grant client” is confusing as it is not a
>> “client of the grant” but rather a “client of the resource”.
>>
>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-2>
>>  and AWS CloudFormation
>> <https://en.wikipedia.org/wiki/AWS_CloudFormation>.[3]
>> architecture
>> <https://en.wikipedia.org/wiki/Service-oriented_architecture>,
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> 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

---

From: Justin Richer <[email-masked]>
Date: Tue, 11 Aug 2020 16:35:25 -0400

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 <[email-masked]> 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 <https://www.dictionary.com/browse/grant>
> verb (used with object)
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 11, 2020, at 3:25 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 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) athttps://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. 
>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 11 Aug 2020 15:08:53 -0700

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 <[email-masked]> 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
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 12 Aug 2020 11:57:55 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 11, 2020, at 3:49 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 12 Aug 2020 09:40:00 -0700

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 <[email-masked]> 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.
>
> 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.
>
>>> 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.
>>>
>>> <https://en.wikipedia.org/wiki/Workflow_automation> and orchestration
>>> is that workflows are processed and completed as processes within a single
>>>> 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
>>>> 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.
>>>>
>>>>
>>>>
>>>> Technology Limited which is authorised and regulated by the Financial
>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 12 Aug 2020 18:43:31 +0200

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 <[email-masked]> 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.
>>
>>> 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]
>>>
>>>
>>>
>>>> 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.
>>>>
>>>> <https://en.wikipedia.org/wiki/Configuration_management>,
>>>> coordination, and management of computer systems and software
>>>> virtualization <https://en.wikipedia.org/wiki/Platform_virtualization>
>>>> , provisioning <https://en.wikipedia.org/wiki/Provisioning>, converged
>>>>> *Cc:* Francis Pouatcha <[email-masked]>; Justin Richer <
>>>>> [email-masked]>; Dick Hardt <[email-masked]>; Benjamin Kaduk <
>>>>> [email-masked]>; Fabien Imbault <[email-masked]>; Denis <
>>>>> [email-masked]>; [email-masked]
>>>>> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable
>>>>> the user)
>>>>>
>>>>> entities.  BTW, I firmly believe that the legal entity also needs to be
>>>>> ID'd by the transaction.
>>>>>
>>>>> Peace ..tom
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> We can always have some wording that explains that an "Orchestrator"
>>>>> in GNAP plays a similar role to "Client" in OAuth.
>>>>>
>>>>>
>>>>>
>>>>> Dave
>>>>>
>>>>>
>>>>>
>>>>> 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 4:49 AM Fabien Imbault <
>>>>> [email-masked]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 12 Aug 2020 12:56:55 -0400

I would disagree with this definition regardless of who proposed it. Please, do not make this personal. It isn’t for me.

 — Justin

> On Aug 12, 2020, at 12:40 PM, Dick Hardt <[email-masked]> 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. :)
> 
> On Wed, Aug 12, 2020 at 8:58 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 11, 2020, at 6:08 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 12 Aug 2020 18:59:42 +0200

Hi,

I agree with that process.

Just as an additional reference (more related to identity),
https://canada-ca.github.io/PCTF-CCP/PCTF.html demonstrates I think the
importance of the terminology. In that case, they bring many useful
definitions (appendix A). By the way, for them, client is "The intended
recipient for a service output. External clients are generally persons
(Canadian citizens, permanent residents, etc.) and businesses (public and
private sector organizations). Internal clients are generally employees and
contractors."

Another example, less obvious: instead of authentication which is a very
overloaded term, you end up with verification and validation for identity
and credential (appendix D).

Then of course one needs to find the right mix between reinventing the
wheel (and the risk of making it hard to get into) and being specific
enough.

Fabien

On Tue, Aug 11, 2020 at 7:25 PM Denis <[email-masked]> wrote:

> The definition shall be written in such a form that it can replace the
> term in its context.
> It shall not start with an article (“the”, “a”) nor end with a full stop.
> you have a counter proposal for either the term and/or its definition. As
> an example, only stating that
> *From:* TXAuth <[email-masked]> <[email-masked]> *On
> Behalf Of *Tom Jones
> *To:* Dave Tonge <[email-masked]> <[email-masked]>
> *Cc:* Francis Pouatcha <[email-masked]> <[email-masked]>; Justin Richer
> <[email-masked]> <[email-masked]>; Dick Hardt <[email-masked]>
> <[email-masked]>; Benjamin Kaduk <[email-masked]> <[email-masked]>;
> Fabien Imbault <[email-masked]> <[email-masked]>;
> Denis <[email-masked]> <[email-masked]>; [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Wed, 12 Aug 2020 13:29:43 -0400

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 <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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 13 Aug 2020 11:49:32 +0200

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 <[email-masked]> 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
>
> Maybe to make that discussion more concrete, what else do you imagine
> could be exchanged (beyond resource & idclaims)? A few examples?
>
> Cheers
> Fabien
>
>
>
>>>> 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.
>>>>
>>>>> I also think it’s problematic to lump in user claims with a “grant”
>>>>> and that’s just going to muddle everything.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> infrastructure
>>>>> <https://en.wikipedia.org/wiki/Converged_Infrastructure> and dynamic
>>>>> datacenter <https://en.wikipedia.org/wiki/Datacenter> topics.
>>>>> In this context, and with the overall aim to achieve specific goals
>>>>> and objectives (described through quality of service
>>>>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <
>>>>> [email-masked]> wrote:
>>>>>
>>>>>> 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
>>>>>> 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.)
>>>>>>
>>>>>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault <
>>>>>> 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".
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> ᐧ
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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

---

From: Dave Tonge <[email-masked]>
Date: Thu, 13 Aug 2020 14:58:55 +0200

I would be against using "grant" as both a verb and a noun and stick purely
with one or the other. (In the charter the only use of "grant" is in the
verb: "granted").

Using it as both a verb and a noun will be confusing and less accessible.

I think it will be confusing to say "The Grant Server issues a grant to the
Grant Client representing access that has been granted"

Whether the access takes place via a token being returned and used at a
resource server, or "claims" that are directly returned from the "Grant
Server" I think should be largely irrelevant when it comes to the naming of
the roles.

In almost all use cases that I have seen the "Grant Server" is making a
policy based decision "to grant" access to requested resource(s). To me,
that is the fundamental operation happening. I think nearly all use cases
can be applied to that, e.g. the GS grants access to
 - identity attributes for the end user
 - verify an identity attribute (e.g. that user is over 18)
 - all users photos at resource server X
 - a single photo with id 12345 at resource server Y
 - resource of type X at any resource server that trusts the Grant Server
 - call a payment API with specific properties (e.g. amount < 5)
 - call a file storage API
 - call a "contract signing" API with specific properties (e.g. contract
hash of xxx,)

While "client" is problematic, it does now have wide spread usage, so
perhaps we are stuck with it.
However I agree with Justin and think "Grant Client" makes things more
confusing.

What is wrong with keeping "Client" and "Authorization Server"?

Dave

-- 

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.

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 13 Aug 2020 15:48:48 +0200

Hi,

Nothing inherently wrong with Client/AS, which has worked for years in the
context of OAuth2. The question is to know whether we can build the new
protocol with the same concepts and deal with their known limitations, or
if we're better off with more adapted concepts less prone to
misunderstandings.

Verb vs Noun:
Problem is that the grant (noun) can only be understood if there is a
grant(verb), i.e. some action that grants something.
The grant (noun) definition directly derives from the verb : "something
granted ..."

I personally have no issue even with the fairly convoluted "The Grant
Server issues a grant to the Grant Client representing access that has been
granted" (except perhaps from the word Client, but that's a different
issue).
By the way, grant is nothing new, it's used extensively in OAuth2 as "grant
types" (whatever that means).

Dick summarized well the reasons why he uses GS instead of AS :
1) "grant" is in the working group name (a weaker reason, but still has
been approved). Question: would our reasoning if the protocol ended up
being called OAuth3?
2) grant = larger in scope than AS (not only authorization), as it at least
includes idclaims + other use cases like payment (?) - no consensus, see
difference in appreciation between Justin and Dick

As for "Client", if most people think it is problematic, it seems a good
reason to change if we find a better alternative.
Quoting Dick again: "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." and later "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."

So far there's no consensus however, recent tries: Initiating Application
(Denis), Orchestrator (Francis).

Cheers
Fabien

On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <[email-masked]> wrote:

> I would be against using "grant" as both a verb and a noun and stick
> purely with one or the other. (In the charter the only use of "grant" is in
> the verb: "granted").
>
> I think it will be confusing to say "The Grant Server issues a grant to
> the Grant Client representing access that has been granted"
>
> Financial Services Register (FRN 809360) at 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.
>

---

From: Denis <[email-masked]>
Date: Thu, 13 Aug 2020 15:55:17 +0200

Fabien,

IMHO, nothing is wrong with keeping "Client" since it has a wide spread 
usage
... but only as long as we can agree on a short and a clear definition 
for it.

I can provide the beginning of such a definition: " application ..."

If someone could go a little bit further, this would help. :-)

A similar argumentation for GS.  It could be used but only as long as we 
can agree on a short and a clear definition for it.
Any proposal ?

Denis

> Hi,
>
> Nothing inherently wrong with Client/AS, which has worked for years in 
> the context of OAuth2. The question is to know whether we can build 
> the new protocol with the same concepts and deal with their known 
> limitations, or if we're better off with more adapted concepts less 
> prone to misunderstandings.
>
> Verb vs Noun:
> The grant (noun) definition directly derives from the verb : 
> "something granted ..."
>
> Server issues a grant to the Grant Client representing access that has 
> been granted" (except perhaps from the word Client, but that's a 
> different issue).
> By the way, grant is nothing new, it's used extensively in OAuth2 as 
> "grant types" (whatever that means).
>
> 1) "grant" is in the working group name (a weaker reason, but still 
> has been approved). Question: would our reasoning if the protocol 
> ended up being called OAuth3?
> 2) grant = larger in scope than AS (not only authorization), as it at 
> least includes idclaims + other use cases like payment (?) - no 
> consensus, see difference in appreciation between Justin and Dick
>
> As for "Client", if most people think it is problematic, it seems a 
> good reason to change if we find a better alternative.
> 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." and 
> later "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."
>
> So far there's no consensus however, recent tries: Initiating 
> Application (Denis), Orchestrator (Francis).
>
> Cheers
> Fabien
>
>
>
>
> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I would be against using "grant" as both a verb and a noun and
>     stick purely with one or the other. (In the charter the only use
>     of "grant" is in the verb: "granted").
>
>     I think it will be confusing to say "The Grant Server issues a
>     grant to the Grant Client representing access that has been granted"
>
>     Whether the access takes place via a token being returned and used
>     at a resource server, or "claims" that are directly returned from
>     the "Grant Server" I think should be largely irrelevant when it
>     comes to the naming of the roles.
>
>     In almost all use cases that I have seen the "Grant Server" is
>     making a policy based decision "to grant" access to requested
>     resource(s). To me, that is the fundamental operation happening. I
>     think nearly all use cases can be applied to that, e.g. the GS
>     grants access to
>      - call a "contract signing" API with specific properties (e.g.
>     contract hash of xxx,)
>     While "client" is problematic, it does now have wide spread usage,
>     so perhaps we are stuck with it.
>     However I agree with Justin and think "Grant Client" makes things
>     more confusing.
>
>     Moneyhub Enterprise is a trading style of Moneyhub Financial
>     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.
>
>     Moneyhub Financial Technology Limited or of any other group company.
>
>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 13 Aug 2020 16:59:36 +0200

An attempt.

*<Client> = application that requests access to Resource Servers (RS)
through a Grant Server (GS). *
Examples: a web server, a browser-based app, a mobile app, an IoT device.

*GS = computing service that manages the grant lifecycle to a <Client> on
behalf of a Resource Controler (RC).*
Note : for privacy reasons, the GS may be issuing grants without knowledge
of which resources are requested.

*RS = computing service that grants access only if its Resource Controler
(RC) consents.*
Note : the consent may involve a human interaction or may be automated
based on access control policies.

*RC = entity which is controlling the access to a protected resource. *
Note : a RC may be manually operated by a human or delegated to a machine,
partially or completely.

*Consent = the process of asking a RC to accept or decline based on a grant
request presentation, resulting in either a “yes” or “no” consent decision.*

Fabien

On Thu, Aug 13, 2020 at 3:55 PM Denis <[email-masked]> wrote:

> ... but only as long as we can agree on a short and a clear definition for
> it.
>
> least includes idclaims + other use cases like payment (?) - no consensus,
> see difference in appreciation between Justin and Dick
>
> people view clients as being the software the user is using -- although
> it may not be acting as a client in the oauth context." and later "I do
> agree that it is not the best term in GNAP. Primarily because GNAP is a

---

From: Denis <[email-masked]>
Date: Fri, 14 Aug 2020 12:02:35 +0200

Hi Fabien,

Thank you for your inputs, a ball is finally rolling.

> An attempt.

    I would add upfront: User =  human person

> /<Client> = application that requests access to Resource Servers (RS) 
> through a Grant Server (GS). /

    A few explanations: "through" does not sound appropriate since it
    could be interpreted as the GS being necessarilly placed between the
    Client and the RS.
                                           In addition, more than one GS
    may be necessary.

    My proposal: /<Client> = application that requests access to
    Resource Servers (RS) ///on behalf of a User /by using one or more
    Grant Servers (GS) /
    /Examples: a web server, a browser-based app, a mobile app./

> /GS = computing service that manages the grant lifecycle to a <Client> 
> on behalf of a Resource Controler (RC)./
> Note : for privacy reasons, the GS may be issuing grants without 
> knowledge of which resources are requested.

    I dislike "/on behalf of a Resource Controler (RC)/". The GS may be
    fully ignorant of the existence of the RSs and hence of the RCs.
    In addition, "/grant life cycle/" is undefined./
    /

    My proposal: //GS = /server issuing access tokens to a Client after
    successfully authenticating the User/
    /Note 1: for privacy reasons, the GS may be issuing access tokens
    without the knowledge of which resources are requested.
    Note 2: a GS is able to disclose to a User the User attributes that
    it manages.
    /

> /RS = computing service that grants access only if its Resource 
> Controler (RC) consents./

    I dislike "/its Resource Controler (RC) consents" /because it may
    let think that a human person always needs to consent.

    My proposal: /R//S = server hosting protected resources, capable of
    accepting and responding to protected resource requests
                                       when access tokens are being used/

> /RC = entity which is controlling the access to a protected resource. /
> Note : a RC may be manually operated by a human or delegated to a 
> machine, partially or completely.

    A RC is not an entity but a function. I would also place the machine
    case first.

    My proposal: /RC = function tightly coupled with a RS which controls
    the accesses to a protected resource
    /                        Note : the function may be operated either
    by a machine or by a human person or by some combination of both.

> /Consent = the process of asking a RC to accept or decline based on a 
> grant request presentation, resulting in either a “yes” or “no” 
> consent decision./

    I would instead speak of the "User Consent". The User Consent is a
    set of choices among a proposed set of choices. It is not simply a
    "yes" or "no" consent decision.

    My proposal: /User Consent = ability for a User, after being
    informed, of choosing to release or not to a RS some attributes
    contained in one or more access tokens/

Denis

> Fabien
>
> On Thu, Aug 13, 2020 at 3:55 PM Denis <[email-masked] 
>     IMHO, nothing is wrong with keeping "Client" since it has a wide
>     spread usage
>     ... but only as long as we can agree on a short and a clear
>     definition for it.
>
>     A similar argumentation for GS. It could be used but only as long
>     as we can agree on a short and a clear definition for it.
>     Any proposal ?
>
>     Denis
>
>>     Hi,
>>
>>     Nothing inherently wrong with Client/AS, which has worked for
>>     years in the context of OAuth2. The question is to know whether
>>     we can build the new protocol with the same concepts and deal
>>     with their known limitations, or if we're better off with more
>>     adapted concepts less prone to misunderstandings.
>>
>>     Verb vs Noun:
>>     Problem is that the grant (noun) can only be understood if there
>>     is a grant(verb), i.e. some action that grants something.
>>     I personally have no issue even with the fairly convoluted "The
>>     Grant Server issues a grant to the Grant Client representing
>>     access that has been granted" (except perhaps from the word
>>     Client, but that's a different issue).
>>     By the way, grant is nothing new, it's used extensively in OAuth2
>>     as "grant types" (whatever that means).
>>
>>     1) "grant" is in the working group name (a weaker reason, but
>>     still has been approved). Question: would our reasoning if the
>>     protocol ended up being called OAuth3?
>>     2) grant = larger in scope than AS (not only authorization), as
>>     it at least includes idclaims + other use cases like payment (?)
>>     - no consensus, see difference in appreciation between Justin and
>>     Dick
>>
>>     As for "Client", if most people think it is problematic, it seems
>>     a good reason to change if we find a better alternative.
>>     Quoting Dick again: "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." and later "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."
>>
>>     On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         I would be against using "grant" as both a verb and a noun
>>         and stick purely with one or the other. (In the charter the
>>         only use of "grant" is in the verb: "granted").
>>
>>         I think it will be confusing to say "The Grant Server issues
>>         a grant to the Grant Client representing access that has been
>>         granted"
>>
>>         Whether the access takes place via a token being returned and
>>         used at a resource server, or "claims" that are directly
>>         returned from the "Grant Server" I think should be largely
>>         irrelevant when it comes to the naming of the roles.
>>
>>         In almost all use cases that I have seen the "Grant Server"
>>         is making a policy based decision "to grant" access to
>>         requested resource(s). To me, that is the fundamental
>>         operation happening. I think nearly all use cases can be
>>         applied to that, e.g. the GS grants access to
>>          - call a "contract signing" API with specific properties
>>         (e.g. contract hash of xxx,)
>>         While "client" is problematic, it does now have wide spread
>>         usage, so perhaps we are stuck with it.
>>         However I agree with Justin and think "Grant Client" makes
>>         things more confusing.
>>
>>         Financial Conduct Authority ("FCA"). Moneyhub Financial
>>         Technology is entered on the Financial Services Register (FRN
>>         809360) at 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

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 14 Aug 2020 14:23:14 +0200

Hi Denis,

Thanks for your feedback.
Comments inline (marked with FI).

Fabien

On Fri, Aug 14, 2020 at 12:02 PM Denis <[email-masked]> wrote:

> FI : then end-user is clearer if you want to indicate specifically a human
user. One can also create system users.

> A few explanations: "through" does not sound appropriate since it could be
> interpreted as the GS being necessarilly placed between the Client and the
> RS.
>                                       In addition, more than one GS may be
> necessary.
>
> My proposal:  *<Client> = application that requests access to Resource
> Servers (RS) **on behalf of a User by using one or more Grant Servers
> (GS) *
> *Examples: a web server, a browser-based app, a mobile app.*
>
> FI: agreed.

> I dislike "*on behalf of a Resource Controler (RC)*". The GS may be fully
> ignorant of the existence of the RSs and hence of the RCs.
> In addition, "*grant life cycle*" is undefined.
>
> My proposal:  *GS = server issuing access tokens to a Client after
> successfully authenticating the User*
>
>
> *Note 1: for privacy reasons, the GS may be issuing access tokens without
> the knowledge of which resources are requested. Note 2: a GS is able to
> disclose to a User the User attributes that it manages.  *
>
> FI: I find the new definition less clear. It's not because you don't know
which RS is called that we shouldn't say the decision is made by the RC.
"grant life cycle" is indeed currently undefined, what i had in mind is
basically the grant flow from the GNAP protocol, possibly also including
revocation etc.
Not sure why Note 2 is important to put here.

> I dislike "*its Resource Controler (RC) consents" *because it may let
> think that a human person always needs to consent.
>
> My proposal: *R*
> *S = server hosting protected resources, capable of accepting and
> responding to protected resource requests
> when access tokens are being used*
>
> FI : that is why I suggested a note to make sure it is correctly
understood. I'm not sure the proposed alternative is clearer.

> A RC is not an entity but a function. I would also place the machine case
> first.
>
> My proposal:
> *RC = function tightly coupled with a RS which controls the accesses to a
> protected resource *                        Note : the function may be
> operated either by a machine or by a human person or by some combination of
> both.
>
> FI : your proposition on the note makes it much better. On the main
definition, I'm not sure what you mean by function, as a result I'm not
sure a reader would understand. Why do you need to say "tightly coupled?"

> *Consent = the process of asking a RC to accept or decline based on a
> grant request presentation, resulting in either a “yes” or “no” consent
> decision.*
>
> I would instead speak of the "User Consent". The User Consent is a set of
> choices among a proposed set of choices. It is not simply a "yes" or "no"
> consent decision.
>
> My proposal: *User Consent = ability for a User, after being informed, of
> choosing to release or not to a RS some attributes contained in one or more
> access tokens*
>
>
FI: this may be misleading I think. The consent is done by a RC (or in
OAuth terms, RO), not the application user.
I agree there may be a combination of consent decisions, but I think it's
important to say that in the end for each individual choice, you do have a
yes/no decision.

>> the context of OAuth2. The question is to know whether we can build the new
>> 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 --
>> later "I do agree that it is not the best term in GNAP. Primarily because
>> from OIDC."

---

From: Justin Richer <[email-masked]>
Date: Fri, 14 Aug 2020 10:30:39 -0400

+1 for “end user” as the human person, and perhaps “<client> operator” as the role they play when, you know, operating the <client>. (Where <client> should still have a more specific name.)

 — Justin

> On Aug 14, 2020, at 8:23 AM, Fabien Imbault <[email-masked]> wrote:
> 
> Hi Denis, 
> 
> On Fri, Aug 14, 2020 at 12:02 PM Denis <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Fabien,
> 
> FI : then end-user is clearer if you want to indicate specifically a human user. One can also create system users.
>> <Client> = application that requests access to Resource Servers (RS) through a Grant Server (GS).  
> A few explanations: "through" does not sound appropriate since it could be interpreted as the GS being necessarilly placed between the Client and the RS. 
>                                       In addition, more than one GS may be necessary.
> 
> My proposal:  <Client> = application that requests access to Resource Servers (RS) on behalf of a User by using one or more Grant Servers (GS) 
> Examples: a web server, a browser-based app, a mobile app.
> 
> FI: agreed.  
> 
>> GS = computing service that manages the grant lifecycle to a <Client> on behalf of a Resource Controler (RC).
>> Note : for privacy reasons, the GS may be issuing grants without knowledge of which resources are requested.
> I dislike "on behalf of a Resource Controler (RC)". The GS may be fully ignorant of the existence of the RSs and hence of the RCs.
> In addition, "grant life cycle" is undefined.
> 
> My proposal:  GS = server issuing access tokens to a Client after successfully authenticating the User
> Note 1: for privacy reasons, the GS may be issuing access tokens without the knowledge of which resources are requested.
> Note 2: a GS is able to disclose to a User the User attributes that it manages.  
> 
> FI: I find the new definition less clear. It's not because you don't know which RS is called that we shouldn't say the decision is made by the RC. 
> "grant life cycle" is indeed currently undefined, what i had in mind is basically the grant flow from the GNAP protocol, possibly also including revocation etc.
>> RS = computing service that grants access only if its Resource Controler (RC) consents.
>> Note : the consent may involve a human interaction or may be automated based on access control policies.
> I dislike "its Resource Controler (RC) consents" because it may let think that a human person always needs to consent.
> 
> My proposal: RS = server hosting protected resources, capable of accepting and responding to protected resource requests 
>                                   when access tokens are being used
> FI : that is why I suggested a note to make sure it is correctly understood. I'm not sure the proposed alternative is clearer. 
> 
>> RC = entity which is controlling the access to a protected resource. 
>> Note : a RC may be manually operated by a human or delegated to a machine, partially or completely.
> A RC is not an entity but a function. I would also place the machine case first.
> 
> My proposal: RC = function tightly coupled with a RS which controls the accesses to a protected resource
>                         Note : the function may be operated either by a machine or by a human person or by some combination of both.
> 
> FI : your proposition on the note makes it much better. On the main definition, I'm not sure what you mean by function, as a result I'm not sure a reader would understand. Why do you need to say "tightly coupled?" 
>> Consent = the process of asking a RC to accept or decline based on a grant request presentation, resulting in either a “yes” or “no” consent decision.
> I would instead speak of the "User Consent". The User Consent is a set of choices among a proposed set of choices. It is not simply a "yes" or "no" consent decision.
> 
> My proposal: User Consent = ability for a User, after being informed, of choosing to release or not to a RS some attributes contained in one or more access tokens
> 
> 
> FI: this may be misleading I think. The consent is done by a RC (or in OAuth terms, RO), not the application user. 
> I agree there may be a combination of consent decisions, but I think it's important to say that in the end for each individual choice, you do have a yes/no decision. 
> 
> 
> Denis
> 
> 
> 
>> Fabien
>> 
>> On Thu, Aug 13, 2020 at 3:55 PM Denis <[email-masked] <mailto:[email-masked]>> wrote:
>> Fabien,
>> 
>> IMHO, nothing is wrong with keeping "Client" since it has a wide spread usage
>> ... but only as long as we can agree on a short and a clear definition for it.
>> 
>> A similar argumentation for GS.  It could be used but only as long as we can agree on a short and a clear definition for it.
>> Any proposal ?
>> 
>> Denis
>> 
>>> Hi,
>>> 
>>> Nothing inherently wrong with Client/AS, which has worked for years in the context of OAuth2. The question is to know whether we can build the new protocol with the same concepts and deal with their known limitations, or if we're better off with more adapted concepts less prone to misunderstandings.
>>> 
>>> Verb vs Noun:
>>> Problem is that the grant (noun) can only be understood if there is a grant(verb), i.e. some action that grants something. 
>>> The grant (noun) definition directly derives from the verb : "something granted ..."
>>> 
>>> I personally have no issue even with the fairly convoluted "The Grant Server issues a grant to the Grant Client representing access that has been granted" (except perhaps from the word Client, but that's a different issue).
>>> By the way, grant is nothing new, it's used extensively in OAuth2 as "grant types" (whatever that means). 
>>> 
>>> 1) "grant" is in the working group name (a weaker reason, but still has been approved). Question: would our reasoning if the protocol ended up being called OAuth3?
>>> 2) grant = larger in scope than AS (not only authorization), as it at least includes idclaims + other use cases like payment (?) - no consensus, see difference in appreciation between Justin and Dick
>>> 
>>> As for "Client", if most people think it is problematic, it seems a good reason to change if we find a better alternative. 
>>> Quoting Dick again: "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." and later "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."
>>> 
>>> So far there's no consensus however, recent tries: Initiating Application (Denis), Orchestrator (Francis). 
>>> 
>>> Cheers
>>> Fabien
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <[email-masked] <mailto:[email-masked]>> wrote:
>>> I would be against using "grant" as both a verb and a noun and stick purely with one or the other. (In the charter the only use of "grant" is in the verb: "granted").
>>> 
>>> I think it will be confusing to say "The Grant Server issues a grant to the Grant Client representing access that has been granted"
>>> 
>>> Whether the access takes place via a token being returned and used at a resource server, or "claims" that are directly returned from the "Grant Server" I think should be largely irrelevant when it comes to the naming of the roles.
>>> 
>>> In almost all use cases that I have seen the "Grant Server" is making a policy based decision "to grant" access to requested resource(s). To me, that is the fundamental operation happening. I think nearly all use cases can be applied to that, e.g. the GS grants access to
>>>  - call a "contract signing" API with specific properties (e.g. contract hash of xxx,)
>>>  
>>> While "client" is problematic, it does now have wide spread usage, so perhaps we are stuck with it. 
>>> However I agree with Justin and think "Grant Client" makes things more confusing.
>>>

---

From: Francis Pouatcha <[email-masked]>
Date: Fri, 14 Aug 2020 11:06:18 -0400

We have been having a lot of great suggestions and discussion in the list
on terms. As we go on, a lot of knowledge gets buried in the mailing
archives. This why i suggest we use the use cases github wiki to:

- start compiling discussions on single terms into issues (tickets),
- also create a ticket for each use case, either linking the wiki page,

The wiki page will be used to hold the last consolidated state of the
definition or use case.

Using tickets to complement wiki pages will allow us to:
- move valuable contributions on each word or use case to the comment
section of the corresponding ticket.
- allow contributors or visitors to read the summary of what was discussed
on a term (resp. use case) before proceeding with additional
comments/questions.
- Help focus toward reusable content.

What do you think?

Best regards
/Francis

On Fri, Aug 14, 2020 at 10:30 AM Justin Richer <[email-masked]> wrote:

> +1 for “end user” as the human person, and perhaps “<client> operator” as
> the role they play when, you know, operating the <client>. (Where <client>
> should still have a more specific name.)
>
>  — Justin
>
>> FI : then end-user is clearer if you want to indicate specifically a
> human user. One can also create system users.
>
>> A few explanations: "through" does not sound appropriate since it could
>> be interpreted as the GS being necessarilly placed between the Client and
>> the RS.
>> I dislike "*on behalf of a Resource Controler (RC)*". The GS may be
>> the knowledge of which resources are requested.Note 2: a GS is able to
>> protected resource*                        Note : the function may be
>> My proposal: *User Consent = ability for a User, after being informed,
>> of choosing to release or not to a RS some attributes contained in one or
>> more access tokens*
>>
>>
>>> A similar argumentation for GS.  It could be used but only as long as
>>> we can agree on a short and a clear definition for it.
>>> Any proposal ?
>>>
>>> Denis
>>>
>>> Hi,
>>>
>>>> Financial Services Register (FRN 809360) at
>>>> registered in England & Wales, company registration number 06909772.
>>>> Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus
>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.
>>>>

---

From: Denis <[email-masked]>
Date: Fri, 14 Aug 2020 17:33:44 +0200

Hello Francis,

- 1.

The mailing list is the usual way to exchange short information. The use 
of the wiki should be restricted to long contributions.
You are invited to contribute on the mailing list by proposing both a 
wording and its meaning if a current proposed wording
does not meet your expectations and whenever possible with a short rational.

Denis

> We have been having a lot of great suggestions and discussion in the 
> list on terms. As we go on, a lot of knowledge gets buried in the 
> mailing archives. This why i suggest we use the use cases github wiki to:
>
> - allow contributors or visitors to read the summary of what was 
> discussed on a term (resp. use case) before proceeding with additional 
> comments/questions.
> On Fri, Aug 14, 2020 at 10:30 AM Justin Richer <[email-masked] 
>     +1 for “end user” as the human person, and perhaps “<client>
>     operator” as the role they play when, you know, operating the
>     <client>. (Where <client> should still have a more specific name.)
>
>      — Justin
>
>>     On Aug 14, 2020, at 8:23 AM, Fabien Imbault
>>     FI : then end-user is clearer if you want to indicate
>>     specifically a human user. One can also create system users.
>>
>>>         /<Client> = application that requests access to Resource
>>>         Servers (RS) through a Grant Server (GS). /
>>             A few explanations: "through" does not sound appropriate
>>             since it could be interpreted as the GS being
>>             necessarilly placed between the Client and the RS.
>>             My proposal: /<Client> = application that requests access
>>             to Resource Servers (RS)///on behalf of a User/by using
>>             one or more Grant Servers (GS)/
>>>         /GS = computing service that manages the grant lifecycle to
>>>         a <Client> on behalf of a Resource Controler (RC)./
>>>         Note : for privacy reasons, the GS may be issuing grants
>>>         without knowledge of which resources are requested.
>>
>>             I dislike "/on behalf of a Resource Controler (RC)/". The
>>             GS may be fully ignorant of the existence of the RSs and
>>             hence of the RCs.
>>             My proposal: //GS =/server issuing access tokens to a
>>             Client after successfully authenticating the User/
>>             /Note 1: for privacy reasons, the GS may be issuing
>>             access tokens without the knowledge of which resources
>>             are requested.
>>     FI: I find the new definition less clear. It's not because you
>>     don't know which RS is called that we shouldn't say the decision
>>     is made by the RC.
>>     "grant life cycle" is indeed currently undefined, what i had in
>>     mind is basically the grant flow from the GNAP protocol, possibly
>>     also including revocation etc.
>>>         /RS = computing service that grants access only if its
>>>         Resource Controler (RC) consents./
>>>         Note : the consent may involve a human interaction or may be
>>>         automated based on access control policies.
>>
>>             I dislike "/its Resource Controler (RC) consents"/because
>>             it may let think that a human person always needs to consent.
>>
>>             My proposal:/R//S = server hosting protected resources,
>>             capable of accepting and responding to protected resource
>>             requests
>>                                               when access tokens are
>>             being used/
>>
>>             My proposal:/RC = function tightly coupled with a RS
>>             which controls the accesses to a protected resource
>>             /                        Note : the function may be
>>             operated either by a machine or by a human person or by
>>             some combination of both.
>>
>>     FI : your proposition on the note makes it much better. On the
>>     main definition, I'm not sure what you mean by function, as a
>>     result I'm not sure a reader would understand. Why do you need to
>>     say "tightly coupled?"
>>
>>>         /Consent = the process of asking a RC to accept or decline
>>>         based on a grant request presentation, resulting in either a
>>>         “yes” or “no” consent decision./
>>
>>             I would instead speak of the "User Consent". The User
>>             Consent is a set of choices among a proposed set of
>>             choices. It is not simply a "yes" or "no" consent decision.
>>
>>             My proposal:/User Consent = ability for a User, after
>>             being informed, of choosing to release or not to a RS
>>             some attributes contained in one or more access tokens/
>>
>>
>>     FI: this may be misleading I think. The consent is done by a RC
>>     (or in OAuth terms, RO), not the application user.
>>     I agree there may be a combination of consent decisions, but I
>>     think it's important to say that in the end for each individual
>>     choice, you do have a yes/no decision.
>>
>>
>>         Denis
>>
>>
>>>         Fabien
>>>
>>>             A similar argumentation for GS.  It could be used
>>>             butonly as long as we can agree on a short and a clear
>>>             definition for it.
>>>             Any proposal ?
>>>
>>>             Denis
>>>
>>>>             Hi,
>>>>
>>>>             Nothing inherently wrong with Client/AS, which has
>>>>             worked for years in the context of OAuth2. The question
>>>>             is to know whether we can build the new protocol with
>>>>             the same concepts and deal with their known
>>>>             limitations, or if we're better off with more adapted
>>>>             concepts less prone to misunderstandings.
>>>>
>>>>             Verb vs Noun:
>>>>             Problem is that the grant (noun) can only be understood
>>>>             if there is a grant(verb), i.e. some action that grants
>>>>             something.
>>>>             I personally have no issue even with the fairly
>>>>             convoluted "The Grant Server issues a grant to the
>>>>             (except perhaps from the word Client, but that's a
>>>>             different issue).
>>>>             By the way, grant is nothing new, it's used extensively
>>>>             in OAuth2 as "grant types" (whatever that means).
>>>>
>>>>             1) "grant" is in the working group name (a weaker
>>>>             reason, but still has been approved). Question: would
>>>>             our reasoning if the protocol ended up being called OAuth3?
>>>>             2) grant = larger in scope than AS (not only
>>>>             authorization), as it at least includes idclaims +
>>>>             other use cases like payment (?) - no consensus, see
>>>>             As for "Client", if most people think it is
>>>>             problematic, it seems a good reason to change if we
>>>>             find a better alternative.
>>>>             Quoting Dick again: "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." and later
>>>>             "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."
>>>>
>>>>             So far there's no consensus however, recent tries:
>>>>             Initiating Application (Denis), Orchestrator (Francis).
>>>>
>>>>             Cheers
>>>>             Fabien
>>>>
>>>>
>>>>
>>>>
>>>>                 I would be against using "grant" as both a verb and
>>>>                 a noun and stick purely with one or the other. (In
>>>>                 the charter the only use of "grant" is in the verb:
>>>>                 "granted").
>>>>
>>>>                 I think it will be confusing to say "The Grant
>>>>                 Server issues a grant to the Grant Client
>>>>                 representing access that has been granted"
>>>>
>>>>                 Whether the access takes place via a token being
>>>>                 returned and used at a resource server, or "claims"
>>>>                 that are directly returned from the "Grant Server"
>>>>                 I think should be largely irrelevant when it comes
>>>>                 to the naming of the roles.
>>>>
>>>>                 In almost all use cases that I have seen the "Grant
>>>>                 Server" is making a policy based decision "to
>>>>                 grant" access to requested resource(s). To me, that
>>>>                 is the fundamental operation happening. I think
>>>>                 nearly all use cases can be applied to that, e.g.
>>>>                 the GS grants access to
>>>>                 While "client" is problematic, it does now have
>>>>                 wide spread usage, so perhaps we are stuck with it.
>>>>                 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)
>>>>                 athttps://register.fca.org.uk/. Moneyhub Financial
>>>>                 Technology is registered in England & Wales,
>>>>                 company registration number 06909772. Moneyhub
>>>>                 Financial Technology Limited 2020 © Moneyhub
>>>>                 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
>>>>                 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

---

From: Tom Jones <[email-masked]>
Date: Fri, 14 Aug 2020 11:07:55 -0700

that works for me
The roles that an end user agent might expose are
Subscriber
Applicant
Authenticated user
Authorized user
Resource owner
Delegate
Principal
Administrator
Legal override
Emergency (public Health) override
The last three roles are not (necessarily) a single human being, but can
only be represented by a single human in a role.  See my submission on
Delegation for a binding between a human and a role.

I would avoid payments - that is a can of worms that has no common
internationally (meaning more that 6 countries) accepted approach. And the
only convergence seems to be the Google dominated one.
Peace ..tom

---

From: Fabien Imbault <[email-masked]>
Date: Sun, 16 Aug 2020 09:12:16 +0200

+1 on creating a durable resource for this.

As with the core spec, doesn't mean we can't discuss on the mailing list.

Fabien

Le ven. 14 août 2020 à 17:33, Denis <[email-masked]> a écrit :

>>> *GS = computing service that manages the grant lifecycle to a <Client>
>>> on behalf of a Resource Controler (RC).*
>>> *Note 1: for privacy reasons, the GS may be issuing access tokens
>>> without the knowledge of which resources are requested. Note 2: a GS is
>>> able to disclose to a User the User attributes that it manages.   *
>>>
>>> FI: I find the new definition less clear. It's not because you don't
>> know which RS is called that we shouldn't say the decision is made by the
>> RC.
>>> *RS = computing service that grants access only if its Resource
>>> Controler (RC) consents.*
>>> *RC = function tightly coupled with a RS which controls the accesses to
>>> a protected resource *                        Note : the function may
>>> be operated either by a machine or by a human person or by some combination
>>> of both.
>>>
>>> I would instead speak of the "User Consent". The User Consent is a set
>>> of choices among a proposed set of choices. It is not simply a "yes" or
>>> "no" consent decision.
>>>
>>>>> I think it will be confusing to say "The Grant Server issues a grant
>>>>> to the Grant Client representing access that has been granted"
>>>>>
>>>>> Whether the access takes place via a token being returned and used at
>>>>> a resource server, or "claims" that are directly returned from the "Grant
>>>>> In almost all use cases that I have seen the "Grant Server" is making
>>>>> a policy based decision "to grant" access to requested resource(s). To me,

---

From: Warren Parad <[email-masked]>
Date: Sun, 16 Aug 2020 10:02:18 +0200

Well said! +1 for using the right medium for collaboration. I too have
found email for a lot of discussions to be challenging to follow and keep
track of important details.

On Sun, Aug 16, 2020, 09:12 Fabien Imbault <[email-masked]> wrote:

>>> +1 for “end user” as the human person, and perhaps “<client> operator”
>>> as the role they play when, you know, operating the <client>. (Where
>>> <client> should still have a more specific name.)
>>>
>>>  — Justin
>>>
>>> On Fri, Aug 14, 2020 at 12:02 PM Denis <[email-masked]
>>> <[email-masked]>> wrote:
>>>
>>>> Hi Fabien,
>>>>
>>> I agree there may be a combination of consent decisions, but I think
>>> it's important to say that in the end for each individual choice, you do
>>> have a yes/no decision.
>>>
>>>>
>>>> Denis
>>>>
>>>>
>>>> Fabien
>>>>
>>>>> has been approved). Question: would our reasoning if the protocol ended up
>>>>> being called OAuth3?
>>>>> 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
>>>>>> Conduct Authority ("FCA").. Moneyhub Financial Technology is entered on the
>>>>>> https://register.fca.org.uk/.. Moneyhub Financial Technology is

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 Aug 2020 13:38:54 -0700

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

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 17 Aug 2020 09:37:54 +0200

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 <[email-masked]> wrote:

> - 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
>
>
>>> 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.
>>> :)
>>>
>>>> Since you and I also disagree on whether returning things directly is
>>>> an important distinction (even though both the XAuth and XYZ proposals make
>>>>> 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.
>>>>>
>>>>>> <https://en.wikipedia.org/wiki/System_administration>,
>>>>>> *orchestration* is the automated configuration
>>>>>> virtualization
>>>>>> <https://en.wikipedia.org/wiki/Platform_virtualization>, provisioning
>>>>>> <https://en.wikipedia.org/wiki/Provisioning>, converged
>>>>>> infrastructure
>>>>>> <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]
>>>>>>> [email-masked]>; Dick Hardt <[email-masked]>; Benjamin Kaduk
>>>>>>> <[email-masked]>; Fabien Imbault <[email-masked]>; Denis <
>>>>>>> 3. the site that has a repository of user data with legal
>>>>>>> obligations to protect that data (the GDPR) (role resource server.)
>>>>>>>
>>>>>>> The confusion in my experience usually stems from people
>>>>>>> working with software that is acting in multiple roles. IE, the
>>>>>>> may not be acting as a client in the oauth context.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ᐧ
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>> *Resource Manager (RM)* : application or user that manages an
>>>>>>> access decision function of a Resource Server
>>>>>>>
>>>>>>> Denis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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