Re: [GNAP] Terminology

[Fabien Imbault <[e-mail]>]

Hi,

I agree with that process.

Just as an additional reference (more related to identity),
https://canada-ca.github.io/PCTF-CCP/PCTF.html demonstrates I think the
importance of the terminology. In that case, they bring many useful
definitions (appendix A). By the way, for them, client is "The intended
recipient for a service output. External clients are generally persons
(Canadian citizens, permanent residents, etc.) and businesses (public and
private sector organizations). Internal clients are generally employees and
contractors."

Another example, less obvious: instead of authentication which is a very
overloaded term, you end up with verification and validation for identity
and credential (appendix D).

Then of course one needs to find the right mix between reinventing the
wheel (and the risk of making it hard to get into) and being specific
enough.

Fabien

On Tue, Aug 11, 2020 at 7:25 PM Denis <[e-mail]> wrote:

> To all,
>
> We are circling around. In order to progress about the terminology, I
> propose the following:
>
> 1° Adopt the ISO rule for a definition:
>
> The definition shall be written in such a form that it can replace the
> term in its context.
> It shall not start with an article (“the”, “a”) nor end with a full stop.
> A definition shall not take the form of, or contain, a requirement.
>
> 2° Propose at the same time a term AND its definition.
>
> 3° If you don't like a term or its definition proposed by someone else,
> this is fine ... but only as long as
> you have a counter proposal for either the term and/or its definition. As
> an example, only stating that
> " "client" can be confusing" would not be a valid proposal.
>
> Terms and definitions are used in the context of RFCs issued by a WG and
> it is fine using terms
> already used by other RFCs issued by another WG as long as we clearly
> define them.
>
> Denis
>
> 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]> <[e-mail]> *On
> Behalf Of *Tom Jones
> *Sent:* Tuesday, August 11, 2020 8:44 AM
> *To:* Dave Tonge <[e-mail]> <[e-mail]>
> *Cc:* Francis Pouatcha <[e-mail]> <[e-mail]>; Justin Richer
> <[e-mail]> <[e-mail]>; Dick Hardt <[e-mail]>
> <[e-mail]>; Benjamin Kaduk <[e-mail]> <[e-mail]>;
> Fabien Imbault <[e-mail]> <[e-mail]>;
> Denis <[e-mail]> <[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
>
>
>