Whois Disclosure System

The Registration Data Request Service (RDRS), formerly called the Whois Disclosure System, is an outcome of the ODA that followed Phase 2 of the EPDP Temp Spec, which recommended the creation of a system of access and disclosure of anonymized or proxied registration data. After ICANN Org revealed that SSAD would be costly and time intensive, the ICANN Board requested the development of an idea for a simple ticketing system (STS) designed to centralize requests for registrant information disclosures. If greenlit, the WDS will provide data to help ICANN determine how to proceed with a ticketing system.

History

Following its review of the ODA and a meeting and several rounds of correspondence with the board, the GNSO Council formed a small team to develop the concept of the simple ticketing system (STS) and ICANN Staff began researching the STS's development cost and timeframe. The STS will document requests' nature, receiving registrars, response speed (if at all), and appropriateness of disclosure. The STS will also yield estimates of how many users and requests to expect of the eventual SSAD.
At the April 2022 GNSO Council meeting, Sebastien Ducos explained that the idea was for the Board to pause any decision on the SSAD and instead enter what was a pilot phase but became a proof of concept phase (as of April 4, 2022) to arrive at a simplified SSAD version to run for up to two years in six-month increments to review/test hypotheses about who, what, when, why in terms of traffic at each interval and estimate what would be required and how to deliver it.
On April 27, 2022, the GNSO Council requested that while its STS small team worked on the proof of concept called the "SSAD Light," the ICANN Board pause consideration of the SSAD recommendations.
At ICANN 74, the SSAD Light Concept was presented by ICANN Org to reflect the small team's recommendations for a more affordable, simpler ticketing system, which would not include:

• all the EPDP Phase 2 policy recommendations,
• central or governmental accreditation authorities,
• identity verification of requestors,
• an abuse investigator,
• an obligation or expectation of automated processing of certain requests by contracted parties, or
• billing since ICANN will not pass operational costs to requestors.
  

Instead, the SSAD Light proof of concept will:

• be based on the design described in the SSAD ODA,
• incorporate changes in the design to allow for a more effective model,
• minimize development and operational costs of the system,
• collect request statuses (e.g., approved, denied) from contracted parties, and
• gather data on response times from contracted parties for requests of different priorities.
  

At ICANN 74, the GNSO held a session on EPDP Phase 2 concerning the latest developments on the creation of what used to be called SSAD. During this session, Ashwin Rangan explained how the Whois disclosure system will work. It will:

• use ICANN systems that already exist
• leverage existing and proven ICANN design patterns already available for use by the ICANN Community (such as the naming services portal, operating on salesforce), existing technology stacks (ICANN Account operating on okta identity platform), and
• rely on in-house expertise and users.

It was decided that the Whois disclosure system would be a traffic cop in the middle. The latest version of this proof of concept or minimal viable product proposal would involve the removal of authentication. What's left are accreditation and access.

Opinions

Milton Mueller expressed concerns over a temporary solution becoming a permanent default, from which any further improvements are made, and the absence of a billing function. There may be a very different level of demand if ICANN has to impose some costs on the people making the request. The org could bundle request subscriptions and say give us some fee, like $100, and you get 100 requests or 500 requests for the next two months or something. Steve DelBianco expressed concerns over reporting and lack of use because it may not be any faster or surer that contracted parties will respond to requests. Ash responded that ICANN can't trip GDPR wires by keeping the wrong type of data or for too long, backed by Goran Marby, who reminded the session that the board has not made any decisions and that the org needs six weeks to finish figuring out the technical specifications for a fuller conversation.

Design Reveal

At ICANN 75, ICANN Organization presented the design for the WDS so the ICANN community could decide whether to proceed with a pilot period.

Approval and Implementation

On February 27, 2023, the ICANN Board directed the ICANN Organization to develop and launch a new ticketing system to handle requests for access to nonpublic registration data related to gTLDs. The development and implementation will take 11 months and will rely on the EPDP Phase 2 Small Team advice along with ICANN-accredited registrars. At ICANN 76, the name of the system was changed to Registration Data Request Service (RDRS) and the launch of this new service was set for the end of 2023.

Objectives

• Simplify the process for submitting and receiving requests for nonpublic gTLD registration data for both requestors and contracted parties.
  • Feature for requestors to easily create and manage requests.
  • Feature for registrars to effectively manage and process inbound requests.
• Make it cost-effective
  • Simpler features allow the system to be built quickly.
  • Less costly to build and maintain the system.
  • Utilization of existing ICANN systems.

Features

features	notes
Modeling off of CZDS	Using what’s available within ICANN.
System connects requestors and registrars.	Registries are not system users.
System handles data requests for gTLD registration data.	ccTLDs and non-contracted registries are out of scope
Email verification	No identity verification.
Any communication between requestors and registrars takes place outside of the system.	Examples include clarifying questions, additional documentation requests, data disclosure, etc.
No integration with registrars’ systems.
ICANN-funded	No billing functions.
Privacy by design	Data will be kept secure and accessible on a need-to-know basis only
Data minimization	No data will be retained for longer than necessary
Logging
System logs Request information	System logs Registrar’s decisions
Request Type	Change in priority level
Priority level (1-3)	Request approved/partially approved/denied
Field elements requested	Disclosed data elements (i.e. name, email, phone, etc)
Jurisdiction where the nonpublic registration data will be processed	The reason(s) for the denial
Registrar name associated with the domain subject	Date and time stamps for all system activity
Legal basis for the request	Request creation, status changes, response, etc.
Existence of any supporting document for the request (subpoena, court order, or other legal processes)	Registrar participation

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).

General Data Protection Regulation