Phillip, please take a look at this spec which is a complete description of everything to implement a profile of OAuth based on DNS handles:
https://indieauth.spec.indieweb.org I also have a blog post that talks about this architecture from an OAuth POV: https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web This has been deployed for many years, though not at the scale of BlueSky. There's a few commercial services that use it, there's plugins for Wordpress and Drupal, and a bunch of home-grown implementations. I've been breaking up the spec into smaller I-Ds, most recently presenting this at the OAuth interim meeting earlier this month: https://datatracker.ietf.org/doc/html/draft-parecki-oauth-client-id-scheme https://datatracker.ietf.org/doc/html/draft-parecki-oauth-client-id-metadata-document These are also what the BlueSky implementation is based on. Aaron On Tue, Jan 21, 2025 at 12:03 PM Phillip Hallam-Baker <ph...@hallambaker.com> wrote: > On Tue, Jan 21, 2025 at 2:43 PM Warren Parad <wpa...@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-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
