Re: [GNAP] Terminology

Fabien Imbault <> Thu, 13 August 2020 13:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 650CD3A0C43 for <>; Thu, 13 Aug 2020 06:49:03 -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 J9O4KMZBTVO4 for <>; Thu, 13 Aug 2020 06:49:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFE6F3A0C46 for <>; Thu, 13 Aug 2020 06:49:00 -0700 (PDT)
Received: by with SMTP id s189so7384724iod.2 for <>; Thu, 13 Aug 2020 06:49:00 -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=eesK6L2YktfSqaYIhyHEQK4tvYyHJIn9IKt+lUq9Meg=; b=lgZBVvYekRidrFkNGwflDmK0jNigeVqkQWoimjFsbL+HE66x98L5aQDBeOtQ8iTL3T vDiksHxQRoeW5K1bpTj7dZU31OKkWZCawJnXJPQ1hwLlgEfcH9SYMKwpcWl8fuBk/eR0 Heqea8nzDCVVfDL6CSktKexWIQYBwiGi/Y9+d1YelaCEFW4dTNstsO+HB3AACo8HLLUH ppWy8NI9DWSQbN+hrFGsfsViuvxat27i0OJVWWMKQRN6KOVxpY8AjhwmAow3zqYkO/dJ 4gqGMAx1xfgtZx4sYfA0BYggiW27EDJScbYUjF/0ML4z+q12OuwtuioYjlyd0oRtC5EQ 46gg==
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=eesK6L2YktfSqaYIhyHEQK4tvYyHJIn9IKt+lUq9Meg=; b=Uz9n5dg6vvwyVVvVTUa/mKoYmK6ap8xk3LwCHwpW0eTn4a8F5fNKqsxhjJRiehGLnl lVyWAvNP1+ZZluBD0d+EUc7SR2mwPOtCW4bZjqWbMwESYkDszohmKNBB5PUWGBan+xYF mMOJYuHSl4M3DG9NMCixX7zeFNpZxSPydnaQZFwMK0YB9aNYUiZ/ucUP6CqQ02Q7tP8t MO5bG5gBNq0RJF3jW8byn7VjRl8E4XEB7z5Vpis6xJkvXMsQ2M5YWPvYSlAjntFD3L/L vEfqoCKJZIv+4fSpuUuFQMkJsTCV823bYZxyioe7ILwro/Cbvw75LczocjEZk/D1eUwz 17IA==
X-Gm-Message-State: AOAM53141hhH3NkvITAVzcYjp5YywDcMIiHlUed374JofXPZ2wPlOhBz zZ2uhi2wmyyjWbysNDgCLzdo0K916PZ58omCw3w=
X-Google-Smtp-Source: ABdhPJy6aGMMGjdto08qoc80jG/SlqC1CxRZdAL2WzPPU9uidk6iCx8/KQwJ3SUyvSOhA0YNTDeSkKEbNkeCbSnxGhY=
X-Received: by 2002:a6b:e70d:: with SMTP id b13mr4900966ioh.141.1597326539892; Thu, 13 Aug 2020 06:48:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Thu, 13 Aug 2020 15:48:48 +0200
Message-ID: <>
To: Dave Tonge <>
Cc: Justin Richer <>, Dick Hardt <>, Mike Jones <>, Tom Jones <>, Francis Pouatcha <>, Benjamin Kaduk <>, Denis <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000002d7e05acc29155"
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:49:03 -0000


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

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


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.