[elliottinvent]

Thanks for taking a look and for your comments.

> If I understand correctly, you need to submit the verifiable identifiers (email address and optional salt) to the party where you need to verify.

The verifiable identifier is the email/telephone number, we do not consider the salt a verifiable identifier. Let's put the salt to one side for a moment, because that complicates matters and introduces a dependence.

> That means you need to trust said party to not abuse this information to verify your domain with other services which use the same verification method.

A service provider having your email address doesn't give them any more opportunity to claim your domain than they already have. They still have to verify control over that email address.

> the proof can't be stolen by someone who doesn't own the domain but received your proof.

The email (or salt) isn't the proof that someone has authority for a domain, verifying control over that email address through usual email confirmation links etc, is the proof.

A domain registrant is already providing service providers with their "verifiable identifier" (email or phone) when they sign up for a service – e.g. Google Ads, Facebook etc and these service providers already verify these identifiers with emails containing confirmation links and SMS codes.

The current process is that they tell Google/Facebook the domain and then Google ask you to create a TXT record

[rcme]

I think the difference here is that there is no way to MITM email verification because you get an email in your inbox directly from the service provider. There isn't any way to intercept that. But for domain verification, there is. Hostile service provider A could request ownership of domain X with some other service B. When you, the owner of domain X, go to register ownership of domain X with A, A can show you the information provided service provider B and end up stealing your domain with B.

[elliottinvent]

> Hostile service provider A could request ownership of domain X with some other service B. When you, the owner of domain X, go to register ownership of domain X with A, A can show you the information provided service provider B and end up stealing your domain with B.

This is an interesting attack vector for the current state-of-the-art.

However, you could argue that someone could do the same with the Domain Verification protocol by providing a seemingly useful tool to create a Domain Verification record but secretly hashing the email of the attacker rather than the domain registrant. Since it's hashed (for privacy reasons) there's no way for a normal end-user to realise that.