Re: [GNAP] Terminology

Fabien Imbault <fabien.imbault@gmail.com> Wed, 12 August 2020 16:43 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 092563A13CC for <txauth@ietfa.amsl.com>; Wed, 12 Aug 2020 09:43:49 -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 A5LUF-1ovQ9b for <txauth@ietfa.amsl.com>; Wed, 12 Aug 2020 09:43:43 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 950EA3A1154 for <txauth@ietf.org>; Wed, 12 Aug 2020 09:43:43 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id v6so3424592iow.11 for <txauth@ietf.org>; Wed, 12 Aug 2020 09:43:43 -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=rLA7B0ruv8WNQCB5Hx754jSIechYwfrslAPbDUxXShw=; b=my5NcIIWwzknZljEpc8vsHkzR8gVN1SKW6EpIomWY6+p/qnEoWgdVLby2hrl1sIgfC yjj9PK5J/RCt4+j58W4GsWyoDEbimh28CV3TZcvCwfOo5O2f0PSC36AIlxlhRUDcyX5l 9CcvyddR5Omnro5Mgifj2VUvAd3DvkHLCyd7ClORM9fgWIrj3LtwbzaW0Tcx1LPGhbJO 7od/iBq3lHRaOSBSYVBU9RGBf+47qp+QOfKeS6CI/xrxSJz96syTxLKohDpsTR00fFak EWo5FipzKNVVzXVMG2SEtRM0dEFdJ41nh7ISx+DKR1GXKvu+nrYImKRtOIlBhm7Jn98D ingg==
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=rLA7B0ruv8WNQCB5Hx754jSIechYwfrslAPbDUxXShw=; b=iK8UBD5QaACD5136kqxyKe+ZO3l5HBe6PhCJkNy/RHr/XVxBsp+vldYBJu1d5m0G0A 86N5ACJmfNfGuXY9TNyNHQvVeRKfuS2+iwuBBZrQJf3E23pT7euzeFGdtSH20g7yriD3 PQcVM4QYOlTXSdrY0bmvvA72Bj2H7BzggQFI6E/nli1PB64NraIZ4mpXmsHd/aAgq7dq Dx9qfwwg2q2e4qMSU24LXo771xDlUwu41lkek1BOs1liF3P0SceWalOUX2HzEvyMyhvw tnIMIhuwQnhjuu0sX6ZqDzk5OZdH/Q+Qka8HwG+rqzlV2gnYjcSKVKPs5Hgei06JOl0L 1Phg==
X-Gm-Message-State: AOAM530w0bYi/VC8Qm9Ou0jkqoz8amcKJTcJ/EJcksvF06uO1p/sEgCg uWxQTV2JOcE+ekTP/Q+uMC8s3+rwTySu0dAvgeE=
X-Google-Smtp-Source: ABdhPJwlWSE0ddJ9oUJczzvLGauWtrXva163jLv1dXIaAeGEIrkc+Xd89r858Xl6u+DA93+FksEiCr1B98Dz0Cvijzc=
X-Received: by 2002:a5d:8041:: with SMTP id b1mr680742ior.74.1597250622793; Wed, 12 Aug 2020 09:43:42 -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>
In-Reply-To: <CAD9ie-scGz1s=q=g=GSD9gL3X3O3rHG0ukQVPewZ6dMw5dDeHw@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Wed, 12 Aug 2020 18:43:31 +0200
Message-ID: <CAM8feuRiT4wk827M_o=TEEW9FtZk3PaBR1AFr2seT5GJ+ZoLKw@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="000000000000fd2d5b05acb0e3ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/5rZFpnn9S5QlfS-jPYEGXtZ5oGY>
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: Wed, 12 Aug 2020 16:43:49 -0000

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>gt;; 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
>>>>>
>>>>>
>>>>
>>>
>>