Re: [GNAP] Terminology - into Github Issues

Fabien Imbault <> Sun, 16 August 2020 07:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EACB3A081F for <>; Sun, 16 Aug 2020 00:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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_FONT_FACE_BAD=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 wlY_ocXGxWla for <>; Sun, 16 Aug 2020 00:12:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7874C3A0820 for <>; Sun, 16 Aug 2020 00:12:28 -0700 (PDT)
Received: by with SMTP id h4so14633958ioe.5 for <>; Sun, 16 Aug 2020 00:12:28 -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=JIyB0JAyZ63f2Ojk0XiR2y3w8kjmKU4C5bUgD21jPcs=; b=uPMxH7cp5LcBb7M7o/WN3rWrHZgPDczQ4kCN9PwIMEOV8AMLGY1PJZXoaJKR1wyeUr xl1nx75ntZe2ydZOMHnCL/r6zMyg271gE9MabJ6Lc+eD65dalnFjY7N9R55GJ3sVwNrp fZHv6yB9sFWhqEwkh8HrpGsHSqvaPiM2c/eqwyKHrEcYp5WKkJGYE0dyD10XkjppjlQ6 0C6bWdC9EZrGNNNn0pottJh2X5iDummwejCT5rJxkG3dpup9lXaOiRSjDY8iyE9lbiei fjoZLYvCgKz5cor0EXwlgaIvmKauky0eukGT/Oy3NQM5t5IC7Vc02CU/UL0oku9XwP73 zLkA==
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=JIyB0JAyZ63f2Ojk0XiR2y3w8kjmKU4C5bUgD21jPcs=; b=XkZIyJrWVx2wlRNakgl3usUy4B4xNwawStpZ0u2Q+AlU3WRmxgvY/dtFQL4YjfPsZq sbBCuF9vLp/uuplF5BDeWTryvriMkiMa5lG9tuc+pjHe7w3mTgKhS+c2Yaron91L/Ofa +Puk9aODn4LA7JAhNOHigjP1hKFpAzjiib54YzKI20huL+JdKHT7e5OVmrY2MtTslvQP +9b+p+SJsMvOv33Syc/h73cIEbp6u8pfH0SA8RKjEsc7PgH//f53O2EGv2u1kmjpHMEi I1e6gncSm1COT8csJ+/aYHzm7lyFnIweds5srD1c6e3g7QaAXdEE1KwLgTiCgj9ipXTp WrgA==
X-Gm-Message-State: AOAM530eLA0Gh4nixc2m1sEwIkfG8S4Hq1Qx878o9rHyz23PGqaHDkJH cG8/YafbWUpDPLxNQ/84kp9sZxUYdtXj6v4SXXE=
X-Google-Smtp-Source: ABdhPJyOoMDUaxk53cesVrZHFPSvmHg8q4hkKyc4ZpxlJmgDKJ8MJButoGgxAbxYRTXCVQteBjRjrBbx0d4YUpzXGhg=
X-Received: by 2002:a05:6638:22c7:: with SMTP id j7mr9541742jat.77.1597561947482; Sun, 16 Aug 2020 00:12:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Sun, 16 Aug 2020 09:12:16 +0200
Message-ID: <>
To: Denis <>
Cc: Francis Pouatcha <>, GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="00000000000062f00305acf96025"
Archived-At: <>
Subject: Re: [GNAP] Terminology - into Github Issues
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 16 Aug 2020 07:12:32 -0000

+1 on creating a durable resource for this.

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


Le ven. 14 août 2020 à 17:33, Denis <> a écrit :

> 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:
> - 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 <> 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 Aug 14, 2020, at 8:23 AM, Fabien Imbault <>
>> wrote:
>> Hi Denis,
>> Thanks for your feedback.
>> Comments inline (marked with FI).
>> Fabien
>> On Fri, Aug 14, 2020 at 12:02 PM Denis <> wrote:
>>> Hi Fabien,
>>> Thank you for your inputs, a ball is finally rolling.
>>> An attempt.
>>> I would add upfront: User =  human person
>>> 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). *
>>> Examples: a web server, a browser-based app, a mobile app, an IoT device.
>>> 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.
>> Not sure why Note 2 is important to put here.
>>> *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*
>>> 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 <> 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.
>>> --
>>> TXAuth mailing list
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> --
> TXAuth mailing list