Not sure I understand, are you somehow trying to reinvent WebFinger? (I understand the different implementation but from the user PoV it looks a lot like that)
Le mar. 21 janv. 2025, 18:26, Phillip Hallam-Baker <ph...@hallambaker.com> a écrit : > 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 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 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 - 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 to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
