[OAUTH-WG] Re: DNS Handles
Phillip Hallam-Baker <phill@hallambaker.com> Tue, 21 January 2025 21:03 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 606F1C1E56AB for <oauth@ietfa.amsl.com>; Tue, 21 Jan 2025 13:03:35 -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 d-BPhCVxrR-8 for <oauth@ietfa.amsl.com>; Tue, 21 Jan 2025 13:03:34 -0800 (PST)
Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) (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 5C8B6C1E165D for <oauth@ietf.org>; Tue, 21 Jan 2025 13:03:34 -0800 (PST)
Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-6e1a36b3684so74980296d6.1 for <oauth@ietf.org>; Tue, 21 Jan 2025 13:03:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737493413; x=1738098213; 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=wZWcdEBcEs/OWCrE/EaQhh0Q7ylhWxYk8gdfx2+gUsA=; b=o9Fh1UTBVy1yvMiWXIn3GfvA+WXLzC4s79pEXSX89/47AXCXAR/6OMLLXYWjwVs8je r9NC9ffH8wfbGOJi2SUaC9+jLrOmhHe7KU+Ud6Wk44gV3z+kJtOyzGRlrsbQFm7BYQE7 W2MBWxmlMdXbrPLkJApu89wnSGAtKLN8HvfQIgcrqt0Nl0gZitAWH0rZSBN/jC+TLRkY EJPeUsGvOetFbJQBEWfnDzP4tlAebTPwDqDgNWvN94Mvoxp/QVkHhjbjjI/BIfXMLB/d kgPnNb2rzzC3hHMjytnnjN0rZCIdiT3iSKr567D1z3BHAjrVF3mZhwNuGBC6FNuqNiBF OucQ==
X-Forwarded-Encrypted: i=1; AJvYcCUP1UxKYAIgnhuSD0k1hPiFgryHN21rk1fBmGmWANrj71GecWMoSeYy9H2JkAqf+zEpr9M6/Q==@ietf.org
X-Gm-Message-State: AOJu0YwfOiVCx7MPMnahxlYvBaN3bg/j+r0tzMXZ1RtApowBw40961Km sHpdhmWsqAqDjFtL3a2RrVebRbgHyaBOKSlB2pen3QmKZGg+SxffROUfUVBf4R3mLzCze4Ct/1T NYJ7T9CCVT6/XQHVK6kgtTbKj+AQ=
X-Gm-Gg: ASbGncujdmaXSPe4awHk6UDlumKW/GUOUFsZU2fAeqQPYlMVRaTNnVbO2ulixOmJnmu 66/JfpAeUVT10AeXv/hLWaTMb730yQuW4SXXstyTnWQZ78vloXrhUCDTErS8+JXDpYEYKC9/p8f wWM2GtIQ2o
X-Google-Smtp-Source: AGHT+IEZt7i2EwHrrgjjMvXBIsscehkhm24n1vBSJgnFpVe+t8LtOd/DUk5ojJ94oI5yva51xHXfqtsbwrY6PjTwzgw=
X-Received: by 2002:ad4:5c8b:0:b0:6d8:898a:a508 with SMTP id 6a1803df08f44-6e1b21765ddmr250666086d6.16.1737493413377; Tue, 21 Jan 2025 13:03:33 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+Lwgykk+B2UspfXBcLipFiTifNBf-WG-DeXPpWT39syqqVg@mail.gmail.com> <CAD9ie-tYsCODGfNTBDZgr46s4O4B9-u79jR=G10y4sN5HBiKgQ@mail.gmail.com> <CAMm+Lwje3G7EPkapFfVksbNtPN11LOs7Gj3Jj09uuFyvAb4FRQ@mail.gmail.com> <CAJot-L06J-T7vK2FJY4JGFQj4Zu=xFyNnKpnNM2SktCpOuTDKw@mail.gmail.com> <CAMm+Lwg+OizX_+bW7gkFqE3S6OGdF=h=7hpMSgnREWiqawiA5g@mail.gmail.com> <CAJot-L1rbkYg3rooqLrWw5StrqJMFZp7puc4GK+ACOqPtVbaig@mail.gmail.com> <CAMm+Lwj6qFy+njAd1T1F70EieJfxHCnkEcVLiGf8u7gSjhg0Kw@mail.gmail.com> <CAJot-L0chuJT26xPJHYzXzBgGKm=79brf88-7fqucmf9DDs5Hw@mail.gmail.com>
In-Reply-To: <CAJot-L0chuJT26xPJHYzXzBgGKm=79brf88-7fqucmf9DDs5Hw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 21 Jan 2025 16:03:21 -0500
X-Gm-Features: AbW1kvbmx4etKCaxTBF6HF1vH0__GOZCAdtL_WMderjsBtV1nUJrWnan1GFtMbc
Message-ID: <CAMm+LwjCb4eTTAM2oAwF8--XfG6wzmXQfO7Ap87p5U1v+vSK3Q@mail.gmail.com>
To: Warren Parad <wparad@rhosys.ch>
Content-Type: multipart/alternative; boundary="000000000000b43fd4062c3db526"
Message-ID-Hash: JSGVF6IMO4IMR5ZQOCO4WB4RHVPDYGTE
X-Message-ID-Hash: JSGVF6IMO4IMR5ZQOCO4WB4RHVPDYGTE
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: Dick.Hardt@gmail.com, 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/TIwV1-8tgGhJ6MijKrV-xp8j0BA>
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>
The differences in the new approach as I see it are 1) The user identifier is '@' followed by their DNS address and that is the ONLY syntax used to present that identifier. No URIs, URLs, QR codes, etc. the only thing a user is required to remember and type in at a site where they want to claim their identity is their DNS handle. I am experimenting with calling the system @nywhere because this means I can prompt the user with the @ sign as the field label with 'nywhere' as text replaced as soon as they start to type. Which I think provides a really nice contextual grounding for the user. I am willing to change this but not to use https// or similar. URLs were never intended to be user facing labels. 2) The user can change their handle and preserve their account. In the ATprotocol scheme, the DNS handle is resolved to a DID which is a fingerprint of a public key that can be used as a root of trust for making claims related to the handle. Now, I have reservations about this part of the BlueSky spec and the fact that it is bound to a public key doesn't really mean anything unless the private key is held by the end user. It is a part of the spec that I want to align with end-to-end secure communications tech that put the private key under user control. But in the meantime, it DOES provide the ability to change handles and that is really important as it allows users to move from an 'at-will' handle controlled by another to a personal registration. 3) The entire system is loosely coupled. Relying sites are not required to establish any prior relationship with the authentication provider. This is obviously something a lot of folk are going to object to but the only way that an authentication system can become ubiquitous is if it is permissionless. I talked to folk about connecting my Internet Drafts comment forum up to the IETF datatracker and was told this was likely to require contracts and agreements and such. The emerging infrastructure allows me to authenticate the user regardless of who is providing their authentication without needing any prior agreement, app key or anything. On Tue, Jan 21, 2025 at 3:13 PM Warren Parad <wparad@rhosys.ch> wrote: > I'm not really following. Maybe let's start at the end and work ourselves > backwards. As an Identity Provider today, we generate JWTs for our users > that applications can use. Users log in to applications via our > Authorization Server and get application specific JWTs. Based on your > suggestion how does the result JWT different from the one that we are > generating for the user+application today? > > On Tue, Jan 21, 2025 at 9:02 PM Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> On Tue, Jan 21, 2025 at 2:43 PM Warren Parad <wparad@rhosys.ch> wrote: >> >>> The only thing lacking is a base of authentication service providers >>>> that are willing to give users control. >>> >>> >>> As someone who works for one of those "authentication service >>> providers", what exactly would we need to support that we don't already? >>> >> >> I am writing a draft. The short answer is almost nothing. But not nothing. >> >> The longer answer is that we need to have: >> >> 1) A detailed explanation that puts ALL the information needed to >> implement against the profile in one place. I am working on an Internet >> draft to do exactly that. >> >> 2) A discussion of how to best present the scheme as something whose >> primary purpose is as an authentication provider rather than an account >> with one social media property that can also be used elsewhere. >> >> 3) A discussion of how to use the DNS handles to enable end-to-end secure >> messaging. If Bob is reading a comment by Alice under @alice.example.com, >> that is the handle he is likely to want to use to message her. >> >> 4) A discussion about what else we might want a DNS handle provider to >> support. I have a prototype running that extends to supporting the IoT >> requirements raised in SETTLE. >> >> Right now, we have 'a' way to do this which is not necessarily the best >> way or the way that allows us to grow in all the ways we might want in the >> future. >> >> I have a history of being able to market protocols and get them into >> widespread use. I haven't always been successful but have more successes >> than failures and I think I know what it takes to make DNS Handles widely >> used, which businesses I need to approach, etc. etc. >> >> The reason I am raising this here now, is that before I go round to the >> DNS registrars (and their affiliates) and the VPN providers and such to say >> this is the thing to do, I want to make sure we have everything straight at >> a technical level so we are all on the same page. >> >> >>
- [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