Notes/ Action Items
High-level Notes/Actions:
- Leadership will look into options for training on GDPR Training and rep=
ort back to the EPDP Team.
- EPDP Team encouraged to provide input on proposed approach in relation =
to triage report as outlined .
- EPDP Team encouraged to review Issue Categorization and proposed Projec=
t plan.
- The Leadership / Support team will revise the framework for considering=
data processing to:
- accommodate additional forms of LEA-type requests for data, e.g., publi=
c authorities
- clarify the role of ICANN in the eco-system
- clearly differentiate between the purposes of collecting data vs disclo=
sing data to third parties
- differentiate (=E2=80=9Cun-conflate=E2=80=9D?) the role of ICANN and co=
ntracted parties in the processing of data
- clearly layout how disclosure of data to third parties is governed thro=
ugh GDPR compliance
- Contracted parties are to examine the purposes enumerated in the Tempor=
ary Specification (=C2=A7=C2=A7 4.4.1, 4.4.3-4.4.7; 4.11-4.12) and recommen=
d changes
- All are asked to consider the broad wording in section 4.4.8 of the Tem=
porary Specification and recommend detailed purposes so that data sets can =
be deduced from those purposes
Questions for ICANN Org from the EPDP Team:
None
All Action items:
Action item #1: EPDP Team to share recommendations for =
whom or which organization should be considered to provide GDPR training to=
the EPDP Team.
Action item #2: EPDP Team to provide input on path forw=
ard for triage report on the mailing list.
Action item #3: EPDP Team to review Issue Categorizatio=
n and proposed Project Plan and provide feedback.
Action item #4: Staff to review whether any other polic=
ies would need to be called out under Registrar-Registry-ICANN Contract Pur=
poses, in addition to dispute resolution services.
Notes & Action items
These high-level notes are designed to help the EPDP Team navigate t=
hrough the content of the call and are not meant as a substitute for the tr=
anscript and/or recording. The MP3, transcript, and chat are provided separ=
ately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ=
em>.
1. Roll Call & SOI Updates (2 min)
- Attendance will be taken from Adobe Connect
- Remember to mute your microphones when not speaking and state your name=
before speaking for transcription purposes.
- Please remember to review your SOIs on a regular basis and update as ne=
eded. Updates are required to be shared with the EPDP Team.
2. Welcome and Updates from EPDP Team Chair (3 min)
- Please take note of today's agenda - pretty full, but main objective is=
to start deliberations on 4.4
- Request for GDPR training from RySG - support expressed from many. Lead=
ership team will work on options to provide a training that would be provid=
ed in addition to the regular Tuesday / Thursday meeting.
Action item #1: EPDP Team to share recommendations for =
whom or which organization should be considered to provide GDPR training to=
the EPDP Team.
3. Reconcile input received on Triage Report, if needed, and confirm rep=
ort for submission to the GNSO Council (5-10 min)
- Comments submitted by BC, IPC, RySG, RrSG and Milton (see https://community.ican=
n.org/x/jxBpBQ)
- Comments focused on:
- Reinforcement that comments made and recorded in this report are not bi=
nding, limiting or prejudicial on any party
- Some important points were missed and should have been included
- Correction of legal or other terminology
- Form of the issue
- Question
- Some say =E2=80=9CA=E2=80=9D and others say =E2=80=9Cnot A=E2=80=9D
- Some advocacy
- Policy vs specification
- Options going forward: one more draft accepting substantive points from=
above, or, submit color-coded matrix (and comments) only, use comment summ=
aries to guide substantive discussion.
- Consensus policy can include specification so not necessarily correct t=
hat GNSO Policy Recommendations cannot affect specifiations. But what is th=
e difference between a policy and a specification? From a contracted party =
perspective, both are enforceable by Compliance.
- Data elements redaction - should positions on current redaction be reco=
rded in the triage report? Maybe better positioned for the substantive disc=
ussion that follows?
- Important to get triage report done so EPDP Team can move on to substan=
ce.
Action item #2: EPDP Team to provide input on path forw=
ard for triage report on the mailing list.
4. Review of project plan (10 min) (see also section category allocation=
attached)
- See issue categorization table shared prior to the meeting - divided in=
to four sections 1) Sections affected by EDPB, 2) Sections where the Team i=
ndicated that amendment is desirable (2a - sections where change is require=
d to bring the section to compliance with GDPR, 2b) sections requiring less=
attention as issues are not expected to impact compliance with GDPR, 3) Se=
ctions related to existing policies / procedures, 4) background, rationale,=
justification / admin.
- This categorization has inspired the proposed project plan for how issu=
es are expected to be considered throughout the remaining meetings.
- See project plan.
- Will it be possible to keep this level of abstraction as there is inter=
connectivity between topics - for example what is the data collected for, f=
or what legal basis and agree on certain data subjects being required for c=
ertain purposes and take those through the whole lifecycle of the data.
- Update should be made to reflect that 4.4. is purposes for collection, =
not access. Need to focus on how purposes are related to collection, storag=
e and disclosure as they relate to ICANN's mission.
Action item #3: EPDP Team to review Issue Categorizatio=
n and proposed Project Plan and provide feedback.
5. Touch base on comments received on & review status of: (10-=
20 min)
A. Appendix D =E2=80=93 Uniform Rapid Suspension (see discussion summary=
index (DSI) at https://community.icann.org/x/ExxpBQ)
B. Appendix E =E2=80=93 Uniform Domain Name Resolution Dispute Policy (s=
ee DSI at https://community.icann.org/x/ExxpBQ)
C. Appendix G: Supplemental Procedures to the Transfer Policy (see DSI a=
t https:/=
/community.icann.org/x/ExxpBQ)
- No comments / input received to date
- Leadership team to consider how to encourage input on how these appendi=
xes may need to be updated, if needed
6. Commence deliberations for section 4.4 =E2=80=93 Lawfulness and Purpo=
se of Processing gTLD Registration Data (see DSI at https://community.icann.org/x/Ex=
xpBQ) (50 min)
- See slides distributed and discussed during the meeting (https://community.icann.org/downloa=
d/attachments/90773587/EPDP%20Team%20Meeting%2028%20August%202018%20Final.p=
df?version=3D1&modificationDate=3D1535459741597&api=3Dv2)  =
;
- Take particular note of the EDPB advice: There are processing activitie=
s determined by ICANN, for which ICANN, the registrars and registries, requ=
ire their own legal basis and then there are processing activities determin=
ed by third parties, which require their own legal basis and purpose. ICANN=
should take care not to conflate its own purposes with the interests of th=
ird parties. Data legitimately collected by ICANN, registrars and registrie=
s would not categorically exclude the subsequent disclosure of personal dat=
a to third parties for their own (legitimate) interests and purposes. Perso=
nal data disclosure can be made for the purposes of the legitimate interest=
s third parties, provided that those interests are not overridden by the in=
terests or fundamental rights and freedoms of the data subject, i.e., discl=
osure is proportionate and limited to that which is necessary and the other=
requirements of the GDPR are met.
- See slide 19 - purposes limited to the data necessary to provide servic=
es bargained for and required by contract, uses necessary to provide servic=
es bargained for and required by policy or contract. However there may be o=
ther legitimate purposes for which this data may be accessed for example by=
LEA or for consumer protection, investigation of cybercrime, DNS abuse, in=
tellectual property protection, contract compliance.
- Should be clear that ICANN does not determine the data to be collected =
alone, especially if Ry and Rr are considered joint controllers.
- Overarching concern of the GAC is that there is only reference to the L=
EA and not references other public authorities and their obligation to carr=
y out their tasks. Also need to clarify whether this also includes cross-ju=
risdictional requests, but with necessary safeguards on how these are to be=
handled.
- Is this meant to be inclusive or are some purposes missing from slide 1=
9? Performance of contract, consent do not seem to be covered, for example.=
UDRP is an example of a dispute resolution mechanism that is required by c=
ontract and as such, does it need to be subject to the balancing act?
- Registars also collect information for its own purposes, on behalf of t=
he account holder, such as invoicing information. Does this need to be cont=
rolled by ICANN? ICANN's role should focus on domain name registrations and=
the agreements it has with contracted parties. Need to be clear and look a=
t the contractual relationships, these can also govern third party interest=
s. Need to look at what data needs to be collected to fulfil contractual ob=
ligations and then review how this data can also be accessed for legitimate=
third party interests.
- Need to bring in ICANN's purposes - why does ICANN require collection o=
f data of CPs? Is done through the contract making contracted parties joint=
controllers. Third party legitimate interests are different from this - it=
is asking this data from Rr, not a legitimate purpose of Rr.
- By whom are purposes pursued - see slide 20.
- Slide 21 - proposed categorization of purposes (Registrar-Registry-ICAN=
N Contract Purposes / Third-Party Purposes). Consider whether the breakdown=
should follow the GDPR (6.1(b), 6.1.(f), 6.1.(a)).
- Possible path forward for Registrar-Registry-ICANN Contract Purposes - =
see slide 22. CP input needed - are there additional legitimate reasons why=
contracted parties collect data from registrants? Should these purposes be=
re-grouped to better capture their relevance, list and consolidate data ne=
cessary to support all purposes?
- Possible path forward for third party purposes - see slide 23. Are the =
purposes enumerated here valid and legitimate? Do those purposes have a cor=
responding legal basis? If there are instances where personal data can be m=
ade available to third parties under these conditions, then we can retain t=
he purpose in the Specification; Describe the data elements required.
- Should ICANN Contractual Compliance move to Registar-Registry-ICANN Con=
tract Purposes.
- Registrars collect data for their business purposes that are well out o=
f the ambit of ICANN's control, including the MS process. Need to kee=
p in mind that distinction. Should make a clear demarcation of what data is=
collected and for what purposes it is collected as registration data in th=
e gTLD world and what data the registrars process for their own purposes. O=
nly the former shall be governed and enforced by ICANN.
- What is the purpose of a domain name registration? Start at the basics.=
This maybe too complex to meet the deadlines that are in place? Most of th=
e purposes outlined on slide 22, apart from 4.4.12 seem to be directly rela=
ted to domain name registration.
- Need to also consider whether there are other means to fulfil the needs=
identified. For example, for payment and invoicing there may be other ways=
in which contractual obligations are fulfilled. May be taking on too much.=
Should focus on essential elements of the temporary specification.
- Isn=E2=80=99t that circular: =E2=80=9Cit=E2=80=99s in our contract, the=
refore it must be legal because the law allows for service of a contract"=
li>
- Consider list of purposes and data elements, outlining processing steps=
. For example, excel sheet with all the data elements collected by the regi=
strar, look at travel from that data from registrar to registry for perform=
ance to the contract, what on the basis of a legitimate interest, what on t=
he basis of consent? That may focus on a sub-set of data elements that is c=
ollected by registrars. Then follow that for EBERO, escrow, ICANN, etc. See=
also https://www.=
icann.org/resources/pages/gtld-registration-dataflow-matrix-2017-07-24-en [=
icann.org] which could serve as a potential basis.
- Consider adding =E2=80=98for the compliance with ICANN policies=E2=80=
=99 to slide 22. Some may not expressly listed here, so consider making it =
a stand-alone item. Note that any policies would need to be compliant with =
GDPR and a separate data protection impact assessment may be needed.
- Concern about including purposes that go beyond ICANN=E2=80=99s mission=
, for example 4.4.8 and 4.4.9. Some noted that it is ICANN=E2=80=99s respon=
sibility to make sure the DNS works and can be trusted. Should this be a ra=
tionale that is included as it is the basis for third party access?
- If data is collected for the sole purpose of maintaining the registrati=
on and compliance with ICANN policies, isn=E2=80=99t third party access for=
a legitimate purpose not overcome by the rights of the individual, accepta=
ble and consistent with ICANN=E2=80=99s mission? That is not disputed, but =
making third party purposes part of ICANN=E2=80=99s purposes is the concern=
as that could broaden what is collected. But focus is on purposes for coll=
ection that would focus on ICANN=E2=80=99s purposes so there would not be a=
risk that data collected is expanded as that cannot be done on the basis o=
f a third party legitimate purpose. Third party purposes do not include col=
lection.
- Issue is with the reference to =E2=80=98framework=E2=80=99 without it b=
eing defined anywhere (in 4.4.8 and 4.4.9). Framework may be further addres=
sed in the access discussion? Could be read as ready and available to suppo=
rt decisions that are made in the EPDP team?
- Can an agreement be written up that data collected for domain name regi=
stration purposes can then be made available to third parties under certain=
conditions? Could ask third parties to flesh out which data elements would=
be needed for those third party access?
- Should consider how 4.2 and 4.3 fit with this?
Action item #4: Staff to review whether any other polic=
ies would need to be called out under Registrar-Registry-ICANN Contract Pur=
poses, in addition to dispute resolution services.