Re: [GNAP] Terminology

Fabien Imbault <> Thu, 13 August 2020 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DE943A0CF1 for <>; Thu, 13 Aug 2020 07:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s23x7tRs6beH for <>; Thu, 13 Aug 2020 07:59:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FDBF3A0CEE for <>; Thu, 13 Aug 2020 07:59:49 -0700 (PDT)
Received: by with SMTP id r13so1361337iln.0 for <>; Thu, 13 Aug 2020 07:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cL8eH8m3CBf1CjqzGsH72+Pon+2iyJVPxsHdMPjFMaY=; b=O/2Vd+wFsLT2DQWol4c1RooPtLI1lGS7VJZ+niGuv6f2g48e/YgeAzeivDsNdHrIP7 OE9bGspbH5UwnZXZFVVLVPzsFZ5uHcne1Gph4S4YAbXCf2nJ9OeelLPH5s/7Dv6cRieC 3Zfkx4oqv6H7/KNe8ubDzw3dtBb5NwcaLhs5Pn7A3OoJBtQxGzSoez2wPWiZJCtbv0GO yT0HyjhFfuODTZa0HpA/cDfnTpHtmPFXVJ0QMEi+JC8WcWOnf5dbL3pp22vwKfYXrlCZ Fk4boT3Com2bfsERtzOmNczgluUmNwOwCJfdR7OcNPa4BXurxtJ6kviwP9bSd16oWhke 1nYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cL8eH8m3CBf1CjqzGsH72+Pon+2iyJVPxsHdMPjFMaY=; b=fXEwdM11c5JMroEM/vz+kcsAiT52XD4ylou1ipr4qGPEo0pWa4U71XGGVGizFMl+Wu UCcTGPuLKOkXt1SpWTnT2Jflr5rIwfornCVSO+8fImGq/UcKmvolCoFSDuaYGWt1Cy1b 7A3Zte5Yo99TeMIJ+gFR36XoEDJV+jROMFOT/GSynhyOSNTR8ROWWCTFJzPZ6P9NxAlG vThNCODXz7wGdAAJe19zjpYsCTo17KNHaa0MDWc2CsY/IAGDd1zyGk1f+QwZ5PB8yJlF BOhnWbfwQ2D6KFtUfGITEr59mrRqJv+KRKZSn/fzLiDvKgS2XiLb9ctBy6kgUf77TvAG zmyw==
X-Gm-Message-State: AOAM530eT33HZ1OJ/thRv5JHq1NrtpLnhNHx3QtBpIhqEECVZZaZssyy QgR0JIBkHncc4WRfrgESc/Due356qStwOVxTNuc=
X-Google-Smtp-Source: ABdhPJyysw6JDnFLr+ccXLSGUisZArq7CGeMZgsXRAyO5k+tv9Z9NFw8i1XNvGpwTA29Cl0HueXYpMECdOzjQbVG/xs=
X-Received: by 2002:a05:6e02:686:: with SMTP id o6mr4694503ils.188.1597330788803; Thu, 13 Aug 2020 07:59:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Thu, 13 Aug 2020 16:59:36 +0200
Message-ID: <>
To: Denis <>
Cc: Dave Tonge <>, Justin Richer <>, Dick Hardt <>, Mike Jones <>, Tom Jones <>, Francis Pouatcha <>, Benjamin Kaduk <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000416a8505acc38ee2"
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 14:59:57 -0000

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


On Thu, Aug 13, 2020 at 3:55 PM Denis <> 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.
> 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:
> 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.