Page History

Notes/ Action Items

EPDP Phase 2 - Meeting #37

Proposed Agenda

Thursday, 19 December 2019 at 14.00 UTC

1. Roll Call & SOI Updates (5 minutes)

2. Confirmation of agenda (Chair)

3. Welcome and housekeeping issues (Chair) (5 minutes)

1. Update of F2F

• There are seven members who have not yet booked their travel – please do so ASAP
• Day 0 will include a welcome cocktail
• There will be a Team dinner on Day 1
• Meetings will end at 14:30 on Day 3 – please plan on staying the entire time
  1. Legal committee update
• Questions approved by the legal committee will shortly be sent to the plenary team
• Summaries of the Phase 2 memos will shortly be sent to the plenary team
  1. Status of building blocks
• Two communications went out yesterday – one regarding a response from the Belgian DPA, and one regarding ICANN’s initial response to financial sustainability
• Is ICANN expecting an additional communication on the Strawberry letter?
• The letter is an invitation to provide more information. There will likely be another informal meeting b/w ICANN org and the Belgian DPA before additional formal guidance is received
• Irrespective of the model the Team ends up recommending for the SSAD, the roles of controllers and processors are based on factual assessments of how data is processed. This is helpful input as the Team continues its work.
• The Belgian DPA seems to think this is a joint controller relationship – the weakness of the original strawberry memo is it did not lay out the roles and responsibilities
• It is not the role of supervisory authority…this is a direct statement to stop nagging the DPAs and design a system that complies with the law
• Thought the point of the letter is to clarify what the law says
• Would ICANN org like feedback from the EPDP Team before it meets with the Belgian DPA?

4. Preliminary Rec - User Groups

1. Review updated language and comments / suggestions provided by deadline
2. Feedback from EPDP Team

• Include internet service providers and abuse providers in the non-exhaustive list
• The examples are to assist the Team in accreditors
• Add civil law enforcement, criminal law enforcement, consumer protection, and data protection authorities.
• The first two sentences give the flexibility to the accreditation authority to create user categories/groups. That language seems more flexible and a better way forward.
• Conceptual problems in the list: the level of overlap of the categories is problematic For example, is Google a social media company or a search engine? The most important categorical distinctions is b/w LEA and non-LEA
• Including a short list of examples is helpful and gives comfort to certain stakeholder groups
• Overlapping categories is OK. The category will mean something as far as what kind of authorization you would have
• May be helpful to include implementation advice to identify groups
• Just b/c you are not on a list does not mean by you cannot make a request
• Proposal to delete user group BB and add a paragraph into the accreditation BB re: user groups
• This is a helpful solution
• For the first reading of the Initial Report, Support Staff to formulate an additional line re: user groups
• There should be transparency into this process – how many entities applied for accreditation – how many were accepted, how many were rejected, etc.

     3. Confirm next steps

5. Preliminary Rec – Acceptable Use Policy

1. Review comments / suggestions provided by the deadline in relation to edits discussed previously

• There were several language suggestions made, but the group thought it may not be able to make this decision until the authorization provider is known
• On i, this is the last version the group landed on suggested by Thomas
  1. Feedback from EPDP Team
• The NCSG comment, if agreed to, will need to be applied in two other places
• Proposal to add the word “some” in front of investigations
• H would read that EPDP Team has acknowledged that some legal … to keep the request confidential from data subject
• Increased risk needs to be defined – there is specific language in GDPR
• Add an asterisk and footnote with the provision of the GDPR
• Does legal investigation refer to law enforcement? This may need slightly different wording.
• There should be a defined process with a presumption of confidentiality
• The safest way to do this is to use subpoenas, warrants, etc. – a due process mechanism is the best way to handle this
• This language is a recognition that there may be a need for confidentiality and this could be a dialogue b/w the LEA and the controller/authorization provider
• There is a difference b/w proactively notifying a data subject about a request. This is more about certain requests being omitted from a report a data subject may request
• The assumption from the strawberry team is in order to fully shed the liability is that the CP is blind to the request. How does the CP communicate that a request is confidential if the CP is blind to the request
• On h – ask James and Chris and staff to do some back and forth to finetune this proposal and include it in the initial report
• Staff, based on the conversation, and initial James and Chris proposal – see how to modify point h – share with J and C and then share with team in the next version of the Initial Report

      2. Confirm next steps

6. Preliminary Rec - Purposes

1. Review comments / suggestions provided by deadline
2. Feedback from EPDP Team

• Providing clarity on purposes is important
• This is article 22, and we have been warned against profiling. Putting something on paper would be to ignore legal advice previously received.
• These are not purposes – these are rationales the requestor is making. Uncomfortable with the second half of the paragraph
• For operational reasons, an enumerated list would be helpful
• BC believes a list of third-party purposes is necessary – if there is no specificity in the policy, BC would have trouble supporting the entire policy – the Team should look to ways to reduce liability
• Legal rights of the requestor is misleading – legal reasons and/or obligations may be better
• Helpful to identify common elements and automate as much as possible
• From a legal perspective, this may incentivize requestors to sandwich questionable requests with legitimate requests
• Adding purposes does not equate to carte blanche access to data
• The above is OK if purposes is changed to “justification for disclosure”

       3. Confirm next steps

7. Homework over the holiday period

1. Staff to publish updated version of draft Initial Report by 24 December at the latest with updates to the building blocks as discussed to date
2. EPDP Team to flag any issues / concerns by 7 January at the latest:
   • please do not reopen previously closed discussions unless there is new information to consider.
   • If you have concerns about certain section, please provide alternative language to address your concern but also factoring in other perspectives expressed to date.
   • Please do not redline but provide language suggestions in the form of comments so that these can be reviewed by all before being applied.
   • Minor edits (grammar, style) can be sent to the staff support team directly.

8. Wrap and confirm next EPDP Team meeting (5 minutes):

1. Thursday 9 January 2020 at 14.00 UTC
2. Confirm action items
3. Confirm questions for ICANN Org, if any