[OAUTH-WG] Re: DNS Handles

Aaron Parecki <aaron@parecki.com> Tue, 21 January 2025 18:37 UTC

Return-Path: <aaron@parecki.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 6B092C18DB96 for <oauth@ietfa.amsl.com>; Tue, 21 Jan 2025 10:37:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
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 cw5qcrgk3yAP for <oauth@ietfa.amsl.com>; Tue, 21 Jan 2025 10:37:19 -0800 (PST)
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 2BDB1C1930B0 for <oauth@ietf.org>; Tue, 21 Jan 2025 10:37:18 -0800 (PST)
Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-518a861612eso30732e0c.1 for <oauth@ietf.org>; Tue, 21 Jan 2025 10:37:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; t=1737484637; x=1738089437; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZHv8O3W3WnzekSIG+R5Inc1gO0nVRwVQxRsH1tsXK/Y=; b=ibyMmW71j2GPxcG8x2rOO/dFrLNIm0ZrJ6IHOgaqJ3/ITlJivrnA8Glfxmn5VoS2Nt AVyS/whl0q02bGwMIHaznwPGVCG9/1RN8jMOwHpJSD4jDxm/vBCyjxeA+j5aOwWgB0Jw GDTVgzhT8qNb9DWxszEnp8q44J1yvDVNhnXTbqvBhsRgWV6HeMcwe1RADW8Pts6zQf/7 C13ickWM2YDxeh/hOSgBrhk9SaoF/uo7Q9cZX7sZKFOXf3bHEyxZY96kQYi2rHixDQ4v n9rW7wLLqnTD4V6Xnr9AzclyE9cV1L26U0b6VinCKJNYB83fwzRddpqP+f14h7TRzWFr Odqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737484637; x=1738089437; 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=ZHv8O3W3WnzekSIG+R5Inc1gO0nVRwVQxRsH1tsXK/Y=; b=q/bNbHsS7lYnXQZ1qdsrVQ0jq6h1oTGs+Poxj95DClkIpTYNuVPvLqAwP1WyoxqFqy Kz2kaziAsCYjoWCVTq7cWp0BawxZQjB7T+PzuC4r/L+crhaQngbJd3aval6NswDd1oU3 xxCmSvbNa373Njw3lNTrqxPQC/+pv2D1ZbOAQXMSBUzhEUkRHiMeaIam3Gb58Wyjd7oO Bg7r41C4f22Su1NWZVd6WD5CttvvIE+guM85GCu2hiAMpR3br9ZQeRUif3a7+b1CYj1o WaLmg1o+/J1fP+K2TAO3b8aDwLj4reCbdGnrcvvw/cdhYanr9W7odJ1xaaZqU7ANT4rE kj/w==
X-Forwarded-Encrypted: i=1; AJvYcCW24h3nlDUhdm2PcWvAR+MDPUXS2oWD7g8Wj4VkRxY9SMwUjtO6RrgQDVs0imC2BFiVkx+COA==@ietf.org
X-Gm-Message-State: AOJu0YzsglojeNygPrhmV3FIYmwoMeT2gz65Zno2RiShulZZ2SJpkUA+ p/DPO7XzrSVtDvre1ifWaVV8enPZPNDX5df2OSTiC5j8VOaqXY6+oM0CF9dUFWcBYqWPkKPb0Ko =
X-Gm-Gg: ASbGnctYRvRcos7DR0CVv2xNU5FDWnV/tyIe+5hkZO50aBOd9x3InskrREHtDvw6dn1 FhYHyiMmI5vcdReBndDxnwFUhaP2muH+O/Yab82arxn518j0cmXymDR5ZB/PzNRqTbspaAXsA6W HFqU2KEdD48u0MXmKqg/Y4yoHzLKzh4m/yoYAEV1nScDMtscl7uDxsg4N5BXhJMnGpZmN+DZmwW kxn4jaW8TX7+MvRoMcymbT3nmyWV2h2AYYwu8FvFPhRzyOzPS8NhN8sjBnsdWpEz7C3hMsHvxHi g1Dtceu4S9w3tchX1yDBf7DWsN+bOXnEgbw/gfU=
X-Google-Smtp-Source: AGHT+IGJrHu7u1YBneSkj6drmmbXs3IM5oUuvKImkYb2lXQvDMT5a5Knicyl0pD71A1c+7XYOXMtmQ==
X-Received: by 2002:a05:6122:918:b0:516:dc0f:c925 with SMTP id 71dfb90a1353d-51cd983a309mr21878575e0c.6.1737484637224; Tue, 21 Jan 2025 10:37:17 -0800 (PST)
Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com. [209.85.222.41]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-8642cacb0eesm2469176241.10.2025.01.21.10.37.16 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jan 2025 10:37:16 -0800 (PST)
Received: by mail-ua1-f41.google.com with SMTP id a1e0cc1a2514c-85c436db302so33818241.0 for <oauth@ietf.org>; Tue, 21 Jan 2025 10:37:16 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCVstbj+rwTQnhUk4gowbiYbeMhBA9yefwsmtA/MQn/REfx2vuhr4SrP0RyP8zHkDuHTGIWjVw==@ietf.org
X-Received: by 2002:a05:6122:da4:b0:50d:39aa:7881 with SMTP id 71dfb90a1353d-51d6f8f9f1amr13965887e0c.0.1737484636395; Tue, 21 Jan 2025 10:37:16 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+Lwgykk+B2UspfXBcLipFiTifNBf-WG-DeXPpWT39syqqVg@mail.gmail.com> <CAJot-L36t-LWPGRZu7ACkKyzsxDgD6zcevxrONbLBxtjh3KdWA@mail.gmail.com> <CAMm+Lwg+rbjU-Q17Re=KHrNvk6UXKtS35VS2LrY8cUwkyT6piw@mail.gmail.com>
In-Reply-To: <CAMm+Lwg+rbjU-Q17Re=KHrNvk6UXKtS35VS2LrY8cUwkyT6piw@mail.gmail.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Tue, 21 Jan 2025 10:37:04 -0800
X-Gmail-Original-Message-ID: <CAGBSGjp+JFzy-yhs92ampN96PTOFDXy8JsAJ9rxrgGNuYYcqMA@mail.gmail.com>
X-Gm-Features: AbW1kvaR-jG7mdXlpIy3voXrgIo8qDNReDaZtvsHNqAvpJqMcZpmMCClGKPy-cI
Message-ID: <CAGBSGjp+JFzy-yhs92ampN96PTOFDXy8JsAJ9rxrgGNuYYcqMA@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: multipart/alternative; boundary="0000000000008e2c57062c3baa5a"
Message-ID-Hash: OLCYYMN2E2ZSUIXZMVKWXUCZPMSVBFYQ
X-Message-ID-Hash: OLCYYMN2E2ZSUIXZMVKWXUCZPMSVBFYQ
X-MailFrom: aaron@parecki.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/bzc04-Ej54uaym8sEe8mx1tA4wM>
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>

We should talk next time we meet at IETF. This is something I've been
working on for a very long time.

Most recently, I've been working on prototyping a similar thing leveraging
an experimental feature in FedCM, called "IDP Registration", enabling an RP
to use an arbitrary IDP rather than one from a fixed list like "Sign in
with Google". FedCM solves the UX problem that has plagued adoption of
"bring your own IDP" efforts like OpenID in the past.

I have a blog post about this with a demo video and details on how to put
together the various OAuth building blocks to make it happen:

https://aaronparecki.com/2024/05/12/3/fedcm-for-indieauth

There's also a handful of people who have spun up IDPs that support this
with their own domain and trying out the FedCM feature, you can see all the
details here: https://github.com/w3c-fedid/idp-registration/issues/2

Aaron


On Tue, Jan 21, 2025 at 10:19 AM Phillip Hallam-Baker <phill@hallambaker.com>
wrote:

> 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 mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>