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 --oauth@ietf.org To unsubscribe send an email tooauth-le...@ietf.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
