Domain binding

A two way binding between a claim key and the domain a business already uses, so that a lookalike domain cannot carry a credible claim. This is the cheapest effective defence in the model and the one most readers will actually benefit from.

A TXT record at the _revow label of the business domain, naming the key. Deliberately boring, deliberately one line.

_revow.northpier.example.  3600  IN  TXT  "v=revow1; key=0xa805a67f59cccc9869d5dcb4ffc02fc697b5819d"

Optional, to narrow a key to one claim:

_revow.northpier.example.  3600  IN  TXT  "v=revow1; key=0xa805a67f...; claim=fba0fc855026ba97"

Several records are allowed on one domain, because a firm has several people. A consumer treats the set as a whitelist for that domain.

The domain names the key, and the claim names the domain in its domain field, which the subject signed. A domain owner cannot claim somebody else key, and a key holder cannot claim somebody else domain. Either half on its own is meaningless and a consumer that checks only one half has implemented the wrong thing.

1. Read the claim domain field

   It must be present and must be a registrable domain, not a path or a URL.

2. Resolve the TXT record

   Query _revow at that domain. Use DNSSEC where the zone is signed, and say in the interface whether it was.

3. Match the key

   The claim subject must appear in at least one record with v=revow1. Matching is case insensitive on the hex.

4. Report the pair, not a verdict

   The wording is that this key is published on that domain. Not that the business is verified.

A consumer caches a successful resolution for no longer than the record TTL, and treats a resolution failure as absence rather than as a negative result. A DNS outage must never render as a warning about the subject, because a reader cannot tell the difference and a wrong accusation is a real cost to a real business.

A domain can be bought. An expired domain can be bought by somebody else, together with the ability to publish a record naming their own key, which is why claims expire and why the register and attestation layers exist. A domain also proves a business and never a qualification.

Onboarding is the real objection. The answer is that this is lazy and optional: the professional pastes a domain, the application shows the exact line to add, and absence of the record renders nothing at all. No error, no nag, no blocking step. A professional who does not care never meets the feature.