IETF Logo Mail Archive

Re: [OAUTH-WG] third party applications

Dick Hardt <dick.hardt@gmail.com> Fri, 28 August 2020 14:57 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2034E3A0C52 for <oauth@ietfa.amsl.com>; Fri, 28 Aug 2020 07:57:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 64gCcXRQr-Gw for <oauth@ietfa.amsl.com>; Fri, 28 Aug 2020 07:57:35 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 EFEB63A0C57 for <oauth@ietf.org>; Fri, 28 Aug 2020 07:57:34 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id f26so1626638ljc.8 for <oauth@ietf.org>; Fri, 28 Aug 2020 07:57:34 -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=YKIxr0wIXgAMF5O2lOEhBsPZVdLZd2Zlp9ADmvcfvwY=; b=SVto7taw5Qu987cJ0CxJGJn+KmzLL8NNDYkvrjgKEkolMvcgmZH0EtXLkbeafIxOGj dygZZE8QFb9n7CrPuDnTgDrOCKRFne4+BzDDp6vq/xwFyHqu0xKX1IrdhYa1I/2tMxYI 0MdP7rec9dvAjuzm3EjDzdR1KNnljmyJeTCtM7AA6affHiPjzOVNXVLyv0qQay/554Lo p8g4uroWzEkGoCpgdwSri1ie40Q13Ai0GjYwhrIwU9Duv3auENgf0Zb5WvFydXKQhqXf ds1EraLIppLvBUWSMCX9Vxfge6lj+c1mqGUcefWsgWt0pLYro30wHGmjTAnEbwWx8OhL 7GWQ==
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=YKIxr0wIXgAMF5O2lOEhBsPZVdLZd2Zlp9ADmvcfvwY=; b=EeLCK5tmiXUS8UDp10iSfFC6EeOMT9h7EM7yc3hlcGz5g5rVNylnpaCqxakdZsAYVG PvYqNeyrAbrSfFMseoX8J/+WmlukDQyvji94nR5MQFcU9kBZlfByrpyD82IQZaoyCMGg NiPbXe4csn0dgvh8B3zYsBRAanmn4nBsSVj9LzistKgkHq9RTEUkL516YNJ3yaCCsaNR gRujt2B2SXipKas+9FcdbJoyhIHTzcAKPe33rCHhBqiQZen731aIsep6BH4fr6+YEhMu lOak4VnCGT1NXJqwB7ggzNqKKosUvIIRUme1gqc8eK2U7jCzBYXUivKcuT0a2a0JufAx 1KAg==
X-Gm-Message-State: AOAM533gwEhJIBk/ww/jxYip+XmaZOdx+xJXN/1kHDuKxAA322UU1JVq e6dXInApf4ItC3Hc2+7jNpCGjUAgmlock3gg3SCR89fNFL8=
X-Google-Smtp-Source: ABdhPJzki026YFkxig7sZ+5yj35+XZ+bqhb/s1sYAOMspDq9gEhWQRNsJtUGc/mViypNFu9N6TWvskTHUtmXjl0w54M=
X-Received: by 2002:a2e:9b45:: with SMTP id o5mr1050965ljj.142.1598626652860; Fri, 28 Aug 2020 07:57:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAEMK1uY0cSOyyU2t0N9RTOzmMeEpfMsb7K9WfQD=fQdCde9jTQ@mail.gmail.com> <B2AA5092-32BD-499D-9EAF-09AB95E6E9B6@lodderstedt.net> <CAD9ie-sRNyRd3TX2_9-MaW3R+Swgp2Lg0uyXoBwu5rGw8Jphfg@mail.gmail.com> <2F52A020-8C82-4593-97D7-BE4C252CADD8@lodderstedt.net>
In-Reply-To: <2F52A020-8C82-4593-97D7-BE4C252CADD8@lodderstedt.net>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 28 Aug 2020 07:56:56 -0700
Message-ID: <CAD9ie-vVt47TdyhU1qiGL9CLgsQ3mriPJ0irkw7ddBsdwv8QLw@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Dima Postnikov <dima@postnikov.net>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c5b54105adf145b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2YZDf3AvTrSdIkI4WNk89RS5xOA>
Subject: Re: [OAUTH-WG] third party applications
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2020 14:57:37 -0000

Well, OAuth is not very useful in a monolithic application. No need for an
interoperable protocol for that kind of application.

And in separating functions, you are creating separate trust domains. Yes,
it is still all internal, but it enables a separation of concerns.
ᐧ

On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt <torsten@lodderstedt.net>
wrote:

> In my experience OAuth is used in 1st party scenarios as means to separate
> functions (e.g. central user management vs. different products) within the
> same trust domain thus enabling architectural flexibility.
>
> I would just remove any constraint on the kind of applications OAuth can
> be used for. I don’t see how this governs the protocol design.
>
> > On 28. Aug 2020, at 15:29, Dick Hardt <dick.hardt@gmail.com> wrote:
> >
> > The driver in my opinion for first-party use of OAuth is to separate the
> trust domains so that the application is scoped in what it can do vs an
> application that has full access to all resources. I agree that third-party
> can indicate that internal use does not apply. How about the following?
> >
> >    The OAuth 2.1 authorization framework enables an independent
> >    application to obtain limited access to an HTTP service, either on
> >    behalf of a resource owner by orchestrating an approval interaction
> >    between the resource owner and the HTTP service, or by allowing the
> >    application to obtain access on its own behalf.  This
> >    specification replaces and obsoletes the OAuth 2.0 Authorization
> >    Framework described in RFC 6749.
> > ᐧ
> >
> > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt <torsten=
> 40lodderstedt.net@dmarc.ietf.org> wrote:
> > I agree. OAuth works for 3rd as well as 1st parties as well.
> >
> > > On 28. Aug 2020, at 05:26, Dima Postnikov <dima@postnikov.net> wrote:
> > >
> > > Hi,
> > >
> > > Can "third-party" term be removed from the specification?
> > >
> > > The standard and associated best practices apply to other applications
> that act on behalf of a resource owner, too (internal, "first-party" and
> etc).
> > >
> > > Regards,
> > >
> > > Dima
> > >
> > > The OAuth 2.1 authorization framework enables a third-party
> > >
> > >    application to obtain limited access to an HTTP service, either on
> > >    behalf of a resource owner by orchestrating an approval interaction
> > >    between the resource owner and the HTTP service, or by allowing the
> > >    third-party application to obtain access on its own behalf.  This
> > >    specification replaces and obsoletes the OAuth 2.0 Authorization
> > >    Framework described in
> > > RFC 6749.
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>

v2.23.0 | Report a Bug | By Email