[Gnso-epdp-team] Notes, action items from EPDP Team Meeting #31 - 4 December 2018

Tue Dec 4 22:12:58 UTC 2018

Dear EPDP Team,

Below, please find the notes and action items from today’s EPDP Team call.

Thank you.

Best regards,

Marika, Berry, and Caitlin

EPDP Team Meeting #31

Tuesday, 4 December 2018

Notes and Action Items

High-level Notes/Actions:

Action item #1: EPDP Team to review updated letter to EDPB circulated by Stephanie and provide input by next meeting - 6 December. 

Action item #2: Continue small team deliberations on ICANN - Contracted Parties controller related issues and implementation questions. 

Action item #3: Staff to set up doodle poll for small meeting to further discuss controller issues. Doodle poll to go to whole team but only those interested in joining should fill out the doodle. (Completed)

Action item #4: Staff to update this recommendation to reflect change from 'enter into' to 'develop' in first paragraph of recommendation #6 having to do with data processing agreements with data escrow providers.

Action item #5: EPDP Team to develop message to request ICANN Org to: (a) commence development of legally compliant data processing agreements with escrow providers, and (b) create agreements that indicate that data escrow providers are in a processor (rather than controller role) or provide information to the EPDP team why that should not be the case. ICANN to share this work with the EPDP Team to help inform its deliberations. 

Action item #6: EPDP Team to send message to ICANN indicating that, after discussion of ICANN-raised issues with regard to data processing agreements with Dispute Resolution Providers, that no change is required to the current Initial Report recommendation and ask for a detailed explanation if ICANN Org disagrees with that assessment. 

Action item #7: EPDP Team to review Purpose O (Research) proposed language prior to the next meeting (see item #13)

Action item #8: EPDP Team members to indicate the objective of the discussion on Whois data accuracy and how this fits within the Temporary Specification and the EPDP Team Charter? 

Notes & Action items

These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. 

1.         Roll Call & SOI Updates
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 needed. Updates are required to be shared with the EPDP Team. 

2. Welcome and Updates from EPDP Team Chair (5 minutes)

    a. Review of outstanding action items

    b. Other updates, if applicable

Webinar on public comment forum - some updates were made to the slide deck per the input from the EPDP Team. Main focus was to ensure broad understanding of the report as well as how to provide input to the public comment forum. Some questions were raised during Q & A session. Well attended with over 100 attendees. See https://community.icann.org/x/9grVBQ. 
Translations of executive summary and overview of preliminary recommendations will get posted later today on the public comment forum.
If you have not received notification re. Toronto F2F travel, please let gnso-secs know and book your travel as soon as possible. Hotel information is needed for some to be able to book travel. This information is expected to be confirmed shortly and will be shared with the EPDP Team as soon as possible (note – hotel confirmation was confirmed during the meeting). 

3. Letter to EDPB (20 minutes):

    a. Update from small team meetings (see https://mm.icann.org/pipermail/gnso-epdp-team/2018-December/001012.html)

    b. Any comments / input?

    c. Confirm next steps

Two small team meetings were held to discuss next steps in relation to EDPB communication. See email summarizing outcomes of those discussions.
Consider sending an abbreviated letter to the EDPB. Stephanie shared a proposed revised version which is more in the form of a notification. Not role of EDPB to provide legal advice. EPDB has indicated that they do not want to engage with individuals, but ICANN / ICANN community is not individuals. As such, EPDP Team should be free to ask any agreed upon questions. Any outreach would need to be in the most informed way. 
Seek further advice from outside legal counsel to answer these questions. Diane is writing a SOW, to be reviewed by ICANN. Will need to get approved by PCST. Consider using the law firm that the RDS PDP WG used. May also consider consulting with DPAs itself. SOW to be shared with the EPDP Team before it is finalized. 
Need to modify questions for this purpose. Consider working with those involved in the small team to modify these questions via email. May also need to involve alternates, if needed. Needs to come back to the full EPDP Team for finalization.  
Any work done in a smaller team will come back to the full EPDP Team for agreement / sign off. 
Why was Art 14 not referenced in letter to EDPB? Deals with personal data that has been collected that is not from data subject. Includes a number of requirements for the controller in such a situation. May need to be further considered by the EPDP Team. 

Action item #1: EPDP Team to review updated letter to EDPB circulated by Stephanie and provide input. 

4. Continue review of list of topics for further discussion (60 minutes)

    a. Continue deliberations on topics for further discussion.

        Consider items #3, #4, #5 and #6 on the list (see document attached)

Informal discussion of some attendees that were in attendance of a (separate) meeting that took place in Brussels last week re. joint-controllership (Daniel Halloran, Diane Plaut, Alan Woods). Eagerness to further explore whether a joint controller relationship exists and what the construct could/would look like if it would be determined that a joint controller relationship exists. Consider creating a small team to further this conversation. Note also a number of implementation related questions that ICANN Org has flagged. May also be a point that needs to be brought to the EDPB? Volunteers to date: Diane, Alan W., Thomas, Dan Halloran. 

Action item #2: Continue small team deliberations on controller related issues and implementation questions. 

Action item #3: Staff to set up doodle poll for small meeting to further discuss controller issues. Doodle poll to go to whole team but only those interested in joining should fill out the doodle. (Completed)

Item #3 - data agreements are complex, some are two, others are three-way agreements. ICANN Org is a beneficiary in all these arrangements. Data escrow providers differ in their views of what their role is - some are of the view that they are processors, others view themselves as controllers. Would it be possible to have a graphic that would demonstrate how the different relationships play out? ICANN Org is putting together some materials and will consider whether a graphic could be added to that. Detail in the recommendation may not be helpful here, may just need to say that relevant discussions are held, and relevant agreements put in place, without being too specific? Who is responsible for negotiating the appropriate agreement with the escrow provider? Is that ICANN or the registrar? CPs have disaster recovery in place separately, data escrow requirements are an additional layer on top required by ICANN. In certain cases this will result in duplication. ICANN holds the contract and defines the terms with escrow providers. Responsible parties need to review agreements and make sure these are GDPR compliant - that is the underlying objective of the recommendation. Is there a way to rewrite this particular recommendation so that everyone is comfortable with it? ICANN would reach agreement on key legal and technical terms and then each registry/registrar would have some opportunity to negotiate provisions that would not impact on these legal and technical terms. Legal setup may only vary in nuances? Data escrow providers are in effect processors. Would inform EPDP Team deliberations if ICANN could share a draft data processing agreement, or an addendum that could be added to the existing escrow agreements. See "1" of recommendation #6 - may need to reflect that it is not ICANN Org that is entering in an agreement with the data escrow providers. Arrangements are more complex than this recommendation seems to imply. Other parts of the recommendation may also need further considered, but no specific issues identified at this stage. Consider updating in the first paragraph 'enter into' to 'develop' to clarify that ICANN Org does not enter in these agreements. Also ask ICANN Org to already start this development and ask for analysis / development on role of data escrow providers as most are of the view that escrow providers are processors in this scenario

Action item #4: Staff to update this recommendation to reflect change from 'enter into' to 'develop' in first paragraph of recommendation #6.

Action item #5: EPDP Team to develop message to request ICANN Org to already commence development of these legally compliant data processing agreements with escrow providers and share these with the EPDP Team to help inform its deliberations. 

Question for ICANN Org: Could ICANN Org provide further details in relation to whether data escrow providers are considered independent controllers or processors?      

#4 - along same lines as comment for #3. Initial Report foresees a straightforward data processing agreement but is a more complex arrangement. Need to consider this further. Need to have arrangements in place that would give reassurances that required safeguards in place to send personal data to DPRs. Would need an appropriate agreement in place to provide those assurances. Consider changing 'data processing agreements' to 'appropriate legally compliant agreements'? Leave as is as reference to "data processing agreements" leaves option open for controller or processor agreement.
What is the implication of not changing the recommendation? Would be helpful for ICANN Org to specify what the impact is - for example, could it result in ICANN Org recommending to the Board that the recommendation would not be approved? In raising these areas for discussion, ICANN Org looking at what questions exist from an implementation perspective - for this one, it is looking at the current situation as currently no arrangements are in place, so this might require further thinking to be implemented or determine whether there are further concerns. Important to distinguish whether there is a concern with the spirit of the recommendation or certain details. Would also be helpful to provide specific recommendations for changes if the issue is with the details that would leave spirit of the recommendation in place. 
#6 - footnote 4 re. accuracy. What is the objective of the discussion and how does that fit within the Temporary Spec and the charter? Not clear how current requirements on accuracy are dealt with following Temp Spec adoption. Would be helpful to clarify if those requirements still apply. Yes, data accuracy specification in the RAA - puts the burden of accuracy on registrants and for registrars to check formatting. Challenge is that with redaction, from outside this is now opaque. Does not mean that CPs are not keeping up with these requirements – is still continuing since May 25th. What did ICANN Compliance share in relation to ARS? Not run by compliance but other part of ICANN (GDD), but compliance is responsible for addressing any issues identified. Currently ARS is on hold as it was based on publicly accessible information. Status is that ARS that it was put on hold to assess implications of that program under GDPR – ICANN Org is continuing to do this. Communication around future of ARS is expected to be published towards the end of the year or early next year. Figure out a way to carry this program forward. Note that it has been done using publicly available WHOIS data, much more limited now than previously but core part of program will remain to be in place possibly with some additional changes. Access for ICANN Org would be the question here – disclosure would only be to ICANN Org. 5.1 GDPR Accuracy – different views on what accuracy means in this context. Differing viewpoints on whether validation by controller is needed. Proponents should make the case why 5.1 would require additional validation requirements.

Action item #6: EPDP Team to review Purpose O (Research) proposed language prior to the next meeting (see item #13)

Action item #7: EPDP Team members to share with the list what the objective of the discussion on accuracy is and how this fits within the Temporary Specification and the EPDP Team Charter, as well as expected timing of this discussion? 

5. Preview of Phase 2 work items (15 minutes):

    a. Review mind map (see attached)

    b. Confirm understanding of EPDP Team on where it is on meeting requirements to commence phase 2 work.     

Deferred to Thursday’s meeting

6.      Wrap and confirm next meeting to be scheduled for Thursday 6 December 2018 at 14.00 UTC 

a.                  Confirm action items

b.                  Confirm questions for ICANN Org, if any

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20181204/2fd7fb6e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4621 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20181204/2fd7fb6e/smime-0001.p7s>