Re: [GNAP] Terminology

Dave Tonge <dave.tonge@moneyhub.com> Thu, 13 August 2020 12:59 UTC

Return-Path: <dave.tonge@moneyhub.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 7C4463A0BFC for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 05:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_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 (1024-bit key) header.d=moneyhub.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 G7p0SKDkddS2 for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 05:59:07 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 D3A5D3A0BFF for <txauth@ietf.org>; Thu, 13 Aug 2020 05:59:07 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id f10so2583919plj.8 for <txauth@ietf.org>; Thu, 13 Aug 2020 05:59:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Iq/eMFQoUmQKRh2QXHUIG/S94FRpNtXVT6LeMg8HAAM=; b=XApJOiIYC6KLtxqmN08D96Rf/4gl1zGgyGN5LrchoxG9z7xpz9aAwWrMziYS1Isuaf 8cy09sB/du3M15Mr1SME0NOE4cdjDkMbYcOm3HHWvZQLTGv9gzSewMxPGXKmVqOI/c8N eyID+dlBjvYH0MLr/9C5BZOGAF2AR9oBfLy4Q=
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=Iq/eMFQoUmQKRh2QXHUIG/S94FRpNtXVT6LeMg8HAAM=; b=tvSeVdreJMXwtxrULfKu2jDrvRrsJjUcCANwxy1Qr+n6uFBGEr6yhi6TTB+qe3qv2q ivK1Gs789oDYLQqhGtLevIktiMy5ITbymBLEl2wcaqnQDy4kwR535Y+qJNApHNQO2B3L X9EzD9Dzm3eOm78ztE6G/xpKPC8xZvIaS8hFNuUw+Snta/oz7kuJVT+fsV6kxOKtxZe8 2vzr2y3WSzMDEs7nhl8LVhrTKcgkekm6in+WqQw5043PvtzCRGosC9vgeXuvUmgcSn4y YnxFnzP7u5Ny49O558Fz8f/gRF680QRRvihGflxHdK7lX/FZqJR3ohBvCilMf9El7knT rvDQ==
X-Gm-Message-State: AOAM532ZmmiDeDj6KzYr9yJX/b5xDy92Z1Mc8cCwjYE1+YSIGi5BEJSU HmO/HFwCdzt4VN+8rTd0D1RIVg2Ggpi+JtNLQaPLLrQMZZuXWgqk18vGX1lCnhH43NyBbpxmgxZ A6O+B8U/5KbQC3oU=
X-Google-Smtp-Source: ABdhPJx9N2meuDiMw1eNiQ364kpFgFqR1Vvp6LmwCRb8zB8tXu6eyKCKVd4LrrC7Ki2aZuKJTYLVITXW9nRDCa9WNHE=
X-Received: by 2002:a17:90b:1295:: with SMTP id fw21mr4505016pjb.81.1597323547089; Thu, 13 Aug 2020 05:59:07 -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>
In-Reply-To: <CAM8feuSVVfccaZC80bnGNq9H2xwxH++5PCkZ-mTtVVPy3t=uCA@mail.gmail.com>
From: Dave Tonge <dave.tonge@moneyhub.com>
Date: Thu, 13 Aug 2020 14:58:55 +0200
Message-ID: <CAP-T6TS_+ve6C=5YfUF_tBqyWu6OcW7TqqjXD8OGx9S42pLqSg@mail.gmail.com>
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: 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>, Denis <denis.ietf@free.fr>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009db96205acc1de21"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/q7Q3Ca5J8Tn2VecmXqv-8_OMCTU>
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 12:59:10 -0000

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