[OAUTH-WG] Re: Call for adoption - First Party Apps

Neil Madden <neil.e.madden@gmail.com> Thu, 05 September 2024 06:14 UTC

Return-Path: <neil.e.madden@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 DCCDDC14F6B5 for <oauth@ietfa.amsl.com>; Wed, 4 Sep 2024 23:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-TMD7p3TG5L for <oauth@ietfa.amsl.com>; Wed, 4 Sep 2024 23:14:54 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC06C14F69D for <oauth@ietf.org>; Wed, 4 Sep 2024 23:14:54 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a86c476f679so53615666b.1 for <oauth@ietf.org>; Wed, 04 Sep 2024 23:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725516892; x=1726121692; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=dNYDCmAHUZhVXl/DpDORWnqY2WW6SiJPmVagBj+l5j8=; b=dJ/3KvmmFj3LiWq/vJKyDFrl10EjRv/7J2tf0uuSvAAo6nh19f/hjyQhtCIBvJFdQR hqN4xs2lwGxUCzJXZ37T1PD37ibyXYC1Gq078BP3W8PgegG0U+hX3NNxOJKdAYdHPXqp /cGtcUfWNlIjG6JfFfJQ/PXrbFmxywv+x8lbzAKKYKE1/veaXSE6225a4SWtDeHMj9x0 UtZiAGnqkIFSDeoK3HfEzxat7MkJU40arcbnkzpJGLGIi04vhtkZEH6CDPtuBfQHeinS +t6+aUiPcGdiccIfCMA9hxtUJ8SwVqasVfQRs3pAvOatRYFTQWhgbsM3xbvA9bvEYMRd qAhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725516892; x=1726121692; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dNYDCmAHUZhVXl/DpDORWnqY2WW6SiJPmVagBj+l5j8=; b=HwfdrL8hOKM+t/9J8wOVgxHW8SPEwsbQ7Tc94oGvzcLklPSHGy/P1aT1Gg4bUn7ZOO bWzW5MTtz8twfToud2/4xzwaeA0kN1QKhDFQX8JDdsvSaA8qbmQqM6HpgiErBp6GT7GM xkWZEZ3l8Ep/S5RRxqKNBC6eMtWhOapfb7WUL5bQrtzDoq+MpIpG35Vb6BiEG2iVB594 Ibp3Md8Grx1blz2kFVEghJr2o1Ct9xQUbdUGivyZEshLvdeHHz9ntFA3dkf8JR+lbU2z F9/mJDPnneFCGu4Zr4nYCzqRTg3jJu7q2kzAuxHZq+I/A6l5izgM5fj19SFZ58gfbb4u s7gQ==
X-Forwarded-Encrypted: i=1; AJvYcCXdI5AMjyFslsa+RADVDCEAY1Gq/GB1Amwn2bpsNFKAplcgWgMw2r0gudm/BGZJ3ymX+eSegA==@ietf.org
X-Gm-Message-State: AOJu0YwsULtvL+i+W7XUrxUtCKwiSj/yYabZ8N5RjGI6bJJr7jDZX9Xl AToJWpqAsWQ9C4L/owBqLgOtApyc26gi2PFCrYn5PGZUvWRKuh4Q
X-Google-Smtp-Source: AGHT+IESRyjagw+GSQ65zx54jOpDxvu4s0Tyie/c92KD5rhBDG0YuvhoHCOVzWzbZMr+xwlZyclEWA==
X-Received: by 2002:a17:907:72d1:b0:a86:a41c:29e with SMTP id a640c23a62f3a-a89b93db7b8mr1300492466b.2.1725516891654; Wed, 04 Sep 2024 23:14:51 -0700 (PDT)
Received: from smtpclient.apple ([2a00:23ee:2280:3abf:5465:eb2a:59f8:b0e4]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8a623715e5sm85923766b.131.2024.09.04.23.14.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Sep 2024 23:14:51 -0700 (PDT)
From: Neil Madden <neil.e.madden@gmail.com>
X-Google-Original-From: Neil Madden <Neil.E.Madden@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Thu, 05 Sep 2024 07:14:40 +0100
Message-Id: <20805055-CBE7-4AE0-9CEA-018F78740C47@gmail.com>
References: <484F176F-7C7E-41CC-9BB5-E2487B927E2F@alkaline-solutions.com>
In-Reply-To: <484F176F-7C7E-41CC-9BB5-E2487B927E2F@alkaline-solutions.com>
To: David Waite <david@alkaline-solutions.com>
X-Mailer: iPhone Mail (21F90)
Message-ID-Hash: B7GSYUKPCOJZWTX7FFD5H7IL4VKDAKWQ
X-Message-ID-Hash: B7GSYUKPCOJZWTX7FFD5H7IL4VKDAKWQ
X-MailFrom: neil.e.madden@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: oauth <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: Call for adoption - First Party Apps
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/wbgQgwNH0T8tOfdxfIxcaahQEr0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

On 5 Sep 2024, at 05:45, David Waite <david@alkaline-solutions.com> wrote:
> 
> 
> 
>> On Sep 4, 2024, at 4:27 PM, Neil Madden <neil.e.madden@gmail.com> wrote:
>> 
>>> On 4 Sep 2024, at 22:48, Watson Ladd <watsonbladd@gmail.com> wrote:
>>> 
>>> I can always grab the cookie jar off the user browser if I have that
>>> level of access.
>> 
>> USB access is not privileged, but that’s beside the point.
> 
>> 
>> Put another way, the phishing-resistance of WebAuthn only really makes sense in a world of sandboxed apps: web apps, mobile apps. Any spec that encourages the use of OAuth auth flows outside of such sandboxed environments, as this one potentially does, is going to make defending against phishing harder.
> 
> The client is not an identified/authenticated component in the architecture, so there is a user trust required in using a client - that the client actually is an agent acting in the user’s interest rather than acting maliciously.
> 
> Platforms have the ability to provide specific API for these interactions to become a trustworthy client, and to block privileged access (including access to speak directly to hardware) behind audited entitlements to prevent from installed software acting as a malicious client.

Right, this is what I mean by sandboxed.

> 
> Note that some platforms also provide entitlements and heuristics for password manager access - however, as a knowledge-based system the platform cannot really prevent malicious applications from still attempting to manipulate their way to credential phishing.
> 
>> 
>> (I’d also question why first-party apps need a standardised API for this anyway: they can do whatever they like using proprietary APIs already).
> 
> I would struggle to come up with standards-track RFCs which would not be able to instead be accomplished with proprietary APIs. The editors and working groups found value in peer review and in interoperability.

Standards are for promoting interoperability, not for getting free peer review of private APIs. 

> 
> I have seen the pitfalls of a proprietary approach to this and would say peer review is important. My primary concern is whether we can have a clients that authenticate against multiple implementing ASes based solely on this work. Profiling authentication methods like passkey-based authentication would go a long way toward alleviating that concern.
> 
> -DW