Page History
For phase 1 questions and responses, please see Input from ICANN Org
Question:
During recent meetings the EPDP Team has been examining public comments received on its Initial Report. Recommendations in the Initial Report are based on certain assumptions. For instance, the EPDP Team has been working under the assumption that ICANN Org (or its designee) would be the Accreditation Authority, and, accordingly, would be responsible for enforcing accredited SSAD users’ compliance with the Accreditation Policy, Acceptable Use Policy, etc. In addition, it is assumed that ICANN Org would perform the Central Gateway function.
Today’s discussion revealed that the Team’s assumptions may not be entirely correct. It was suggested that ICANN Org may have concerns regarding, for example, how this enforcement responsibility fits within its Mission and Bylaws as it is not yet clear how the contractual relationships would be structured between the Central Gateway Manager and accredited users, noting ICANN Org enforcement currently only occurs between ICANN Org and Contracted Parties where a direct contractual relationship exists.
It was also suggested that communication with ICANN Org would be useful to confirm all assumptions the Final report will be based on. In light of this, could ICANN Org please provide clarifications on the following questions:
If SSAD becomes an adopted consensus policy, would ICANN Org will perform the Accreditation Authority function?
If SSAD becomes an adopted consensus policy, would ICANN Org will perform the central Gateway function?
If SSAD becomes an adopted consensus policy, would ICANN Org enforces compliance of SSAD users and involved parties with its consensus policy?
Additionally, could ICANN Org please confirm the EPDP Team’s assumption that ICANN Org and Contracted Parties are joint controllers regarding disclosure of registration data through the SSAD?
Response:
If SSAD becomes an adopted consensus policy, would ICANN Org will perform the Accreditation Authority function?
If SSAD becomes an adopted consensus policy, would ICANN Org will perform the central Gateway function?
Yes, if the Board adopts the EPDP Phase 2 team’s recommendations as consensus policy, ICANN org would implement the functions the Board directs the org to assume. In the cost estimate document we recently shared with the EPDP, ICANN org indicated in its assumption that it would outsource these functions to a third party.
If SSAD becomes an adopted consensus policy, would ICANN Org enforce compliance of SSAD users and involved parties with its consensus policy?
ICANN is prepared to enforce all consensus policies that are adopted by the ICANN Board. It is important to note that the SSAD recommendations contain requirements for gTLD registries and registrars, which would be enforced through the standard Contractual Compliance process. The SSAD recommendations also include other policies and requirements for other parties, including SSAD requestors. For each of these policies and requirements, the enforcement mechanisms would vary depending on the party.
Additionally, could ICANN Org please confirm the EPDP Team’s assumption that ICANN Org and Contracted Parties are joint controllers regarding disclosure of registration data through the SSAD?
ICANN org acknowledges that this is the EPDP Team’s assumption at this stage. We also note Bird & Bird’s Phase 2 “Liability” memo to the EPDP Team (9 September 2019), which stated that “the most likely outcome – and certainly most supervisory authorities’ starting position – is that CPs are controllers – and, given ICANN's role in determining purposes and means of processing, that they will be joint controllers with ICANN org in respect of their disclosure of Registration Data to Requesters via a SSAD.” Once the recommendations are finalized by the EPDP Team, approved by the GNSO Council, and adopted by the Board, this issue will be addressed during the implementation process.
To implement the EPDP Team’s recommendations, ICANN org will determine, in consultation with the Implementation Review Team, what data protection arrangements will be required. This will include evaluating what processing of personal data is contemplated by the recommendations, and applying a step-by-step evaluation process to analyze each processing operation contemplated under the EPDP Team’s recommendations. At that stage, we will assess who controls what processing, and with whom, and enter into the necessary arrangements to account for this. This is not a matter of preference or contractual designation by the parties, but must be determined by applying the law to the facts presented for each distinct processing operation. (Ultimately, a data protection authority or a court would have the final say in how controllership provisions apply.) Given that this determination is so fact-specific and the SSAD model is not yet final, it is currently not possible to confirm the EPDP’s assumption of joint controllership in this context.
------------
Additional context from ICANN org: It’s important to emphasize that ICANN org considers the development of an SSAD to be within ICANN’s remit, as is the enforcement of GNSO consensus policies adopted by the ICANN Board, including policies related to gTLD registration data. ICANN’s Bylaws [icann.org] recognize that ICANN coordinates the development and implementation of policies concerning the registration of second-level domain names in gTLDs. (See ICANN Bylaws, Section 1.1.) This includes policies, as outlined in Annex G-1 and Annex G-2 to the Bylaws, concerning issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the internet, registrar services, registry services, or the domain name system. (See ICANN Bylaws, Annex G-1) An example of this would be a policy addressing maintenance of and access to accurate and up-to-date information concerning registered names and name servers. ICANN org believes that implementation and enforcement of a policy for an SSAD would fall within this scope.
The Board has previously recognized the critical nature of this work. The Board anticipated this effort in the Temporary Specification, under Annex: Important Issues for Further Community Action[icann.org], where it notes at 1: “continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board.” Further, the EPDP’s own charter[gnso.icann.org], which was approved by the GNSO Council, clearly indicates that the development of policy recommendations for a System for Standardized Access to Non-Public Registration Data is within the remit of the EPDP.
When considering GNSO consensus policies for adoption, the ICANN Board will consider whether the recommendations themselves fall within the scope of ICANN’s Mission and Bylaws. As noted above, the concept of an SSAD seems to fit within this scope. Any EPDP recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a vote of more than two-thirds of the Board, the Board determines that such policy is not in the best interests of the ICANN community or ICANN. (See ICANN Bylaws, Annex A-1, Section 6). If the recommendation was approved by less than a GNSO Supermajority Vote, the majority vote of the Board would be sufficient to determine that such policy is not in the best interests of the ICANN community or ICANN. Any non-approval by the Board would trigger a consultation between the GNSO Council and the Board, which occurred with respect to a subset of the EPDP Phase 1 Team’s recommendations. The ICANN org and Board liaisons have endeavored during this EPDP to provide the team members with implementation-related and other guidance as the team has deliberated recommendations.
Question:
A lot of the work that our group is doing cannot only be characterized as the community’s policy work, but it is in fact ICANN’s (org) compliance.
Looking at the cost of becoming compliant, the easiest way to save money is to use synergies. We have asked in the past whether ICANN has written a record of processing activities, carried out DPIAs, asked for legal advice on related aspects etc. To my knowledge, we have not been provided with any such documentation.
To be clear, it would be extremely helpful for our group to be able to review existing documents. Even though if our group might hold different views on certain questions, any existing work products would expedite our work. Maybe there are documents in the making, in which case we could build our workplan around potential delivery dates to be able to benefit from such work products. If there is actually no documentation already, it would be good to get clarity around that, too, and we could try to work so that duplicate efforts of the org and our group can be avoided, i.e. so that the org can benefit best from the legal advice we are seeking.
Either way, when looking at where the money shall come from, I think it would be fair not to consider expenditures as the community’s policy making only, but as part of ICANN’s overall compliance activities.
Response:
We agree that both ICANN org and contracted parties must be compliant with GDPR, which is the focus of the EPDP. Your point about synergies is also a good one, which is why we are following the EPDP Team’s suggestion from Phase 1 to use Bird & Bird both to advise ICANN org and to answer questions from the EPDP Team.
With regard to your comment about record of processing activities, the EPDP Team previously asked for ICANN Compliance’s record of processing. In a 20 November 2018 response, ICANN org provided an ICANN Compliance summary of processing activities. That response can be viewed here: <<https://mm.icann.org/pipermail/gnso-epdp-team/2018-November/000944.html>>
Implementation of EPDP Phase 1 recommendations will require additional documentation of registration data processing activities, including activities by ICANN org, registry operators, registrars, and other third-parties. That work is underway and will be shared with the community and EPDP Team when ready.
With regard to Data Protection Impact Assessment, as previously mentioned in a response to the EPDP Team on 17 November 2018, ICANN org has not previously done a DPIA. The response stated: “In general, a DPIA is designed to (a) describe the processing and purpose of processing of personal data, including where applicable the legitimate interest pursued by the controller, (b) assess the processing necessity and proportionality, and (c) help manage the risks to the rights and freedoms of data subjects resulting from the processing. The elements of a DPIA are more fully described in Article 35(7) of the GDPR. Under Article 35(1), a DPIA is only required where a type of processing is “likely to result in a high risk to the rights and freedoms of natural persons”.
“ICANN org considered conducting a DPIA since early in the discussion of GDPR and gTLD registration data. One of the issues is when to do a DPIA that is most timely and useful--should the DPIA be conducted on the original requirements in the registry and registrar agreements, on the Temporary Specification which is temporary, or on the new requirements being discussed in the EPDP? We continue to evaluate whether that assessment should be performed and, if so, when.” A link to this response can be viewed here: <<https://mm.icann.org/pipermail/gnso-epdp-team/2018-November/000909.html>>
Question:
Is there an attorney-client relationship between ICANN Org and Bird & Bird?
Response:
In light of your recent question, “Is there an attorney-client relationship between ICANN Org and Bird & Bird,” and related communications on the EPDP Team list, we wanted to provide this background.
ICANN org retained the law firm of Bird & Bird as an additional expert to help advise on GDPR matters, including advising the EPDP Team. There is an attorney-client relationship between ICANN org and Bird & Bird. In connection with this engagement, Bird & Bird is providing analysis on issues related to the EPDP’s work that is being shared with the EPDP Team. In announcing this engagement to the EPDP Team, ICANN org noted that ICANN has used the services of Bird & Bird in the past in a similar engagement, in providing public advice to the community Thick WHOIS Implementation Review Team. Given the positive experience with working with Bird & Bird on that public advice, Bird & Bird’s understanding of ICANN and its ecosystem, as well as its deep expertise in international privacy and data protection matters, ICANN org determined that the Bird & Bird team could help provide additional expertise to advance the efforts of ICANN org and the GNSO Expedited PDP Team.
Members of the EPDP Team’s legal committee proposed using the same independent outside counsel for both the EPDP Team and ICANN Org. To that end, in the “Considerations for Procurement of Legal Services” document compiled by Kurt Pritz, the Phase 1 Chair, which incorporated the Statement of Work written by Stephanie Perrin and Diane Plaut, as well as a note on Conflict (by Margie Milam), and on possible efficiencies by Thomas Rickert, it was noted that the same outside counsel could be used for both the EPDP Team and ICANN org. The notes to ICANN included in the “Considerations” document stated that it was the EPDP Team’s belief that both ICANN org and the EPDP Team would require answers to the same or similar questions and that, therefore, reaching out to one firm might avoid duplicate costs and also potentially conflicting advice.
Question:
Does ICANN org plan to share the TSG’s report with the EPBD/DPAs? If so, please provide more information on the timeline.
Response:
Dear EPDP Team,
Thank you for your question. As you may know, the Technical Study Group has been exploring technical solutions for authenticating, authorizing, and providing access to non-public registration data for third parties with legitimate interests. More information regarding ICANN org’s next steps following the draft technical model shared during ICANN 64 can be found on Göran’s blog post published on 5 April 2019.
Question:
Can ICANN org please provide a list of the current notices registrars are required to provide to registrants?
Response:
Please refer to this Notice Requirements Table for a list of current notices registrars are required to provide to registrants.
