Re: [GNAP] Terminology

Denis <> Thu, 13 August 2020 13:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEE393A0C5F for <>; Thu, 13 Aug 2020 06:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4L67ZPW4Zy43 for <>; Thu, 13 Aug 2020 06:55:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3B083A0C4D for <>; Thu, 13 Aug 2020 06:55:19 -0700 (PDT)
Received: from [] ([]) by mwinf5d83 with ME id F1vH230082bcEcA031vHbM; Thu, 13 Aug 2020 15:55:17 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 13 Aug 2020 15:55:17 +0200
To: Fabien Imbault <>, Dave Tonge <>
Cc: Justin Richer <>, Dick Hardt <>, Mike Jones <>, Tom Jones <>, Francis Pouatcha <>, Benjamin Kaduk <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Denis <>
Message-ID: <>
Date: Thu, 13 Aug 2020 15:55:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------2AA6ADA604B763C657664B38"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [GNAP] Terminology
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Aug 2020 13:55:27 -0000


IMHO, nothing is wrong with keeping "Client" since it has a wide spread 
... 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 ?


> 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 < 
> <>> 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").
>     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
> 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.