Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

[Fabien Imbault <[e-mail]>]

+1 on making necessary changes. Keeping the status quo is a good idea only
if it fits with the new purpose of the work. Based on what we learned from
years of experience, I think we should be open to revising the terminology.

Fabien

Le mar. 4 août 2020 à 21:32, Warren Parad <[e-mail]> a écrit :

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