[Txauth] Key handle vs client id & handle

Dick Hardt <dick.hardt@gmail.com> Fri, 10 July 2020 20:17 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 629DF3A091D for <txauth@ietfa.amsl.com>; Fri, 10 Jul 2020 13:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jBZjHWDosWgp for <txauth@ietfa.amsl.com>; Fri, 10 Jul 2020 13:17:12 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 997703A0920 for <txauth@ietf.org>; Fri, 10 Jul 2020 13:17:12 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id o4so3880931lfi.7 for <txauth@ietf.org>; Fri, 10 Jul 2020 13:17:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0WKxvrenDIbKvd+ZgJ61ehGpKXGBNJezsr8zJ++2/Tc=; b=T0P9s8cQLdeohTzVQxL40AKKMdh647HGS+7cKy7giZIs0KW4IeDI3VqTyCUwCHhvsw jU8bGcMiq7KJRgTrw5zsJP4erC7rnYL/2MLlSB+EidRjw50WCz118cl5ho0eoBzRPTMN wBMvXDS92lH3DMksvGpK8dcVlOuuscFppXISQsnRkoVpgVfzhEnywVi4Meml17ny3hVb vrgmLvvXWhjJCTrm/op/6NfcX4vS6/vJbx+G8cPlRk2xsgix8U/WS2c5VwRKjcB0mBZ5 Au0wYnaBb7IpF1eYF0B3xePM342JFde4/pAmV+NUWJVuyVN8USs2zL1DGgrkbaNY9H6H RdNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0WKxvrenDIbKvd+ZgJ61ehGpKXGBNJezsr8zJ++2/Tc=; b=L+QctWfjcTIrSHEDUWQPCoGM5sSkZx4aR0mXswRP0GR8AovFfELQZhvBFtcyPO4fK2 Pe1/+HZP7fxgMdAPVXiNhJXenVyxx7FhO/e+hAjFoi63/D1yKz5v7L9kFxQrKKk1G6cB /LceBiX+QzAlH7Bsx+DmptMh8he6k8me/1UaK1ViB7+vFXg4Zl/b7V6hZfXrCnPftbcR EW5bv+XCFoPWF1I97FFmvuOb06nOa8OdRqJXvdc10Y2ZHkiMqeQQdcjkzqO/ycWSE0U5 GUOfHSAMr1xKm/A88P1bgKezc8QHPdonBvLLj5K/ocSawH4N/3Xg125fZbGTRjZNEWse nQ7Q==
X-Gm-Message-State: AOAM532nUwelGY29i0nuGv7a5lZdRB+nLT7QpHLUx2mFd4Pux9rSDuO2 YSdxVZy0fnIxQCiy/xZfzW+6mRzBAhOObjsz/Qg/vxGo
X-Google-Smtp-Source: ABdhPJx+VBpihhTlEQpS5QUCCElkY9aQ720FLjS+oF9MaawmQ4tj/B4HMwGJzZlu1bFKV8YmDew0cJqCgKHwFSH90/Y=
X-Received: by 2002:ac2:5093:: with SMTP id f19mr45146094lfm.10.1594412230321; Fri, 10 Jul 2020 13:17:10 -0700 (PDT)
MIME-Version: 1.0
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 10 Jul 2020 13:16:34 -0700
Message-ID: <CAD9ie-uEEbky1O0tiaszSd=myX3LUwiARPZ_O6oRAwc5DG3kjw@mail.gmail.com>
To: txauth@ietf.org, Justin Richer <jricher@mit.edu>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009d2a8705aa1c0607"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/gjLdwORSwLI9ZsTcD6c36tDGZOE>
Subject: [Txauth] Key handle vs client id & handle
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2020 20:17:16 -0000

+ Mike as he had interest in this topic

My understanding is that an existing OAuth 2 client would use their current
client id as their key handle, and a dynamic client (one that was not
pre-registered) would be given a key handle by the AS.

There are potentially some significant differences between a registered
client, and a dynamic client to an AS.

The AS is likely to know the identity of a registered client, and have
different policies between the two types of clients. For example, a
registered client may have access to a 'write" scope, while a dynamic
client does not.

The AS may have 100s or 1000s of registered clients, but a dynamic client
may have 10Ms or 100Ms of instances, which may dictate separate storage
services. Additionally, internal to the AS, which systems can write to the
registered client store is going to be different than the dynamic
client store.

In XYZ, subsequent calls to the AS, both registered clients and dynamic
clients pass a key handle, so there is no easy way to differentiate between
the two.

While the AS could embed semantics in the key handle identifier to indicate
which identifiers are pre-registered vs dynamic, there are many cases where
the AS does need to know the difference, so making the difference a feature
of GNAP seems like a better path.