Re: [OAUTH-WG] third party applications

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 28 August 2020 14:49 UTC

Return-Path: <torsten@lodderstedt.net>
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 8A2CD3A0CF8 for <oauth@ietfa.amsl.com>; Fri, 28 Aug 2020 07:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=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=lodderstedt.net
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 QGi03v-ZrvYl for <oauth@ietfa.amsl.com>; Fri, 28 Aug 2020 07:49:45 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 BFECA3A0CF4 for <oauth@ietf.org>; Fri, 28 Aug 2020 07:49:44 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id ba12so1416970edb.2 for <oauth@ietf.org>; Fri, 28 Aug 2020 07:49:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Gj0hkq8mLEnt7ETh4N1aZiUNPU24zYEsQaJR8bYrwXo=; b=YezUYltr8+lXXIof8YyyXnS6DoJtHpL6tatkZKd+3UwKBcXe+qOljZcA5bDIPpR2gR yeQef8XsAJ23y5he67+iuzDGvwrC6WaBpsXv2emBfQ1oqgauqjRbQZCF85VKfu5iAYJ9 MOC7yUbR762bjHcmmBAUNXGT/TzWsqTGor5alUdgzLwIegtGVNzTnX+JJH1iqZz1DKaF ZzCh1Ft8IgLbpvPjgbEeNcSY07GHy1Cp7HflPrpxcq7tJa/7gv3nIOp1Y/qAWBVyItG8 u9VDFlt4nPhhf1KCAd3K7HdGNxW7m4Our5hwaO23TjNiCMvKD5G6WSmxlyQ3bmA6rLE3 fSOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Gj0hkq8mLEnt7ETh4N1aZiUNPU24zYEsQaJR8bYrwXo=; b=snba2Ow+HFZ0I+c80p4OaO4R9C0TSeJ+1qZLLHdq2oRAoTWK6HlTOqIMPizcWQCGVl R4uFkDpS96LgGWXdr1QEafm8rUEMGJI2m869l4otG4TOzZw3TD6T5W6QkUm7k8XRorRy TSaDdHCyU/QjaVN+oiPoNHKjmuZexZVm1Goqc/RUqYWZ1g9QildfUt9CpmL2Ovt3S0vg KN8qctXJrFHhpw7nKYUVdWkWCPsljDFDOotftHIWH8htdeNcOVqdcSBpf+2BRGoX5lKj 4WYYxcu/CTLpeZWjYYTHiFe0KMqzPvJxr3jG0aaEiVW3Zoobjryy6BoQUvcuV+f3UKLI 92CA==
X-Gm-Message-State: AOAM530ydshQvyj2SxqJfTK2pb+4nPFQdHp1ZwoBbPBm9VLixWeXjkyW vnxNFCoj7k7S5fIbGZqJZKQElw==
X-Google-Smtp-Source: ABdhPJwpEm3Rcitiowr8oQ8bUDv0KzYnveWizWWbthP1/YXttoX7ddDErNCYYGoFej1+QAb6KvmmBQ==
X-Received: by 2002:a05:6402:b32:: with SMTP id bo18mr2263192edb.201.1598626183061; Fri, 28 Aug 2020 07:49:43 -0700 (PDT)
Received: from p200300eb8f1e2a7f0135b1f6009a5514.dip0.t-ipconnect.de (p200300eb8f1e2a7f0135b1f6009a5514.dip0.t-ipconnect.de. [2003:eb:8f1e:2a7f:135:b1f6:9a:5514]) by smtp.gmail.com with ESMTPSA id n14sm1188787edb.52.2020.08.28.07.49.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2020 07:49:42 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <CAD9ie-sRNyRd3TX2_9-MaW3R+Swgp2Lg0uyXoBwu5rGw8Jphfg@mail.gmail.com>
Date: Fri, 28 Aug 2020 16:49:41 +0200
Cc: Dima Postnikov <dima@postnikov.net>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F52A020-8C82-4593-97D7-BE4C252CADD8@lodderstedt.net>
References: <CAEMK1uY0cSOyyU2t0N9RTOzmMeEpfMsb7K9WfQD=fQdCde9jTQ@mail.gmail.com> <B2AA5092-32BD-499D-9EAF-09AB95E6E9B6@lodderstedt.net> <CAD9ie-sRNyRd3TX2_9-MaW3R+Swgp2Lg0uyXoBwu5rGw8Jphfg@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/VzgQx86vJNd0aheTKdAqBg3fJFY>
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:49:47 -0000

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