[OAUTH-WG] Re: DNS Handles

[Vladimir Dzhuvinov / Connect2id <[e-mail]>]

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/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 
> <http://hallambaker.com> so I issued myself @phill.hallambaker.com 
> <http://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 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 @alice.example.com <http://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 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 coffee.hallambaker.com 
> <http://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 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 [e-mail]
> To unsubscribe send an email [e-mail]