[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.
- [OAUTH-WG] DNS Handles Phillip Hallam-Baker
- [OAUTH-WG] Re: DNS Handles Warren Parad
- [OAUTH-WG] Re: DNS Handles Phillip Hallam-Baker
- [OAUTH-WG] Re: DNS Handles Aaron Parecki
- [OAUTH-WG] Re: DNS Handles Dick Hardt
- [OAUTH-WG] Re: DNS Handles Warren Parad
- [OAUTH-WG] Re: DNS Handles Phillip Hallam-Baker
- [OAUTH-WG] Re: DNS Handles Warren Parad
- [OAUTH-WG] Re: DNS Handles Phillip Hallam-Baker
- [OAUTH-WG] Re: DNS Handles Warren Parad
- [OAUTH-WG] Re: DNS Handles Phillip Hallam-Baker
- [OAUTH-WG] Re: DNS Handles Warren Parad
- [OAUTH-WG] Re: DNS Handles Phillip Hallam-Baker
- [OAUTH-WG] Re: DNS Handles Aaron Parecki
- [OAUTH-WG] Re: DNS Handles Phillip Hallam-Baker
- [OAUTH-WG] Re: DNS Handles Dick Hardt
- [OAUTH-WG] Re: DNS Handles Phillip Hallam-Baker
- [OAUTH-WG] Re: DNS Handles Dick Hardt
- [OAUTH-WG] Re: DNS Handles Phillip Hallam-Baker
- [OAUTH-WG] Re: DNS Handles Sam Goto
- [OAUTH-WG] Re: DNS Handles Thomas Broyer
- [OAUTH-WG] Re: DNS Handles Dick Hardt
- [OAUTH-WG] Re: DNS Handles Aaron Parecki
- [OAUTH-WG] Re: DNS Handles Vladimir Dzhuvinov / Connect2id
- [OAUTH-WG] Re: DNS Handles Phillip Hallam-Baker
- [OAUTH-WG] Re: DNS Handles Pawel Kowalik