Whois Disclosure System

From ICANNWiki
Revision as of 15:53, 12 October 2022 by Jessica (talk | contribs) (Created page with "The Whois Disclosure System is an outcome of the ODA that followed Phase 2 of the Expedited Policy Development Process on the Temporary Specification for gTLD Registrati...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.[1] 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.[2]
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.[3]
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.[4]
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.[5]

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.

The Whois disclosure system needs to be written but will be a traffic cop in the middle. The latest version of this proof of concept or minimal viable product proposal involves the removal of authentication. What's left are accreditation and access.[6] 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.[7] 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.[8] At ICANN 75, ICANN Organization presented the design for the WDS so the ICANN community could decide whether to proceed with a pilot period.[9]

References