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 14:59 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 80EE43A0D05 for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 07:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_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 6GMljjXewv_U for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 07:59:57 -0700 (PDT)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 5DA2D3A0CFA for <txauth@ietf.org>; Thu, 13 Aug 2020 07:59:56 -0700 (PDT)
Received: by mail-oi1-x236.google.com with SMTP id n128so1450265oif.0 for <txauth@ietf.org>; Thu, 13 Aug 2020 07:59:56 -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=GTKrLehP7L2nBykdm5El+3R+SOQdQfvwi/MXjF6PzpY=; b=evmGH5QH/8XWv+S2GnAiLcQ3NYSHgJyhuCwpgwTOnj4jVPoOwdonTVUiUnHYnqUFtZ do4kM6AeZxG8g0L90bunRB8bt7RhqWcF7wRH8ViVw73BPfDQjGku5pVi4mxf7EiK7vM8 grHnzAgbmln86MpGOD3QVuRLpdAEWpCQZcifUUPDUuc6V7gQk0+qk0uRvWGMfpSunUs1 W7oMev7V1AuyRW8Edhh5xZjuVzjx6FdvZHUh9VTpCqsKZZ6fNeWtkCCJKRoNuMsoKPLN JchKaoieTncP/w42C9YssfdO420nb/ef+UkwejERJa+M8FvuIr3aThzeNXgMYtzsgEZT fNDA==
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=GTKrLehP7L2nBykdm5El+3R+SOQdQfvwi/MXjF6PzpY=; b=GI7Nd1dgyVQP62XuIVxgVbPPbWJdvkedx8tw6RH9TPM7ZGiXgyYJmTvprxyq9brEcq WZRCIsYd6BTLnlqkm/HyfrFkO7ThjQWpkN6U68T1aN8eoUmxbaqdQQ5Jo6O8Xzxm9t2Z qBrRKN8dTXUQa1rHBx46xRUvPj5jWNNSRyi/kW2xS/WHUPFsB9+Xg2+Zeh6L4H2P8/Mj 8kOBVpy/awepxPJAa12GdwSVYWYcaszMEA3g1R/w2SNWFsU3wvY4aLP7IaF2tEruv2IS H/PSM9A2T/5+TIMBvSoNjKLB7PhTjeRitCb5gIJVlvw5AR6dEvEeyzIHS41RhUOqTrhv kv/w==
X-Gm-Message-State: AOAM5308egQ3wRi+MUXnHteX2WMymG125sUE0NGgx7gDUqph0TkAvaGU 0J/Qejd9fs6GTvXc1lJ3D3KQcuOHQ1obko2Pef0=
X-Google-Smtp-Source: ABdhPJyYA3NhJ4laPiNdGiPp3WxQg2F6tVB2waCEBut0TwLia3SwZltZEx+UnRhrQUTav1YgByC+EU5WhsfVOF5DA4M=
X-Received: by 2002:a54:448f:: with SMTP id v15mr3772374oiv.172.1597330795500; Thu, 13 Aug 2020 07:59:55 -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>
In-Reply-To: <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Thu, 13 Aug 2020 07:59:43 -0700
Message-ID: <CAK2Cwb5ZVpTzOtQBGcw5zgteGe5EGR9sMBxWVrQ2mZP7-tc-kg@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Dick Hardt <dick.hardt@gmail.com>, 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="000000000000a79ad605acc38ec9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/P7Yhtkyp82TITUIMRWnHxbym2xY>
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 15:00:01 -0000

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
>