[DNSOP] Domain Verification Techniques using DNS

[[e-mail]]

Dear DNSOP WG,

My company has developed a domain verification technique using DNS, it fits the abstract of draft-ietf-dnsop-domain-verification-techniques. 

I am writing to ask the WG's opinion on whether our technique is within the scope of the current draft and if so, whether it should be considered for inclusion.

Our technique is outlined here:
https://www.domainverification.org

You can see an example DNS TXT record by using the following dig command:

dig 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com TXT

Although our method fits the draft's title and abstract, it is quite different to the method detailed in the best current practice of the draft. 

It is similar in the following ways:

- Data is stored in a DNS TXT record

- Data is stored at a subdomain of the target domain, rather than stored at the apex of the zone

- The record includes an expiry date for the verification


It differs in the following ways:

- Each DNS TXT record does not provide verification for an individual service provider, each record enables verification for an authorised party (domain owner, SEO agency, etc)

- Authorised parties are identified by email or telephone number (we call these verifiable identifiers) 

- A hash of the verifiable identifier is used as a DNS label in the DNS name of the TXT record, so that authorised parties are not easily discoverable

- The TXT record includes permissions for the authorised party, the scope can be as narrow as a particular service provider – e.g. "search.google.com" – similar to the current BCP draft; permissions can also be much broader, e.g. by category (like "seo") or permissions that enable the authorised party to verify the domain with any service provider

– For an authorised party to verify the domain with a service provider, they must provide their verifiable identifier (email or phone) to the service provider and then demonstrate ownership of that verifiable identifier, using standard techniques (e.g. clicking an email verifications link or receiving an SMS verification code).

- The current draft ensures that the string used in the DNS TXT is not reproducible across service providers; our method has the opposite objective – to ensure that the string is reproducible across service providers.


It is our ultimate goal for these records to be created by domain registrars upon domain registration (with registrant opt-in) to provide their customers with seamless onboarding when adding their domain to service providers.

I am interested in the views of the WG on whether this technique could be included in the draft, and if not, whether the scope of the draft should be narrowed to be BCP for providing verification on a service-provider basis.


In accordance with BCP79, I am disclosing the following patents which relate to our technology:

Patents related to storing a hash of a verifiable identifier (email, phone, etc) in DNS for the purposes of verification:

- UK granted patent: https://patents.google.com/patent/GB2585353B
- US pending patent: https://patents.google.com/patent/US20220141172A1

Patents related to storing a hash of a verifiable identifier as a DNS label for the purposes of verification:

- UK pending and unpublished patent: https://patents.google.com/patent/GB202216304D0
- US patent to be filed.

As I understand it, this disclosure is a condition of contributing to the discussion. For the avoidance of doubt: I am not asserting any rights over the methods discussed in the current draft at all – only our new method being proposed for inclusion. 

We are still working on licensing but creating Domain Verification records will always be free for domain registrants or registrars, service providers will require a license to verify domains using the protocol.

This is my first time contributing to the IETF, please forgive me for any accidental transgressions – I am here to contribute as productively as possible.

Best regards,

Elliott Brown
CEO
NUM Technology Ltd