Summary

  • A current REGEXT Internet-Draft can describe which RDAP contact fields were checked, by whom, when, under which framework and with what method or evidence; most of those elements are optional, and none creates a universal right to disclose or rely on the result.
  • Operators need an audience-and-validity disclosure receipt that separates the verification event from currentness, requester authority and the particular fields released. That receipt is an editorial operating proposal, not an IETF requirement.

One fact, two audiences

Consider an email address that was confirmed through a link during registration. A public RDAP user may need to know nothing about the proofing exercise. An authenticated investigator handling abuse may have a legitimate reason to learn that the address passed a reachability check on a particular date. A competent authority may be entitled to a different subset under a different rule. The registrar, meanwhile, may need to retain the detailed record without disclosing it through RDAP at all.

There is no contradiction in those outcomes. Verification answers whether a stated process was performed against a stated claim. Disclosure answers whether a particular recipient may receive particular information for a particular purpose. Reliance asks what conclusion that recipient may draw. These are separate decisions, with separate owners and failure modes.

The distinction becomes operationally urgent when verification metadata is standardized. A machine-readable field travels easily. A small badge travels even faster. Once a dashboard or downstream service flattens “email checked by reachability on 10 March” into “verified registrant,” it has expanded the claim, erased its date and invented an audience-independent assurance. The danger is not that the original data is false. It is that accurate, bounded data is made to say too much.

What the draft proposes—and what it does not

Revision 04 of Registration Data Access Protocol (RDAP) Extension for Verified Contact Information is dated 24 August 2026. The IETF Datatracker lists it as an active Internet-Draft in the REGEXT context, at Candidate for WG Adoption, with the IESG state “I-D Exists.” It has no formal standing or IETF endorsement. Its header identifies Standards Track as the intended status, but intended status is not approval.

The draft proposes a verifiedContacts_data array in RDAP entity objects. An element can identify the claims checked—such as email, phone number, address or name—and can carry a verification date, verifier identity, verification identifier, trust framework, method, evidence category, remarks and extension data. Multiple verification objects can coexist. That is useful because a name and an email address may have been checked through different processes, by different parties, at different times.

Almost every descriptive element is optional. Optionality does not make the extension meaningless; it makes consumer discipline indispensable. A record with claims: ["email"] and method: "reachability" supports a narrower conclusion than a record about name and address under an external identity framework. A private trust framework points to server policy, not to a globally understood assurance level. A missing verifier or date leaves a different evidentiary shape from a complete record. Consumers must interpret what is present, not silently manufacture what is absent.

Revision 04 makes one boundary unusually clear: verificationDate marks when the verification process was completed, and its absence does not imply that verification is current. Even when a date is present, the draft does not turn it into an expiry date. Whether an email checked six months ago remains fit for an abuse-response workflow depends on an operator’s freshness policy, later corrections and the risk of the intended use.

The draft also distinguishes methods from evidence. A reachability check requires active acknowledgement—entering a code, clicking a link or an equivalent confirmation. Documentary and record-based methods answer other questions. The same evidence may be inspected by different methods, and one method may be applied to different evidence. That is why the combination matters. “Verified” on its own is not a portable assurance level.

Verification is not identity, authority or control

A reachable mailbox is not necessarily a legal identity. A legal identity is not necessarily the beneficial owner of a domain. A person associated with a registrant is not necessarily authorized to act for it today. A correctly formatted address is not necessarily occupied. A name checked against a document does not establish continuing control of the network resource to which an RDAP entity is linked.

These distinctions can feel pedantic until an automated consumer uses the wrong one. An anti-abuse team may prioritize a message because an email was recently reachable. A compliance process may require stronger identity evidence. A transaction may require corporate authority. A resource-transfer review may need proof of present control. Each workflow has a legitimate evidentiary threshold; none should borrow a broader conclusion from the word “verified.”

This is also why a private trust framework should not be dismissed as invalid or promoted as universal. It means interpretation depends on the server operator’s policy. The useful question is not whether “private” sounds weaker than a named external framework. It is whether the relying party can identify the policy, its version, the claims it covers, the checks it requires and the conditions under which the result remains usable.

The evidence label can itself be sensitive

It is tempting to think privacy is protected if RDAP never returns the underlying passport, bank statement or utility bill. The draft does not propose exposing those documents. Yet the metadata describing an evidence category can still reveal something important: that a passport was used, that a tax record was consulted, that a birth record or population register formed part of the process, or that a biometric or physical comparison occurred.

That information may help an authorized recipient understand assurance. It may also reveal the shape of a person’s identity-proofing trail to someone who does not need it. The draft’s Security Considerations therefore matter more than their short length suggests: contact-verification data may have privacy implications, and servers must ensure that disclosure complies with applicable law and policy.

The introduction is equally important. It says verification status may appear in a publicly accessible RDAP service or in a closed service requiring prior authorization for legitimate access seekers or authorities. That is not a declaration that every deployment must pick one audience forever. It is a reminder that the extension can cross different access models. The governance work lies in preserving the access decision when software makes the response.

NIS2 Article 28 is part of the draft’s context for accurate and complete domain-name registration data. It should not be inflated into a general command to publish proofing metadata to the world. Collection, maintenance, verification, access and public disclosure are different verbs. A sound implementation documents the legal or policy basis for each one rather than letting the word “accuracy” erase the boundaries among them.

The universal-badge failure

The most likely implementation error is not a malformed JSON object. It is a successful transformation that removes meaning. A portal sees one verification object and paints a green check. An export retains the check but drops the claim list. A risk engine retains the check but drops the method. A case-management tool retains the check but drops the date. A public cache retains the evidence label after the original authorization has changed.

Every step may be technically valid. Together they produce a claim the source never made.

A universal badge has at least five hidden ambiguities:

  1. Object ambiguity: which RDAP entity and which contact value was checked?
  2. Claim ambiguity: was it reachability, identity, address accuracy or something else?
  3. time ambiguity: when did the process finish, and what freshness policy applies now?
  4. policy ambiguity: which trust framework and version gave the result meaning?
  5. audience ambiguity: who was authorized to see the metadata and for what purpose?

The cure is not a more colourful badge. It is a record that keeps those questions answerable.

An audience-and-validity disclosure receipt

Operators should create a receipt for the decision that turns retained verification data into an RDAP response. This is an operational proposal from this article, not part of the Internet-Draft.

The receipt should bind the RDAP object and exact claim set to the verification identifier, verifier and completion time when those fields exist. It should record the method and evidence class actually asserted, plus the trust framework and the precise policy version used to interpret it. A bare framework label is not enough when its requirements can change.

It should then record the recipient side of the decision: requester class, authenticated identity where applicable, declared purpose, public or gated channel, and the exact fields disclosed or withheld. The authorizing rule—law, contract, published access policy or case-specific decision—belongs beside the result. So do the accountable owner and a review path.

Finally, the receipt needs a validity horizon. That does not mean inventing an expiry value inside the RDAP extension. It means recording the operator’s own re-verification interval, event-driven triggers, treatment of a missing verificationDate, and any later correction, revocation or supersession. If a mailbox changes hands, a registration is amended or a verifier’s policy is withdrawn, an old disclosure must not continue to look current merely because its JSON remains parseable.

The receipt should not copy identity documents, biometric material or secret verification data. Its job is to preserve the reasoned boundary around disclosure, not to create a second sensitive archive.

A minimum deployment that remains reversible

Heng Lu’s preference for a minimum initial specification is valuable here. Interoperability benefits from shared names for claims, methods, evidence and frameworks. It does not require every registry, registrar and RDAP consumer to converge immediately on one global disclosure policy.

A cautious deployment can begin with a narrow claim class, a documented private framework, a defined freshness horizon and an authenticated audience. It can publish redaction explanations without publishing the evidence category itself. It can measure mistaken reliance, appeal volume and stale records before expanding access. The shared syntax makes later coordination possible; the local receipt keeps early decisions reversible and attributable.

That approach avoids two symmetric mistakes. The first is refusing useful verification metadata because policy is not globally uniform. The second is treating a common syntax as proof that policy already is uniform. The better middle is localized decision-making with comparable records.

Sources