[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 >
- [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