Dear EPDP Team,
Please find notes and action items from yesterday’s face-to-face session below.
Thank you.
Best regards,
Marika, Berry, and Caitlin
--
EPDP Team Meeting (1 of 2) ICANN65
25 June 2019
Action Items
All early input is due by Monday, 8 July.
EPDP Support Staff to review and incorporate input received on IP use case and distribute to the Team by end of day. (COMPLETED)
EPDP Team to review and provide feedback on updated IP use case, ideally in advance of Thursday’s meeting.
Alex Deacon and Amr Elsadr to review updated safeguard re: bulk access.
GAC reps to aim to complete draft public safety use case by Thursday, 27 June.
EPDP Team to identify in advance any questions or comments for engagement session with ICANN org to discuss next steps in relation to outreach with DPAs.
I. Early Input Phase 2
· By 21 June, input was received from RySG and RrSG.
· Support Staff created an early input review tool. The input is categorized by the various charter questions.
· The input from the BC has also been added here.
· Two different types of input were received: some input was focused on substantive responses to the charter questions, while other input focused on potential additional charter questions
· There is an obligation for the EPDP Team to respond to the early input or to specify how the input has been or will be dealt with.
Feedback from Team:
· It would be helpful if the groups who have not yet provided input could alert the Team that they do intend to provide input
· The ISPCP, IPC, NCSG, and GAC all noted their intent to submit input.
· Please submit all input by Monday, 8 July.
· Action: Please submit all early input by Monday, 8 July.
II. Example Use Case (Thomas Rickert)
· This example was designed to assist the Team in its thinking.
· Start by looking at who is asking for what, and what shall be returned?
· Rather than looking at complex legal questions, this is designed to look at real-life examples and plain language answers.
· This draft is not the final work product, but is designed to be a starting point. It is a work in progress.
· If the Team agrees on the building blocks or the component parts, it will be easier to build the UAM. Once the Team agrees on the component parts, smaller teams can work together on additional use cases
· This use case includes trademark owners, their attorneys or agents.
· Why is non-public data requested? In this example, data is requested in order to take legal action against IP law violations.
· Lawful basis - in this example, 6(1)(f) was chosen. The lawful basis can be split by the processing activity.
· General safeguards: accredited users may only request current data (no data about domain history). While there are commercial vendors that have capabilities to do boolean searches, bulk access, reverse look-ups, etc., that is likely out of scope for this group. At this time where there is no centralized system, disclosure requests must be directed at the contracted party.
· Data elements typically necessary: in data protection terms, the starting point is privacy by design and data minimization. For cybersquatting, what data does one likely need? Registrant name, organization, postal address, possibly email.
EPDP Feedback to Template:
· Re: the methodology: how narrow should each use case be? Narrow use cases are helpful for focus, but with respect to this use case - does it allow for the investigation of trademark infringement?
· This example is not necessarily about scope, but rather the template itself.
· Where is the team heading with this? While it’s useful to learn from the use case, but if the decisions discussed here are deemed to be policy, how will new cases be handled? Does a PDP need to be reconvened?
· Re: the concept of accreditation, how generalized is accreditation, and who would do it? If facebook says it has 375 trademarks and 420 agents working on this, will they be accredited as a group, or is it per request? Once a request has been granted, does the process have to be repeated? It is useful that accreditation can be withdrawn.
· It would be helpful to walk through the case from start to finish to determine what component parts are needed.
· With respect to the format, how does this feed into the purposes? The Team does need to address safeguards and accreditation - if we do this for every use case, this exercise will take a very long time.
· Re: the accreditation section - perhaps this needs to be split up by pre-disclosure and post-disclosure.
· The differences b/w the various use cases may not be that profound. While it may vary slightly, it’s unlikely to vary that much.
· While many use cases may be similar, it is important to review many use cases diligently.
· Also need to consider notification of data subject and retention periods.
· Question re: accreditation: what purpose does accreditation serve? What if a marks holder loses its mark? Similarly, what if the authority to act on behalf of a marks holder is withdrawn?
· These questions are operational details to be worked out - the accreditation may have a time limit with an option to renew, as well have a fee associated with it.
· With respect to the lawful basis - whose lawful basis are we discussing here? Is it the controller, is it the contracted party, or the requestor? Is it within this Team’s scope to discuss the lawful basis of the requestor? Isn’t it the requestor’s responsibility to define its own lawful basis?
· The concept of accreditation does not grant the requestor carte blanche access to data. It may be helpful to get legal advice on the transfer of data for the third party’s lawful purpose.
· The lawful basis can be split as needed for different processing activities.
· A user may not have the same reasons for disclosure each time. Law enforcement may have a different legal basis for different requests.
· Defining someone else’s legitimate interest is not this group’s job - it is the job of the requestor to define its legitimate interest and may have a legal basis on a specific request.
· Lawful basis is defined by processing activity and needs to be examined by processing activity.
· With respect to the feasibility of use groups - when the Team discussed the UAM, in order to make this as efficient as possible, it’s important to have categories of users. Will this group consider user groups?
· User groups are possible, but it is a difficult starting point and should not be discussed at this time.
· With respect to Box C, lawful basis, it should be specified that this is the lawful basis of the contracted party. We can add the lawful basis of the requestor; however, if we look at all of the lawful bases for requestors, that will be very difficult for public authorities.
· The existence of a user group does not imply that every request from a member of the group will be treated identically.
· It is important to include a requirement here - after having received data through this disclosure process with a time limit, we need to have a requirement of actual use of the data or an explanation there was a decision not to use the data. If the same party repeatedly requests disclosure and then not use the data for the objectives for which it is requested, that could be problematic. There should be a requirement of use/non-use and some sort of tracking of that - this should be added to the safeguards category. Safeguards and maintenance of accreditation may be very linked.
· It may not be a reasonable requirement to use or not use the data.
· General principle of data protection: one cannot hold data with the intention to process it in the future. If you request data for a particular purpose and then don’t use it for that purpose, there is no legitimacy to the request.
· It may be helpful to define the legal basis of obtaining and retaining the data. Once the purpose is fulfilled, the requestor would need to delete the data.
· For safeguards - it may be helpful to add an obligation in the safeguards to only use the data for the specified purpose.
· For the next discussion, it may be helpful to focus on safeguards - a priori accreditation safeguards, general criteria that apply to all requests across the board, then accountability safeguards.
General Safeguards
· It should be made clear that the end result should not require a legal action but also allows for investigation.
· Action: Change the title of the Use Case to: Trademark owners processing data in the establishment, exercise or defense of legal claims for trademark infringement
· Are there any proposed additional safeguards to add to the list?
· Suggestion: general principle that the requestor agrees to process the data in compliance with GDPR as a general matter. If there is sufficient legal posture to request data of one domain name, not sure why only data of one single domain name can be viewed at a time.
· Only data requested should be supplied.
· Data must be securely transmitted.
· With respect to multiple requests - if there is a particular trademark that is potentially infringed 10,000 times, there may be 10,000 requests submitted at once; however, each of those requests may be a different registrant or record, and you can really only look at them one at a time.
· With respect to the change of title - what is the difference b/w trademark infringement or cybersquatting. If cybersquatting is a form of trademark infringement, are both terms needed?
· The reference to only data of a single name - you issue one request, you get one return. There is no issue where a legal department putting in 10 domain names and getting 10 responses back.
· The purpose of the single domain point is to avoid phishing expeditions.
· There should not be restrictions in the policy language restricting implementation - we shouldn’t, for example, dictate if a registrar can employ a bulk tool
· The data has to be a domain specific request.
· RDAP - if you make a query, you get a single response.
· With respect to volume limitations and slowed down response times, if one has more than one legitimate request, one should be able to make those requests. Volume limitations cannot be automatically imposed if there is a legitimate reason why the request is made. Captchas are not applicable in the RDAP context.
· Volume limitations: this bullet point should be stricken. In its place, something like: "Each query must have a legitimate purpose expressed."
· The individualized nature of the request is not an implementation issue; it is a policy issue.
· Some registrars prefer multiple domain names in one request rather than each domain name separately.
· “Accredited parties are not provided with bulk access” - seems to be a repetitive point
· It’s important to specify who the general safeguards are applicable to. There are general 5(1)(f) safeguards and other safeguards.
· The question to answer - is it important to include everything required under GDPR, or can it just note that GDPR compliance is required.
· With respect to captchas, it may not just be RDAP that is used.
· If this team tries to capture every possible case in this system, this EPDP will not end.
· There may be unique cases where a requestor works directly with the contracted party outside of this system.
· This team is building a policy, not an access system - the policy would apply to everything. In terms of bulk access, if the largest part of the request is all identical and the only difference is the domain name, why would we want the contracted party to receive thousands of requests?
· With respect to the bulk access bullet, the bullet above is not identical - they do not cancel each other out.
· The reason the bullet felt redundant is b/c you request data from a name and then receive the data back for one name. The line regarding viewing is orthogonal from requesting.
· Procedures and safeguards are being conflated here.
· Group editing on the fly isn’t always effective - it may be better to do this kind of work in a small group.
· Should this document include general safeguards that apply to everyone and everything, or just this use case?
· Registrants should also have the right to transparency about their personal data being processed
· Search functions and reverse lookups may be legal.
· Disclosure requests may not go directly to the contracted party, particularly if contracted parties are trying to lower/diminish their liability.
· Contracted parties cannot pass their liability on to someone else since they are the entities requesting the data.
· Building technical safeguards can protect against rogue players that may abuse the system.
· There is a decentralized system at the moment. This system cannot be structured so that you can go to any registrar and say - go get the info for this domain name that sits at another registrar.
· What is the problem the Team is trying to address with the safeguard of only directing the request at the contracted party.
· At the moment, there is not a centralized system. In the absence of the centralized system, the burden is with the requestor to determine where the domain name is and contact the appropriate party.
· The language regarding volume limitations may be appropriate here, but not in every case.
· There needs to be protections on both sides - there could be a situation where a registrar abuses the system as well.
PWC Presentation
Please refer to presentation.
Michael Palage/Brian Beckham Presentation
Please refer to presentation.
General Safeguards
Re: safeguards for the presentations we just heard, first we need a risk assessment.
What was the purpose of the presentations?
The presentations were given to help stimulate the group’s thinking about how to approach the policy questions
Will there be more presentations?
None are scheduled at this time.
If other third parties would like to provide presentations, it would be preferable to have pre-recorded presentations.
With respect to future proofing the policy, maybe “look-up or search capabilities should be limited to the capabilities of RDAP”.
Disagree with the above comment b/c RDAP does have some of those features
The WHOIS system never had those functions or features; those were third party data aggregators. We should start with where we went dark with WHOIS.
Rather than adding everything that is not allowed, why not clearly state what IS allowed?
Bulk access is not defined - note that Alex and Amr will work together on modified language. Commitment to review this bullet before Thursday.
Support staff to take into account the comments heard today and circulate an updated version of the draft by the end of the day.
Accreditation of User Groups
Rec. 18 should be added in here
Code of Conduct is a defined concept in GDPR
Just because a code of conduct has not been done before does not mean it should discourage us from developing one
A code of conduct to give to the authorities for review would help avoid sanctions if parties play by those rules
The term code of conduct is referenced in the RAA and we need to make sure when referencing this, a distinction is made.
Any other business
There is a group who is actively lobbying for legislation to essentially reverse the work being done here
This group should protect its charter and ensure no participants here are participating in this legislative effort.
