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

Tom Jones <thomasclinganjones@gmail.com> Thu, 13 August 2020 16:25 UTC

Return-Path: <thomasclinganjones@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3C33A0B31 for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 09:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDmwp3_fkxQk for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 09:25:13 -0700 (PDT)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3263A0E57 for <txauth@ietf.org>; Thu, 13 Aug 2020 09:25:13 -0700 (PDT)
Received: by mail-ot1-x32b.google.com with SMTP id v21so5239299otj.9 for <txauth@ietf.org>; Thu, 13 Aug 2020 09:25:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VNF72MRUBBCz5ywb1zVgnKHJvxvZlvVslWrAQw98N4I=; b=vTA1yKGC/uSILQvY5QHLzQYpSLrX0/sdNZIaHHoP39Wa9krtrNu2gc1aC/PhW1g+/q G+UGVmJgMnj4d/5mCH810mCWMwkCT/qnXQcvvhjSnTnjav92rGfh5FVc8wof77tu5fz0 htDnbvhu9j+9oEN6bIyKV4vBnbjBmjbwKwnFOcUfe1wqLRXDsvB2xgMB5f5mPYUW0O73 hFGz7Vc48u8PGGrTGQU/X8sqHVl5uBIvvLXYvAZIxy4n1P/c0UXGb03wrdbeg1moqQbI VIcBSIfxUm9h+xWdyfpp/CMcjvixJmZm44T/d5K63mFXqAKsNPEzWbVzZSoLNnD7U9Od rNaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VNF72MRUBBCz5ywb1zVgnKHJvxvZlvVslWrAQw98N4I=; b=TAjoerXMh8RT0vz0feBX+9B+9O4v+SDDLQVd+tFCSV/q2W6A/UbeEMAhXAUN7R9fnd O0DT2s/pNyCSBB6kLjtbaCfcXSX1hbomkymCO3L1W/LgzRSicSFVgkesaA2ZBXH4DWhk qeZNrU5A/x9Qs9dh3+WDkAdzZbdasqFaAqdlTZctY1mH22L0aQHkUDE4NTF5VXGAbS+7 jt7vXrV3kjsTVWB9t2Oxbch3mb3nx47EbL7iTbeBTyRm4f5DU5gjKJ4oEPaIfCxSc48x TTcW+/LcRMiYKX6zdMNaji9zIM1cgdE0Z5GsUjCQCDnpiXYr1eC9Og92F5cATn8H0lyC LnmQ==
X-Gm-Message-State: AOAM532AZtBlWE3NnsQXmL9Sp5CCbci7kSB/wZsBUC6s6x1vFFR/jVIj YeosHNkEMR37d7NEMYp8IoDxQUkgezQk6hOM6n8=
X-Google-Smtp-Source: ABdhPJx1/NZmjA+625vAtIca1UXbjLjURj14aBeeZcSOen3ahBocVdfzW800bEOFRQgRfxdoJvHeAVBW+2lYi6Zffw4=
X-Received: by 2002:a9d:3e49:: with SMTP id h9mr4808527otg.87.1597335912608; Thu, 13 Aug 2020 09:25:12 -0700 (PDT)
MIME-Version: 1.0
References: <c5f40413-93b8-2e8c-0a3e-14a07cd27ad0@free.fr> <ECF217AE-1D67-4EAE-AE51-531F6EE6E222@mit.edu> <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <CAJot-L2hykst2vFxcwLn_auDMMaw7psVwsKFHKhQp9DA49ydWg@mail.gmail.com> <A4DC7B4E-FD34-454F-9396-B971CF5D57A4@mit.edu> <CAD9ie-tKEp+PV3F4p84Zbu7Kd1dQutawnzHybt8cmg-XniLYLQ@mail.gmail.com> <CAOW4vyN4ifCXmk1XAyGK4cEfY1jTp6+AWOL-uNjEpVcp0Ku0UQ@mail.gmail.com> <CAD9ie-ugjNevqKAPWFjKqGMMpCvX6yyC=M4bs9naenJf-k9uqg@mail.gmail.com> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <CAK2Cwb5ZVpTzOtQBGcw5zgteGe5EGR9sMBxWVrQ2mZP7-tc-kg@mail.gmail.com> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> <CAD9ie-vrFmSMY6bC4BqtpVn9i6MeFnghOXaHfdhXvOr59u1rzg@mail.gmail.com>
In-Reply-To: <CAD9ie-vrFmSMY6bC4BqtpVn9i6MeFnghOXaHfdhXvOr59u1rzg@mail.gmail.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Thu, 13 Aug 2020 09:25:00 -0700
Message-ID: <CAK2Cwb4hBe0Bug1g2ACwX04vYZEP5wOLjjM+WotZ_ABjw8mqPA@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Francis Pouatcha <fpo@adorsys.de>, Denis <denis.ietf@free.fr>, Benjamin James Kaduk <kaduk@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a87a1305acc4bf8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/uihzSL0mKBOQfbiaA_sXUv777nw>
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2020 16:25:16 -0000

If you want to refer to the role i believe the correct term is user agent.
Peace ..tom


On Thu, Aug 13, 2020 at 8:27 AM Dick Hardt <dick.hardt@gmail.com> wrote:

> I think Tom's objection, and I agree with it, is that humans don't
> interact in bits and bytes.
>
> I think it is useful to separate human interactions with software from
> software interactions with software. The latter we can standardize, the
> former we can call out as part of the overall process, but it is not
> something that is testable or required for interop, so I would argue human
> to software interactions are NOT part of the protocol.
>
> ᐧ
>
> On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
>
>> It’s a role fulfilled by a person, so I’m not sure where the objection
>> you’re raising comes from.
>>
>> Also, whatever roles we define here, whether software or human-ware, they
>> need to be related to the protocol.
>>
>>  — Justin
>>
>> On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com>
>> wrote:
>>
>> I strong object to the objectification of human users. It is way past
>> time that the IETF becaume user oriented instead of web service oriented.
>> users are human in my language.
>> Peace ..tom
>>
>>
>> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
>>
>>> If defined as the party operating the client software, then the user is
>>> a role. I believe this is more accurate and inclusive than the definition
>>> you have proposed with the user as an entity.
>>>
>>>  - Justin
>>> ________________________________________
>>> From: Dick Hardt [dick.hardt@gmail.com]
>>> Sent: Tuesday, August 11, 2020 6:21 PM
>>> To: Francis Pouatcha
>>> Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
>>> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a
>>> driving use case for the creation of OAuth)
>>>
>>> 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 <fpo@adorsys.de<mailtomailto:
>>> fpo@adorsys.de>> 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 <dick.hardt@gmail.com<mailtomailto:
>>> dick.hardt@gmail.com>> 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
>>> [
>>> https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ
>>> <https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]%E1%90%A7>
>>>
>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:
>>> jricher@mit.edu>> 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 <wparad@rhosys.ch<mailtomailto:
>>> wparad@rhosys.ch>> 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
>>>
>>> [
>>> https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA
>>> ]
>>>
>>> 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 <kaduk@mit.edu<mailtomailto:
>>> kaduk@mit.edu>> 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
>>> Txauth@ietf.org<mailto:Txauth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/txauth
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org<mailto:Txauth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>> --
>>> TXAuth mailing list
>>> TXAuth@ietf.org<mailto:TXAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/txauth
>>> --
>>> TXAuth mailing list
>>> TXAuth@ietf.org<mailto:TXAuth@ietf.org>
>>> 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
>>> TXAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>>