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

Warren Parad <wparad@rhosys.ch> Tue, 04 August 2020 19:32 UTC

Return-Path: <wparad@rhosys.ch>
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 0DB533A1145 for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 12:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, 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 (1024-bit key) header.d=rhosys.ch
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 hCu9dpDMUF-2 for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 12:32:46 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 38B933A1141 for <txauth@ietf.org>; Tue, 4 Aug 2020 12:32:46 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id a65so22293656otc.8 for <txauth@ietf.org>; Tue, 04 Aug 2020 12:32:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dm11nECxBMXC6pD40LBIJ+x3ZrOAyGALvHti0/a/xn4=; b=Pg3hPRoTfLb5XNa9gcOpq4vbexC7cli/jNlHlHxcnGzxULvIcx2f2FOf4hCWpRzPO5 G4E9biMnNpmnUlXGRJ3/P7TTZvuLA/z3K92eJZZDSstL7l9hobJqIA8cbXkIpUtph/8X ad1BlzhS2eS72UeDeqftmgimS8NIUzLfG0q84=
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=dm11nECxBMXC6pD40LBIJ+x3ZrOAyGALvHti0/a/xn4=; b=uMfYHEOTglC2BYDPW28GhapuPTaBwEkDGbu6n951FG431sS+VxhlkLBgQV6zqiEemw l9vlMa+/p997WqzaIfD0B4SaTCVwxCp6/B9r6hXmYbmRmsKjCToC/wPYxbXANnUhYrEy E1wtAYuhKmXcWHc957fBCoCTGseHXgtRRgT3BFxhYBP3BGLBbwRKgRUCWNfBcWdteqhc ZRZQwYUxD0nrqFMQF2muKjnmvJ4KQdRFc8oVce4bme3JjTZTeYySYCL7JJpTkv2LaZnQ qoo7XngptjBlKhGk+myWjp4oWjwi03TLrnbeAwhf7Wqk+2M9puysEGC4kHU9xdUdaO/h qEmw==
X-Gm-Message-State: AOAM533MptEB7aq+GMnUmlUR7cGcK/khDC2hJCRrjlR5rdGdsFvJ0KdI em0hKgHRORprpZ88/HqUtvcZF8KzKxOeT9OOThZuA5iprhNP
X-Google-Smtp-Source: ABdhPJxRWlAS3Y7o99bz2NRZOWqyWZUdFi5jkgeq4aEYy6wgyoHmAKIczSEVOOAbIii8xhb3f/OqEKwMGCLl4m6qdZs=
X-Received: by 2002:a9d:7741:: with SMTP id t1mr9020028otl.368.1596569565392; Tue, 04 Aug 2020 12:32:45 -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>
In-Reply-To: <20200804185313.GT92412@kduck.mit.edu>
From: Warren Parad <wparad@rhosys.ch>
Date: Tue, 4 Aug 2020 21:32:34 +0200
Message-ID: <CAJot-L2hykst2vFxcwLn_auDMMaw7psVwsKFHKhQp9DA49ydWg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Denis <denis.ietf@free.fr>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce0f3805ac1251c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/5li7ixGPe-aLcT1408pN3c9S-JU>
Subject: Re: [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 19:32:48 -0000

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
>