]> IIT-CNR/Registro.it

Via Moruzzi,1 Pisa IT 56124 mario.loffredo@iit.cnr.it http://www.iit.cnr.it

IIT-CNR/Registro.it

Via Moruzzi,1 Pisa IT 56124 maurizio.martinelli@iit.cnr.it http://www.iit.cnr.it

VeriSign, Inc.

12061 Bluemont Way Reston VA 20190 US jgould@verisign.com http://www.verisigninc.com

Verified Contacts Extension This document describes an extension to the Registration Data Access Protocol (RDAP) that allows the inclusion of verification status information for contact fields such as email addresses and phone numbers. The goal is to improve data quality and trustworthiness of RDAP responses by indicating which pieces of contact data have been verified and how.

Introduction The Registration Data Access Protocol (RDAP) provides access to registration data for domain names, IP addresses, and autonomous system numbers. However, RDAP responses do not currently include explicit information about whether contact information such as email addresses or phone numbers has been verified. This document defines a simple extension that enables RDAP providers to include verification status for contact fields. This is useful in contexts where contact verification may be legally required or strongly recommended. In particular, Article 28 of Directive (EU) 2022/2555 () requires top-level domain (TLD) name registries and domain name registrars to collect and maintain accurate and complete domain name registration data. It also mandates them to verify, to the extent possible, the accuracy of such data. The extension defined in this document can support compliance with this obligation by enabling the inclusion of verification status for contact fields in RDAP responses.

Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

RDAP Conformance Servers implementing this extension MUST include the string "verifiedContacts" in the "rdapConformance" () array of all relevant RDAP responses. The registration of the "verifiedContacts" extension identifier is described in .

JSON Structure The verification information is conveyed via a new top-level object member named "verifiedContacts_data" within the entity objects.

Entity object including the "verifiedContacts_data" member { "objectClassName": "entity", "handle": "ABC123-EXAMPLE", "rdapConformance": ["rdap_level_0", "verifiedContacts"], ... "verifiedContacts_data": { "email": { "verificationDate": "2025-03-15T12:00:00Z", "method": "emailVerification" } ... } }

verifiedContacts_data Structure The "verifiedContacts_data" member is an object whose keys are contact details (e.g., "email", "voice", "fax", "addr"). Each value is an object containing:

"verificationDate":

(REQUIRED) A string with the date and time of verification.

"method":

(OPTIONAL) An string indicating the following verification methods:

"emailVerification":

Sending a confirmation link to the specified email address and requiring user interaction (e.g., clicking the link) to confirm ownership.

"smsToken":

Sending a one-time token (OTP) via SMS to the provided phone number and requiring the user to submit the token to confirm ownership.

"manualReview":

Manual review of contact data by a human operator (e.g., calling the phone number, making a live video call, inspecting submitted documentation).

"eidValidation":

Validation of contact data using a digital identity service, either before or after registration (e.g., eIDAS-compliant identity providers).

"addressVerification":

Verification of the postal address using a geolocation or address validation service (e.g., Google Maps API, OpenStreetMap, postal databases).

"crossValidation":

Cross-checking of contact details (e.g., name, VAT number, postal address) against trusted third-party repositories (e.g., EU VIES).

"thirdPartyAssertion":

Relying on a trusted third party (e.g., registrar, CSP, certification authority) to assert that contact data has been verified externally.

Instead of returning an object for each verified contact detail, a server MAY use the "all" key to signal that all data has been verified.

IANA Considerations IANA is requested to register the following value in the RDAP Extensions Registry:

Extension identifier:

verifiedContacts

Registry operator:

Any

Published specification:

This document.

Contact:

IETF <iesg@ietf.org>

Intended usage:

This extension identifies RDAP extension for verified contact information.

Security Considerations Contact verification data may have privacy implications. Servers MUST ensure that disclosure of this information complies with applicable data protection laws and policies.

References Normative References &RFC2119; &RFC9083; &RFC8174; European Parliament and Council

Change History

Change from 00 to 01

1. Made The "verifiedContacts_data" keys consistent with those defined in draft-ietf-regext-rdap-jscontact.
2. Further specified the verification methods and changed their format to CamelCase.