zlacker

>>aendru+(OP)
This is a terrible implementation of domain verification. dns-01 and http-01 are more or less standardized at this point. Use them, and don't roll your own. Reference: https://letsencrypt.org/docs/challenge-types/.

>>paxys+x4
They definitely should have used HTTP-01 if they’re doing verification on the web, but since this is about using a domain as identity this really belongs in DNS.

The issue with DNS-01 (and HTTP-01 to a lesser extent) as someone else mentioned is that the user friction is really high.

I’ve been working on a solution to this that I’ve been meaning to post to HN and this seems like as good an opportunity as any so here it is: [1]

It’s a method of storing a hashed (and optionally salted) verifiable identifier (think email or mobile) at a subdomain to prove authority for a domain.

1. https://www.domainverification.org

>>elliot+vl
> this really belongs in DNS.

And the primary way of identifying yourself is in fact DNS.

> I’ve been working on a solution to this

Your solution is almost identical to the BlueSky one: put a TXT record at _atproto.<domain> that resolves to a DID. The difference is that they mandate the DID spec and you do not. Which is totally fine! Just figured I'd let you know :)

>>stevek+xm
Thanks for taking a look and for your comment.

Another key difference is that the _atproto TXT record is discoverable since it’s always at _atproto. Whereas the “verifiable identifier” I use isn’t discoverable because it’s hashed and used as a dns label.

The ultimate goal here would be for these records to be populated by domain registrars upon a domain being registered (with registrant’s permission obviously).

This could create a kind of fast lane for domain verification across providers like Google Ads, Facebook, Office365 and everyone else that requests DNS verification.

The worst thing is that hundreds of providers request domain verification TXTs at the zone apex:

dig target.com TXT