Re: [OAUTH-WG] convert to credentialed client... ( was OAuth2.1 credentialed client )

David Waite <david@alkaline-solutions.com> Mon, 11 October 2021 22:53 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 381D33A1016 for <oauth@ietfa.amsl.com>; Mon, 11 Oct 2021 15:53:55 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.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 0Ys0OQb0ShVY for <oauth@ietfa.amsl.com>; Mon, 11 Oct 2021 15:53:50 -0700 (PDT)
Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793733A1076 for <oauth@ietf.org>; Mon, 11 Oct 2021 15:53:49 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id BFA8D207190; Mon, 11 Oct 2021 22:53:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1633992828; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gBZL7axgH6jER/vTxLMR8IzWtTuRB4WqJBixLy2MFjQ=; b=laZ+XyPa0frZ1/jlj6x/AJCv5WLjpXkBxo+n8k0YAIWJjnir62GGG83P7FVf49a+7qEP/Z O/Kr7y/yKkKMFS2uMQvrNTLAfRibftGYb2R11+Hjzk9+ibTCJWLRrg6eujgmB5mdwbwjAM QM3qPDMqPqQINWqv0cS+Q1Eyf91DY5I=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: David Waite <david@alkaline-solutions.com>
Mime-Version: 1.0
Date: Mon, 11 Oct 2021 16:53:46 -0600
Message-Id: <7BC470C3-EB07-4C8F-BF9F-7A0C9F5B1DF2@alkaline-solutions.com>
References: <CAD9ie-uWw0TZ9cZPzWLNJn5-J025xOO7AiKcxdmezVVhEx13oQ@mail.gmail.com>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, OAuth WG <oauth@ietf.org>
In-Reply-To: <CAD9ie-uWw0TZ9cZPzWLNJn5-J025xOO7AiKcxdmezVVhEx13oQ@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1c4cOvnfopN_fDHxx9L1ELnP5Vs>
Subject: Re: [OAUTH-WG] convert to credentialed client... ( was OAuth2.1 credentialed client )
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: Mon, 11 Oct 2021 22:53:56 -0000

> On Oct 11, 2021, at 11:52 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
> 
> 
> Thanks for the feedback Brian. We have struggled in how to concisely describe credentialed clients.
> 
> "identifying a client" can be interpreted a number of ways.
> 
> The intent is that the AS knows a credentialed client is the same client it previously interacted with, but that the AS can not assume any other attributes of the client, for example that it is a client from a given developer, or has a specific name.

It sounds like the goal is to distinguish authenticating the client from trust of the client pedigree, e.g. the only authenticity of a public client might be that it can catch the redirect_uri, and the only authenticity of a dynamically registered client is what you required and verified up to that point. 

Some of that trust may be on confidentiality of data, prior reputation, safeguards to prevent token exfiltration or unauthorized token use locally, etc.

A credentialed client is not more trusted than a confidential client - it is just more uniquely identifiable. A public client does not have a mechanism (within OAuth today) to prove its trustworthiness on request because it is not authenticated as the party with that trust.  You instead would need to e.g. do client registration with a software statement. 

It may help to know what actions are MUST NOT or SHOULD NOT for credentialed clients vs confidential clients. Without that, the distinction seems it should be self contained in 2.1 like the client profiles, and maybe the term confidential client be explained to be a misnomer and more broadly explained that confidential vs public client is _not_ to meant to be a described as a trust distinction.

-DW