This is a project I've been working on for a little while and I'm interested in your feedback and point of view.

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.