ICANN’s Expedited Policy Development Process (EPDP) recently reached a milestone in its work to address the problem of how to access domain name registration data (formerly known as WHOIS) in a way that complies with privacy laws, including Europe’s General Data Protection Regulation (GDPR). The EPDP Phase 2 Final Report contains 22 “policy recommendations,” which, if adopted by the GNSO Council and then the ICANN board of directors, will become the new policy governing a System for Standardized Access/Disclosure (SSAD) of domain registration data.
Brand owners will likely be both disappointed with the overall outcome, yet encouraged by the EPDP’s improvements over the status quo. We provide a brief synopsis of the Final Report’s 171 pages and 22 policy recommendations in this blog.
Policy summary
If approved, the SSAD will consist of a centralized gateway where all requests for redacted domain registration data may be submitted. This represents an improvement over the status quo in that requestors will no longer need to identify and contact each individual registrar or registry (“contracted party”) to request data for the domain name in question.
Unfortunately, for nearly every request type (including IP-related requests), the gateway will not provide the requested data. Rather, the gateway will merely route requests to the appropriate contracted party for review. As we’ve noted, requests for WHOIS data have historically not fared well – achieving only a 14% success rate, even when providing all information suggested by the Registrar Stakeholder Group. Without further assurances about access to this data, any process that places requests at each contracted party’s discretion will be concerning to many brand owners.
That said, the SSAD policy may improve outcomes for IP owners’ requests in five key ways.
Positive developments
- Greater confidence with accreditation
While accreditation will not guarantee approval of any request, it may prove helpful. The SSAD policy requires all requestors to be accredited. Since anyone using the system must be able to become accredited, accreditation could be as simple as confirming an email address for one-off requestors. The accreditation contemplated by the Phase 2 policy will also allow credentials like a trademark registration to be independently verified, connected to the requestor and then associated with any requests made by that requestor. Signed assertions can also be connected to an accreditation, including things like, “I affirm that I will process this data in compliance with the law.” This upfront validation and request standardization should provide registrars and registries with greater confidence in requestors’ legal rights, allowing them to approve more requests.
- Shorter SLAs
The EPDP Phase 1 policy mandates a 30-day response time service level agreement (SLA) for registrars and registries to respond to requests for redacted data, with a shorter timeframe for urgent requests. The Phase 2 policy has a much shorter response target of five business days, although it uses a more nebulous SLA concept based on mean response time for all requests processed by an individual registrar or registry in a certain period. The Phase 2 policy also includes a shorter timeframe for urgent requests.While this is an improvement over the status quo, it’s worth noting that this SLA will likely still be too long for cybersecurity purposes which require action in minutes or hours, as opposed to days.
- No blanket denials for IP
Attempting to address the widespread problem of registrars refusing to assist with any IP-related matters, the policy prevents registrars from denying a request merely because it relates to IP infringement.
- Opt-in automation
The Phase 2 policy requires that contracted parties have the option to automate positive responses to certain request types and certain requestors, while prohibiting automated denials. Coupled with the robust accreditation framework, this should enable willing contracted parties to provide instant access to entities with sufficient rights, credentials and signed assertions.
- Logging, auditing and reporting for transparency
The SSAD must track request approval rates, and will provide public visibility into which contracted parties routinely deny requests.
Shortcomings
Despite these positive developments, the Phase 2 policy has two primary shortcomings which may prove problematic for brand owners.
- Contracted party discretion
For requests that contracted parties have not elected to automate, the new policy requires them to decide whether to provide data each time it’s requested. The policy permits contracted parties to withhold data if the contracted party subjectively feels the requestor’s interests are “overridden by the interests or fundamental rights and freedoms of the data subject.”1 It is unlikely that 2,000+ contracted parties will apply this test consistently, a concern ICANN recently expressed to the EU Data Protection Board:The uncertainty about how to balance legitimate interests in access to data with the interests of the data subject leaves much to the subjective judgment and discretion of the registrar, as the controller receiving an access request, on whether to grant or refuse access to the non-public gTLD registration data. Due to a lack of legal certainty, registrars, as controllers, are likely to evaluate privacy and data protection in absolute terms, without considering other rights and legitimate interests, to avoid possible regulatory sanctions or a judgment against them.2
As noted above, brand owners’ experience thus far indicates that requests are far more likely to be refused than approved. Accordingly, brand owners hoping for a more centralized, consistent and reliable data access model like the Unified Access Model are likely to be disappointed.
- Enforcement
Unlike all other ICANN consensus policies which require contracted party action, the Phase 2 policy merely requires contracted parties to perform the balancing test mentioned above. Troublingly, ICANN has said explicitly that it will not require a contracted party to disclose data in any case where the contracted party has decided not to disclose. This policy enforcement approach differs from the UDRP, for example, under which ICANN will require a contracted party to transfer an infringing domain name regardless of whether the contracted party wants to comply.
Next steps
Although the Final Report has been published, the SSAD policy is far from finalized. Next, the Final Report must be approved by ICANN’s GNSO Council during its September meeting. Rather than reviewing the report substantively, the GNSO Council’s standard of review for PDP outcomes is merely to ensure that all procedural steps were followed. While the EPDP has not yet addressed several items in its charter (e.g. whether contracted parties must distinguish between legal person and natural person registrants vs. merely redacting all data), these “priority 2” items will likely be deferred to future policy development work, allowing the Council to send the SSAD to ICANN’s board of directors for approval.
The ICANN board will then substantively review the SSAD policy recommendations, presumptively approving them unless the board finds that they are not “in the best interests of the ICANN community or ICANN (the Corporation).”3
A potential hiccup for the Phase 2 policy is that for the reasons mentioned above, among others, several of the policy recommendations do not have consensus from the ICANN community, a baseline requirement for the creation of consensus policy. Groups representing most intended SSAD users are notably missing from consensus on several policy recommendations, including the IP Constituency, Business Constituency, Government Advisory Committee, Security and Stability Advisory Committee and the At-Large Advisory Committee representing internet users at large. This puts the ICANN board in the unenviable position of determining whether the policy is in the best interests of the ICANN community, even as many community members vocally oppose it.
Even if the ICANN board approves the policy, or some subset of its policy recommendations, it will still likely take a couple years before an SSAD is functional. First, ICANN will need to translate the policy recommendations into a binding consensus policy, and then the SSAD itself (with 2,000+ contracted party connections) must be built.
The EPDP will continue to be an evolving policy area for at least the coming months, if not years. Please contact us with any questions, including about how you can get involved.
1See GDPR Article 6, Section 1(f)
2See May 22, 2020 letter from ICANN CEO to European Data Protection Board, https://www.icann.org/en/system/files/correspondence/marby-to-jelinek-22may20-en.pdf
3See https://www.icann.org/resources/pages/governance/bylaws-en/#annexA
