Return-Path: 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 D7BE7C15198C for ; Sun, 26 Jan 2025 08:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 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_NONE=-0.0001, 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 Yl3YhN4AtcVc for ; Sun, 26 Jan 2025 08:01:07 -0800 (PST) Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) (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 54676C14F712 for ; Sun, 26 Jan 2025 08:01:07 -0800 (PST) Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-6dd1b895541so77785326d6.0 for ; Sun, 26 Jan 2025 08:01:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737907265; x=1738512065; 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=AuE2R4hFm1rz0wMEKur15Fnlq7tCMVmbo7l+G8aOIss=; b=JhtuClZAhmNA/kLRFFbnp5g54aQ9Lqhv/Ai7g6zxYFGBtDycyS+msMFakyeIwWIrDQ PQujg2Yu3EMIHD/Sh0GBo37cU7A6B5E0unZH+Uqo/pMwnspWUrSzfURBjNiTlmpNVgq3 sj74DOSVGrA8Q6uWTjySt1SKhH1UgxmvDdhZWVKqxs6OYYXq8UpcGwFDySPz9/du24C2 o2zPaJct0SDFzgk3ZxHobZvifnoyg8qJLubdH5/HAf1T+Bn49APe36Jq6mzw8VHqZOGO p6fuYWZJBh4nrOa6OERj4nsFtqU2fgE/SEa+aD3k0p5mthCT4t0CtFPMdCIZk7uKYl2i 2Lug== X-Gm-Message-State: AOJu0YyGu8CHpEU02BvKWY5CYfX/hVBEtwQcY9ylI1JzxZuhxjbqb9Q2 OI2r6QPRiQJZRWhY0RvTh6UUiV7mEhnBGBUQitbTRGRrlwd3ozVbt7ZpQSz8jEzPAmpEnorQt5t 5IruIA9Q2iCWZZ0wt5rung/NRN7iY5NI+ X-Gm-Gg: ASbGnctVPYS60gK9Dqv51GGfUYSafFSWJfvu22BJcDLwhBhVZYbtRlYYMsTJvFCstUn qoUVjnXy/CCagFjXHes5gfD7ozXIumbwKBOpulFcXqQbfE9BLWTXVKt+qpfdZcR2d8cbngdYjcL 5Zd883cTdjmIXJwr+a9eDk X-Google-Smtp-Source: AGHT+IHZSQanDd8BHh47I6bUyjUXLCiaiHWTV66xeHOxY1KCHW9rLBz8w/NzEsNbejTh8C14QmuRBm7dytfnZeDcWqg= X-Received: by 2002:a05:6214:590a:b0:6d4:22d4:f5b0 with SMTP id 6a1803df08f44-6e1b220a5abmr547574246d6.33.1737907265343; Sun, 26 Jan 2025 08:01:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Sun, 26 Jan 2025 11:00:54 -0500 X-Gm-Features: AWEUYZl73PkdwnIQs3kgacV58xX_4tG-FiLJ3-pd9Qot7LV8kG9rr07beYNNP1I Message-ID: To: "Vladimir Dzhuvinov / Connect2id" Content-Type: multipart/alternative; boundary="0000000000003417f7062c9e11a3" Message-ID-Hash: CYQOL2FQ2LBMJCNPV4A34EGLJE3PFVDP X-Message-ID-Hash: CYQOL2FQ2LBMJCNPV4A34EGLJE3PFVDP 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: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_DNS_Handles?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003417f7062c9e11a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well useful prior art. I suspect that there are several folk looking at what is being built and working out how to backdate a claim with a continuation of a patent already in progress - as happened many times with Web tech. The question everyone seems to be asking is 'why this way, why now'. I think the answer is that developing an identity scheme is much easier technical problem than folk imagine, anyone can propose an identifier and resolution scheme and everyone did and so we ended up with dozens of schemes on the table and the whole problem was to pick just one. And that is why the BlueSky adoption of one scheme and getting 29 million users is a game changer: there is critical mass behind that approach and that is vastly more significant than any technical concerns. DNS handles also meet the critical criteria for success - they are genuinely open, human comprehensible and can be internationalized. On Sun, Jan 26, 2025 at 2:35=E2=80=AFAM Vladimir Dzhuvinov / Connect2id < vladimir@connect2id.com> wrote: > Hello Phillip, > > In the late 2010s DENIC (the .de registrar) worked on a PoC for DNS-based > discovery and client registration for OpenID Connect. > > They produced two drafts which you can find here: > > > "An Architecture for a Public Identity Infrastructure Based on DNS and Op= enID > Connect" > > > https://datatracker.ietf.org/doc/html/draft-bertola-dns-openid-pidi-archi= tecture-01 > > > "OpenID Connect DNS-based Discovery" > > https://datatracker.ietf.org/doc/html/draft-sanz-openid-dns-discovery-01 > > > Vladimir Dzhuvinov > > On 21/01/2025 19:15, Phillip Hallam-Baker wrote: > > As some of you are probably aware, BlueSky makes use of OAuth2 as their > primary authentication mechanism with one important divergence from the > established use pattern: account identifiers are DNS handles. > > I have been looking at this approach in some detail and I think that just > as 90% of the Web was not new but contained the missing pieces that > completed the puzzle, the use of DNS handles may represent a similar step > forward for OAuth and much much more. > > As I see it, there are two types of DNS handle, personal registration > handles under a name held by the user. I have hallambaker.com so I issued > myself @phill.hallambaker.com. Most users don't have a DNS name so they > make use of 'at will' handles that are provided by a service provider. > Right now, that is pretty much limited to Blue Sky (I also > have @hallam.bsky.social). But what if the use of DNS handles became the > standard way to do OpenID instead of being limited to an account with the > provider cartel? What if I could use my DNS handle to log in anywhere? > > > I have been working on this and have developed code that puts up a social > media forum entirely disconnected from BlueSky and the ATprotocol but > allows use of the same handles. So once I have the site finished, you wil= l > be able to comment on my personal blog at https://phill.hallambaker.com/ > using the same account you use for BlueSky. And you will be able to comme= nt > on the specs and join in private forum discussions at mplace2.social. > > And when I started, that was really all I was looking to do plus work out > how to use the same mechanism with the end-to-end secure personal > communications scheme I have developed. If Alice is using @ > alice.example.com for social media, isn't that the obvious handle to use > to reach her for direct messaging? And if she accepts a contact exchange, > shouldn't I also be able to send her email and drop files? how about usin= g > the same handle to set up a MOQ video chat? > > > What this gets us to is a place where there is a big incentive for users > to get themselves a multi-purpose DNS handle for their personal internet > identity. Ideally of course, this is a personal registration allowing the > user to change their service provider(s) at will without switching costs. > But even an at-will handle is making them independent of the provider > cartel. > > And we can go further, I have code that automates management of IoT > devices under either type of handle. So I can buy a coffee pot, onboard i= t > to my personal set of devices and set it up with the DNS record entries a= nd > certificates to reach it as coffee.hallambaker.com - all by scanning the > QR code and giving it the name 'coffee'. > > As with the Web, 90% of what we need to make this happen already exists - > OAuth, OpenID, DNS Update, ACME, I am just writing a profile that takes > very large specs and chops out bits to choose a single way to do things. = As > you would expect, I am filling in some of the gaps using code I have > written for the Mesh but we could use Signal protocol instead - if the > provider was willing to open up its walled garden. > > > I believe the above represents a compelling value proposition. But as I > got into documenting, I started to find more and more opportunity. > > Let us imagine that we rejigger the current ATprotocol spec for DNS > handles slightly so that we make the authorization service a first class > party rather than being assumed to be a service provided by a particular > content provider. Let us also give it a new name (I am currently > using @nywhere) under which this particular log in trope can be recognize= d > and assume that it is widely supported as a means of logging into content > providers across the Internet. > > In that scenario, I could log into my authentication provider once in the > morning and that would give me access to all the content properties I nee= d > access to across the Web. And that provides an antidote for the current > trend towards absurd and obnoxious demands for 2FA to access assets that > are ultimately worthless. No, a crappy Web store does not need me to crea= te > an account for me to browse their wares and it certainly doesn't need to > demand me respond to an email callback. > > If I have a single authentication provider, then it can authenticate me > once in the morning and I am good to go for the day. And we don't need to > be limited to the limited capabilities of authentication schemes that wor= k > across HTML/HTTP. We can use biometrics, etc. etc. > > This gives us a route to get rid of passwords that is actually deployable= . > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org > > --0000000000003417f7062c9e11a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wel= l useful prior art. I suspect that there are several folk looking at what i= s being built and working out how to backdate a claim with a continuation o= f a patent already in progress - as happened many times with Web tech.

The question everyone seems t= o be asking is 'why this way, why now'.

I think the answer is that developing an identity sc= heme is much easier technical problem than folk imagine, anyone can propose= an identifier and resolution scheme and everyone did and so we ended up wi= th dozens of schemes on the table and the whole problem was to pick just on= e. And that is why the BlueSky adoption of one scheme and getting 29 millio= n users is a game changer: there is critical mass behind=C2=A0that approach= and that is vastly more significant than any technical concerns.

DNS handles also meet the critical= criteria for success - they are genuinely open, human comprehensible and c= an be internationalized.

=

On Sun, Jan 26, 2025 at 2:35=E2=80=AFAM Vla= dimir Dzhuvinov / Connect2id <vladimir@connect2id.com> wrote:
=20 =20 =20

Hello Phillip,

In the late 2010s DENIC (the .de registrar) worked on a PoC for DNS-based discovery and client registration for OpenID Connect.

They produced two drafts which you can find here:


"An Architecture for a Public Identity Infrastructure Based on DNS and OpenID Connect"

https://datatracker.ietf.org/= doc/html/draft-bertola-dns-openid-pidi-architecture-01


"OpenID Connect DNS-based Discovery"

https://datatracker.ietf.org/doc/html/dr= aft-sanz-openid-dns-discovery-01


Vladimir Dzhuvinov
On 21/01/2025 19:15, Phillip Hallam-Baker wrote:
=20
As some of you are probably aware, BlueSky makes use of OAuth2 as their primary authentication mechanism with one important divergence from the established use pattern: account identifiers are DNS handles.

I have bee= n looking at this approach in some detail and I think that just as 90% of the Web was not new but contained the missing pieces that completed the puzzle, the use of DNS handles may represent a similar step forward for OAuth and much much more.

As I see it, there are two types of DNS handle, personal registration handles under a name held by the user. I have hallambaker.com so I issued myself=C2=A0@phill.hallambaker.com. Most users don't have a DNS name so they make use of 'at wil= l' handles that are provided by a service provider. Right now, that is pretty much limited to Blue Sky (I also have=C2=A0@hallam.bsky.social). But what if the use of DNS handles became the standard way to do OpenID instead of being limited to an account with the provider cartel? What if I could use my DNS handle to log in anywhere?


I have bee= n working on this and have developed code that puts up a social media forum entirely disconnected from BlueSky and the ATprotocol=C2=A0but allows use of the same handles. So once= I have the site finished, you will be able to comment on my personal blog at https://phill.hallambaker.com/ using the same account you use for BlueSky. And you will be able to comment on the specs and join in private forum discussions at mplace2.social.

And when I started, that was really all I was looking to do plus work out how to use the same mechanism with the end-to-end secure personal communications scheme I have developed. If Alice is using=C2=A0@alice.example.com for social media, isn't that the obvious handle to use to reach her fo= r direct messaging? And if she accepts a contact exchange, shouldn't I also be able to send her email and drop files? how about using the same handle to set up a MOQ video chat?


What this gets us to is a place where there is a big incentive for users to get themselves a multi-purpose DNS handle for their personal internet identity. Ideally of course, this is a personal registration allowing the user to change their service provider(s) at will without switching costs. But even an at-will handle is making them independent of the provider cartel.

And we can go further, I have code that automates management of IoT devices under either type of handle. So I can buy a coffee pot, onboard it to my personal set of devices and set it up with the DNS record entries and certificates to reach it as cof= fee.hallambaker.com - all by scanning the QR code and giving it the name 'coffee'.

As with th= e Web, 90% of what we need to make this happen already exists - OAuth, OpenID, DNS Update, ACME, I am just writing a profile that takes very large specs and chops out bits to choose a single way to do things. As you would expect, I am filling in some of the gaps using code I have written for the Mesh but we could use Signal protocol instead - if the provider was willing to open up its walled garden.


I believe the above represents a compelling value proposition. But as I got into documenting, I started to find more and more opportunity.

Let us imagine that we rejigger the current ATprotocol=C2=A0spec for D= NS handles slightly so that we make the authorization service a first class party rather than being assumed to be a service provided by a particular content provider. Let us also give it a new name (I am currently using=C2=A0@nywhere) under which this particular log in trope can be recognized and assume that it is widely supported as a means of logging into content providers across the Internet.

In that scenario, I could log into my authentication provider once in the morning and that would give me access to all the content properties I need access to across the Web. And that provides an antidote for the current trend towards absurd and obnoxious demands for 2FA to access assets that are ultimately worthless. No, a crappy Web store does not need me to create an account for me to browse their wares and it certainly doesn't need to demand me respond to an email callback.

If I have = a single authentication provider, then it can authenticate me once in the morning and I am good to go for the day. And we don't need to be limited to the limited capabilities of authentication schemes that work across HTML/HTTP. We can use biometrics, etc. etc.

This gives us a route to get rid of passwords that is actually deployable.


_______________________________________________
OAuth mailing list -- o=
auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
--0000000000003417f7062c9e11a3--