[OAUTH-WG] Re: DNS Handles

Sam Goto <goto@google.com> Wed, 22 January 2025 05:20 UTC

Return-Path: <goto@google.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 AD7E2C1CAE74 for <oauth@ietfa.amsl.com>; Tue, 21 Jan 2025 21:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.607
X-Spam-Level:
X-Spam-Status: No, score=-17.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 36Zss4j5NCsM for <oauth@ietfa.amsl.com>; Tue, 21 Jan 2025 21:20:49 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 4F22CC169435 for <oauth@ietf.org>; Tue, 21 Jan 2025 21:20:49 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-53e44a42512so2648e87.1 for <oauth@ietf.org>; Tue, 21 Jan 2025 21:20:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737523247; x=1738128047; 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=cZWODsdtcI6hOMNxWJO5sE0vDSorfA/9mCvCw5GTerw=; b=FmIiIjf/bRqRfJ5r371n0Q73BRQ1l4bpGkQe9xFTo16moVTyliVD/VCWtnEjBlbwX7 3wTblsKK5HP+qa2HOCPInMhP7Xsdk2KQYQQ5hUouB23FsyEls/UJ6Am5Ajoop5hLlTrI lG2RrEzFzfn9wHwl+PhaD4bHCbW2EtruHmnu75Ytj+49b7oqfW2fp+FRzM69b13vc5mA Sai5Mtc6z3LlRiC36w9lCvQUjeicsp2Y9p7QbKmISU0F7G9Xyj0ybc9idqEY8YM/as7d C6Y/gSefdg/9uZCMLK0nlN17gKWUF6swP+vlYx6P8DkMpfeKG2ywpMCabogpomoe+0vj kMEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737523247; x=1738128047; 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=cZWODsdtcI6hOMNxWJO5sE0vDSorfA/9mCvCw5GTerw=; b=tHo9N2v/kv3+C5wXLaMSSHr0RUc9I70ZlHvb8vW6YMTI4SO6ChYW+tQjdf4SVX7q2i dQ78XGSA5UX2JpUrX6tlOhnO/1Kt5cuMd+7DkU5uep5pghNotg4ZrfioeDhSVMqnEL8f WGJg+go0LU9n1uMljttHcN/9QReqeh6QiQ+aKk5fBoRXzPElX47iaynsPYyJR1MumWs6 gjLZSNaSGvRp8tnf0KNazTuxzoJtRIxnL9Q/+wNeVM8xKZSe+OqPRudqSEskRG797DWK ZdkL6dH7x4wssfv/ihgdJ53xNSKyNeT+BFo7wa/qqhrmXxfGqFDKoI4EE2ycKReg2WjR FU3w==
X-Forwarded-Encrypted: i=1; AJvYcCV3YJuJINTpm9Y0hPrnmqAMYgU/mv9BPWiao8LyYP3AvazmQVSKYCIxu79ALcokOtoL9abgaA==@ietf.org
X-Gm-Message-State: AOJu0Yy+dMI+LRsRRgCPohw1+GobTOsFr2F2xJVKgkPRCJPwC+j4vSKy OVJWt9h+mpeDHjuOeMHJj4Uze2mKGUGuCQ/9KYwHHO6tOIKHyRQeW/2mx1ueXa748xbLomSvk7Z dR6ffDCPc9UoRZjRFEyRlyoA9XJWpZH/x6mNp
X-Gm-Gg: ASbGncuuuEqI+gC3c42lQwKbvtjNNt0Lfqc7qEXUtWSQz816GpQGSJiFrAQrZsfdoOd zs+N3OmME1NIk8pDtHEU7H057//cImoeNDso7uP/yqCRpgH6hgA==
X-Google-Smtp-Source: AGHT+IGj8D28GJ72Pcdz17IUlR/8oxgOHhPp63qXdiyiLgl+S6on7nojMyXs7APi7vNrUGAr6tDb5IAVEmsgsxYErg4=
X-Received: by 2002:ac2:4e63:0:b0:53d:dd69:51dc with SMTP id 2adb3069b0e04-543bc244104mr149952e87.6.1737523247197; Tue, 21 Jan 2025 21:20:47 -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> <CAMm+LwjCb4eTTAM2oAwF8--XfG6wzmXQfO7Ap87p5U1v+vSK3Q@mail.gmail.com> <CAD9ie-vMW=hm4j2Y5-weGzfuPmS-S48ZwEBpX-eV3HCH6tt-ew@mail.gmail.com> <CAMm+LwgB39dAOCnqHpAAjXCVcguytBYMRDQ2RJoKGfJcxdjEyg@mail.gmail.com> <CAD9ie-tiReSKfU4yNYA=UB4mrkAve2+1yrUWa5CRZmrtVx2HGg@mail.gmail.com>
In-Reply-To: <CAD9ie-tiReSKfU4yNYA=UB4mrkAve2+1yrUWa5CRZmrtVx2HGg@mail.gmail.com>
From: Sam Goto <goto@google.com>
Date: Tue, 21 Jan 2025 21:20:38 -0800
X-Gm-Features: AbW1kvYuaz_KuUS2N7ccUtZzDxGnPs6waM-TUYqMzhkvkNL_j9HrEuW_toIrwHY
Message-ID: <CAMtUnc4NMYEkJyukJSEMBN0icw0gTVuAyZ36bZ4u954OiDKRuA@mail.gmail.com>
To: Dick Hardt <Dick.Hardt@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f0c03b062c44a78f"
Message-ID-Hash: M73JO6OBKG6MSDYI6GTAYRCKLVS5UZEF
X-Message-ID-Hash: M73JO6OBKG6MSDYI6GTAYRCKLVS5UZEF
X-MailFrom: goto@google.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: Phillip Hallam-Baker <phill@hallambaker.com>, oauth <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/rOxLrW1WUh7K98pIHglk4CbNwPw>
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>

FWIW, I do agree that it is unlikely that a standard (any standard) will
change anything, but I do think that the rise of bluesky/mastodon in
conjunction with the browser being more involved (as Aaron pointed out,
this specifically
https://github.com/w3c-fedid/idp-registration/issues/2 but this too
https://github.com/w3c-fedid/idp-registration/issues/15) adds at least a
couple missing parts that weren't available a few years ago when it was
last tried, and may be enough to make this viable.

I'm @sgo.to and really feel represented by my domain name on the web, and I
hope this pattern gets further developed.



On Tue, Jan 21, 2025, 2:49 PM Dick Hardt <dick.hardt@gmail.com> wrote:

> I’m not saying it won’t happen — I’m saying a standard is unlikely what is
> holding it back.
>
> On Tue, Jan 21, 2025 at 10:33 PM Phillip Hallam-Baker <
> phill@hallambaker.com> wrote:
>
>> Exactly the same happened with social media in general. We had
>> interactive forums and blogs in 1994. Users couldn't quite work out what
>> they were about.
>>
>> Ten years later, Facebook launched with a set of what were well worn
>> features by then and took off.
>>
>> Timing matters a great deal. At the same time OpenID launched, a friend
>> was trying to get a password management service off the ground. It crashed
>> and burned; the users simply hadn't got to a sufficient level of pain yet.
>> Today there are a dozen successful providers in that space.
>>
>> Another point to consider is that there is a very large government entity
>> that is very upset about the 'centralization' of the Web. A government
>> entity that is more than willing to pick fights with BigTech and the means
>> to enforce its legal decisions. This would be a very opportune moment for
>> certain companies to consider whether they would like to modify their
>> technical approach, so they are not unnecessarily inserting themselves into
>> unrelated business transactions or if they wish to press ahead and become
>> that which is between the irresistible force and the immovable object.
>>
>>
>>
>>
>> On Tue, Jan 21, 2025 at 4:45 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>>> Sounds alot like what OpenID was (not OpenID Connect)
>>>
>>> The user entered an identifier into the box and then was logged in. This
>>> was when blogging was taking off, and we all thought people had some
>>> identifier on the internet they would enter. Many of those were just a
>>> domain name.
>>>
>>> According to Built With, OpenID[1] had more adoption in the top 1M sites
>>> (42k) than Google Identity Platform[2] does today (35k).
>>>
>>> If you look at the OpenID graph, you see it spikes up, and then drops
>>> off rapidly. Consensus was that people did not know what to do.
>>>
>>> Perhaps the world is different now -- but I don't think so. It was not a
>>> lack of standards back then, and a standard is unlikely to change anything
>>> now.
>>>
>>> /Dick
>>>
>>>
>>>
>>> [1] https://trends.builtwith.com/docinfo/OpenID
>>> [2] https://trends.builtwith.com/widgets/Google-Identity-Platform
>>>
>>> On Tue, Jan 21, 2025 at 9:03 PM Phillip Hallam-Baker <
>>> phill@hallambaker.com> wrote:
>>>
>>>> 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 mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>