Dear Janis, Thank you for the questions you sent to ICANN org on 23 October <https://mm.icann.org/pipermail/gnso-epdp-team/2019-October/002702.html> regarding the responsibility that ICANN org would be willing to take on in connection with any System for Standardized Access/Disclosure (SSAD) recommended by the EPDP Team. We appreciate the opportunity to forward this response from Göran Marby. Please let us know if you have further questions or would like to discuss this response in greater detail. Thank you, Eleeza and Dan ICANN org liaisons ________________________________ Dear Janis, I write in response to the questions you sent to ICANN org on 23 October <https://mm.icann.org/pipermail/gnso-epdp-team/2019-October/002702.html> regarding the responsibility that ICANN org would be willing to take on in connection with any System for Standardized Access/Disclosure (SSAD) recommended by the EPDP Team. These questions were forwarded by the ICANN org EPDP Phase 2 Team liaisons and I am pleased to provide this response. As you are aware, since receiving your questions, ICANN org published<https://www.icann.org/news/blog/icann-org-seeks-european-data-protection-boa...> the paper, “Exploring a Unified Access Model for gTLD Registration Data<https://www.icann.org/en/system/files/files/unified-access-model-gtld-registration-data-25oct19-en.pdf>,” which it has forwarded to the European Data Protection Board (EDPB) for feedback. We will share any feedback as an input to the EPDP Phase 2 team’s consideration of a SSAD. I believe that the paper provides insights into ICANN org’s views on many of the questions posed by the EPDP Team to ICANN org. We have also prepared the answers below to further inform your discussions. The ICANN org paper outlined a hypothetical model for purposes of soliciting feedback from the EDPB about how the European Union’s General Data Protection Regulation (GDPR) would apply to such an access model. The model proposed in the paper has two goals, as further explained below: to centralize the decision-making power over an access request, with the goal of minimizing the exposure of the contracted parties, and ensuring consistent data security standards, and promoting consistent, predictable user experience to the extent possible. In order to seek actionable guidance from EU data protection authorities, it was necessary to make certain assumptions about how a centralized UAM might operate. This is inevitably sensitive. ICANN org is well aware that policy-making authority and responsibility lies with the bottom-up multi-stakeholder consensus policy development process and the paper notes that assumptions made therein are for discussion purposes only. We understand and note that the EPDP Team will make its own policy recommendations, and that those may differ from the model outlined. I also want to acknowledge the concerns raised by various members of the EPDP Team that the paper was not shared with the team prior to ICANN org’s submission to the EDPB. Our consultations with the European Commission on the paper took longer than anticipated. In order to allow for a discussion at the EPDP’s face-to-face meeting in Montreal and maximize the opportunity for EDPB members to review the document in advance of its December plenary, we elected to submit the paper and release it to the EPDP on 25 October. We regret that the timing didn’t allow for further opportunities to interact with you in advance of submission. I welcome your input on how ICANN org can support your efforts in the future. I hope the answers to your specific questions below are useful. I am grateful for the hard work the EPDP Team has undertaken and ICANN org remains ready to answer any further questions you may have. Regards, Göran Marby ________________________________ Questions to ICANN org: Does ICANN have a clear preference on whether or not it will: 1. Field these requests for non-public data? Should the EPDP recommend such a model and it is permissible under the GDPR, ICANN org is open to performing the central gateway role described in the “Exploring a Unified Access Model” paper or taking responsibility for delegating this function to another party. In the model we proposed, the contracted parties would not know who the requestor is, or for what purpose the requestor is requesting data, when responding to the central gateway’s request for data. We hope that the EDPB will confirm our understanding that the contracted parties would be responsible as controllers for this transfer to the central gateway, but not responsible for the central gateway’s subsequent transfer to the requestor. ICANN org hopes that the EDPB will confirm that this separation of processing activities and related responsibilities would significantly reduce the legal exposure of the contracted parties for the decision to disclose registration data to a UAM user, particularly relative to the central gateway and also compared to a decentralized model. The contracted parties’ processing within a UAM could be compared to third parties (such as banks) transferring information about debtors to credit bureaus. In this example, the banks, as data controllers, are only responsible for this initial transfer. They are not responsible for any subsequent transfers of the data of debtors to requestors. The decision about such transfers to requestors is made by the credit bureau as (sole and independent) controller. We believe that a UAM would also enhance data security and could reduce what the contracted parties would need to do to meet their obligations to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk (see Art. 32 (1) a) GDPR). The steps and roles described here are also described in greater detail in Sections 3-5 of the paper. 2. Maintain its own RDS replica database? As described in the paper, ICANN org does not propose maintaining a replica of the RDS database. The transfer of data is described in Section 5 and in Section 7, which details where the data is collected and stored, including Condition 2, which notes: “Central Gateway does not store Registration Data. Requests for non-public registration data processed via the proposed UAM would reach Contracted Parties, who would pass the data through the centralized system to the requestor. No registration data would be stored in the centralized system.” ICANN org has not proposed the idea that it might maintain its own RDS replica database. We do not believe this is necessary to achieve our goal of reducing the exposure of contracted parties, and replicating the data in a central database would create additional processing risks. This is not in the Technical Study Group’s technical model<https://www.icann.org/en/system/files/files/technical-model-access-non-publi...> and was not proposed in discussions leading up to the adoption of the Temporary Specification. 3. Make a/the determination of the validity of the request? Answering this question requires considering what is meant by “validity.” The “Exploring a Unified Access Model” paper identifies multiple steps and roles that are played in the processing of a request for registration data, and in the determination of whether or not to disclose data to a requestor. This UAM is based on the TSG’s technical model<https://www.icann.org/en/system/files/files/technical-model-access-non-publi...> and would consolidate operational burdens and also, in ICANN org’s view, the responsibility for making these decisions. In the proposed UAM, an entity that wishes to request access to non-public registration data must first become accredited to use the UAM by verifying its identity using an approved identity provider. There could be one or more identity providers in the model. Once a requestor is accredited and the requestor’s identity is verified, the requestor may submit a query to the gateway operator. When the gateway operator receives a query from a verified requestor, it would route the request to the authorization provider. Section 4 of the paper describes the role of the authorization provider. This entity would be responsible for evaluating a given query and the identity of the requestor against the community-developed policy governing access to non-public registration data, and determining whether or not the request should be approved based on the application of that policy. Subject to Board approval, ICANN org is willing and able to play this role and/or identify a third-party entity to perform this function to the extent it reduces the exposure of contracted parties under the GDPR and is consistent with EPDP-developed policy. The “Exploring a Unified Access Model” paper seeks EDPB confirmation that this approach would effectively reduce the exposure of contracted parties under the GDPR. 4. Assume responsibility for this decision, in any scenario where ICANN doesn’t hold the data directly and must require a Contracted Party to respond to the Requestor (even if the Contracted Party disputes ICANN’s determination)? Answering this question requires consideration of what is meant by both “responsibility” and “this decision.” Responsibility could refer to who makes a decision, or alternatively, to who is liable under the law for the consequences of making that decision. It seems logical that the liability for making a decision should sit with the entity that makes that decision and the paper seeks EDPB confirmation that this is the case. The question also asks about “this decision.” There are multiple decisions to be made in an access model, including: * The identity provider’s decision regarding whether or not the requestor has adequately verified its identity; * The authorization provider’s decision as to whether the requestor has satisfied policy standards for access, which would take into account the balancing of the interests of the data subject with the interests of the requestor in receiving the requested data; * The gateway operator’s decision as to whether or not the criteria for the requestor’s access to data have been met (has identity been verified and has the request been authorized?); and * The contracted party’s decision about whether or not to release data to the gateway operator (as the contracted party would be contractually required to do) upon request from the gateway operator, in furtherance of the interest in maintaining the security, stability, and resiliency of the Domain Name System. * The role of the gateway operator is not to evaluate the merit of a request for non-public data. This role ensures that a request is authorized and authenticated. The gateway operator acts as a conduit between the requestor, the identity provider, the authorizer, and the contracted parties. The TSG report contemplates that a model could be created in which the contracted parties would not be aware of a requestor’s identity (even at a macro level, such as whether a request is submitted from a security researcher, intellectual property holder, law enforcement, etc.) or what data is requested, and would simply supply the the registration data set via RDAP to the central gateway whenever such data is requested by the gateway. In that scenario, ICANN org would not need to “hold the data” to respond to the requestor and it would seem that the contracted party should not be tasked with or liable for the decision to authorize a request, balancing the interests of the requestor and the data subject, because it is not involved in making that decision. In a UAM based on the TSG, the last part of your question would not apply (“even if the Contracted Party disputes ICANN’s determination.”) A contracted party would not have visibility into a request and, as a result, would have no basis to challenge the authorization of a request. The authorization provider, not the gateway operator, would determine whether or not to approve the request by applying policy criteria for access to data, which would take into account the balancing of the interests of the data subject with the interests of the requestor in receiving the requested data. The only decision the contracted party would make would be whether to comply with its contractual requirement to disclose the data to the gateway in response to an authenticated and authorized request. 5. Consider an approach whereby ICANN acts as a more or less “gateway” for authorized data to pass through, data provided by the Contracted Party at the request of ICANN (per contractual requirement), with the responsibility for such disclosure to be assumed by ICANN. In the paper, ICANN org proposed that it could operate a gateway for authorized data to pass through. As noted above, the gateway operator does not make the decision to authorize disclosure. In the proposed model, the authorization provider would decide whether or not the criteria for disclosure are met. If a request is authorized and authenticated, the gateway operator would request the data from the contracted party and disclose the relevant data set to the requestor. Please see the answers above and the paper for additional detail regarding responsibility for each of the actors in such a model. From: Marika Konings <marika.konings@icann.org> Date: Wednesday, October 23, 2019 at 6:05 AM To: Eleeza Agopian <eleeza.agopian@icann.org>, Daniel Halloran <daniel.halloran@icann.org> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: Questions for ICANN Org from EPDP Team Chair Dear ICANN org liaisons, On behalf of Janis Karklins, in his capacity as EPDP Team Chair, please find hereby a number of questions for ICANN org he would appreciate a response to as soon as possible: Does ICANN have a clear preference on whether or not it will: 1. Field these requests for non-public data 2. Maintain its own RDS replica database 3. Make a/the determination of the validity of the request 4. Assume responsibility for this decision, in any scenario where ICANN doesn’t hold the data directly and must require a Contracted Party to respond to the Requestor (even if the Contracted Party disputes ICANN’s determination) 5. Consider an approach whereby ICANN acts as a more or less “gateway” for authorized data to pass through, data provided by the Contracted Party at the request of ICANN (per contractual requirement), with the responsibility for such disclosure to be assumed by ICANN. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses_...> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gns...>.