Show HN: Automatic Domain Verification
27 points| elliottinvent | 2 years ago |domainverification.org
The Domain Verification protocol stores a DNS TXT record at a DNS name derived from a hashed "verifiable identifier" (email, telephone, DID), enabling anyone that can prove control over the verifiable identifier to prove authority for the domain name, whilst preserving the privacy of the authorised party.
Once setup, the record enables automatic domain verification for any service provider.
This record could be automatically setup by domain registrars upon domain registration (with registrant opt-in) creating a fast lane for verification with service providers many new small businesses use (eg Google Ads, Facebook, Office365, Dropbox, etc).
=====
Many of us would have verified a domain name by pasting a string into a DNS TXT record. These methods are currently being discussed and standardised at the IETF [2].
Let's Encrypt's DNS-01 method [3] is probably considered the state of the art. The differences between DNS-01 and Domain Verification protocol are:
- DNS-01 requires a new TXT record for each service provider. With Domain Verification Protocol, multiple service providers can use the same record.
- Instructions to setup a DNS-01 TXT record are instigated by the service provider, whereas a Domain Verification Protocol record can be setup independently by a user or a domain registrar. They could even pre-populated by a registrar upon domain registration (with registrant opt-in)
- There’s no concept of permissions in DNS-01, the act of creating the record gives the user full access for the domain with the service provider. With Domain Verification protocol multiple records can be setup, limited permissions could be setup for different third parties. For example give a marketing agency authentication to claim the domain on social media but nowhere else.
I'm still working on licensing but creating these records will always be free. I hope to find service providers that see significant upside in reducing friction for user onboarding that are willing to pay to license it.
Worked example: Let's say you want to authenticate the user with the email user@example.com with the domain dvexample.com, these are the steps:
a. HASH(user@example.com) -> 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg
b. Store Domain Verification record at: 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com
c. TXT record determines permissions and time limit:
@dv=1;d=Example user email;e=2025-01-01;s=[seo;email];h=4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg
Thanks for taking a look,
Elliott
1. https://news.ycombinator.com/item?id=35827952
2. https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-ver...
3. https://letsencrypt.org/docs/challenge-types/
=====
Quick sidebar:
This was originally submitted to HN under the title "Show HN: Make domain verification as easy as verifying an email or phone number" 3 days ago [1]. It was doing really well (#3 on front page) then totally disappeared from front page and went to bottom of page 1 of Show HN.
After an email exchange with dang (incredibly helpful as always), he explained that it got flagged with the "overheated discussion detector" and it turned out I caused this by diligently responding to every comment as fast as my fingers would type because I wanted to keep engagement going. Helpfully dang took the flag off it about 12 hours later after our email exchange, but understandably the momentum was lost.
So I feel like it kinda got killed, just as it was picking up pace and as the US west coast was waking up. So I am humbly reposting it with a modified description based on the comments of the last post.
breck|2 years ago
My feedback would be a simpler approach, ditching the hash. Why not just encourage people to put their email address in plain text in a DNS record? If they want anonymity, they can fall back to the way verification is done today. If they want convenience, they can broadcast their email&DNS link.
For example, I own "BreckYunits.com" and my email address is listed throughout my site. I wouldn't be giving up any privacy by putting that in a DNS record.
Sure, some people will exaggerate the fear risk (usually the ones selling a security product), but I'm of the old school opinion that we should advocate good behavior and admonish bad behavior on the web and build a more civil world.
CharlesW|2 years ago
My reading is that it's because the purpose of the effort is to compel Google, Facebook, etc. license this proprietary protocol from the creator. I don't personally understand what the moat is since DNS- or file-based verification is a basic feature of all services that need to validate domain control.
elliottinvent|2 years ago
hitchdev|2 years ago
>For example give a marketing agency authentication to claim the domain on social media but nowhere else.
How does it prevent them from claiming it elsewhere?
doodlesdev|2 years ago
elliottinvent|2 years ago
In the meantime, you can see the spec here: https://gitlab.com/NUMTechnology/Domain-Verification/docs/-/...
nbpalomino|2 years ago
HN hug of death maybe?
elliottinvent|2 years ago
It’s ok for me but I’ll check the logs.
It’s just a basic fly.io setup at the moment but it should be more than capable of dealing with the traffic - just html (and htmx) front end and Sinatra back end.
It stood up pretty well to the traffic last time.