Re: [GNAP] Terminology

Fabien Imbault <fabien.imbault@gmail.com> Thu, 13 August 2020 14:59 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 7DE943A0CF1 for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 07:59:55 -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 s23x7tRs6beH for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 07:59:49 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 9FDBF3A0CEE for <txauth@ietf.org>; Thu, 13 Aug 2020 07:59:49 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id r13so1361337iln.0 for <txauth@ietf.org>; Thu, 13 Aug 2020 07:59:49 -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=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; d=1e100.net; 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: <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>
In-Reply-To: <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Thu, 13 Aug 2020 16:59:36 +0200
Message-ID: <CAM8feuQeCzma7aSMqBV=kFYXmBVNyVBPzFoVrR=Tmku9tgBSLg@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Dave Tonge <dave.tonge@moneyhub.com>, Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt@gmail.com>, Mike Jones <Michael.Jones@microsoft.com>, Tom Jones <thomasclinganjones@gmail.com>, Francis Pouatcha <fpo@adorsys.de>, Benjamin Kaduk <kaduk@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000416a8505acc38ee2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/itEmrGhQJbRJ6bUjT6HUvXmZXVQ>
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: 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.*

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