Re: [GNAP] Terminology - into Github Issues

Warren Parad <> Sun, 16 August 2020 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 493553A084A for <>; Sun, 16 Aug 2020 01:02:34 -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, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7QUjKgEdBflY for <>; Sun, 16 Aug 2020 01:02:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65CB83A0796 for <>; Sun, 16 Aug 2020 01:02:31 -0700 (PDT)
Received: by with SMTP id d14so12297822qke.13 for <>; Sun, 16 Aug 2020 01:02:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aA5rWRCpeeROYRr59Lv/mr9mRw28hb9VhHIHsUSWfgY=; b=naxPfsoP3Bo8CkLZX4NsTGBkow/kmnjgv1X23aoTsXFHDyeOlVu/VT1zSRLL3NcFHz 7f6W2Hq92QCIVPdNpsnJlSXbfK5FvBdGW7cLLEcrCDX2hUGutnp+9AbzjHJRhXAtTjLD coRqfA4F4toyKTneUwrQ6FleU8/OaYkKO7QO4=
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=aA5rWRCpeeROYRr59Lv/mr9mRw28hb9VhHIHsUSWfgY=; b=I11fnro48Ti4262p3ljSOikzwc6DfzoA24n2WqQXq3puRKEFgG8GUz9SRKdWFeYXZl BzKgina8zfrv7/x/g/QTzSPs3fDhka2UPMJLv+w7I+4urPVVafWcWNL75JCaO+t4+6n9 VPMxMwHyflOQx1bSDUzkmUAND5qNabSHAMz2uP+e20bvxUjZKY7rjxTtPGA+yzS1LGDU Xa/EAf7cTZr4DmeX2xqg9cdBuq3du3MJKhxlNqWenWmidLbWSZrSZpE0d3hNyHpEiufX B82rRjLTFp+mJzaltGhzEwhPWOi1RjdI5HGwNX4S7Utfo5G1w52V9LqdFtiJ1e0YPcDr 23cg==
X-Gm-Message-State: AOAM530bVpRLJM3cIyaaGldcQXDvt8lcDlGVRB+IAlC7mEAS1cdGSjc/ k3ngFYn1W47apW+ceLHO63nHE9peX/kNryDPI920
X-Google-Smtp-Source: ABdhPJySijDsW2upb+7IMmvdXlFXCMRh4Yxm1Ml6totII7cdMoKSCfVcpmvKv0vVJUgOjVBYbbzqS98Nu0yRXKeQZ8g=
X-Received: by 2002:a05:620a:21c1:: with SMTP id h1mr8436112qka.178.1597564950128; Sun, 16 Aug 2020 01:02:30 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Warren Parad <>
Date: Sun, 16 Aug 2020 10:02:18 +0200
Message-ID: <>
To: Fabien Imbault <>
Cc: Denis <>, Francis Pouatcha <>, GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="0000000000005bc5a405acfa133a"
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 08:02:34 -0000

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 <> wrote:

> +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 <> 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
> --
> TXAuth mailing list