[OAUTH-WG] OAuth2.1 credentialed client
Ash Narayanan <ashvinnarayanan@gmail.com> Sat, 09 October 2021 02:57 UTC
Return-Path: <ashvinnarayanan@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 400F53A0FD2 for <oauth@ietfa.amsl.com>; Fri, 8 Oct 2021 19:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_MESSAGE=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=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 a4urWTPGsFiH for <oauth@ietfa.amsl.com>; Fri, 8 Oct 2021 19:57:05 -0700 (PDT)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 8F2493A0F47 for <oauth@ietf.org>; Fri, 8 Oct 2021 19:57:05 -0700 (PDT)
Received: by mail-oi1-x22e.google.com with SMTP id z126so1910246oiz.12 for <oauth@ietf.org>; Fri, 08 Oct 2021 19:57:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nb+uohGy9Hopsac6pH/+SIRjg4R8ME+LxosZS7ZGQfg=; b=Z/ZOi2mjYXGMRXR1qs+rJNu5yj2OO5MUvLn/ntkhtfAEB9zUqO97mm6SQulJWxL42X a/fuzOkCBFS8GhKVMKnQ0J2HjzQM6ezgzW4sRp5Vq0l05a0dMY7+YpaTUmeaqdaZbBLH RwSIcYOoyDsexGOojFjFMG5Ut20XhcKbqHs5BRQHM+kWsriMZ2kftll5CT3T43T0lECr j42d1o1Kr3PMqE85vgNnFmjN/Kh3sRpwqDOWQWRvUbHsSdLwlVMpL5M6MNv67epzzzUd n6EwsskEgkHtpxfNtpCtRbipl43PSGu9rt6me2o5pK7Z760ZfjOdqw796treWw8e9FHS 1LmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nb+uohGy9Hopsac6pH/+SIRjg4R8ME+LxosZS7ZGQfg=; b=D1rwUBd/5SlqTuItZFIa1BWqlw2K85hRM2QtdgJqzT1T/v7pu5IFc5hC1jp9KLtBBR R9m8E1gV89HlLCuGMRl6tTxU1+0XP2ngn0oxNvEnHkX6LEvj2hDApdnK1TrD60dzk+5e LxiA+JdoxEATXZNRL7LH4ilyhAXXRFPQAWRMkQLNgm88gpLGqR6QnhAJkAEhQc6As8/h VTwunuz+jPphF4tNXncPI3Rey5r8qdGkK8lPl4Zy1cm6G5emrPj7y7ulmGUvQnQOs7NF /9yYo2vuWDz00G1GwqnBcoyN6aZjVi1cTIdkUSV0HnFZX2qkjyJP9R+vI51gqfaNhc/G APaA==
X-Gm-Message-State: AOAM5330QYB2NqFXsPhjxA8hjdqHhrMtM9k/QNFzGiz/fac2J1/7a5lG tEjfco3AfS5DXuw1BkyOSqBPHDpb6XmVMkc+BpKezn0dk48=
X-Google-Smtp-Source: ABdhPJwDsbSdTjTWaLENiu2Ea3vauINItzKwG1TVocc1ZbZy+kBSnNOed2AOLzwjHj4+4A65hfzwvzHMVaDBFL5cshA=
X-Received: by 2002:a05:6808:1522:: with SMTP id u34mr10562117oiw.126.1633748224289; Fri, 08 Oct 2021 19:57:04 -0700 (PDT)
MIME-Version: 1.0
References: <163347956410.26563.6262394233835671220@ietfa.amsl.com> <CAGBSGjryjQ3pnh+RnGnxqjCENgG-6td1JBSG4tV9VZfVSaKvnQ@mail.gmail.com>
In-Reply-To: <CAGBSGjryjQ3pnh+RnGnxqjCENgG-6td1JBSG4tV9VZfVSaKvnQ@mail.gmail.com>
From: Ash Narayanan <ashvinnarayanan@gmail.com>
Date: Sat, 09 Oct 2021 13:56:52 +1100
Message-ID: <CAFvbn=YisYSbu8sL+TLgRakJ52oA6TEQSJ8i_4+9qNNQ0b9bkA@mail.gmail.com>
To: Aaron Parecki <aaron@parecki.com>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008fae7a05cde2a6e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Dqng8APRhCMIvGtpajHr7-Gqq2s>
Subject: [OAUTH-WG] 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: Sat, 09 Oct 2021 02:57:10 -0000
I'm not sure if these items have been brought up previously or are already on the agenda to be discussed at the interim meeting. Referring to the latest draft ( https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html) ... 1. The definition given under section 2.1 Client Types is: > Clients that have credentials but no prior relationship with the AS are > designated as "credentialed clients" This does not seem like the best or even the right definition to me. The definition as it stands, is in two parts: a) "Clients that have credentials" b) Clients that have "no prior relationship with the AS" With (a), the typical use-case is an app that runs on the end-user device and dynamically registers itself with the AS. Such a client does not "have" credentials to begin with, or at least the use of the word "have" here, if it's intended to mean "at some point will have", does not differentiate it from confidential clients, which are also defined to be clients "that have credentials". Instead, a better choice of words for credentialed clients may be "Clients that dynamically obtain credentials". (b) is not necessarily true, because the credentialed client may very well be a known client and therefore have a prior relationship with the AS. Think of (common) scenarios where the AS and client are both part of the same organisation or a peer organisation, and therefore the client metadata an AS receives in a dynamic registration request is already known to the AS. An AS may only decide to accept dynamic registrations from such known clients. Of course I may not be interpreting "prior relationship" as it may be intended, in which case that needs to be clarified somewhere. 2. Continuing with section 2.1 Client Types, for a native application, it says: > On the other hand, dynamically issued credentials such as access tokens or > refresh tokens can receive an acceptable level of protection. Why is this also not mentioned for a browser-based application? Unless I'm mistaken, in terms of accessibility for an intruder, in-memory for a native app is equivalent to in-memory for an SPA and local storage for a native app is equivalent to local storage for an SPA. Cheers, Ash
- [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-04.t… internet-drafts
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-… Aaron Parecki
- [OAUTH-WG] OAuth2.1 credentialed client Ash Narayanan
- [OAUTH-WG] convert to credentialed client... ( wa… Brian Campbell
- Re: [OAUTH-WG] convert to credentialed client... … Dick Hardt
- Re: [OAUTH-WG] convert to credentialed client... … Brian Campbell
- Re: [OAUTH-WG] convert to credentialed client... … David Waite
- Re: [OAUTH-WG] convert to credentialed client... … Ash Narayanan
- Re: [OAUTH-WG] convert to credentialed client... … Warren Parad
- Re: [OAUTH-WG] convert to credentialed client... … Ash Narayanan
- Re: [OAUTH-WG] convert to credentialed client... … Brian Campbell
- Re: [OAUTH-WG] convert to credentialed client... … Domingos Creado
- Re: [OAUTH-WG] convert to credentialed client... … Ash Narayanan