Re: [GNAP] Terminology

Fabien Imbault <fabien.imbault@gmail.com> Mon, 17 August 2020 07:38 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 98EA43A052C for <txauth@ietfa.amsl.com>; Mon, 17 Aug 2020 00:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_LOW_CONTRAST=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 h_dswjSzR8IG for <txauth@ietfa.amsl.com>; Mon, 17 Aug 2020 00:38:07 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 2A1A13A13D8 for <txauth@ietf.org>; Mon, 17 Aug 2020 00:38:07 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id p18so9861817ilm.7 for <txauth@ietf.org>; Mon, 17 Aug 2020 00:38:07 -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=JT+YA4zYXK7ET6guC4l4nlecohH2UUWF1P/hWepzIf4=; b=Rkl6Yq/R2gpLKxwiBGWsciwi9BcFZqxRq7ZF/0A29OUHcq5XzR2EsPJy65XeZww318 NH+NK2i0ZbkTxn/fC5aW1mQOL1oJP7WR0AK28KDBcX/LPoGLGXju3st2ssUmhIzpkDHc nbBkkiuSdXBcSsejG59EJ+dfgp4oQk+kIazFfD4kD6ylBVAWh0lPsl93M9Dnb42aqr79 eZAF3L8TeOuzZIUnK4oi6TvDPOm2QNnD7XnTxCRpZWTWTj3aVAsvuUxcNNha79+pgNa5 A/9tqfra7SrV/MCDq29OJfDbiQUJRi4fk5HhLjACZCOJdjvyvze6TJ9H67Yu0+8j6Fb4 BdAQ==
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=JT+YA4zYXK7ET6guC4l4nlecohH2UUWF1P/hWepzIf4=; b=i+Gs1o59XojHtvXNnhfsAqUHuqY4bspnjTO9Jfjcs9yFPHMyxWeVAeTmhI2j+SjNvU 3C8QcgNDbgisfe9vFu+nRI3Wc5URb/woh1A1NB7IoGDm0htD0fQ3ZpBpezxU7BEBoQcw UQnqYUGo3YX/vEFOnk7uLnzSlDfXN+hItzDc03lNE92nd2wu9h7sVnLToBlAb6DoeCTy PTUfMswZqhz9Y8GcwNPGmGqAMpX/jwLKmXBnWCnzWsb/dbFjeIh9WAorcuGDcJIyl1Gl IflWRsAP3dsa2vzvc6M+FFdS9YPhnS61SGAYmWb92i4EtZW+9fwFzzKuc01XAA9hWCSR nwUQ==
X-Gm-Message-State: AOAM533F4J6kGZN09AomxZGEVp5K9L0Y3cDAd7aXGJfCRDoNmV1SuffE 31X2COUh5Wr/ow6Wu6j/jg3xfuipeRaTbSGxxJk=
X-Google-Smtp-Source: ABdhPJzXeH/W6zV1SbqvuAfUmgngHMlrLzQxes4wBqjPhN9OMeQ9Knxjo7pysovW5TlEXcGNC/p5PvUNea5B5wzY1nM=
X-Received: by 2002:a05:6e02:686:: with SMTP id o6mr11715714ils.188.1597649886260; Mon, 17 Aug 2020 00:38:06 -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> <CAD9ie-vpThMuWFba0u_3BSiC9HYitS_99a5YNhDpd_XjbfUiig@mail.gmail.com>
In-Reply-To: <CAD9ie-vpThMuWFba0u_3BSiC9HYitS_99a5YNhDpd_XjbfUiig@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Mon, 17 Aug 2020 09:37:54 +0200
Message-ID: <CAM8feuQqAB_Gnm-o26S37tCDgoXHa6ZwxpNjdKSWZOT_CtX65Q@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Mike Jones <Michael.Jones@microsoft.com>, Tom Jones <thomasclinganjones@gmail.com>, Dave Tonge <dave.tonge@moneyhub.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="000000000000f237e805ad0dd9da"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/E8zpNK7MppAZvJX8NGtlF9NZvLc>
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: Mon, 17 Aug 2020 07:38:12 -0000

Thanks Dick. Assertions about the Grant Client could be cool ;-)

I think it's great that you list the terms you use in the spec, in section
1.5.

Fabien

On Sun, Aug 16, 2020 at 10:39 PM Dick Hardt <dick.hardt@gmail.com> wrote:

> Sorry Fabien, I had started this email and had not sent it.
>
> If we are successful, other ISO may build extensions on GNAP, just as
> OpenId Connect was built on top. Hopefully we will have created the right
> extension points so that it is straightforward. Here are some examples of
> other things that could be granted (I don't expect these to be worked on in
> this WG, or at least not anytime soon):
>
> - A grant of "digital money" from the Grant Server to the Grant Client.
> The GS is granting the funds to the GC with the User's authorization. This
> is not the same as authorizing a payment per the example in the wiki.
>
> - An assertion about the Grant Client made by the Grant Server,
> potentially with the User's authorization. This assertion could allow the
> GC to prove something about itself to a separate entity, or even a separate
> GS.
>
> /Dick
>
>
> On Wed, Aug 12, 2020 at 9:43 AM Fabien Imbault <fabien.imbault@gmail.com>
> wrote:
>
>> Hi Dick,
>>
>> Maybe to make that discussion more concrete, what else do you imagine
>> could be exchanged (beyond resource & idclaims)? A few examples?
>>
>> Cheers
>> Fabien
>>
>>
>>
>> On Wed, Aug 12, 2020 at 6:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>>> What is being granted is whatever is being negotiated between the Grant
>>> Server and the Grant Client -> Which fits into the name of the WG, Grant
>>> Negotiation and Authorization Protocol, allows us to have names that are
>>> specific and precise for the roles (Grant Server and Grant Client rather
>>> than Requesting Party), and is usable by an extension that wants to
>>> negotiate some new thing between the two roles.
>>>
>>> I introduced the term "Grant" in XAuth to mean what the client
>>> requested, and what the "server" provided, which included both resource
>>> access and identity claims. You are narrowly defining grant to ONLY mean
>>> "access to something". Sometimes I think you just want to disagree with me.
>>> :)
>>>
>>> I'd be interested in hearing from others!
>>>
>>>
>>>
>>> In the current drafts, that is resource access and identity claims.
>>>
>>> ᐧ
>>>
>>> On Wed, Aug 12, 2020 at 8:58 AM Justin Richer <jricher@mit.edu> wrote:
>>>
>>>> What is being granted is access to something. This makes sense in terms
>>>> of rights bound to an access token, but I would argue it makes less sense
>>>> for things returned directly.
>>>>
>>>> Since you and I also disagree on whether returning things directly is
>>>> an important distinction (even though both the XAuth and XYZ proposals make
>>>> this distinction), it doesn’t surprise me that you’d want to extend the
>>>> notion of “grant” to include anything and everything in the request and
>>>> response.
>>>>
>>>> I am arguing for it being more specific and precise.
>>>>
>>>>  — Justin
>>>>
>>>> On Aug 11, 2020, at 6:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>
>>>> A grant is whatever the client is asking from the server. Currently we
>>>> have access to resources and identity claims. It could contain anything
>>>> else an extension adds that a client may request from a server.
>>>>
>>>> Given the definition of grant that I included, why is grant not the
>>>> right term to use for this?
>>>>
>>>>
>>>> On Tue, Aug 11, 2020 at 1:35 PM Justin Richer <jricher@mit.edu> wrote:
>>>>
>>>>> I did not say the term “grant” was problematic, I said that your
>>>>> definition of it was problematic. Namely, the desire to lump in claims
>>>>> about the user into the definition of the “grant”.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> On Aug 11, 2020, at 3:49 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>>
>>>>> I agree that orchestrator may be a role in the protocol -- it is not a
>>>>> role in XYZ or XAuth today.
>>>>>
>>>>> Justin: would you explain why you think the term "grant" is
>>>>> problematic? It is in the WG name!
>>>>>
>>>>> The client is receiving more than access to resources from the GS, it
>>>>> is also receiving claims, so "client of the resource" is too limiting.
>>>>>
>>>>> Reading the definition of grant[1], it fits as a verb of what the GS
>>>>> is doing, and fits as a noun of what the GS provides to the client.
>>>>>
>>>>> A Grant Server is an Authorization Server in OAuth, and an OpenID
>>>>> Provider in OpenID Connect.
>>>>> The Grant Client is a Client in OAuth, and a Relying Party in OpenID
>>>>> Connect.
>>>>>
>>>>> Having new terms (GS and GC) in GNAP, separating the roles from OAuth
>>>>> and OpenID Connect.
>>>>> It is straightforward to know what a GC and GS do when you understand
>>>>> that a grant is a combination of resource access (from OAuth) and claims
>>>>> (from OpenID Connect).
>>>>>
>>>>> /Dick
>>>>>
>>>>> [1] https://www.dictionary.com/browse/grant
>>>>> verb (used with object)
>>>>> to bestow or confer, especially by a formal act:to grant a charter.
>>>>> to give or accord:to grant permission.
>>>>> to agree or accede to:to grant a request.
>>>>> to admit or concede; accept for the sake of argument:I grant that
>>>>> point.
>>>>> SEE MORE
>>>>> noun
>>>>> something granted, as a privilege or right, a sum of money, or a tract
>>>>> of land:Several major foundations made large grants to fund the
>>>>> research project.
>>>>> the act of granting.
>>>>>
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu>
>>>>> wrote:
>>>>>
>>>>>> I agree that “orchestration” is separate from what the classical
>>>>>> “client” in OAuth is doing — but the term “orchestrator” fits with the
>>>>>> “user agent” concept that’s been brought up here before, so I’m inclined to
>>>>>> believe it can be a separate role from the client.
>>>>>>
>>>>>> I personally think that “grant client” is confusing as it is not a
>>>>>> “client of the grant” but rather a “client of the resource”.
>>>>>>
>>>>>> I also think it’s problematic to lump in user claims with a “grant”
>>>>>> and that’s just going to muddle everything.
>>>>>>
>>>>>>  — Justin
>>>>>>
>>>>>> On Aug 11, 2020, at 3:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>>>
>>>>>> I echo Mike's comments on preserving names when possible. The shift
>>>>>> from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many.
>>>>>>
>>>>>> I also echo Tom's comments about separating Entities from Roles.
>>>>>>
>>>>>> Orchestration[1] in my opinion is not what the "client" is doing.
>>>>>>
>>>>>> Below is a stab at separating the entities and the roles
>>>>>>
>>>>>> /Dick
>>>>>>
>>>>>> *Tl;dr: *
>>>>>> - Client -> Grant Client
>>>>>> - added Relying Party, Claims Issuer, and Grant Server Operator as
>>>>>> entities
>>>>>>
>>>>>> *Roles* - parties to the protocol
>>>>>> Grant Client (GC), Grant Server (GS), Resource Server (RS)
>>>>>>
>>>>>> *Entities* - parties to a Trust Framework
>>>>>> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server
>>>>>> Operator (GSO), Resource Owner (RO)
>>>>>>
>>>>>> *Grant *- may contain claims and/or access to resources
>>>>>>
>>>>>> *#Protocol Roles*
>>>>>>
>>>>>> *Grant Client* (GC)
>>>>>> - used by User
>>>>>> - operated / provided by RP
>>>>>> - requests Grants from the GS
>>>>>> - access resources at an RS
>>>>>> - consumes Claims
>>>>>>
>>>>>> *Grant Server* (GS)
>>>>>> - operated by GSO
>>>>>> - may interact with the User
>>>>>> - may interact with the RO
>>>>>> - accepts grant requests from GCs
>>>>>> - issues grants to GCs
>>>>>> - may issue claims
>>>>>>
>>>>>> *Resource Server* (RS)
>>>>>> - manages access to resources for the RO
>>>>>> - provides access to resources for the GC
>>>>>> - accepts access granted by the GS
>>>>>>
>>>>>> *#Legal Entities*
>>>>>>
>>>>>> *User*
>>>>>> - uses Grant Client
>>>>>> - may interact with the Grant Server
>>>>>> - may also be a RO
>>>>>> - trusts RP, Issuer, GSO
>>>>>>
>>>>>> *Relying Party* (RP)
>>>>>> - provides Grant Client to the User.
>>>>>> - may trust Issuers, GSOs, and ROs
>>>>>>
>>>>>> *Claims Issuer* (Issuer)
>>>>>> - issues claims to RP
>>>>>> - may use GS or RS to issue claims
>>>>>>
>>>>>> *Grant Server Operator* (GSO)
>>>>>> - operates the GS
>>>>>> - trusted by User, RP, and RO
>>>>>> - may also be an Issuer
>>>>>>
>>>>>> *Resource Owne*r (RO)
>>>>>> - owns resources at the RS
>>>>>> - trusts GSO to control access to the resources
>>>>>> - may be same entity as the User
>>>>>> - may also be an Issuer
>>>>>>
>>>>>> [1] https://en.wikipedia.org/wiki/Orchestration_(computing)
>>>>>>
>>>>>> Orchestration (computing)
>>>>>> From Wikipedia, the free encyclopedia
>>>>>> Jump to navigation
>>>>>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#mw-head>Jump
>>>>>> to search
>>>>>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#searchInput>
>>>>>> In system administration
>>>>>> <https://en.wikipedia.org/wiki/System_administration>,
>>>>>> *orchestration* is the automated configuration
>>>>>> <https://en.wikipedia.org/wiki/Configuration_management>,
>>>>>> coordination, and management of computer systems and software
>>>>>> <https://en.wikipedia.org/wiki/Software_deployment>.[1]
>>>>>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-Erl-1>
>>>>>> A number of tools exist
>>>>>> <https://en.wikipedia.org/wiki/Category:Orchestration_software> for
>>>>>> automation of server configuration and management, including Ansible
>>>>>> <https://en.wikipedia.org/wiki/Ansible_(software)>, Puppet
>>>>>> <https://en.wikipedia.org/wiki/Puppet_(software)>, Salt
>>>>>> <https://en.wikipedia.org/wiki/Salt_(software)>, Terraform
>>>>>> <https://en.wikipedia.org/wiki/Terraform_(software)>,[2]
>>>>>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-2>
>>>>>>  and AWS CloudFormation
>>>>>> <https://en.wikipedia.org/wiki/AWS_CloudFormation>.[3]
>>>>>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-3>
>>>>>> Usage[edit
>>>>>> <https://en.wikipedia.org/w/index.php?title=Orchestration_(computing)&action=edit&section=1>
>>>>>> ]
>>>>>> Orchestration is often discussed in the context of service-oriented
>>>>>> architecture
>>>>>> <https://en.wikipedia.org/wiki/Service-oriented_architecture>,
>>>>>> virtualization
>>>>>> <https://en.wikipedia.org/wiki/Platform_virtualization>, provisioning
>>>>>> <https://en.wikipedia.org/wiki/Provisioning>, converged
>>>>>> infrastructure
>>>>>> <https://en.wikipedia.org/wiki/Converged_Infrastructure> and dynamic
>>>>>> datacenter <https://en.wikipedia.org/wiki/Datacenter> topics.
>>>>>> Orchestration in this sense is about aligning the business request with the
>>>>>> applications, data, and infrastructure.[4]
>>>>>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-4>
>>>>>> In the context of cloud computing
>>>>>> <https://en.wikipedia.org/wiki/Cloud_computing>, the main difference
>>>>>> between workflow automation
>>>>>> <https://en.wikipedia.org/wiki/Workflow_automation> and
>>>>>> orchestration is that workflows are processed and completed as processes
>>>>>> within a single domain for automation purposes, whereas orchestration
>>>>>> includes a workflow and provides a directed action towards larger goals and
>>>>>> objectives.[1]
>>>>>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-Erl-1>
>>>>>> In this context, and with the overall aim to achieve specific goals
>>>>>> and objectives (described through quality of service
>>>>>> <https://en.wikipedia.org/wiki/Quality_of_service> parameters), for
>>>>>> example, meet application performance goals using minimized cost[5]
>>>>>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-sc2011workflow-5> and
>>>>>> maximize application performance within budget constraints.[6]
>>>>>> <https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note-ipdps2013scaling-6>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <
>>>>>> Michael.Jones@microsoft.com> wrote:
>>>>>>
>>>>>>> One of the things that people hated about OAuth was it invented new
>>>>>>> terminology that wasn’t in common use.  But for better or for worse, the
>>>>>>> terms Client, Authorization Server, and Protected Resource are now widely
>>>>>>> understood.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Let’s not make people similarly hate GNAP by inventing even more
>>>>>>> novel terms, when existing terms will fit the bill.  Client wasn’t a
>>>>>>> perfect choice but adding “Orchestrator” to the vocabulary menagerie would
>>>>>>> definitely make things worse.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                                                        -- Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* TXAuth <txauth-bounces@ietf.org> *On Behalf Of *Tom Jones
>>>>>>> *Sent:* Tuesday, August 11, 2020 8:44 AM
>>>>>>> *To:* Dave Tonge <dave.tonge@moneyhub.com>
>>>>>>> *Cc:* Francis Pouatcha <fpo@adorsys.de>de>; Justin Richer <
>>>>>>> jricher@mit.edu>gt;; Dick Hardt <dick.hardt@gmail.com>om>; Benjamin Kaduk
>>>>>>> <kaduk@mit.edu>du>; Fabien Imbault <fabien.imbault@gmail.com>om>; Denis <
>>>>>>> denis.ietf@free.fr>gt;; txauth@ietf.org
>>>>>>> *Subject:* Re: [GNAP] Terminology
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> the term "orchestator" does not match any use case i have.
>>>>>>>
>>>>>>> Let's be clear that there are four entities to a single transaction
>>>>>>> in the real world sense of things. (and others that support the
>>>>>>> transaction.)
>>>>>>>
>>>>>>> Then we can focus on the end point roles. I will focus on the data
>>>>>>> privacy issues, API's have the same parties with different terminology.
>>>>>>>
>>>>>>> 1. the subject of the data to be transferred.
>>>>>>>
>>>>>>> 2. the user of a grant from the subject to act as delegate. (see
>>>>>>> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable
>>>>>>> the user)
>>>>>>>
>>>>>>> 3. the site that has a repository of user data with legal
>>>>>>> obligations to protect that data (the GDPR) (role resource server.)
>>>>>>>
>>>>>>> 4 the site that wants either access to the data, or some privacy
>>>>>>> preserving statement about the existence and content of the data. (role of
>>>>>>> client, vendor, PISP, etc.)
>>>>>>>
>>>>>>> 5. some sorts of facilitator sites for allowing access (roles like
>>>>>>> authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been left
>>>>>>> out of OAUTH for good reason.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is a note supporting the separation of roles from legal
>>>>>>> entities.  BTW, I firmly believe that the legal entity also needs to be
>>>>>>> ID'd by the transaction.
>>>>>>>
>>>>>>> Peace ..tom
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <dave.tonge@moneyhub.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi all
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I agree that "client" can be confusing. I would be in support of
>>>>>>> alternative terminology.
>>>>>>>
>>>>>>> We can always have some wording that explains that an "Orchestrator"
>>>>>>> in GNAP plays a similar role to "Client" in OAuth.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Dave
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault <
>>>>>>> fabien.imbault@gmail.com> wrote:
>>>>>>>
>>>>>>> Hi Francis,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I like your proposal, seems much more intuitive.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fabien
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le mar. 11 août 2020 à 04:17, Francis Pouatcha <fpo@adorsys.de> a
>>>>>>> écrit :
>>>>>>>
>>>>>>> Hello Denis, Justin, Dick, Fabien,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In this post (
>>>>>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/)
>>>>>>> i suggested we use the word "Orchestrator" to designate the piece of
>>>>>>> software that orchestrate interaction between "Requestor" (a.k.a. User), AS
>>>>>>> and RS to obtain the protected resource.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We are turning around the same topic. As soon as we go beyond the
>>>>>>> original oAuth protocol, the word 'Client' becomes confusing.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In the same response, I suggest we talk about "roles" and not
>>>>>>> "entities".
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /Francis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <dick.hardt@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I still think that client was the right name in OAuth 2, as the
>>>>>>> client wanted to do a client-server interaction, so the client used OAuth 2
>>>>>>> to get an access token to interact with the "server".
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /Dick
>>>>>>>
>>>>>>> ᐧ
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer <jricher@mit.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The term client in OAuth came from the computer science definition
>>>>>>> of client-server interaction.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This, I would argue, is exactly why it’s a bad label for something
>>>>>>> that’s distinctly more specific in this context, and I would love to see
>>>>>>> GNAP adopt a more specific label for the role that we traditionally called
>>>>>>> “client” in OAuth.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  — Justin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The client is getting an access token so it can call a server,
>>>>>>> specifically, a resource server (to differentiate it from the authorization
>>>>>>> server).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ᐧ
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <
>>>>>>> fabien.imbault@gmail.com> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> To me, client has always been a strange word in the context of
>>>>>>> OAuth, as it has a meaning well defined both in everyday life (this client
>>>>>>> is a good customer) and in computer science (client-server interaction).
>>>>>>> Thus I always have to make the mental translation to the OAuth world before
>>>>>>> any discussion... And any teaching experience shows that it does make the
>>>>>>> concepts hard to grasp for a majority of (clever) people.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As for the RO, previous discussions suggested Resource
>>>>>>> Controller (RC) also, which may be a bit more specific than manager.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fabien
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr> wrote:
>>>>>>>
>>>>>>> Justin and Dick,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [Was:  "Revisiting the photo sharing example (a driving use case for
>>>>>>> the creation of OAuth)"]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> So let us attempt to define new terms:
>>>>>>>
>>>>>>> *initiating application (IA)*: application by means of which a user
>>>>>>> initiates interactions with RS(s) and AS(s)
>>>>>>>
>>>>>>> In the same way, we should get rid of the term Resource Owner (RO),
>>>>>>> which is currently defined as:
>>>>>>>
>>>>>>> Resource Owner (RO): entity capable of granting access to a
>>>>>>> protected resource
>>>>>>>
>>>>>>> I propose to replace it with Resource Manager (RM):
>>>>>>>
>>>>>>> *Resource Manager (RM)* : application or user that manages an
>>>>>>> access decision function of a Resource Server
>>>>>>>
>>>>>>> Denis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I agree with Justin. Redefining well used terms will lead to
>>>>>>> significant confusion. If we have a different role than what we have had
>>>>>>> in the past, then that role should have a name not being used already in
>>>>>>> OAuth or OIDC.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Given what we have learned, and my own experience explaining what a
>>>>>>> Client is, and is not, improving the definition for Client could prove
>>>>>>> useful. I am not suggesting the term be redefined, but clarified.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For example, clarifying that a Client is a role an entity plays in
>>>>>>> the protocol, and that the same entity may play other roles at other times,
>>>>>>> or some other language to help differentiate between "role" and "entity".
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /Dick
>>>>>>>
>>>>>>> ᐧ
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I’m in favor of coming up with a new term that’s a better fit, but
>>>>>>> I’m not really in favor of taking an existing term and applying a
>>>>>>> completely new definition to it. In other words, I would sooner stop using
>>>>>>> “client” and come up with a new, more specific and accurate term for the
>>>>>>> role than to define “client” as meaning something completely different. We
>>>>>>> did this in going from OAuth 1 to OAuth 2 already, moving from the
>>>>>>> even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the
>>>>>>> term “consumer” at all, nor does it use “server” on its own but instead
>>>>>>> always qualifies it with “Authorization Server” and “Resource Server”.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> GNAP can do something similar, in my opinion. But what we can’t do
>>>>>>> is ignore the fact that GNAP is going to be coming up in a world that is
>>>>>>> already permeated  by OAuth 2 and its terminology. We don’t have a blank
>>>>>>> slate to work with, but neither are we bound to use the same terms and
>>>>>>> constructs as before. It’s going to be a delicate balance!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  — Justin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think that is fundamentally part of the question:
>>>>>>>
>>>>>>> We are clear that we are producing a protocol that is
>>>>>>> conceptually (if not more strongly) related to OAuth 2.0, and
>>>>>>> reusing terms
>>>>>>> from OAuth 2.0 but with different definitions may lead to unnecessary
>>>>>>> confusion
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If we say that this document assumes OAuth2.0 terminology, then we
>>>>>>> should not change the meanings of any definition. If we are saying this
>>>>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick the best
>>>>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I have a
>>>>>>> lot of first hand experience of industries "ruining words", and attempting
>>>>>>> to side-step the problem rather than redefining the word just confuses
>>>>>>> everyone as everyone forgets the original meaning as new documents come
>>>>>>> out, but the confusion with the use of a non-obvious word continues.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Food for thought.
>>>>>>>
>>>>>>> - Warren
>>>>>>>
>>>>>>>
>>>>>>> *Warren Parad*
>>>>>>>
>>>>>>> Founder, CTO
>>>>>>>
>>>>>>> Secure your user data and complete your authorization architecture.
>>>>>>> Implement Authress <https://bit.ly/37SSO1p>.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>>>>>>>
>>>>>>> Hi Denis,
>>>>>>>
>>>>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
>>>>>>> > Hi Justin,
>>>>>>> >
>>>>>>> > Since you replied in parallel, I will make a response similar to
>>>>>>> the one
>>>>>>> > I sent to Dick.
>>>>>>> >
>>>>>>> > > Hi Denis,
>>>>>>> > >
>>>>>>> > > I think there’s still a problem with the terminology in use
>>>>>>> here. What
>>>>>>> > > you describe as RS2, which might in fact be an RS unto itself,
>>>>>>> is a
>>>>>>> > > “Client” in OAuth parlance because it is /a client of RS1/. What
>>>>>>> you
>>>>>>> > > call a “client” has no analogue in the OAuth world, but it is
>>>>>>> not at
>>>>>>> > > all the same as an OAuth client. I appreciate your mapping of
>>>>>>> the
>>>>>>> > > entities below, but it makes it difficult to hold a discussion
>>>>>>> if we
>>>>>>> > > aren’t using the same terms.
>>>>>>> > >
>>>>>>> > > The good news is that this isn’t OAuth, and as a new WG we can
>>>>>>> define
>>>>>>> > > our own terms. The bad news is that this is really hard to do.
>>>>>>> > >
>>>>>>> > > In GNAP, we shouldn’t just re-use existing terms with new
>>>>>>> definitions,
>>>>>>> > > but we’ve got a chance to be more precise with how we define
>>>>>>> things.
>>>>>>> >
>>>>>>> > In the ISO context, each document must define its own terminology.
>>>>>>> The
>>>>>>> > boiler plate for RFCs does not mandate a terminology or
>>>>>>> definitions section
>>>>>>> > but does not prevent it either. The vocabulary is limited and as
>>>>>>> long as
>>>>>>> > we clearly define what our terms are meaning, we can re-use a term
>>>>>>> already
>>>>>>> > used in another RFC. This is also the ISO approach.
>>>>>>>
>>>>>>> Just because we can do something does not necessarily mean that it
>>>>>>> is a
>>>>>>> good idea to do so.  We are clear that we are producing a protocol
>>>>>>> that is
>>>>>>> conceptually (if not more strongly) related to OAuth 2.0, and
>>>>>>> reusing terms
>>>>>>> from OAuth 2.0 but with different definitions may lead to unnecessary
>>>>>>> confusion.  If I understand correctly, a similar reasoning prompted
>>>>>>> Dick to
>>>>>>> use the term "GS" in XAuth, picking a name that was not already used
>>>>>>> in
>>>>>>> OAuth 2.0.
>>>>>>>
>>>>>>> -Ben
>>>>>>>
>>>>>>> --
>>>>>>> Txauth mailing list
>>>>>>> Txauth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>> --
>>>>>>> Txauth mailing list
>>>>>>> Txauth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> TXAuth mailing list
>>>>>>> TXAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> TXAuth mailing list
>>>>>>> TXAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> TXAuth mailing list
>>>>>>> TXAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Francis Pouatcha
>>>>>>>
>>>>>>> Co-Founder and Technical Lead
>>>>>>>
>>>>>>> adorsys GmbH & Co. KG
>>>>>>>
>>>>>>> https://adorsys-platform.de/solutions/
>>>>>>>
>>>>>>> --
>>>>>>> TXAuth mailing list
>>>>>>> TXAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *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.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> TXAuth mailing list
>>>>>>> TXAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>