[GNAP] Terminology

[Denis <[e-mail]>]

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] 
> <mailto:[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]
>>     <mailto:[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]
>>     <mailto:[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] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/txauth
>>
>>     -- 
>>     Txauth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/txauth
>
>     -- 
>     TXAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/txauth
>