Dear All,

Below, please find notes and action items from today’s call, EPDP Team Meeting #35.  The next EPDP Team meeting will be Thursday, 20 December at 1400 UTC.

Thank you.

Best regards,

Marika, Berry, and Caitlin

__

EPDP Team Call #35

Tuesday, 18 December 2018 14:00 UTC

High-Level Notes/Actions

1. EPDP Support Staff to circulate draft recommendation regarding registrar disclosure of privacy/proxy data to requestor, as developed by the team discussion during the meeting. This draft recommendation will replace the language in Section 2.6 of Appendix A.
2. EPDP Leadership to summarize the EPDP Team’s discussion of registrant consent to publication of private data and send to the mailing list for further discussion.
3. The EPDP Legal Committee will hold its first meeting tomorrow, Wednesday, 19 December at 1400 and will discuss and refine potential questions to submit for further legal guidance.

Question to ICANN

What is the rationale for the bolded wording in this Temporary Specification section: As soon as commercially reasonable, Registrar MUST provide the opportunity for the Registered Name Holder to provide its Consent to publish the additional contact information outlined in Section 2.3 of Appendix A for the Registered Name Holder.

What was the community input into this Temporary Specification section that, in each of the two cases, led to the wording, “as soon as commercially reasonable,” and “MUST“?

Notes

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

• Support Staff will be circulating language regarding geographic differentiation and policy impact analysis this week for the EPDP Team's review.

b. Other updates, if applicable

c. Announce LC Members and introduce agenda for first meeting (EDPB questions)

• First meeting will be held tomorrow (18 Dec, 1400 UTC) during the normal EPDP call time
• Members of the LC include:
• Board - Leon
• BC - Margie
• IPC - Diane
• ISPCP - Thomas
• RySG - Kristina  
• RrSG - Emily
• GAC - Laureen
• ALAC - Hadia
• EPDP Leadership - Kurt, Rafik
• The first meeting's agenda will be to review the SOW and EDPB questions to refine for ultimate review by legal counsel.
• Who decided the criteria for the legal committee?
• In following the CCWG Work Stream 2 model, the idea was only to have attorneys on the Legal Committee; however, since not all groups have attorneys, the rule is not absolute.
• EPDP Members should refrain from using colored language in their emails to the team.

   d. Review of commonly-asked Google Form questions

• Document will be sent to the Team with the notes for today.
• Please email additional questions regarding the Google Form to: gnso-epdp-lead@icann.org.

3. Continue review of list of topics for further discussion

Privacy/Proxy Services - how the P/P records appear in the public WHOIS

• If there is a privacy/proxy service, the Registrar must return the full WHOIS data. BC wanted to confirm Section 2.6 of Appendix A.
• It may make sense to add language similar to Section 2.6 of Appendix A as a policy recommendation.
• This is a good idea because if a requester jumps through hoops to ultimately receive P/P data, it will be wasted time for both the requestor and the registrar.
• PPSAI work is currently on pause. This makes sense if the service is offered by the registrar or a service offered by an affiliate of the registrar. In the event the service is independent of the registrar, the registrar could not return the underlying data. The language may need to be tightened up for situations in which a registrar is unaware that a P/P service is being used.
• The registrar can only deliver underlying information if it is aware there is underlying information.
• P/P services would be legal persons and not natural persons.
• The Team could work on the current wording, but it makes sense to solve for the majority case and not the edge case.
• The RAA includes rules for registrar’s P/P services and it applies to registrar affiliates as well.
• Not advocating for removal of this requirement, but more specific language is needed to capture non-affiliated cases.
• For reference, the RAA rules relating to privacy/proxy apply to services "offered or made available by Registrar or its Affiliates in connection with each registration" (3.4.1.5)
• Possible draft language: The EPDP recommends that in the case of a domain name registration where a Privacy/Proxy service, offered or made available by Registrar or its Affiliates in connection with a registration is used, (e.g. where data associated with a natural person is masked), Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email.
• Action support staff to capture the above language and email to the EPDP Team.
• Email from ICANN org to IPC - delay of PPSAI IRT - ICANN org believes the EPDP will address some of the issues.
• If the PPSAI work requires something from this team, OK, but this team's job should not be doing the PPSAI IRT's work.
• PPSAI situations there may be privacy customers Privacy Customer 125 could still be personal data since it is capable of identifying a person. Anonymized emails can still be personal data.
• To the extent that the EPDP team (within its charter scope) has specific guidance on the issues as they relate to PP services, that may be helpful to the PPSAI IRT when they finalize their proposed model and draft agreements.
• If the PPSAI IRT needs something specific from the EPDP Team, the burden is on them to come forward with what they need.
• The Team should not make assumptions - we may not be automatically providing the needed guidance the PPSAI IRT needs to complete its work.
• If the Team can provide guidance, or if the PPSAI IRT can provided questions to us, there should be a communication path b/w the two groups.
• We need to discuss and agree what will be on the agenda. Only a minority of members wanted to discuss P/P.

Registrant Consent to Publication – option for registrants to request to have all of their RDS data published

• It is important to allow registrants to make this decision. Registrars may not offer this if not required to, so it would be better to make this a requirement and honor the registrant's choice.
• The EPDP Team's job is to say - does the Temp Spec allow ICANN and contracted parties compliant with the GDPR? Creating a consensus policy requiring this is creating an implementation impossibility that cannot be implemented prior to 25 May.
• As an alternative, if there is a process by which a registered name holder could actively request their information be published could be OK. The default would be redaction.
• We should be able to do this, but we may not be able to do this by May 2019. Asking the GNSO to start a new PDP is pushing this too far down the road as to make it not viable at all.
• There may be mechanisms allowing for consent, but this should be MAY for both registrars and registrants.
• This should not be mandatory, could be voluntary, but getting consent to publish data on the basis of consent is not easy. While companies may already do this, they may not be doing it well or in a GDPR-compliant way.
• IPC believes this should be a must - registrars must make the option available to registrants.
• How will registries know if there is consent to publish the data, so it makes more sense to make this a "must" rather than a "may".
• If a registrant knows enough about publication of data, they can make an informed decision as to which registrar to use.
• Regarding Art. 6(1)(b) - notes taking steps prior to entering into a contract - this may be more straightforward rather than meddling with consent in Art. 8.
• If you are doing consent-based processing, you need to evidence the consent and the content of that consent comprehensively.
• For everyone on these calls, shopping around for registrars may be simple, but for the typical registrant - it is not simple.
• You need equivalent of an apple agreement to cover consent, but then you would have to deal with withdrawal of consent. We should park this issue for now. It is not for the group to figure this out as we do not have time.
• Art. 6(1)(b) - if in order to enter into a contract, the controller must process data subject's data prior to entering into the contract, that's what the language in Art. 6(1)(b) is meant to represent. Registrars should not be forced to take risks for the sake of certain people. Certain businesses may not be in a position to assume the risk.
• What if we took out the words when commercially feasible and replace it with "may".
• We are not talking about a concept involving implementation costs - providing the data that is optional to publish was the law of the land. Registrars should be required to explain to registrants what data they have the option to publish.
• There seems to be an assumption that everyone is working from the same basis of knowledge, which may not be the case with some registrars and registrants. If it not going to be a "must", we could have a "may" in the recommendations. The reference to "gun shy" was not meant to be inflammatory.
• Registrants asking for their information to be published are making this request for their own benefit - they are not doing it for the benefit of third parties. (they may be using it for marketing, advertising) Ultimately, this should be optional since this is an add-on or value-added service. This could also be captured in the Team's report.
• One of the complaint of registrars is that ICANN heaps regulations on the "good guys". While "may" could be OK, in a situation with the "bad guys", this may allow bad registrars to give another layer of obfuscation with their bad customers.
• If consent is not transferred to the registry, are we defeating the purpose?
• Does this issue become moot when RDAP is deployed?
• It is not clear why offering the option of publishing details and getting consent - why is that so difficult? It sounds straightforward.
• The risk here is getting it wrong - if there is no legal basis for publishing data, this is a risk.
• How can you withdraw consent and remove the data from the escrow provider, the registries and other relevant parties?
• The technical implementation issue is a red herring.
• The technical issues are not insurmountable here.
• "soon as commercially reasonable" is important for small registrars. It should still be a "may".
• Leadership to summarize this conversation via email.
• Support Staff to send draft language re: P/P services to the list.

Consent by the Registrant to Publish and/or Disclose for technical contact

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

   a. Confirm action items

   b. Confirm questions for ICANN Org, if any