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

[Dick Hardt <[e-mail]>]

Hi Francis

The user is an entity, not a role in the protocol in how I am defining
roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of
the core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <[e-mail]> wrote:

> In this context, I suggest we pick some words to work with, and sharpen
> them as we move on, discover and map new use cases to the protocol.
>
> In this diagram from the original thread (
> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/),
> I replaced the words:
>
> +-----------+      +--------------+  +----+  +----+
>  +---------------------+
> | Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller
> |
> |   was     |      |     was      |  | RS |  | or |  |         was
>  |
> |  User     |      |   Client     |  |    |  | AS |  |    Resource Owner
>  |
> +-----------+      +--------------+  +----+  +----+
>  +---------------------+
>   |(1) ServiceRequest     |            |       |                |
>   |---------------------->|            |       |                |
>   |                       |(2) ServiceIntent:AuthZChallenge     |
>   |                       |<---------->|       |                |
>   |                       |            |       |                |
>   |                       |(3) AuthZRequest(AuthZChallenge)     |
>   |                       |------------------->|                |
>   |                       |            |       |(4) ConsentRequest:Grant
>   |                       |            |       |<-------------->|
>   |                       |(5) GrantAccess(AuthZ)               |
>   |                       |<-------------------|                |
>   |                       |            |       |                |
>   |                       |(6) ServiceRequest(AuthZ):ServiceResponse
>   |                       |<---------->|       |                |
>   |(7) ServiceResponse    |            |       |                |
>   |<----------------------|            |       |                |
>   +                       +            +       +                +
>
> The purpose of the GNAP protocol is to help negotiate access to a
> protected resource. It starts with a requestor delegating activity to an
> orchestrator. These are all roles, no entities. Let focus on mapping the
> use cases to the protocol roles and interactions so wwe can discover what
> is missing.
>
> It seems cumbersome to use it in discussions as it is impossible to give
> the word "Client" a clear definition.
>
> We can mention in the final document, that the "Orchestrator" (or whatever
> word we finally use) plays the same role as the "Client" in oAuth2.
>
> Best regards.
> /Francis
>
>
>
>
>
> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <[e-mail]> wrote:
>
>> 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
>> <[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
>>
>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>