[OAUTH-WG] Re: DNS Handles

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 21 January 2025 18:18 UTC

Return-Path: <hallam@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 C9CE3C1E8900 for <oauth@ietfa.amsl.com>; Tue, 21 Jan 2025 10:18:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.654
X-Spam-Level:
X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
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 WydHjwO7YsUY for <oauth@ietfa.amsl.com>; Tue, 21 Jan 2025 10:18:10 -0800 (PST)
Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.173]) (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 250DEC1E56A1 for <oauth@ietf.org>; Tue, 21 Jan 2025 10:18:10 -0800 (PST)
Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-7b6eeff1fdfso537594685a.2 for <oauth@ietf.org>; Tue, 21 Jan 2025 10:18:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737483489; x=1738088289; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CJCUY25pIhE8auIfCNx9w2SmEdsJ/sgtcvaKazOlK6U=; b=XOQTxisy14XQ0BIcAbiWFpfEfaBQjTRUNHucl1NVVQsDSw+S56rXUQWrq0Ez6kV6L3 GlVvd+MqCs7L/azcN8bvZrdQ0E7TMlW2zihsy14+3TzRuI6DUHoASGhG3HQ2PgH+Ut+9 PCtHYMux+vMG0TGDFXR4qLM6dWf1c/Y4WgmkLOeICH5bqiw6jXF3x9RS1lHIs/fJQycI WzQfWQKZyHNiUa6UOzbcEFmIHRl6SY1aBvpQWZf+http0z/tVFhoTyT1ugf07C5G1qGB eEfy1GTJul/sfeelzVcdN5na+bJpcyLAMe59utyzD3uwzHInhHA+SRq8j/alOwEG/7UY 4M4A==
X-Gm-Message-State: AOJu0YxmPjY9G8sTqG1rhmJeGbfYKCFPXrou/OiyQHP8uYszSJ0s4yBP ZwC+w04zoghSUXHFS2dmFvxyDRCdCCPIevBhVL6txEfg5iGSwiNVuhnUUpX/tcnBF+PxOqjo6Kj AK5qCfxWZkmaOOzuIY5X9LUzuvDezKA==
X-Gm-Gg: ASbGncuAqlJdZ+1eumc5cxaUf90lw3lcl1detkjj6zmzUXWnxLwbaz6MBjmxchYf9bq Z6daiT451qN2U7KIfeirGRlK57kHAthNxLzh9KmoWVdS8PZpHD8SV
X-Google-Smtp-Source: AGHT+IG5hZxw7jSBOxKyhpWh1+2adCFCKCZOX1yFY97I5Ds7M/WLs/nTd4Tu+vDdDogmRi+sRO8I7qwniqqtirmWO2A=
X-Received: by 2002:a05:6214:1305:b0:6d8:a591:fb8 with SMTP id 6a1803df08f44-6e1b224c144mr290646636d6.37.1737483489142; Tue, 21 Jan 2025 10:18:09 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+Lwgykk+B2UspfXBcLipFiTifNBf-WG-DeXPpWT39syqqVg@mail.gmail.com> <CAJot-L36t-LWPGRZu7ACkKyzsxDgD6zcevxrONbLBxtjh3KdWA@mail.gmail.com>
In-Reply-To: <CAJot-L36t-LWPGRZu7ACkKyzsxDgD6zcevxrONbLBxtjh3KdWA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 21 Jan 2025 13:17:58 -0500
X-Gm-Features: AbW1kvbygfRyqQnCWkzNdIsKG7MUDU17UsgS1kYx3rNBSLAxRRCG62ODm-pfres
Message-ID: <CAMm+Lwg+rbjU-Q17Re=KHrNvk6UXKtS35VS2LrY8cUwkyT6piw@mail.gmail.com>
To: Warren Parad <wparad@rhosys.ch>
Content-Type: multipart/alternative; boundary="0000000000002c6c7d062c3b665c"
Message-ID-Hash: Q2L3AYGZ2CNFIEOCJJVHRBRASWEHBF54
X-Message-ID-Hash: Q2L3AYGZ2CNFIEOCJJVHRBRASWEHBF54
X-MailFrom: hallam@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@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: DNS Handles
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/EXzT-r4P8EISZ6kUllkD2s8KIO8>
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 Tue, Jan 21, 2025 at 12:30 PM Warren Parad <wparad@rhosys.ch> wrote:

> If I understand correctly, I don't like this at all. In the OAuth context
> you can already use (nay, must use) your DNS as the Issuer for these tokens
> and specify the appropriate user ID in the *sub *claim of the generated
> identity tokens. Given this is already possible, and realistically up to
> the AS Issue to determine which values to populate into the *sub. *The
> fact that the Subject claim should really be opaque to the resultant OAuth
> compatible application, I'm not really sure what is being requested here.
>
> Based on what you are saying, what existing standard needs to be created
> or changed to support this, because from my perspective, this is already
> the current state of the world, isn't it?
>

Standards are what people actually use.

Right now, I cannot go to a Web site and expect them to support use of my
DNS handle, even though almost all the infrastructure required to support
it already exists.

IETF has been talking about decentralization, here is a mechanism that can
achieve it. And its not just the IETF. There are a lot of governments who
are rather upset at the walled-garden cartels and some have begun the
process of breaking them up.


Standards are not just about agreeing ways to do things, it is the process
of getting widespread agreement to use the same approach.

As for the need for documentation, I am utterly unable to understand what
you are saying about checking the sub field and the
ATprotocol documentation on it is opaque at best. And a really good rule of
thumb in things security is that where the descriptions are unclear, there
are at best non-conforming deployments that have security vulnerabilities.

I am highly skeptical of Passkeys because the 'documentation' they have
provided is mostly marketecture with pointers to documents that spend more
time defining unhelpful jargon than actually explaining anything.

If this is to become a widely supported approach, we need a profile to
describe the particular way to go about it. What we have now is a stack of
specifications that have evolved over a period of 20 years designed to
support a slightly different objective.