[OAUTH-WG] Re: DNS Handles

[Warren Parad <[e-mail]>]

Phillip, can you concretely share an actual issue though? E.g. What is the
standard and what exact problem does it solve? From my naïve perspective, I
don't see how you are requesting anything different from what OAuth already
is exactly providing.

Maybe one particular you might not be aware of is the effort by the
browsers, and honestly, mostly by this WG to make FedCM solve what I
believe is more than 100% of the problem space you might be talking about.
Are you familiar with FedCM?
https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API

On Tue, Jan 21, 2025 at 7:32 PM Dick Hardt <[e-mail]> wrote:

> From a privacy perspective, using a correlatable identifier across all
> sites simplifies tracking to the detriment of the user's privacy.
>
> The other concern with this approach is control of the identifier is
> control of your identity. How does my mom get back control?
>
> We have similar issues with email, which is by default how people login to
> most sites and do an email loop to prove control of their identifier if
> they (or the attacker) does not have the password.
>
> On Tue, Jan 21, 2025 at 5:26 PM Phillip Hallam-Baker <
> [e-mail]> 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 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>