Notes/ Action Items
Action Items
- EPDP Team members to review the cost estimate and provide advance questions via the email list by COB Monday, 11 May.=
li>
- EPDP Team members who have not completed their homework on Recommenda=
tion 7 and 16 (automation) and Recommendations not considered by COB Tu=
esday, 12 May.
- EPDP Team to review and provide input on the discussion table for Recommendation 4<=
/a> (third party justification) and Recommendation 14 (retention) by COB Tuesday, 1=
1 May.
- Support Staff to update Recommendation 6 based on today=E2=80=99s discu=
ssion and post for EPDP Team review by COB Monday, 11 May.
EPDP Phase 2 - Meeting #56
Proposed Agenda
Thursday 7 May 2020 at 14.00 UTC
- Roll Call & SOI Updates (5 minutes)
2. Confirmation of agenda (Chair)
3. Welcome and housekeeping issues (Chair) (5 minutes)
a. Update on SSAD model cost estimate and schedule for review
- EPDP Team to submit questions/comments in advance of Tuesday=E2=80=99s =
meeting via the list
- Xavier will present a high-level overview of the cost estimate
- The meeting is not mandatory; however, we recommend one member from eac=
h represented group attends
- The nature of the document is to inform the debate- we should not argue=
over suggested numbers, as these are estimates
b. Update on public comment proceedings for Initial Report and Addendum<=
/p>
- Both public comment proceedings (Phase 2 Initial Report and Addendum) h=
ave closed.
- For the initial report, only two additional comments were received and =
they have been incorporated into the corresponding PCRTs and discussion doc=
uments.
- On the wiki page, rows highlighted in green represent the comments the =
Team has reviewed
- For the public comment on the addendum report, staff is working on the =
compilation. We have received 21 total substantive submissions: 7 groups (2=
did not submit), 12 organizations, and two individuals.
- The addendum PCRTs will be posted to the public comment wiki page =E2=
=80=93 Support Staff expects to complete these by tomorrow.
- Regarding the calendar, if we do not count this meeting, there are seve=
n meetings remaining. Seven meetings will not provide the group enough time=
to review all of the comments and suggestions on the remaining outstanding=
recommendations. Therefore, beginning the week of 18 May, we begin two mee=
tings per week (Tuesday/Thursday) so that we can review all comments by 30 =
June.
4. Recommendation #6 =E2=80=93 CP Authorization (45 minutes)
a. Review remaining discussion items (6-22) gleaned from input pro=
vided on rec=
ommendation #6 discussion table (see discussion items attached)
- Question 5 =E2=80=93 can further details be provided regarding the defi=
nition of necessary?
- The reason this language is provided is to reflect the concept of data =
minimization
- This definition comes from the opinion of Bird & Bird
- How this applies to compliance is an implementation issue
- Answer to ICANN org is review the B&B memo to put the definition in=
a broader context
- Should not be handing off the data minimization to the IRT
- Questions 6 =E2=80=93 8
- Data protection authorities should not be a referral mechanism =E2=80=
=93 that is not their role
- It is not the role of DPAs to get involved in these requests, but there=
should be an appeals mechanism built into the policy for wrongful denials<=
/li>
- There are other examples of appeal mechanisms in ICANN in the new gTLD =
process or the UDRP that we could look to =E2=80=93 ICANN should create a l=
ightweight mechanism in addition to what already exists
- Who is the decider? In the hybrid model, it is the CP. However, the def=
inition of necessary is in the policy so that everyone has an understanding=
of what can be disclosed.
- Concern over who can compel disclosure =E2=80=93 there would have to be=
significant assurances that the panel would have sufficient expertise in t=
he relevant jurisdictions
- In this situation, who would be held liable for the release of data?
- Understand there is a desire to get a second opinion, the second opinio=
n does not exist b/c where would the liability exist? Unlikely that a contr=
oller would agree to this
- Not all contracted parties will be subject to GDPR, however the policy =
will give the ability to all CPs whether the law warrants it or not to deny=
these requests. Sympathetic to concerns raised here, in many cases =E2=80=
=93 the law will not justify the decision that is made.
- Not all registrars are going to comply =E2=80=93 so there should be a d=
ata trust or advisory board that will hear the cases and dismiss the spurio=
us ones and act on the bad actors. GDD cannot take this on. The problem is =
that if you set up a mechanism, the liability would pass to ICANN as co-con=
troller for establishing the mechanism.
- Support the idea for an advisory panel =E2=80=93 if a CP has a pattern =
of cases found against them, this could feed into a compliance inquiry
- Planning to build a secure logging mechanism for the SSAD =E2=80=93 if =
there is a controller that has an usually high rate of rejecting requests t=
hat are well-formed, that is data to be fed to an advisory panel for system=
ic offenders
- This is not an appeals mechanism but a request for reconsideration mech=
anism to give the CP a notice that it may not have handled the balancing te=
st properly. We have to look at what the legal basis for the disclosure is.=
The vast majority of disclosures will be based on 6(1)(f) =E2=80=93 the qu=
estion is how can you force someone to do that they are entitled but not le=
gally obliged to do? We need to have contractual language whereby CPs who s=
ystemically do not apply the requirements properly, ICANN compliance can sa=
nction them. Where the discretion is recognized is an appropriate fashion, =
the disclosure decision needs to rest with the contracted party.
- Courts are available here, but would a court in the appropriate jurisdi=
ction hear the case in a timely manner? Since the decision rests on the CP =
and they are not obliged under the GDPR, then it must be contractual langua=
ge that CPs are obliged to release the data unless there is an overriding r=
eason why they cannot
- It is possible that some registrars may routinely reject or accept ever=
y disclosure request. Based on the way some individuals used WHOIS in the p=
ast, there may be hundreds or thousands of requests per day. The idea that =
every discrete request will be subject to reconsideration will not scale. T=
here should be a way to deal with patterns of rejection. Appeals and sancti=
ons need to be considered at a much higher level. If requestors are entitle=
d to this, data subjects must also be entitled to this.
- If there is a cost associated with reconsideration, this will likely no=
t be abused. Reconsideration cannot only go back to the CP b/c a reconsider=
ation will not change the original determination. Support an advisory panel=
.
- Could the mechanism take care of systemic issues?
- There is merit to exploring higher level appeals rather than a case-by-=
case basis
- Supportive of requestors going back to CP on their balancing test =E2=
=80=93 keeping systemic abuse in check is important in any process =E2=80=
=93 do, however, have concerns if a CP says they will say no to every reque=
st. Phase 1 requires a balancing test =E2=80=93 if they do not do this, the=
CP is not following the consensus policy.
- There should be a separate lane for systemic issues and the occasional =
one-off when the requestor would like a second look
- In response to Q8, it=E2=80=99s important to consider how the requestor=
will communicate with the CP =E2=80=93 whether it=E2=80=99s a request for =
additional information, or how the information is delivered back to the req=
uestor
- This is a pitfall the Team has overlooked =E2=80=93 do not think the CP=
can just casually fire off any sort of disclosure information in an email =
back to a requestor. Consider whether there is an in-band response where th=
e SSAD relays a response to the requestor in a secure fashion, or if there =
is an out of band response. Need to figure this out and consider the operat=
ional time required to make this happen.
- Initial Report suggests that disclosed data should be sent to requestor=
in a secure manner. Here, the question is if additional information is nee=
ded to make the determination =E2=80=93 how should this work?
- When the CGM receives the request and passes it to the CP, it opens a t=
icket for that. It does makes sense that if the CP needs further informatio=
n, it goes through the CGM for that information. If that additional informa=
tion that is relayed to the contracted party contains personal information,=
the solution for that would be encryption.
- There should be a feedback loop for trackability and evidence that ther=
e has been communication =E2=80=93 it should go through the central system,=
and encryption should be employed. Central Gateway would make an RDAP requ=
est with a password.
- The Team is getting a bit technical for what we=E2=80=99ve been asked t=
o do here.
- Response to Question 9:
- This calling out of a specific interest is ill-advised.
- This is a common reason for denial of requests, which is why this text =
was added. This language is verbatim from PPSAI =E2=80=93 this is important=
for IPC.
- The argument for taking this out is that one particular type of request=
is being singled out.
- This is a limitation on the CP =E2=80=93 you are giving a special dispe=
nsation to one group. This is a perfectly fine example to deny a disclosure=
request.
- The word =E2=80=9Csolely=E2=80=9D is meaningful here. Object to taking =
this clause out.
- The concern raised earlier deals with a malformed request, not a reject=
ion based on IP infringement
- If the SSAD is a shortcut to avoid legal process, then it should say so=
.
- =E2=80=9Cnor can approval or refusal=E2=80=9D
- Adding approval does not work here. If you want to reject requests just=
because they relate to content on the website, there is a big problem here=
. Many CPs may want to automate the request solely based on IP infringement=
on a website.
- If groups do want automated disclosure if there is alleged intellectual=
property infringement =E2=80=93 refusing is unjust for IP infringement, bu=
t approval is also unjust in this instance. If this cannot be accepted, thi=
s is disincentivizing other groups from approving the original language.
- The =E2=80=9Cor approval=E2=80=9D may be misconstrued to prevent automa=
tion of these cases. If we add a footnote that could help. If approval is s=
olely based on IP allegation, what else would be required? We have spent a =
year discussing what would be required, like accreditation, lawful basis, e=
tc. That is what makes the additional language extraneous.
- If you have gotten through the gateway, provided proof of your trademar=
k and provided an allegation of infringement =E2=80=93 that does not take i=
nto account that evidence would have already been provided to support the r=
equest. Maybe add [without adequate supporting documentation]
- Add =E2=80=9Cdisposition of the request=E2=80=9D instead of =E2=80=9Cre=
fusal=E2=80=9D
- Question 10 response
- Phase 1 recommendation on legal v. natural is about the public system d=
atabase, it is not about what is disclosed here. The proposed language shou=
ld remain.
- Concern here =E2=80=93 if we were talking about only GDPR, this might m=
ake sense, but there are other privacy laws out there and there are some ju=
risdictions that do not provide legal entities with the same protections an=
d rights as natural individuals.
- Could add a sentence about unless expressly prohibited by applicable la=
w
- There are some human rights implications are not considered applicable =
law. May data protection laws that have been passed are not enforced.
- There may be a case where non-personal information is redacted as a mat=
ter of course, and it does need to be requested. What we are seeking here i=
s some certainty that if you know for a fact that there is non-personal dat=
a, it will be disclosed.
- Is there anyone who cannot live with the text on the screen?
Do not agree with the term =E2=80=9Cexpressly=E2=80=9D and do not think =
=E2=80=9Capplicable law=E2=80=9D protects important interests. Unless expre=
ssly prohibited by applicable law is too high a bar.
- We have been told the scope of the PDP is limited to GDPR, but we widen=
ed that to include applicable law, and now are widening it further.
- Suggestion to add: Human Rights implications must be taken into account=
when making a decision on disclosure =E2=80=93 perhaps this should go in t=
he balancing test section.
- Maybe there is a way to create a flag on a registration for a human rig=
hts organization
- Support Staff to review and incorporate Stephanie=E2=80=99s suggestion,=
if possible
b. Confirm next steps
- It is imperative for groups to do their homework.
5. Recommendation #7 Authorization Automated & Recommendation #16 Au=
tomation
a. Review =E2=80=98cannot live with=E2=80=99 items identified (see updated recommend=
ations)
b. Confirm next steps
6. Recommendations not considered by EPDP
a. Review discussion items gleaned from input provided on recommendations not consid=
ered by EPDP
b. Confirm next steps
7. Wrap and confirm next EPDP Team meeting (5 minutes):
a. Thursday 15 May at 14.00 UTC. Topic to be addressed: Acceptable Use, =
Query Policy, Terms of use, Data Retention
b. Confirm action items
c. Confirm questions for ICANN Org, if any