Questions regarding disclosure risks
Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote:
Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity?
I ask because depending on what you mean, there may be other scenarios.
All best,
--Greg
*From:*Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Sarah Wyld *Sent:* Wednesday, September 18, 2019 3:18 PM *To:* gnso-epdp-team@icann.org *Subject:* [Gnso-epdp-team] Questions regarding disclosure risks
Hello all,
During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data.
In order to fulfill this request, one of two things must be true. Either:
1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor
These potential scenarios raise the following questions:
1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance?
Thank you,
-- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team <mailto:gnso-epdp-team-bounces@icann.org> <gnso-epdp-team-bounces@icann.org> On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Greg Aaron <greg@illumintel.com> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Thanks much, James. My observation is about the models we discussed in L.A. (What kinds of hamburgers are on the menu?) We should be precise about what we mean by "distributed". I see three models: * Model #1: Queries come from requestors into a central point (run somehow by ICANN), that central point distributes the queries to the relevant registrars/registries, then the central point routes the replies back to the requestors. The central point also passes out authentication credentials to the parties making queries. This is the technical model the TSG wrote about. This has a DISTRIBUTED data model - the data resides at the registries/registrars. It has CENTRALIZED query input/output and access/authentication functions. * Model #2: A central point passes out authentication credentials, and requestors and registries/registrars then use those to trade queries with each other directly. This is a DISTRIBUTED model in two ways: the data is distributed because it resides at the registries/registrars, and query-making and response takes place among distributed parties. It is CENTRALIZED in one way: access/authentication functions. * Model #3: ICANN holds a registry containing all RDS data, obtained from the registries/registrars, and all queries go to and immediately served back from there. The central point also controls access (authentication creds). This is all CENTRALIZED. I will call this the Lord of the Rings Model: "One registry to rule them all / One registry to find them / One registry to bring them all / And at ICANN bind them." In Model #1, ICANN can be the party making the disclosure decisions. In that case, the registry/registrar would be acting pretty much as a data processor - if ICANN sends it a query, the registry/registrar simply supplies the data. Or, the registrar/registry can be the decision-maker in model #1. Model #2 only allows the registry/registrar to be the decision-maker. Model #3 exists only for ICANN to be the decision-maker. So, ICANN can be "the decider" without a centralized registry. The most crucial question is whether ICANN can or will act as the decider. If ICANN's the decider, then we have a choice between Model #1 or Model #3. If ICANN will not be the decider, then we have a choice of Model #1 or Model #2. Sarah posited ICANN as the decider, and then said the registry/registrar would be making 6(1)f decisions. I didn't understand that, because there can only be one decider. So, we need to know who the decider will be. And the WG should enumerate the plusses and minuses of each of the models. All best, --Greg From: James M. Bladel <jbladel@godaddy.com> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs' Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I'll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. "Addressed" = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, "provided" can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I'm misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the "centralized" version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some "requestor" stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks- J. _______________ James Bladel GoDaddy _____ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org <mailto:gnso-epdp-team-bounces@icann.org> > on behalf of Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com> > Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say "addressed" what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com <mailto:swyld@tucows.com> > Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com> >; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by "responding party"? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team <mailto:gnso-epdp-team-bounces@icann.org> <gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN "relay" disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Greg, This is a pretty good overview of the models but I think there is a fourth option in there that needs to be aired. In Model #1, ICANN is the central point for distributing queries. You imply further down in your discussion that ICANN is ALSO the decision maker regarding disclosure. However, it does not have to be that way. ICANN could be a central point for distributing queries, but the ultimate decision could still rest with the registrar. This, in fact, is the model we see as most viable in terms of gaining consensus among stakeholders and operating efficiently and legally. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Greg Aaron Sent: Friday, September 20, 2019 1:34 PM To: 'James M. Bladel' <jbladel@godaddy.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Thanks much, James. My observation is about the models we discussed in L.A. (What kinds of hamburgers are on the menu?) We should be precise about what we mean by "distributed". I see three models: * Model #1: Queries come from requestors into a central point (run somehow by ICANN), that central point distributes the queries to the relevant registrars/registries, then the central point routes the replies back to the requestors. The central point also passes out authentication credentials to the parties making queries. This is the technical model the TSG wrote about. This has a DISTRIBUTED data model - the data resides at the registries/registrars. It has CENTRALIZED query input/output and access/authentication functions. * Model #2: A central point passes out authentication credentials, and requestors and registries/registrars then use those to trade queries with each other directly. This is a DISTRIBUTED model in two ways: the data is distributed because it resides at the registries/registrars, and query-making and response takes place among distributed parties. It is CENTRALIZED in one way: access/authentication functions. * Model #3: ICANN holds a registry containing all RDS data, obtained from the registries/registrars, and all queries go to and immediately served back from there. The central point also controls access (authentication creds). This is all CENTRALIZED. I will call this the Lord of the Rings Model: "One registry to rule them all / One registry to find them / One registry to bring them all / And at ICANN bind them." In Model #1, ICANN can be the party making the disclosure decisions. In that case, the registry/registrar would be acting pretty much as a data processor - if ICANN sends it a query, the registry/registrar simply supplies the data. Or, the registrar/registry can be the decision-maker in model #1. Model #2 only allows the registry/registrar to be the decision-maker. Model #3 exists only for ICANN to be the decision-maker. So, ICANN can be "the decider" without a centralized registry. The most crucial question is whether ICANN can or will act as the decider. If ICANN's the decider, then we have a choice between Model #1 or Model #3. If ICANN will not be the decider, then we have a choice of Model #1 or Model #2. Sarah posited ICANN as the decider, and then said the registry/registrar would be making 6(1)f decisions. I didn't understand that, because there can only be one decider. So, we need to know who the decider will be. And the WG should enumerate the plusses and minuses of each of the models. All best, --Greg From: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs' Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I'll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. "Addressed" = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, "provided" can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I'm misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the "centralized" version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some "requestor" stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks- J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say "addressed" what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by "responding party"? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN "relay" disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
I see in a later email Greg made it clear that his Model 1 encompasses either ICANN or the registrar being "the decider." Because of the importance of that distinction, I think we should give the two a different name, perhaps 1a (ICANN decides) and 1b (registrar decides) From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Mueller, Milton L Sent: Monday, September 23, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com>; 'James M. Bladel' <jbladel@godaddy.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg, This is a pretty good overview of the models but I think there is a fourth option in there that needs to be aired. In Model #1, ICANN is the central point for distributing queries. You imply further down in your discussion that ICANN is ALSO the decision maker regarding disclosure. However, it does not have to be that way. ICANN could be a central point for distributing queries, but the ultimate decision could still rest with the registrar. This, in fact, is the model we see as most viable in terms of gaining consensus among stakeholders and operating efficiently and legally. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Greg Aaron Sent: Friday, September 20, 2019 1:34 PM To: 'James M. Bladel' <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Thanks much, James. My observation is about the models we discussed in L.A. (What kinds of hamburgers are on the menu?) We should be precise about what we mean by "distributed". I see three models: * Model #1: Queries come from requestors into a central point (run somehow by ICANN), that central point distributes the queries to the relevant registrars/registries, then the central point routes the replies back to the requestors. The central point also passes out authentication credentials to the parties making queries. This is the technical model the TSG wrote about. This has a DISTRIBUTED data model - the data resides at the registries/registrars. It has CENTRALIZED query input/output and access/authentication functions. * Model #2: A central point passes out authentication credentials, and requestors and registries/registrars then use those to trade queries with each other directly. This is a DISTRIBUTED model in two ways: the data is distributed because it resides at the registries/registrars, and query-making and response takes place among distributed parties. It is CENTRALIZED in one way: access/authentication functions. * Model #3: ICANN holds a registry containing all RDS data, obtained from the registries/registrars, and all queries go to and immediately served back from there. The central point also controls access (authentication creds). This is all CENTRALIZED. I will call this the Lord of the Rings Model: "One registry to rule them all / One registry to find them / One registry to bring them all / And at ICANN bind them." In Model #1, ICANN can be the party making the disclosure decisions. In that case, the registry/registrar would be acting pretty much as a data processor - if ICANN sends it a query, the registry/registrar simply supplies the data. Or, the registrar/registry can be the decision-maker in model #1. Model #2 only allows the registry/registrar to be the decision-maker. Model #3 exists only for ICANN to be the decision-maker. So, ICANN can be "the decider" without a centralized registry. The most crucial question is whether ICANN can or will act as the decider. If ICANN's the decider, then we have a choice between Model #1 or Model #3. If ICANN will not be the decider, then we have a choice of Model #1 or Model #2. Sarah posited ICANN as the decider, and then said the registry/registrar would be making 6(1)f decisions. I didn't understand that, because there can only be one decider. So, we need to know who the decider will be. And the WG should enumerate the plusses and minuses of each of the models. All best, --Greg From: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs' Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I'll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. "Addressed" = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, "provided" can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I'm misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the "centralized" version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some "requestor" stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks- J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say "addressed" what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by "responding party"? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN "relay" disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
+1 From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Mueller, Milton L Sent: Monday, September 23, 2019 8:30 AM To: Mueller, Milton L <milton@gatech.edu>; Greg Aaron <greg@illumintel.com>; 'James M. Bladel' <jbladel@godaddy.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks I see in a later email Greg made it clear that his Model 1 encompasses either ICANN or the registrar being "the decider." Because of the importance of that distinction, I think we should give the two a different name, perhaps 1a (ICANN decides) and 1b (registrar decides) From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Mueller, Milton L Sent: Monday, September 23, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'James M. Bladel' <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg, This is a pretty good overview of the models but I think there is a fourth option in there that needs to be aired. In Model #1, ICANN is the central point for distributing queries. You imply further down in your discussion that ICANN is ALSO the decision maker regarding disclosure. However, it does not have to be that way. ICANN could be a central point for distributing queries, but the ultimate decision could still rest with the registrar. This, in fact, is the model we see as most viable in terms of gaining consensus among stakeholders and operating efficiently and legally. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Greg Aaron Sent: Friday, September 20, 2019 1:34 PM To: 'James M. Bladel' <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Thanks much, James. My observation is about the models we discussed in L.A. (What kinds of hamburgers are on the menu?) We should be precise about what we mean by "distributed". I see three models: * Model #1: Queries come from requestors into a central point (run somehow by ICANN), that central point distributes the queries to the relevant registrars/registries, then the central point routes the replies back to the requestors. The central point also passes out authentication credentials to the parties making queries. This is the technical model the TSG wrote about. This has a DISTRIBUTED data model - the data resides at the registries/registrars. It has CENTRALIZED query input/output and access/authentication functions. * Model #2: A central point passes out authentication credentials, and requestors and registries/registrars then use those to trade queries with each other directly. This is a DISTRIBUTED model in two ways: the data is distributed because it resides at the registries/registrars, and query-making and response takes place among distributed parties. It is CENTRALIZED in one way: access/authentication functions. * Model #3: ICANN holds a registry containing all RDS data, obtained from the registries/registrars, and all queries go to and immediately served back from there. The central point also controls access (authentication creds). This is all CENTRALIZED. I will call this the Lord of the Rings Model: "One registry to rule them all / One registry to find them / One registry to bring them all / And at ICANN bind them." In Model #1, ICANN can be the party making the disclosure decisions. In that case, the registry/registrar would be acting pretty much as a data processor - if ICANN sends it a query, the registry/registrar simply supplies the data. Or, the registrar/registry can be the decision-maker in model #1. Model #2 only allows the registry/registrar to be the decision-maker. Model #3 exists only for ICANN to be the decision-maker. So, ICANN can be "the decider" without a centralized registry. The most crucial question is whether ICANN can or will act as the decider. If ICANN's the decider, then we have a choice between Model #1 or Model #3. If ICANN will not be the decider, then we have a choice of Model #1 or Model #2. Sarah posited ICANN as the decider, and then said the registry/registrar would be making 6(1)f decisions. I didn't understand that, because there can only be one decider. So, we need to know who the decider will be. And the WG should enumerate the plusses and minuses of each of the models. All best, --Greg From: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs' Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I'll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. "Addressed" = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, "provided" can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I'm misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the "centralized" version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some "requestor" stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks- J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say "addressed" what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by "responding party"? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN "relay" disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Attached is the final version of a PowerPoint that I shared exactly one year ago at the first LA meeting. There wasn't much interest back then, but it should be helpful when considering these topics. The notes attached to each slide explain the details, but this matrix is a summary. (I have also attached the matrix as an attachment.) CP delivers data to requestor Data passes through ICANN from CP to requestor ICANN always holds the data * Request goes to CP * CP is the decider 2 * Request goes to ICANN * CP is the decider * Request goes to CP * ICANN is the decider 3 * Request goes to ICANN * ICANN is the decider 4 5 6, 7 Feel free to propose additional variations if applicable. (Note that the reference to "UAM" was based on my interpretation of the ICANN-proposed model from mid-2018; that term no longer has any practical meaning and should not be construed as applicable to anything Goran or Strawberry team have discussed recently.) /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Friday, September 20, 2019 8:35 AM To: Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs' Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I'll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. "Addressed" = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, "provided" can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I'm misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the "centralized" version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some "requestor" stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks- J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say "addressed" what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by "responding party"? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN "relay" disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of James M. Bladel <jbladel@godaddy.com> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Greg Aaron <greg@illumintel.com> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" <AHeineman@ntia.gov> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" <jbladel@godaddy.com>, Greg Aaron <greg@illumintel.com>, 'Sarah Wyld' <swyld@tucows.com>, "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of James M. Bladel <jbladel@godaddy.com> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Greg Aaron <greg@illumintel.com> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Hi all, I would like to thank Sarah, Greg, and Mark Sv for helping us organize these concepts and frame the possible options. I support James’ request to staff, noting that ICANN’s preferences, while not dispositive, are valuable input for our work. Good point, Ashley. James, I think we’re mostly on board, and there is additional value to the CPs in the model you outline if there is no right to deny the request. The Bird & Bird memo notes that, “a CP's liability under the GDPR is significantly affected by whether it is a "controller" or a "processor", and that this determination hinges on three factors: 1. The degree of actual control exercised by a party, 2. The image given to data subjects, and 3. Reasonable expectations of data subjects on the basis of this visibility. We can (and should) drastically influence 2 and 3 with policy recommendations that require crystal-clear notice to registrants about how registration data will be processed. We identified this opportunity early on as the RAA is insufficiently vague, and I think we’re probably unanimous on this. The remaining factor tending to increase CP liability is the degree of actual control exercised, or “the right to deny the request.” I understand that the ability to deny requests appears attractive for risk mitigation, but I implore CPs and the EPDP team to understand that this would increase liability for CPs. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Friday, September 20, 2019 2:24 PM To: Heineman, Ashley <AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Hi all, First off, happy Friday to all! This is a good discussion and really getting at the heart of what decisions we need to make in our work to get any kind of recommendations across the finish line. Brian – can I just clarify your note below please? If I understand correctly, you are indicating the contracted parties are, in fact, the controllers and continue to have liability with regard to non-public data but you DO NOT want them to have the ability to reject any requests for non-public data that flow to them through the SSAD? Did I get that right? I can understand a scenario where that would be advisable if the contracted parties were processers of the data, but having a hard time seeing how this would be possible when it has been established that CP’s are actually controllers. Might be something that’s better discussed on a future call, but I do think this is certainly a question that needs to be addressed. Have a good weekend all! Matt From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org> Reply-To: "King, Brian" <Brian.King@markmonitor.com> Date: Friday, September 20, 2019 at 12:51 PM To: "James M. Bladel" <jbladel@godaddy.com>, "Heineman, Ashley" <AHeineman@ntia.gov>, Greg Aaron <greg@illumintel.com>, 'Sarah Wyld' <swyld@tucows.com>, "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi all, I would like to thank Sarah, Greg, and Mark Sv for helping us organize these concepts and frame the possible options. I support James’ request to staff, noting that ICANN’s preferences, while not dispositive, are valuable input for our work. Good point, Ashley. James, I think we’re mostly on board, and there is additional value to the CPs in the model you outline if there is no right to deny the request. The Bird & Bird memo notes that, “a CP's liability under the GDPR is significantly affected by whether it is a "controller" or a "processor", and that this determination hinges on three factors: 1. The degree of actual control exercised by a party, 2. The image given to data subjects, and 3. Reasonable expectations of data subjects on the basis of this visibility. We can (and should) drastically influence 2 and 3 with policy recommendations that require crystal-clear notice to registrants about how registration data will be processed. We identified this opportunity early on as the RAA is insufficiently vague, and I think we’re probably unanimous on this. The remaining factor tending to increase CP liability is the degree of actual control exercised, or “the right to deny the request.” I understand that the ability to deny requests appears attractive for risk mitigation, but I implore CPs and the EPDP team to understand that this would increase liability for CPs. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Friday, September 20, 2019 2:24 PM To: Heineman, Ashley <AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Brian should confirm, but I think that Brian is referring to some ongoing discussion of scenarios where the CP has been judged to be a processor rather than a data controller even if they are the data collector. (I am setting that aside for now) My recollection of the memo in the context of a JCA was: 1. Within a joint controller relationship, tasks can be divided between the controllers 2. It is possible within a joint controller relationship for CP to do the data collection and the other controller (here envisaged as a centralized entity) to perform balancing tests 3. If the delegation of tasks is as in #2 above, then the balancing entity takes more/all the risk of bad balancing decisions 4. If the CP maintains a right within the JCA to perform a pre-balancing test with a right to reject individual requests, there is less risk benefit to the CP than if the CP does not maintain such a right From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Matt Serlin Sent: Friday, September 20, 2019 12:15 PM To: King, Brian <Brian.King@markmonitor.com>; James M. Bladel <jbladel@godaddy.com>; Heineman, Ashley <AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi all, First off, happy Friday to all! This is a good discussion and really getting at the heart of what decisions we need to make in our work to get any kind of recommendations across the finish line. Brian – can I just clarify your note below please? If I understand correctly, you are indicating the contracted parties are, in fact, the controllers and continue to have liability with regard to non-public data but you DO NOT want them to have the ability to reject any requests for non-public data that flow to them through the SSAD? Did I get that right? I can understand a scenario where that would be advisable if the contracted parties were processers of the data, but having a hard time seeing how this would be possible when it has been established that CP’s are actually controllers. Might be something that’s better discussed on a future call, but I do think this is certainly a question that needs to be addressed. Have a good weekend all! Matt From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Reply-To: "King, Brian" <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>> Date: Friday, September 20, 2019 at 12:51 PM To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi all, I would like to thank Sarah, Greg, and Mark Sv for helping us organize these concepts and frame the possible options. I support James’ request to staff, noting that ICANN’s preferences, while not dispositive, are valuable input for our work. Good point, Ashley. James, I think we’re mostly on board, and there is additional value to the CPs in the model you outline if there is no right to deny the request. The Bird & Bird memo notes that, “a CP's liability under the GDPR is significantly affected by whether it is a "controller" or a "processor", and that this determination hinges on three factors: 1. The degree of actual control exercised by a party, 2. The image given to data subjects, and 3. Reasonable expectations of data subjects on the basis of this visibility. We can (and should) drastically influence 2 and 3 with policy recommendations that require crystal-clear notice to registrants about how registration data will be processed. We identified this opportunity early on as the RAA is insufficiently vague, and I think we’re probably unanimous on this. The remaining factor tending to increase CP liability is the degree of actual control exercised, or “the right to deny the request.” I understand that the ability to deny requests appears attractive for risk mitigation, but I implore CPs and the EPDP team to understand that this would increase liability for CPs. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Friday, September 20, 2019 2:24 PM To: Heineman, Ashley <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>>; Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Hi Mark, For the record, I agree with points 1 through 4. I agree with the whole thing if “judged” becomes “reasoned,” but who wants to split hairs on a Friday afternoon 😊 Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Mark Svancarek (CELA) <marksv@microsoft.com> Sent: Friday, September 20, 2019 3:26 PM To: Matt Serlin <matt@brandsight.com>; King, Brian <Brian.King@markmonitor.com>; James M. Bladel <jbladel@godaddy.com>; Heineman, Ashley <AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Questions regarding disclosure risks Brian should confirm, but I think that Brian is referring to some ongoing discussion of scenarios where the CP has been judged to be a processor rather than a data controller even if they are the data collector. (I am setting that aside for now) My recollection of the memo in the context of a JCA was: 1. Within a joint controller relationship, tasks can be divided between the controllers 2. It is possible within a joint controller relationship for CP to do the data collection and the other controller (here envisaged as a centralized entity) to perform balancing tests 3. If the delegation of tasks is as in #2 above, then the balancing entity takes more/all the risk of bad balancing decisions 4. If the CP maintains a right within the JCA to perform a pre-balancing test with a right to reject individual requests, there is less risk benefit to the CP than if the CP does not maintain such a right From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Matt Serlin Sent: Friday, September 20, 2019 12:15 PM To: King, Brian <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>>; James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Heineman, Ashley <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>>; Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi all, First off, happy Friday to all! This is a good discussion and really getting at the heart of what decisions we need to make in our work to get any kind of recommendations across the finish line. Brian – can I just clarify your note below please? If I understand correctly, you are indicating the contracted parties are, in fact, the controllers and continue to have liability with regard to non-public data but you DO NOT want them to have the ability to reject any requests for non-public data that flow to them through the SSAD? Did I get that right? I can understand a scenario where that would be advisable if the contracted parties were processers of the data, but having a hard time seeing how this would be possible when it has been established that CP’s are actually controllers. Might be something that’s better discussed on a future call, but I do think this is certainly a question that needs to be addressed. Have a good weekend all! Matt From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Reply-To: "King, Brian" <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>> Date: Friday, September 20, 2019 at 12:51 PM To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi all, I would like to thank Sarah, Greg, and Mark Sv for helping us organize these concepts and frame the possible options. I support James’ request to staff, noting that ICANN’s preferences, while not dispositive, are valuable input for our work. Good point, Ashley. James, I think we’re mostly on board, and there is additional value to the CPs in the model you outline if there is no right to deny the request. The Bird & Bird memo notes that, “a CP's liability under the GDPR is significantly affected by whether it is a "controller" or a "processor", and that this determination hinges on three factors: 1. The degree of actual control exercised by a party, 2. The image given to data subjects, and 3. Reasonable expectations of data subjects on the basis of this visibility. We can (and should) drastically influence 2 and 3 with policy recommendations that require crystal-clear notice to registrants about how registration data will be processed. We identified this opportunity early on as the RAA is insufficiently vague, and I think we’re probably unanimous on this. The remaining factor tending to increase CP liability is the degree of actual control exercised, or “the right to deny the request.” I understand that the ability to deny requests appears attractive for risk mitigation, but I implore CPs and the EPDP team to understand that this would increase liability for CPs. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Friday, September 20, 2019 2:24 PM To: Heineman, Ashley <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>>; Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Hey Matt, Really agree that this is where we need to be, discussion-wise. Thanks all for engaging. To your first question: nope, and sorry that I wasn’t more clear. One potential outcome I don’t think we should abandon pursuing is a scenario where the contracted parties are merely processors, at least for the processing activity of disclosure (which itself has different components e.g. “decider” and “sender”). It has not been “established that CP’s are actually controllers,” and that’s probably a good misconception to clear up very early. Bird & Bird’s memo said that in the specific set of hypothetical facts we described to them, they think CPs could be deemed to be processors, but they think it’s more likely that CPs would be deemed to be joint controllers (under those set of facts and assumptions, on which we have not come to consensus). I think it’s possible for us to alter those facts (and eliminate the need for assumptions) in such a way that creates a controller-processor scenario, which Bird & Bird has said would minimize CP liability, so I think this is a good goal for us. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Matt Serlin <matt@brandsight.com> Sent: Friday, September 20, 2019 3:15 PM To: King, Brian <Brian.King@markmonitor.com>; James M. Bladel <jbladel@godaddy.com>; Heineman, Ashley <AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi all, First off, happy Friday to all! This is a good discussion and really getting at the heart of what decisions we need to make in our work to get any kind of recommendations across the finish line. Brian – can I just clarify your note below please? If I understand correctly, you are indicating the contracted parties are, in fact, the controllers and continue to have liability with regard to non-public data but you DO NOT want them to have the ability to reject any requests for non-public data that flow to them through the SSAD? Did I get that right? I can understand a scenario where that would be advisable if the contracted parties were processers of the data, but having a hard time seeing how this would be possible when it has been established that CP’s are actually controllers. Might be something that’s better discussed on a future call, but I do think this is certainly a question that needs to be addressed. Have a good weekend all! Matt From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Reply-To: "King, Brian" <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>> Date: Friday, September 20, 2019 at 12:51 PM To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi all, I would like to thank Sarah, Greg, and Mark Sv for helping us organize these concepts and frame the possible options. I support James’ request to staff, noting that ICANN’s preferences, while not dispositive, are valuable input for our work. Good point, Ashley. James, I think we’re mostly on board, and there is additional value to the CPs in the model you outline if there is no right to deny the request. The Bird & Bird memo notes that, “a CP's liability under the GDPR is significantly affected by whether it is a "controller" or a "processor", and that this determination hinges on three factors: 1. The degree of actual control exercised by a party, 2. The image given to data subjects, and 3. Reasonable expectations of data subjects on the basis of this visibility. We can (and should) drastically influence 2 and 3 with policy recommendations that require crystal-clear notice to registrants about how registration data will be processed. We identified this opportunity early on as the RAA is insufficiently vague, and I think we’re probably unanimous on this. The remaining factor tending to increase CP liability is the degree of actual control exercised, or “the right to deny the request.” I understand that the ability to deny requests appears attractive for risk mitigation, but I implore CPs and the EPDP team to understand that this would increase liability for CPs. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Friday, September 20, 2019 2:24 PM To: Heineman, Ashley <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>>; Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Please keep in mind that merely delegating the decision making power to a third party like ICANN, be it by contract or policy that we have to abide by does not make us less of a controller. If that were possible everyone would delegate controllership to third parties to avoid liability. Let us try to move on from unproductive "what if" scenarios and start working within the framework of the legal advice we received, in which CPs _are_ seen as controllers. Anything else is not productive, would take forwever to work out and find consensus on and be a waste of our time, which is, as I am told, precious enough. If we want to release another report in the timeline we discussed, there is no time for complicated models and complete reversals of how this industry works. We have our advice to the questions asked by the IPC and BC, lets now follow that advice and accept its conclusions and move on to working with it. Best, Volker Am 20.09.2019 um 20:51 schrieb King, Brian via Gnso-epdp-team:
Hi all,
I would like to thank Sarah, Greg, and Mark Sv for helping us organize these concepts and frame the possible options. I support James’ request to staff, noting that ICANN’s preferences, while not dispositive, are valuable input for our work.
Good point, Ashley.
James, I think we’re mostly on board, and there is additional value to the CPs in the model you outline if there is no right to deny the request. The Bird & Bird memo notes that, “a CP's liability under the GDPR is significantly affected by whether it is a "controller" or a "processor", and that this determination hinges on three factors:
1. The degree of actual control exercised by a party, 2. The image given to data subjects, and 3. Reasonable expectations of data subjects on the basis of this visibility.
We can (and should) drastically influence 2 and 3 with policy recommendations that require crystal-clear notice to registrants about how registration data will be processed. We identified this opportunity early on as the RAA is insufficiently vague, and I think we’re probably unanimous on this.
The remaining factor tending to increase CP liability is the degree of actual control exercised, or “the right to deny the request.” I understand that the ability to deny requests appears attractive for risk mitigation, but I implore CPs and the EPDP team to understand that this would increase liability for CPs.
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726_ markmonitor.com <http://www.markmonitor.com>_
*MarkMonitor *Protecting companies and consumers in a digital world
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *James M. Bladel *Sent:* Friday, September 20, 2019 2:24 PM *To:* Heineman, Ashley <AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Questions regarding disclosure risks
Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on.
Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark.
Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds *to the entity*, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars.
The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity.
J.
-------------
*James Bladel*
GoDaddy
*From: *"Heineman, Ashley" <AHeineman@ntia.gov <mailto:AHeineman@ntia.gov>> *Date: *Friday, September 20, 2019 at 13:10 *To: *"James M. Bladel" <jbladel@godaddy.com <mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com <mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org>> *Subject: *Re: [Gnso-epdp-team] Questions regarding disclosure risks
Notice:This email is from an external sender.
Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in.
Thanks!
Ashley (GAC)
------------------------------------------------------------------------
*From:*Gnso-epdp-team <gnso-epdp-team-bounces@icann.org <mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com <mailto:jbladel@godaddy.com>> *Sent:* Friday, September 20, 2019 11:35 AM *To:* Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com <mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org>> *Subject:* Re: [Gnso-epdp-team] Questions regarding disclosure risks
Greg et al -
Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff.
Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow *causes* another (contracted) party to transmit the data to the Requestor.
Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point).
Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are:
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).
We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders).
Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons.
Thanks—
J.
_______________
James Bladel
GoDaddy
------------------------------------------------------------------------
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org <mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com>> *Sent:* Thursday, September 19, 2019 14:25 *To:* 'Sarah Wyld'; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] Questions regarding disclosure risks
Notice:This email is from an external sender.
When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query?
*From:* Sarah Wyld <swyld@tucows.com <mailto:swyld@tucows.com>> *Sent:* Thursday, September 19, 2019 11:16 AM *To:* Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] Questions regarding disclosure risks
Hi Greg,
"Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here.
Thanks.
-- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
On 9/19/2019 10:12 AM, Greg Aaron wrote:
Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity?
I ask because depending on what you mean, there may be other scenarios.
All best,
--Greg
*From:* Gnso-epdp-team<gnso-epdp-team-bounces@icann.org> <mailto:gnso-epdp-team-bounces@icann.org>*On Behalf Of *Sarah Wyld *Sent:* Wednesday, September 18, 2019 3:18 PM *To:* gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:* [Gnso-epdp-team] Questions regarding disclosure risks
Hello all,
During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data.
In order to fulfill this request, one of two things must be true. Either:
1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor
These potential scenarios raise the following questions:
1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance?
Thank you,
--
Sarah Wyld
Domains Product Team
Tucows
+1.416 535 0123 Ext. 1392
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Joint controllership is also a what-if scenario 😊 but I think we should consider it. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Volker Greimann Sent: Monday, September 23, 2019 1:58 AM To: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Please keep in mind that merely delegating the decision making power to a third party like ICANN, be it by contract or policy that we have to abide by does not make us less of a controller. If that were possible everyone would delegate controllership to third parties to avoid liability. Let us try to move on from unproductive "what if" scenarios and start working within the framework of the legal advice we received, in which CPs _are_ seen as controllers. Anything else is not productive, would take forwever to work out and find consensus on and be a waste of our time, which is, as I am told, precious enough. If we want to release another report in the timeline we discussed, there is no time for complicated models and complete reversals of how this industry works. We have our advice to the questions asked by the IPC and BC, lets now follow that advice and accept its conclusions and move on to working with it. Best, Volker Am 20.09.2019 um 20:51 schrieb King, Brian via Gnso-epdp-team: Hi all, I would like to thank Sarah, Greg, and Mark Sv for helping us organize these concepts and frame the possible options. I support James’ request to staff, noting that ICANN’s preferences, while not dispositive, are valuable input for our work. Good point, Ashley. James, I think we’re mostly on board, and there is additional value to the CPs in the model you outline if there is no right to deny the request. The Bird & Bird memo notes that, “a CP's liability under the GDPR is significantly affected by whether it is a "controller" or a "processor", and that this determination hinges on three factors: 1. The degree of actual control exercised by a party, 2. The image given to data subjects, and 3. Reasonable expectations of data subjects on the basis of this visibility. We can (and should) drastically influence 2 and 3 with policy recommendations that require crystal-clear notice to registrants about how registration data will be processed. We identified this opportunity early on as the RAA is insufficiently vague, and I think we’re probably unanimous on this. The remaining factor tending to increase CP liability is the degree of actual control exercised, or “the right to deny the request.” I understand that the ability to deny requests appears attractive for risk mitigation, but I implore CPs and the EPDP team to understand that this would increase liability for CPs. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.markmonitor.com&data=02%7C01%7Cmarksv%40microsoft.com%7C0dbae739bfee46b5778808d740042fce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048259048358946&sdata=oKOsUbIYrWS2spUQ8%2BQI%2FM9ztzpKoBol%2FB2iBej0u64%3D&reserved=0> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Friday, September 20, 2019 2:24 PM To: Heineman, Ashley <AHeineman@ntia.gov><mailto:AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com><mailto:greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com><mailto:swyld@tucows.com>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C0dbae739bfee46b5778808d740042fce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048259048358946&sdata=sU8Am1Bjn3bNBiZeGYQSGZVGuLOjizS52K767ihUyXo%3D&reserved=0> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C0dbae739bfee46b5778808d740042fce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048259048368925&sdata=%2FqpBteFLzHxST7D9Kj1836Zg4jaoh1VFlrP%2BgK9vzTo%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C0dbae739bfee46b5778808d740042fce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048259048368925&sdata=Fa9m4JiSf7fStfh8yH9ex1Gee9WZCbnz%2BAqpNdpZGWc%3D&reserved=0>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C0dbae739bfee46b5778808d740042fce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048259048378937&sdata=zCMK33hrCdkBsP6hLKErv8Cj6Y1oTbAHyw4%2BjM%2BNoUE%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Hi, Ashley – see my post of 1:34 pm (pasted below). No, ICANN does not have to establish a replica database. What you and James just described are the same as my Model #1, where the data sits at the registrars/registries but ICANN operates a central point that shuttles the data back and forth. (And ICANN can be the decider, or the registry/registrar can be the decider.) I think the three of us are on the same page here. IMHO the replica database idea probably has the most drawbacks. It may be the most complicated and therefore expensive, the hardest operationally for ICANN and the contracted parties to maintain, and I suspect that it presents the most security problems. It would be helpful for the WG to have analysis of each option’s positives and negatives. Regardless, we do need an answer to the most vital question -- will ICANN be the decider or not? There are two parts to the answer. First is whether the idea of “ICANN the decider” works under GDPR and if the EU data authorities will accept ICANN being in the position. And if “ICANN the decider” is possible, then whether ICANN Org will accept the role. Those two things can be pondered concurrently, but we really need an answer to the first part. Regarding whether ICANN will accept the role: I would think that would be a Board-level discussion, since it is a major risk/liability consideration and because solving the access problem is very important for ICANN’s credibility. Last week I think Chris Disspain said that the Board had not considered the issue. All best, --Greg From: James M. Bladel <jbladel@godaddy.com> Sent: Friday, September 20, 2019 2:24 PM To: Heineman, Ashley <AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" < <mailto:AHeineman@ntia.gov> AHeineman@ntia.gov> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" < <mailto:jbladel@godaddy.com> jbladel@godaddy.com>, Greg Aaron < <mailto:greg@illumintel.com> greg@illumintel.com>, 'Sarah Wyld' < <mailto:swyld@tucows.com> swyld@tucows.com>, " <mailto:gnso-epdp-team@icann.org> gnso-epdp-team@icann.org" < <mailto:gnso-epdp-team@icann.org> gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) From: Greg Aaron <greg@illumintel.com> Sent: Friday, September 20, 2019 1:34 PM To: 'James M. Bladel' <jbladel@godaddy.com>; 'Sarah Wyld' <swyld@tucows.com>; 'gnso-epdp-team@icann.org' <gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Questions regarding disclosure risks Thanks much, James. My observation is about the models we discussed in L.A. (What kinds of hamburgers are on the menu?) We should be precise about what we mean by “distributed”. I see three models: * Model #1: Queries come from requestors into a central point (run somehow by ICANN), that central point distributes the queries to the relevant registrars/registries, then the central point routes the replies back to the requestors. The central point also passes out authentication credentials to the parties making queries. This is the technical model the TSG wrote about. This has a DISTRIBUTED data model – the data resides at the registries/registrars. It has CENTRALIZED query input/output and access/authentication functions. * Model #2: A central point passes out authentication credentials, and requestors and registries/registrars then use those to trade queries with each other directly. This is a DISTRIBUTED model in two ways: the data is distributed because it resides at the registries/registrars, and query-making and response takes place among distributed parties. It is CENTRALIZED in one way: access/authentication functions. * Model #3: ICANN holds a registry containing all RDS data, obtained from the registries/registrars, and all queries go to and immediately served back from there. The central point also controls access (authentication creds). This is all CENTRALIZED. I will call this the Lord of the Rings Model: “One registry to rule them all / One registry to find them / One registry to bring them all / And at ICANN bind them.” In Model #1, ICANN can be the party making the disclosure decisions. In that case, the registry/registrar would be acting pretty much as a data processor – if ICANN sends it a query, the registry/registrar simply supplies the data. Or, the registrar/registry can be the decision-maker in model #1. Model #2 only allows the registry/registrar to be the decision-maker. Model #3 exists only for ICANN to be the decision-maker. So, ICANN can be “the decider” without a centralized registry. The most crucial question is whether ICANN can or will act as the decider. If ICANN’s the decider, then we have a choice between Model #1 or Model #3. If ICANN will not be the decider, then we have a choice of Model #1 or Model #2. Sarah posited ICANN as the decider, and then said the registry/registrar would be making 6(1)f decisions. I didn’t understand that, because there can only be one decider. So, we need to know who the decider will be. And the WG should enumerate the plusses and minuses of each of the models. All best, --Greg _____ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org <mailto:gnso-epdp-team-bounces@icann.org> > on behalf of James M. Bladel <jbladel@godaddy.com <mailto:jbladel@godaddy.com> > Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com> >; 'Sarah Wyld' <swyld@tucows.com <mailto:swyld@tucows.com> >; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy _____ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org <mailto:gnso-epdp-team-bounces@icann.org> > on behalf of Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com> > Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com <mailto:swyld@tucows.com> > Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com> >; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team <mailto:gnso-epdp-team-bounces@icann.org> <gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Even presuming that ICANN is willing to take responsibility, my money is on a hybrid model where ICANN responds to some classes of requests and passes others onto the contracted parties. Two particular types of requests that I think are prime for contracted party decisions are: - requests from law enforcement not in the CP jurisdiction. These are likely to be handled in various ways depending on the relationship of the CP country and the requestor, and it would be difficult for a central body to understand the nuances of the relationships. - requests where without knowing who the registrant is (ie the registrar client), it will be difficult to do the balancing test. In both such cases, forcing the decision at some central level will alsmost certainly end up with potentially valid and justified requests being refused. Alan At 20/09/2019 03:38 PM, Greg Aaron wrote: Hi, Ashley � see my post of 1:34 pm (pasted below). No, ICANN does not have to establish a replica database. What you and James just described are the same as my Model #1, where the data sits at the registrars/registries but ICANN operates a central point that shuttles the data back and forth. (And ICANN can be the decider, or the registry/registrar can be the decider.) I think the three of us are on the same page here. IMHO the replica database idea probably has the most drawbacks. It may be the most complicated and therefore expensive, the hardest operationally for ICANN and the contracted parties to maintain, and I suspect that it presents the most security problems. It would be helpful for the WG to have analysis of each option’s positives and negatives. Regardless, we do need an answer to the most vital question -- will ICANN be the decider or not? There are two parts to the answer. First is whether the idea of “ICANN the decider” works under GDPR and if the EU data authorities will accept ICANN being in the position. And if “ICANN the decider” is possible, then whether ICANN Org will accept the role. Those two things can be pondered concurrently, but we really need an answer to the first part. Regarding whether ICANN will accept the role: I would think that would be a Board-level discussion, since it is a major risk/liability consideration and because solving the access problem is very important for ICANN’s credibility. Last week I think Chris Disspain said that the Board had not considered the issue. All best, --Greg From: James M. Bladel <jbladel@godaddy.com> Sent: Friday, September 20, 2019 2:24 PM To: Heineman, Ashley <AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg � I think we’re assuming thhat there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely � Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) From: Greg Aaron <greg@illumintel.com> Sent: Friday, September 20, 2019 1:34 PM To: 'James M. Bladel' <jbladel@godaddy.com>; 'Sarah Wyld' <swyld@tucows.com>; 'gnso-epdp-team@icann.org' <gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Questions regarding disclosure risks Thanks much, James. My observation is about the models we discussed in L.A. (What kinds of hamburgers are on the menu?) We should be precise about what we mean by “distributed”. I see three models: * Model #1: Queries come from requestors into a central point (run somehow by ICANN), that central point distributes the queries to the relevant registrars/registries, then the central point routes the replies back to the requestors. The central point also passes out authentication credentials to the parties making queries. This is the technical model the TSG wrote about. This has a DISTRIBUTED data model � the data resides at the registries/registraars. It has CENTRALIZED query input/output and access/authentication functions. * Model #2: A central point passes out authentication credentials, and requestors and registries/registrars then use those to trade queries with each other directly. This is a DISTRIBUTED model in two ways: the data is distributed because it resides at the registries/registrars, and query-making and response takes place among distributed parties. It is CENTRALIZED in one way: access/authentication functions. * Model #3: ICANN holds a registry containing all RDS data, obtained from the registries/registrars, and all queries go to and immediately served back from there. The central point also controls access (authentication creds). This is all CENTRALIZED. I will call this the Lord of the Rings Model: “One registry to rule them all / One registry to find them / One registry to bring them all / And at ICANN bind them.” In Model #1, ICANN can be the party making the disclosure decisions. In that case, the registry/registrar would be acting pretty much as a data processor � if ICANN sendss it a query, the registry/registrar simply supplies the data. Or, the registrar/registry can be the decision-maker in model #1. Model #2 only allows the registry/registrar to be the decision-maker. Model #3 exists only for ICANN to be the decision-maker. So, ICANN can be “the decider” without a centralized registry. The most crucial question is whether ICANN can or will act as the decider. If ICANN’s the decider, then we have a choice between Model #1 or Model #3. If ICANN will not be the decider, then we have a choice of Model #1 or Model #2. Sarah posited ICANN as the decider, and then said the registry/registrar would be making 6(1)f decisions. I didn’t understand that, because there can only be one decider. So, we need to know who the decider will be. And the WG should enumerate the plusses and minuses of each of the models. All best, --Greg ________________________________ From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks� J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://www.icann.org/privacy/policy) and the website Terms of Service ( https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi I also agree that a central repository is not desirable and may even be problematic under the GDPR. Even shuttling the disclosrue through ICANN can be seen as problematic as it exposes a third party to the data that has no real need of processing it. I could imagine a central portal working in a way that it accepts and redirects requests to the entities holding the data, who then make the balancing test and if disclosure is granted, make that disclosure directly to the requestor. In either case, the central portal could be informed of the decision. ICANN as the decider is neither beneficial, data protection compliance not desirable. ICANN will not be in a position to make a valid balancing test. Best, Volker Am 20.09.2019 um 21:38 schrieb Greg Aaron:
Hi, Ashley – see my post of 1:34 pm (pasted below). No, ICANN does not have to establish a replica database. What you and James just described are the same as my Model #1, where the data sits at the registrars/registries but ICANN operates a central point that shuttles the data back and forth. (And ICANN can be the decider, or the registry/registrar can be the decider.) I think the three of us are on the same page here.
IMHO the replica database idea probably has the most drawbacks. It may be the most complicated and therefore expensive, the hardest operationally for ICANN and the contracted parties to maintain, and I suspect that it presents the most security problems. It would be helpful for the WG to have analysis of each option’s positives and negatives.
Regardless, we do need an answer to the most vital question -- will ICANN be the decider or not?
There are two parts to the answer. First is whether the idea of “ICANN the decider” works under GDPR and if the EU data authorities will accept ICANN being in the position. And if “ICANN the decider” is possible, then whether ICANN Org will accept the role. Those two things can be pondered concurrently, but we really need an answer to the first part.
Regarding whether ICANN will accept the role: I would think that would be a Board-level discussion, since it is a major risk/liability consideration and because solving the access problem is very important for ICANN’s credibility. Last week I think Chris Disspain said that the Board had not considered the issue.
All best,
--Greg
*From:* James M. Bladel <jbladel@godaddy.com> *Sent:* Friday, September 20, 2019 2:24 PM *To:* Heineman, Ashley <AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Questions regarding disclosure risks
Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on.
Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark.
Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds *to the entity*, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars.
The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity.
J.
-------------
*James Bladel*
GoDaddy
*From: *"Heineman, Ashley" <AHeineman@ntia.gov <mailto:AHeineman@ntia.gov>> *Date: *Friday, September 20, 2019 at 13:10 *To: *"James M. Bladel" <jbladel@godaddy.com <mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com <mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org>> *Subject: *Re: [Gnso-epdp-team] Questions regarding disclosure risks
Notice:This email is from an external sender.
Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in.
Thanks!
Ashley (GAC)
*From:* Greg Aaron <greg@illumintel.com> *Sent:* Friday, September 20, 2019 1:34 PM *To:* 'James M. Bladel' <jbladel@godaddy.com>; 'Sarah Wyld' <swyld@tucows.com>; 'gnso-epdp-team@icann.org' <gnso-epdp-team@icann.org> *Subject:* RE: [Gnso-epdp-team] Questions regarding disclosure risks
Thanks much, James. My observation is about the models we discussed in L.A. (What kinds of hamburgers are on the menu?) We should be precise about what we mean by “distributed”. I see three models:
* Model #1: Queries come from requestors into a central point (run somehow by ICANN), that central point distributes the queries to the relevant registrars/registries, then the central point routes the replies back to the requestors. The central point also passes out authentication credentials to the parties making queries. This is the technical model the TSG wrote about. This has a DISTRIBUTED data model – the data resides at the registries/registrars. It has CENTRALIZED query input/output and access/authentication functions. * Model #2: A central point passes out authentication credentials, and requestors and registries/registrars then use those to trade queries with each other directly. This is a DISTRIBUTED model in two ways: the data is distributed because it resides at the registries/registrars, and query-making and response takes place among distributed parties. It is CENTRALIZED in one way: access/authentication functions. * Model #3: ICANN holds a registry containing all RDS data, obtained from the registries/registrars, and all queries go to and immediately served back from there. The central point also controls access (authentication creds). This is all CENTRALIZED. I will call this the Lord of the Rings Model: “One registry to rule them all / One registry to find them / One registry to bring them all / And at ICANN bind them.”
In Model #1, ICANN can be the party making the disclosure decisions. In that case, the registry/registrar would be acting pretty much as a data processor – if ICANN sends it a query, the registry/registrar simply supplies the data. Or, the registrar/registry can be the decision-maker in model #1.
Model #2 only allows the registry/registrar to be the decision-maker.
Model #3 exists only for ICANN to be the decision-maker.
So, ICANN can be “the decider” without a centralized registry. The most crucial question is whether ICANN can or will act as the decider. If ICANN’s the decider, then we have a choice between Model #1 or Model #3. If ICANN will not be the decider, then we have a choice of Model #1 or Model #2.
Sarah posited ICANN as the decider, and then said the registry/registrar would be making 6(1)f decisions. I didn’t understand that, because there can only be one decider.
So, we need to know who the decider will be. And the WG should enumerate the plusses and minuses of each of the models.
All best,
--Greg
------------------------------------------------------------------------
*From:*Gnso-epdp-team <gnso-epdp-team-bounces@icann.org <mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com <mailto:jbladel@godaddy.com>> *Sent:* Friday, September 20, 2019 11:35 AM *To:* Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com <mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org><gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org>> *Subject:* Re: [Gnso-epdp-team] Questions regarding disclosure risks
Greg et al -
Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff.
Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow *causes* another (contracted) party to transmit the data to the Requestor.
Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point).
Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are:
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).
We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders).
Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons.
Thanks—
J.
_______________
James Bladel
GoDaddy
------------------------------------------------------------------------
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org <mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com>> *Sent:* Thursday, September 19, 2019 14:25 *To:* 'Sarah Wyld'; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] Questions regarding disclosure risks
Notice:This email is from an external sender.
When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query?
*From:* Sarah Wyld <swyld@tucows.com <mailto:swyld@tucows.com>> *Sent:* Thursday, September 19, 2019 11:16 AM *To:* Greg Aaron <greg@illumintel.com <mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] Questions regarding disclosure risks
Hi Greg,
"Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here.
Thanks.
-- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
On 9/19/2019 10:12 AM, Greg Aaron wrote:
Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity?
I ask because depending on what you mean, there may be other scenarios.
All best,
--Greg
*From:* Gnso-epdp-team<gnso-epdp-team-bounces@icann.org> <mailto:gnso-epdp-team-bounces@icann.org>*On Behalf Of *Sarah Wyld *Sent:* Wednesday, September 18, 2019 3:18 PM *To:* gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:* [Gnso-epdp-team] Questions regarding disclosure risks
Hello all,
During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data.
In order to fulfill this request, one of two things must be true. Either:
1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor
These potential scenarios raise the following questions:
1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance?
Thank you,
--
Sarah Wyld
Domains Product Team
Tucows
+1.416 535 0123 Ext. 1392
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
It was my understanding that under a JCA, ICANN would not be a third party with no need to process – as a joint controller, they would be reasonably expected to process. Regarding ICANN’s position to make a valid balancing test, I think it’s good to recognize that many registrations are conducted by resellers. Volker has previously made a point that understanding the geographic or personhood status in such cases would be “an administrative nightmare”. I don’t see why we’d expect a registrar in such cases to have any additional insight over ICANN in making a valid balancing test – either would be sufficient. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Volker Greimann Sent: Monday, September 23, 2019 1:49 AM To: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi I also agree that a central repository is not desirable and may even be problematic under the GDPR. Even shuttling the disclosrue through ICANN can be seen as problematic as it exposes a third party to the data that has no real need of processing it. I could imagine a central portal working in a way that it accepts and redirects requests to the entities holding the data, who then make the balancing test and if disclosure is granted, make that disclosure directly to the requestor. In either case, the central portal could be informed of the decision. ICANN as the decider is neither beneficial, data protection compliance not desirable. ICANN will not be in a position to make a valid balancing test. Best, Volker Am 20.09.2019 um 21:38 schrieb Greg Aaron: Hi, Ashley – see my post of 1:34 pm (pasted below). No, ICANN does not have to establish a replica database. What you and James just described are the same as my Model #1, where the data sits at the registrars/registries but ICANN operates a central point that shuttles the data back and forth. (And ICANN can be the decider, or the registry/registrar can be the decider.) I think the three of us are on the same page here. IMHO the replica database idea probably has the most drawbacks. It may be the most complicated and therefore expensive, the hardest operationally for ICANN and the contracted parties to maintain, and I suspect that it presents the most security problems. It would be helpful for the WG to have analysis of each option’s positives and negatives. Regardless, we do need an answer to the most vital question -- will ICANN be the decider or not? There are two parts to the answer. First is whether the idea of “ICANN the decider” works under GDPR and if the EU data authorities will accept ICANN being in the position. And if “ICANN the decider” is possible, then whether ICANN Org will accept the role. Those two things can be pondered concurrently, but we really need an answer to the first part. Regarding whether ICANN will accept the role: I would think that would be a Board-level discussion, since it is a major risk/liability consideration and because solving the access problem is very important for ICANN’s credibility. Last week I think Chris Disspain said that the Board had not considered the issue. All best, --Greg From: James M. Bladel <jbladel@godaddy.com><mailto:jbladel@godaddy.com> Sent: Friday, September 20, 2019 2:24 PM To: Heineman, Ashley <AHeineman@ntia.gov><mailto:AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com><mailto:greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com><mailto:swyld@tucows.com>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) From: Greg Aaron <greg@illumintel.com><mailto:greg@illumintel.com> Sent: Friday, September 20, 2019 1:34 PM To: 'James M. Bladel' <jbladel@godaddy.com><mailto:jbladel@godaddy.com>; 'Sarah Wyld' <swyld@tucows.com><mailto:swyld@tucows.com>; 'gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>' <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Questions regarding disclosure risks Thanks much, James. My observation is about the models we discussed in L.A. (What kinds of hamburgers are on the menu?) We should be precise about what we mean by “distributed”. I see three models: * Model #1: Queries come from requestors into a central point (run somehow by ICANN), that central point distributes the queries to the relevant registrars/registries, then the central point routes the replies back to the requestors. The central point also passes out authentication credentials to the parties making queries. This is the technical model the TSG wrote about. This has a DISTRIBUTED data model – the data resides at the registries/registrars. It has CENTRALIZED query input/output and access/authentication functions. * Model #2: A central point passes out authentication credentials, and requestors and registries/registrars then use those to trade queries with each other directly. This is a DISTRIBUTED model in two ways: the data is distributed because it resides at the registries/registrars, and query-making and response takes place among distributed parties. It is CENTRALIZED in one way: access/authentication functions. * Model #3: ICANN holds a registry containing all RDS data, obtained from the registries/registrars, and all queries go to and immediately served back from there. The central point also controls access (authentication creds). This is all CENTRALIZED. I will call this the Lord of the Rings Model: “One registry to rule them all / One registry to find them / One registry to bring them all / And at ICANN bind them.” In Model #1, ICANN can be the party making the disclosure decisions. In that case, the registry/registrar would be acting pretty much as a data processor – if ICANN sends it a query, the registry/registrar simply supplies the data. Or, the registrar/registry can be the decision-maker in model #1. Model #2 only allows the registry/registrar to be the decision-maker. Model #3 exists only for ICANN to be the decision-maker. So, ICANN can be “the decider” without a centralized registry. The most crucial question is whether ICANN can or will act as the decider. If ICANN’s the decider, then we have a choice between Model #1 or Model #3. If ICANN will not be the decider, then we have a choice of Model #1 or Model #2. Sarah posited ICANN as the decider, and then said the registry/registrar would be making 6(1)f decisions. I didn’t understand that, because there can only be one decider. So, we need to know who the decider will be. And the WG should enumerate the plusses and minuses of each of the models. All best, --Greg ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7Cd27c174edcbf4e8df8a908d74002d8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048253301325822&sdata=TLa5hkG%2Fd5o2vTz4QROkCJ0xTfe3ZxurooC5gqb1gOE%3D&reserved=0> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7Cd27c174edcbf4e8df8a908d74002d8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048253301325822&sdata=dvesgyNYUtJCaZGjMiROIloi88jq9wFDpqtiqVHVYlo%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7Cd27c174edcbf4e8df8a908d74002d8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048253301325822&sdata=gWvFZRnbp6Twjx4rdK%2BkeyWk%2BcZqC8wHuXN%2FGzQxNRM%3D&reserved=0>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7Cd27c174edcbf4e8df8a908d74002d8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048253301335778&sdata=g4BtsFQWHu33FTLtTtY3Ge0EpcX4cc7C6LS10vRGkIs%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
I agree with Volker that a central repository raises many questions. A central vetting process for the requests for access is a totally different matter, as it would not contain as much PI (theoretically at least) and it could perform only the service of passing on a verified request for data to a data controller. Not to beat the aforementioned dead horse, but I don't believe the CPS can outsource the function of disclosure without significant risk of liability. Stephanie Perrin On 2019-09-23 04: 48, Volker Greimann wrote: Hi I also agree that a central repository is not desirable and may even be problematic under the GDPR. Even shuttling the disclosrue through ICANN can be seen as problematic as it exposes a third party to the data that has no real need of processing it. I could imagine a central portal working in a way that it accepts and redirects requests to the entities holding the data, who then make the balancing test and if disclosure is granted, make that disclosure directly to the requestor. In either case, the central portal could be informed of the decision. ICANN as the decider is neither beneficial, data protection compliance not desirable. ICANN will not be in a position to make a valid balancing test. Best, Volker Am 20.09.2019 um 21:38 schrieb Greg Aaron: Hi, Ashley – see my post of 1:34 pm (pasted below). No, ICANN does not have to establish a replica database. What you and James just described are the same as my Model #1, where the data sits at the registrars/registries but ICANN operates a central point that shuttles the data back and forth. (And ICANN can be the decider, or the registry/registrar can be the decider.) I think the three of us are on the same page here. IMHO the replica database idea probably has the most drawbacks. It may be the most complicated and therefore expensive, the hardest operationally for ICANN and the contracted parties to maintain, and I suspect that it presents the most security problems. It would be helpful for the WG to have analysis of each option’s positives and negatives. Regardless, we do need an answer to the most vital question -- will ICANN be the decider or not? There are two parts to the answer. First is whether the idea of “ICANN the decider” works under GDPR and if the EU data authorities will accept ICANN being in the position. And if “ICANN the decider” is possible, then whether ICANN Org will accept the role. Those two things can be pondered concurrently, but we really need an answer to the first part. Regarding whether ICANN will accept the role: I would think that would be a Board-level discussion, since it is a major risk/liability consideration and because solving the access problem is very important for ICANN’s credibility. Last week I think Chris Disspain said that the Board had not considered the issue. All best, --Greg From: James M. Bladel <jbladel@godaddy.com><mailto:jbladel@godaddy.com> Sent: Friday, September 20, 2019 2:24 PM To: Heineman, Ashley <AHeineman@ntia.gov><mailto:AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com><mailto:greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com><mailto:swyld@tucows.com>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS. But we still need them to explicitly state this, so we can work around it and move on. Ashely – Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark. Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party. The CP then responds to the entity, either by providing the non-public data or issuing a denial (with rationale). In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars. The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity. J. ------------- James Bladel GoDaddy From: "Heineman, Ashley" <AHeineman@ntia.gov<mailto:AHeineman@ntia.gov>> Date: Friday, September 20, 2019 at 13:10 To: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>, 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>, "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice: This email is from an external sender. Hi all. Thanks for this and a quick question on the questions. Does ICANN *have to* establish a replica database in this scenario? Can't the information just more or less pass through ICANN? That would mean less data being transferred and could also presumably less data stored/retained. Right? Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in. Thanks! Ashley (GAC) From: Greg Aaron <greg@illumintel.com><mailto:greg@illumintel.com> Sent: Friday, September 20, 2019 1:34 PM To: 'James M. Bladel' <jbladel@godaddy.com><mailto:jbladel@godaddy.com>; 'Sarah Wyld' <swyld@tucows.com><mailto:swyld@tucows.com>; 'gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>' <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Questions regarding disclosure risks Thanks much, James. My observation is about the models we discussed in L.A. (What kinds of hamburgers are on the menu?) We should be precise about what we mean by “distributed”. I see three models: * Model #1: Queries come from requestors into a central point (run somehow by ICANN), that central point distributes the queries to the relevant registrars/registries, then the central point routes the replies back to the requestors. The central point also passes out authentication credentials to the parties making queries. This is the technical model the TSG wrote about. This has a DISTRIBUTED data model – the data resides at the registries/registrars. It has CENTRALIZED query input/output and access/authentication functions. * Model #2: A central point passes out authentication credentials, and requestors and registries/registrars then use those to trade queries with each other directly. This is a DISTRIBUTED model in two ways: the data is distributed because it resides at the registries/registrars, and query-making and response takes place among distributed parties. It is CENTRALIZED in one way: access/authentication functions. * Model #3: ICANN holds a registry containing all RDS data, obtained from the registries/registrars, and all queries go to and immediately served back from there. The central point also controls access (authentication creds). This is all CENTRALIZED. I will call this the Lord of the Rings Model: “One registry to rule them all / One registry to find them / One registry to bring them all / And at ICANN bind them.” In Model #1, ICANN can be the party making the disclosure decisions. In that case, the registry/registrar would be acting pretty much as a data processor – if ICANN sends it a query, the registry/registrar simply supplies the data. Or, the registrar/registry can be the decision-maker in model #1. Model #2 only allows the registry/registrar to be the decision-maker. Model #3 exists only for ICANN to be the decision-maker. So, ICANN can be “the decider” without a centralized registry. The most crucial question is whether ICANN can or will act as the decider. If ICANN’s the decider, then we have a choice between Model #1 or Model #3. If ICANN will not be the decider, then we have a choice of Model #1 or Model #2. Sarah posited ICANN as the decider, and then said the registry/registrar would be making 6(1)f decisions. I didn’t understand that, because there can only be one decider. So, we need to know who the decider will be. And the WG should enumerate the plusses and minuses of each of the models. All best, --Greg ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Sent: Friday, September 20, 2019 11:35 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; 'Sarah Wyld' <swyld@tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Greg et al - Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin. So I’ll respond to Greg and pose a few questions to ICANN Staff. Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data. For clarity, “provided” can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor. Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to individual Contracted Parties. They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point). Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are: 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). We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work. Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders). Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons. Thanks— J. _______________ James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>> Sent: Thursday, September 19, 2019 14:25 To: 'Sarah Wyld'; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Notice:This email is from an external sender. When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query? From: Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> Sent: Thursday, September 19, 2019 11:16 AM To: Greg Aaron <greg@illumintel.com<mailto:greg@illumintel.com>>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Hi Greg, "Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here. Thanks. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 9/19/2019 10:12 AM, Greg Aaron wrote: Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team<gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org>On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I think it was pretty clear that Sarah was referring to the debate over who makes the actual disclosure decision. As you surely recall, we had debated whether it would be ICANN or registrars. Given that choice, I think Sarah’s two scenarios define the decision space very well. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Greg Aaron Sent: Thursday, September 19, 2019 10:13 AM To: 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
Let’s let Sarah say what Sarah meant. I want to understand the terms she’s using. Sarah, by “responding party” do you mean “the decision-maker about disclosure”? From: Mueller, Milton L <milton@gatech.edu> Sent: Thursday, September 19, 2019 2:12 PM To: Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Questions regarding disclosure risks I think it was pretty clear that Sarah was referring to the debate over who makes the actual disclosure decision. As you surely recall, we had debated whether it would be ICANN or registrars. Given that choice, I think Sarah’s two scenarios define the decision space very well. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org <mailto:gnso-epdp-team-bounces@icann.org> > On Behalf Of Greg Aaron Sent: Thursday, September 19, 2019 10:13 AM To: 'Sarah Wyld' <swyld@tucows.com <mailto:swyld@tucows.com> >; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks Sarah, what do you mean by “responding party”? For example so your scenarios assume that ICANN is acting in a specific legal capacity? I ask because depending on what you mean, there may be other scenarios. All best, --Greg From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org <mailto:gnso-epdp-team-bounces@icann.org> > On Behalf Of Sarah Wyld Sent: Wednesday, September 18, 2019 3:18 PM To: gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Questions regarding disclosure risks Hello all, During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data. In order to fulfill this request, one of two things must be true. Either: 1. ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or 2. ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor These potential scenarios raise the following questions: 1. In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed? 2. In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar? 3. What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance? Thank you, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
participants (11)
-
Alan Greenberg -
Greg Aaron -
Heineman, Ashley -
James M. Bladel -
King, Brian -
Mark Svancarek (CELA) -
Matt Serlin -
Mueller, Milton L -
Sarah Wyld -
Stephanie Perrin -
Volker Greimann