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

Fabien Imbault <fabien.imbault@gmail.com> Tue, 04 August 2020 23:15 UTC

Return-Path: <fabien.imbault@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 5CF653A111B for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 16:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, T_KAM_HTML_FONT_INVALID=0.01, 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 Au8xmvLdcx0v for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 16:15:50 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 521343A1119 for <txauth@ietf.org>; Tue, 4 Aug 2020 16:15:50 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id p13so7297079ilh.4 for <txauth@ietf.org>; Tue, 04 Aug 2020 16:15:50 -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=ex04AsWaUeEYKvNXLn0L1AsjOjljPXJerVvX/cbtE6k=; b=RF9WJo5bs3YWeOZRhyaTM3Ue4zT8euSEGb5QN2C78RAW3wXtYgRong7dt2A0ppl9QM NUJoUow1AtNrRkaDAQu9HkBq7cw+gMpuI2Xy5VbBI3b+eNRqIHyGHJqxrEEiHuobqCiF O1ntj7r7d4JIYqDBcnjow7VKk733WBqXKlauLxxHNEsOFnqmXydyqjhlBFWHMi/zCUa8 UNohZjxt4We3emWiHb6G1jiXWS9Uwxw3ylO1IQpBvFLHI7QjCojbIZyAcMnsVO7wqW1z irsh173kx2PN04l/RGkM4x8mRsjISYTnH5R4ZElKxjQUkRoI++fKE2mexU0X6MrMLRwT oYrw==
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=ex04AsWaUeEYKvNXLn0L1AsjOjljPXJerVvX/cbtE6k=; b=BktJOkmV+NGFkAiKgw7fd3ZRdZ3JgV/1k2YlVIwA8BcEeHEoJzCDT41zUW15zURSFy YEHfQuLTXpCwXDQjxxG79IVUeUAcN+r+IpSonXaF97UHTIzXmFKJybsU2Z//eD+EDKup D/Ubppv18HYjlLG43b2zKYbxJOb6qDUNvpQ8OA088qrDCUciIkS26yOmuCBPdWOE8L/h dpW6WZ5iUfx4i2HIHAtBE508/fEMmL1V1Q+1YfC09ziekLAtNT/T5kjpRrQG53LWRouV yFiXJ2HPtDx2lekfDUPBOH7y003fhY3zhOWz8zCdI7nRT1Bfa+gNO8otXiStv6z2W46s yghQ==
X-Gm-Message-State: AOAM533N/3t/Y8Usa+98SBK89ZNrxb08xcQfvVqTHmTF1xs3h+mHD8vs H6IOeR7EDA8fIP3227gEolgW2Pi6nyjfUzmnQRk=
X-Google-Smtp-Source: ABdhPJxj3l2xhordXsV6Nw6CpJ7FZ0kmCbyWv3vCvqqBaZYgNZFGw6riJk4zKlaHdT6ZURhsDbks0fv9aavy/yf7S94=
X-Received: by 2002:a92:d781:: with SMTP id d1mr826386iln.68.1596582949646; Tue, 04 Aug 2020 16:15:49 -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>
In-Reply-To: <CAJot-L2hykst2vFxcwLn_auDMMaw7psVwsKFHKhQp9DA49ydWg@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Wed, 5 Aug 2020 01:15:37 +0200
Message-ID: <CAM8feuST1XJaiSh+-cVur46tmOuu+tR5pdXrgP3uq6Zv1Td9zw@mail.gmail.com>
To: Warren Parad <wparad@rhosys.ch>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Denis <denis.ietf@free.fr>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009175e205ac156fd7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/3FhsbwIN0Q95dWso3vuP_IVKTzI>
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: Tue, 04 Aug 2020 23:15:52 -0000

+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 <wparad@rhosys.ch> 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 <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
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>