[Gnso-epdp-team] For your review: updated recommendations 10, 11, 12

[Alan Woods]

Dear all,

*Recommendation 12 (removal of the word 'REQUESTS')*

Whereas I appreciate Ashley's reasoning, I so not support removal of the
reference to "requests". The process and the recommendation are linked
wholly to the making of the request, and ensuring that those person who
wish to rely on such requests have some form of assurance that the
contracted parties will not 'ignore' such requests.  The way it is
currently read, poses a worry that it suggests that the policy may
interfere in the actual decision relating to disclosure or not. This
decision will be a decision of the contracted party alone, and should that
decision be incorrect, or someone feels aggrieved by the substantive
decision, their recourse will never be to ICANN, only to a DPA, or the
courts, to complain about failing to meet a legal obligation contained with
a EEA regulation.  Our purpose here is to ensure that a requester has
certain guarantees about the procedural, how to make, where to make, how
long generally, and the reasoning a decision is made that does not favor
release.


*Civil claim requests only*

Regarding Thomas' addition, I would support what he has stated and is
trying to achieve.

Law Enforcement dealing with matters of criminal cases should never feel
like they need to rely on the process as outlined in Recommendation 12. The
CPs (again noting the Good actors in the space --- the others are beyond my
reach) will always engage with LEAs and discuss access for lawful reasons
and the process by which we need to figure this figuring this out - also
this is already a requirement of the RAs under Spec 11 for the most part. I
find that this conversation is huge overreach for the ePDP.

With that I would make the following statements in support of Thomas'
assertion (i.e. LEA's may make requests as the law allows / requires):

1) Any law enforcement official, in the course of their duties as an
officer of the law, is acting in the public interest, and the paragraph
proceeding Art 6(1)f is very clear
"*Point (f) of the first subparagraph shall not apply to processing carried
out by public authorities in the performance of their tasks.*" Therefore
any request from a LEA based on 6(1)(f) for EEA data will be automatically
deemed as not having a legal basis.

2)LEAs who wish access to data, and where such a LEA does not have
jurisdiction then it is for them to go through the proper legal channels to
request access. As LEAs, such requests will ALWAYS be considered a public
authority exercising their interest under either  6(1)(c) , (d) or (e) as
the remaining basis for such requests:

*a) 6(1)(c)* - *processing is necessary for compliance with a legal
obligation to which the controller is subject* - legal basis will have to
be established (this related to EEA data only, however jurisdiction of both
the LEA and the CP are necessary considerations here) (recommendation 12
process is unnecessary)
*b) 6(1)(d) *- *processing is necessary in order to protect the vital
interests of the data subject or of another natural person;* again only
applicable to EEA data, but again I do urge law enforcement who are making
such access requests to consider that in order to justify 'vital interest
protection' we are looking at time sensitive matters and a very high bar,
and surely in such urgent situations LEA should be reliant on other
mechanisms that don't rely on the process of recommendation 12.
*c) 6(1)(e) Public interest - as per Art 6(3)* this interest must be based
on EU or Member State law - To be frank, in this instance properly
establish Public Interest Requests under 6(1)(e) should never have to go
through the recommendation 12 process. LEAs should be ringing the front
doorbell with such requests, and any CP should be jumping through hoops to
see to them. We also don't require ICANN to tell us to do this. If we fail
to meet such requests, censure from ICANN compliance will be the least of
our worries.

So frankly, recommendation 12 is aimed at providing process for civil
claims. I understand the apparent feeling that LEA's are 'left out in the
cold' by this; however, this could not be farther from the truth. LEAs
should be making the CPs jump through the hoops, not vice versa. And if the
LEA does not have the legal basis, or authority to make us jump through
said hoops, then the LEA should be wondering about the basis for their
request, and far more 'non-epdp' matters such as the admissibility of their
evidence and the fruits of the poison tree.

Alan


PS and optional to the extreme, but where non-EEA data may not be
'protected' by the GDPR, and we are stating that a LEA may assert their
'authority' to access that data under recommendation 12, we are encroaching
onto a very unstable ground. To be clear, CPs are not guardians of the
privacy rights of their registrant, nor am I saying should we second guess
the laws of other nations; however, I would urge the ePDP team to think of
the unintended consequences here. We do not wish to make this process
difficult, however not all LEAs are 'good' players, and a CP should be
mindful that the effect that our releases may have, to all data subjects,
regardless whether or not the GDPR or similar law applies. I would suspect
that this is something that the ALAC and the NCSG would be very supportive
of. e.g. As a registry operator, should I provide a representative of
certain Law Enforcement Authority of a certain African nation with the
redacted data of registrant who is has a TLD associated with fighting for
LGBT rights in that particular African nation? Or should we insist upon a
Subpoena from an authority who can compel me to do so - or feel free to not
respond until we approached through 'formal channels',  which the expansion
of recommendation 12 would not allow us to do? Should we make this part of
our recommendation that ICANN can see fit to compel us to answer such
requests simply because they come from a LEA? I leave this as a post script
only, speaking in a personal capacity, as this area is far too much of a
minefield, and is a huge area of global concern for us regardless of the
GDPR reach, and for a separate forum! We should ensure and be stead fast in
requiring strict legal procedures for LEA requests (which the CPs are
exceptionally willing to discuss and sort out), and therefore not allow
recommendation 12 to unnecessarily side step such a discussion.


[image: Donuts Inc.] <http://donuts.domains>
Alan Woods
Senior Compliance & Policy Manager, Donuts Inc.
------------------------------
The Victorians,
15-18 Earlsfort Terrace
Dublin 2, County Dublin
Ireland

<https://www.facebook.com/donutstlds>   <https://twitter.com/DonutsInc>
<https://www.linkedin.com/company/donuts-inc>

Please NOTE: This electronic message, including any attachments, may
include privileged, confidential and/or inside information owned by Donuts
Inc. . Any distribution or use of this communication by anyone other than
the intended recipient(s) is strictly prohibited and may be unlawful.  If
you are not the intended recipient, please notify the sender by replying to
this message and then delete it from your system. Thank you.


On Sun, Feb 10, 2019 at 8:56 PM Thomas Rickert <epdp at gdpr.ninja> wrote:

> Hi Kurt, Ashley, all,
> thanks in particular to Kurt and Ashley for their analysis and
> suggestions.
>
> To be clear, It was not my intention to rule out LEA disclosures or
> establish hurdles for those. The opposite is true: We should not give the
> impression that contracted parties would only honor disclosure requests if
> the requirements in our recommendation 12 are met even if LEA requirements
> for requesting data would be lower. It would be inappropriate for us even
> to give the impression that we would ask LEAs to give more or other data
> than they are required to by law for their disclosure requests.
>
> Let me suggest language that I hope meets Ashley’s requirements while not
> going into too much details on the legal rationales that I have offered
> during our call.
>
> "Whilst the EPDP Team is confident that the criteria enumerated in this
> recommendation work for data disclosure requests relating to civil claims,
> the EPDP Team did not yet have an opportunity work on policy for LEA
> disclosure requests. It may well be that LEA disclosure requests can be
> honored following the criteria in this recommendation, but there may be
> different criteria or processes that need to be followed depending on the
> jurisdiction of the requesting LEA, the alleged crimes involved and the
> location of the contracted party as a condition for the contracted party to
> be entitled to or be required to disclose data."
>
> We could either put this into the text of the recommendation or make it a
> footnote, but I think that a disclaimer of some sort is warranted for the
> sake of transparency with respect to the status of our recommendation and
> our work.
>
> I hope you find this helpful,
> Thomas
>
>
> Am 08.02.2019 um 17:04 schrieb Kurt Pritz <kurt at kjpritz.com>:
>
> Thanks for this additional input on Recommendation 13.  Please forgive
> these observations and consider this recommendation for closing off this
> remaining issue.
>
> During our meeting Thomas was given the floor to explain his edits. During
> that, there was the usual chat going on: first some non-substantive
> commentary, then a different discussion. Partially through Thomas’
> intervention, I shook myself out of watching the chat to listen to Thomas,
> who was making a careful, studied explanation of his addition. I kicked
> myself (figuratively) for missing part his explanation when, in a few
> months, any of us would probably give a lot to have Thomas available to
> answer questions such as these. It made we wonder how many of us were
> watching the chat instead of listening.
>
> Understanding Thomas point, I made the suggestion to the group that we
> retain it in some form (a more complete explanation of the issue) but move
> it down into the body of the recommendation as an item to be considered. At
> that point, my sense was that the team wanted to leave it first and
> foremost and I withdrew my suggestion to move it.
>
> Having said that, I understand Ashley’s comment that we don’t have a full
> handle on the effect of the GDPR sections Thomas cited on out
> recommendations.
>
> I recommend that we:
>
>    - respectfully ask Thomas to augment the issue somewhat with a couple
>    / few sentences.
>    - move that issue to the annotation describing the recommendation with
>    a notation that this issue be sorted out during the implementation
>    discussion.
>
>
> Let me know what you think.
>
> Best regards,
>
> Kurt
>
>
>
>
> At 07/02/2019 03:52 PM, Heineman, Ashley wrote:
>
> Thanks for this and hello colleagues,
>
> After further reflection on today’s discussion of Recommendation 12 and
> the new text proposed by Thomas, I believe this language should be
> deleted.   Specifically –“ “These criteria are applicable to disclosure
> requests relating to civil claims. LEA requests will be handled according
> to applicable laws.â€
>
> While I am extremely pleased with the state of the Recommendation overall,
> this new insertion has not been fully considered and I believe is
> misplaced.
>
> I understand and am sympathetic to Thomas’ concerns, but that being
> said, I believe those concerns are best addressed elsewhere. The singular
> intent of Recommendation 12 is to provide clarity around the process and
> expectations of reasonable lawful disclosure in terms of making requests.
> The recommendation attempts to ensure that expectations are set for how to
> submit requests and in what fashion those requests will be handled once
> received.  The Recommendation does NOT assume that disclosure will be made
> and, further, it isn’t even contemplated how and on what basis a decision
> for disclosing (or not) will be made. Those issues are to be dealt with in
> Phase 2 and/or otherwise in a specific access discussion.
>
> I’m thus concerned that by explicitly limiting this recommendation to
> civil requests will unfairly and unnecessarily remove the benefits of
> process clarity for LEA.
>
> In light of these concerns, I strongly recommend the deletion of this
> text.  Thomas’ legitimate concerns should then be taken up and addressed
> in our Phase 2 work.
>
> Thanks!
>
> Ashley
> 202 482 0298
>
> *From:* Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> *On Behalf Of *Caitlin
> Tubergen
> *Sent:* Thursday, February 7, 2019 3:26 PM
> *To:* gnso-epdp-team at icann.org
> *Subject:* [Gnso-epdp-team] For your review: updated recommendations 10,
> 11, 12
>
> Dear EPDP Team:
>
> Attached, please find the updated recommendations. The updates are the
> result of today’s EPDP Team discussion
>
> As always, please feel free to flag any text that you believe does not
> represent what the Team agreed to.
>
> Best regards,
>
> Marika, Berry, and Caitlin
>
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190211/34922e6c/attachment-0001.html>