Re: [GNAP] Terminology

Fabien Imbault <fabien.imbault@gmail.com> Fri, 14 August 2020 12:23 UTC

Return-Path: <fabien.imbault@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DD63A1078 for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 05:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NJYBBQbHS8M for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 05:23:26 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4833C3A1075 for <txauth@ietf.org>; Fri, 14 Aug 2020 05:23:26 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id p18so4416025ilm.7 for <txauth@ietf.org>; Fri, 14 Aug 2020 05:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PzTDQ7vlwJNkDoGmSCYJtvxWCfzLKvkgsPbXscae5rM=; b=JJtHn2Uuf1GtagjG6AuQbsYINQy/WyrJbqCbFchRE3sq3Z1gRvwMvFKrB2IiMAM2me PyYJs6RyH5Ov10x9Am2Wg26VRLBCmticlWlZ8zOGYSGMMbkbQNLf+EuYSY8qoCagzwNB MBPohIDAgxiO6DlR7KXTzT30vEJhc2+KYF1XabGkaCi5XikR91lF3a2hEOYInqkkFmPw Ba6Y1RHgop9CPEZ8dD4iLyEAp/JOO/xwEW+DNTJiFe5SLQmk8dLb2LCM8ICmavd8+iUK UiuSP+cKAhOtFM9oAcLeyZAtJytddEMuRGtyUG9E76isRRPP6irRGYVrCpcsbrXbuY4J PxQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PzTDQ7vlwJNkDoGmSCYJtvxWCfzLKvkgsPbXscae5rM=; b=RpOxCoruT/8V0tfdmT6bFRqlTXTI1EbJ9yThwi+1IOmu8+NSjO4mPth1aK5lCAykBD +7z3lgLirWlT2zwmJKgs1JWaA0ZZ3jEtx1PL84Yx97yWdPpIbIJMZBRKEG+i7wx2tl50 m19bhv69WlOn1bmcumr6spT4+sfLH+Dhnb79/cEq7aGmBu+ltaYjrmxnvKdzxxRvo2vy A7TIsnOqA8zDPzwGj2uZR3Q6kIKHg0vukw4THfjLyon20sbWpiY2dNWLkCJrj7xcLmGq AXoueBz4jyLu2FohDWIBaYnvOmws0TI0O6CVFCmDbOiTB3l1ppZ2N0Q7sNPKttMMGPwb a/nA==
X-Gm-Message-State: AOAM533hN3ChNG5G1v2ep0HvorHCRxPlXJ30a4AZB9dACjRdemjYOQVj wnzQF1OPlyBeKr38HVR3mn91RKlLmq8u1GgJTBo=
X-Google-Smtp-Source: ABdhPJw6Rm4JxUlol6/yLikoCcq2N6nX1/SkfSOqIXHYP6a+KneMIE4Y3bheC20l9vdS9icBvojlK5/SFkXlJTVydts=
X-Received: by 2002:a92:480f:: with SMTP id v15mr2130241ila.123.1597407805606; Fri, 14 Aug 2020 05:23:25 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR00MB0684496FAFF843EF4286B0ECF5451@DM6PR00MB0684.namprd00.prod.outlook.com> <CAD9ie-u7xbmDvszc4nhgL7PTi+q92wVXDhf5-UsqYWhkdfFf_w@mail.gmail.com> <AA0A1BCB-A128-4C45-B137-FCCB4ECC0B4A@mit.edu> <CAD9ie-ut3B1Hys-8w8FqQ6W+F017V5nZKmu7jyjWgP-PBGYwrg@mail.gmail.com> <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <CAD9ie-srbdXNQMpZQvLCEEsB00gHKuScq7RM9Cw56yS24+Hi2Q@mail.gmail.com> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <CAD9ie-scGz1s=q=g=GSD9gL3X3O3rHG0ukQVPewZ6dMw5dDeHw@mail.gmail.com> <CAM8feuRiT4wk827M_o=TEEW9FtZk3PaBR1AFr2seT5GJ+ZoLKw@mail.gmail.com> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> <CAM8feuSVVfccaZC80bnGNq9H2xwxH++5PCkZ-mTtVVPy3t=uCA@mail.gmail.com> <CAP-T6TS_+ve6C=5YfUF_tBqyWu6OcW7TqqjXD8OGx9S42pLqSg@mail.gmail.com> <CAM8feuRspSdNF-wK=JA2owF7f29w4Am4FamX8fim5NhTQR1k1g@mail.gmail.com> <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> <CAM8feuQeCzma7aSMqBV=kFYXmBVNyVBPzFoVrR=Tmku9tgBSLg@mail.gmail.com> <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr>
In-Reply-To: <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Fri, 14 Aug 2020 14:23:14 +0200
Message-ID: <CAM8feuQJ2qtBOkqt8tYC+41ux7DdEu8A4L9tE5HBhLXj=oJjow@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Dave Tonge <dave.tonge@moneyhub.com>, Francis Pouatcha <fpo@adorsys.de>, Justin Richer <jricher@mit.edu>, Mike Jones <Michael.Jones@microsoft.com>, Benjamin Kaduk <kaduk@mit.edu>, Tom Jones <thomasclinganjones@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d0901c05acd57c1f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/VegoJoevNNvdqjBj-dMczQ6QV94>
Subject: Re: [GNAP] Terminology
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2020 12:23:29 -0000

Hi Denis,

Thanks for your feedback.
Comments inline (marked with FI).

Fabien

On Fri, Aug 14, 2020 at 12:02 PM Denis <denis.ietf@free.fr> 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 <denis.ietf@free.fr> 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 <dave.tonge@moneyhub.com>
>> 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 https://register.fca.org.uk/.
>>> 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
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>