Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

David Waite <david@alkaline-solutions.com> Wed, 07 November 2018 19:30 UTC

Return-Path: <david@alkaline-solutions.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 6D529127B92 for <oauth@ietfa.amsl.com>; Wed, 7 Nov 2018 11:30:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 zEzt0O-YhoF2 for <oauth@ietfa.amsl.com>; Wed, 7 Nov 2018 11:30:35 -0800 (PST)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id B654B1200D7 for <oauth@ietf.org>; Wed, 7 Nov 2018 11:30:35 -0800 (PST)
Received: from [IPv6:2601:282:202:b210:bdbe:87c1:197b:4c88] (unknown [IPv6:2601:282:202:b210:bdbe:87c1:197b:4c88]) by alkaline-solutions.com (Postfix) with ESMTPSA id 0ABD631689; Wed, 7 Nov 2018 19:30:33 +0000 (UTC)
From: David Waite <david@alkaline-solutions.com>
Message-Id: <BEFB5627-BB39-4D9B-B08A-2C3FB98E5FD2@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8D3084AF-F09D-4CE0-9160-BC5FD0B1B2D2"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 07 Nov 2018 12:30:33 -0700
In-Reply-To: <5d754635-836d-07b6-4f6e-a2fa2ebbeaca@forgerock.com>
Cc: Joseph Heenan <joseph@authlete.com>, Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>
To: Simon Moffatt <simon.moffatt@forgerock.com>
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAGBSGjqHKVveZor-oKUWzsQ0Rg5Fk_d2dns_eQFqfvXJynyQaQ@mail.gmail.com> <894C1893-8722-4005-8A33-AECADFD18024@authlete.com> <5d754635-836d-07b6-4f6e-a2fa2ebbeaca@forgerock.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ac1Vq5ilP-MY3tODq_QoJOfZeSo>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
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: Wed, 07 Nov 2018 19:30:37 -0000

> On Nov 7, 2018, at 9:08 AM, Simon Moffatt <simon.moffatt@forgerock.com> wrote:
> 
> It's an interesting topic.  I think there is a definitely a set of options and considerations for this.  Namely operational.  For example, hugely popular mobile apps (multi-million downloads across different OS's) using dynamic reg with per-instance private creds requires the AS to be able to store and index those client profiles easily.  Smaller scale custom built authorization servers are not necessarily going to be able to handle that - hence the popularity of assuming everything is generic and public coupled with PKCE.
> 
Having unique client identifiers does provide some niceties. As examples: it gives a user a chance to administer/revoke those clients, and it gives the AS an opportunity to do behavioral analysis with a per-client rather than per-user granularity.

It also allows you to track user-granted consent per client. There are very limited options (really, just id_token_hint from OIDC) to indicate when hitting the authorization endpoint that you have prior consent.

In any case, the ability to work with public clients or the need to do dynamic client registration is AS policy, not something clients typically have the power to decide.

-DW