Re: [GNAP] Terminology

[Dick Hardt <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> *On Behalf Of *Tom Jones
> *Sent:* Tuesday, August 11, 2020 8:44 AM
> *To:* Dave Tonge <[e-mail]>
> *Cc:* Francis Pouatcha <[e-mail]>; Justin Richer <[e-mail]>;
> Dick Hardt <[e-mail]>; Benjamin Kaduk <[e-mail]>; Fabien
> Imbault <[e-mail]>; Denis <[e-mail]>;
> [e-mail]
> *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 <[e-mail]>
> 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 <[e-mail]>
> wrote:
>
> Hi Francis,
>
>
>
> I like your proposal, seems much more intuitive.
>
>
>
> Fabien
>
>
>
> Le mar. 11 août 2020 à 04:17, Francis Pouatcha <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
>
> On Aug 6, 2020, at 12:53 PM, Dick Hardt <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>
> --
> TXAuth mailing list
> [e-mail]
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>