[Gnso-epdp-team] Questions regarding disclosure risks

Volker Greimann vgreimann at key-systems.net
Mon Sep 23 08:58:16 UTC 2019

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.



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 at icann.org> *On Behalf 
> Of *James M. Bladel
> *Sent:* Friday, September 20, 2019 2:24 PM
> *To:* Heineman, Ashley <AHeineman at ntia.gov>; Greg Aaron 
> <greg at illumintel.com>; 'Sarah Wyld' <swyld at tucows.com>; 
> gnso-epdp-team at 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 at ntia.gov 
> <mailto:AHeineman at ntia.gov>>
> *Date: *Friday, September 20, 2019 at 13:10
> *To: *"James M. Bladel" <jbladel at godaddy.com 
> <mailto:jbladel at godaddy.com>>, Greg Aaron <greg at illumintel.com 
> <mailto:greg at illumintel.com>>, 'Sarah Wyld' <swyld at tucows.com 
> <mailto:swyld at tucows.com>>, "gnso-epdp-team at icann.org 
> <mailto:gnso-epdp-team at icann.org>" <gnso-epdp-team at icann.org 
> <mailto:gnso-epdp-team at 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 at icann.org 
> <mailto:gnso-epdp-team-bounces at icann.org>> on behalf of James M. 
> Bladel <jbladel at godaddy.com <mailto:jbladel at godaddy.com>>
> *Sent:* Friday, September 20, 2019 11:35 AM
> *To:* Greg Aaron <greg at illumintel.com <mailto:greg at illumintel.com>>; 
> 'Sarah Wyld' <swyld at tucows.com <mailto:swyld at tucows.com>>; 
> gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org> 
> <gnso-epdp-team at icann.org <mailto:gnso-epdp-team at 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 at icann.org 
> <mailto:gnso-epdp-team-bounces at icann.org>> on behalf of Greg Aaron 
> <greg at illumintel.com <mailto:greg at illumintel.com>>
> *Sent:* Thursday, September 19, 2019 14:25
> *To:* 'Sarah Wyld'; gnso-epdp-team at icann.org 
> <mailto:gnso-epdp-team at 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 at tucows.com <mailto:swyld at tucows.com>>
> *Sent:* Thursday, September 19, 2019 11:16 AM
> *To:* Greg Aaron <greg at illumintel.com <mailto:greg at illumintel.com>>; 
> gnso-epdp-team at icann.org <mailto:gnso-epdp-team at 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 at icann.org>
>     <mailto:gnso-epdp-team-bounces at icann.org>*On Behalf Of *Sarah Wyld
>     *Sent:* Wednesday, September 18, 2019 3:18 PM
>     *To:* gnso-epdp-team at icann.org <mailto:gnso-epdp-team at 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 at 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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190923/6eb7d75f/attachment-0001.html>

More information about the Gnso-epdp-team mailing list