[OAUTH-WG] Re: DNS Handles

[Pawel Kowalik <[e-mail]>]

Hi Phillip,

The two drafts mentioned by Vladimir were building blocks for something 
called ID4me - https://id4me.org/.

The project is not that alive anymore as it was lacking adoption, 
everyone looking more into blockchain identity solutions at the time.

Documentation is open and available 
https://gitlab.com/ID4me/documentation . Maybe useful for your work. I'm 
happy to talk about it in BKK if you are around.

Kind Regards,

Pawel

On 26.01.25 17:00, Phillip Hallam-Baker wrote:
> Well useful prior art. I suspect that there are several folk looking 
> at what is being built and working out how to backdate a claim with a 
> continuation of a patent already in progress - as happened many times 
> with Web tech.
>
> The question everyone seems to be asking is 'why this way, why now'.
>
> I think the answer is that developing an identity scheme is much 
> easier technical problem than folk imagine, anyone can propose an 
> identifier and resolution scheme and everyone did and so we ended up 
> with dozens of schemes on the table and the whole problem was to pick 
> just one. And that is why the BlueSky adoption of one scheme and 
> getting 29 million users is a game changer: there is critical mass 
> behind that approach and that is vastly more significant than any 
> technical concerns.
>
> DNS handles also meet the critical criteria for success - they are 
> genuinely open, human comprehensible and can be internationalized.
>
>
>
> On Sun, Jan 26, 2025 at 2:35 AM Vladimir Dzhuvinov / Connect2id 
> <[e-mail]> wrote:
>
>     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]
>
>
> _______________________________________________
> OAuth mailing list [e-mail]
> To unsubscribe send an email [e-mail]