Action Items

1. EPDP Team members to review and provide edits to the registrar-proposed questions to ICANN org to by Tuesday, 1 October.

2. Support Staff to edit the accreditation building block in accordance with materials received and the discussion during today’s meeting by Monday, 7 October.

3. Support Staff to edit the retention building block in light of today’s discussion by Tuesday, 1 October. EPDP Team members to review edited language and provide suggested updates (if any) by Monday, 7 October.

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.

EPDP Phase 2 - Meeting #21

Proposed Agenda

Thursday, 26 September 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)

a. RrSG proposed questions for ICANN Org (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-September/002504.html): Does ICANN have a clear preference on whether or not it will:

· Field these requests for non-public data

· Maintain its own RDS replica database

· Make a/the determination of the validity of the request

· Assume responsibility for this decision, in any scenario where ICANN doesn’t hold the data directly and must require a Contracted Party to respond to the Requestor (even if the Contracted Party disputes ICANN’s determination).

EPDP Team Feedback: 

• On 20 September, Registrars sent a message to the list re: questions for ICANN org liaisons.
• With respect to James’ message, should this question be funneled through ICANN org liaisons, or should it go directly to the Board?
• The preferred timing would be to receive input from the Board or ICANN liaisons before ICANN66
• In terms of the recipient, if the questions are directed to the ICANN Board, the Board liaisons can relay the questions to the Board.
• Are EPDP Team Members allowed to provide feedback on this? Re: point 2, the way it is currently written may imply that ICANN maintaining a replica database is the only option
• The intent was to see if ICANN would be open to a replica database, not to presuppose that would be the ultimate route, but this can be reworded to be more clear.
• Uncomfortable that ICANN’s responses may be dispositive of the policy. If ICANN says it will not be responsible, does that mean the EPDP Team cannot make recommendations where ICANN has the responsibility?
• It is useful to raise these questions to ICANN org and ICANN Board, but irrespective of the answers the EPDP Team receives, the EPDP Team needs to review the questions with caution. The ultimate application of the law will be up to the DPAs, not ICANN.
• Even if ICANN has a preference for one of the options, the assumptions in this message have not been agreed upon by the EPDP Team. For example, the EPDP Team has not agreed that a replica database is preferred. The goal of this message should be to understand ICANN’s position in the event the EPDP Team proceeds with any of the approaches in the message.
• Action: Support Staff to distribute a Google Doc with James’ proposed text so the Team can finalize the questions during the next call on Thursday, 3 October.

4.                            Accreditation (building block f & j – see attached) (45 minutes)

1. Overview of updates made in response to input received during F2F meeting (Alex Deacon, Milton Mueller)

• The EPDP Team should have received a link to a google doc yesterday.
• The document Milton and Alex have been working on is roughly based on the accreditation model Alex presented in LA.
• Is there a single body or multiple accreditation bodies?
• Answer: no agreement – IPC notes there should be multiple accreditation bodies, while NCSG notes there should be one accreditation body (ICANN)
• Code of conduct – difference of option whether this should be a uniform policy or differentiate by sector
• Included a set of definitions that defines authentication and authorization
• Accreditation framework must not rule out individual users
• The idea of user groups is an area of divergence for IPC and NCSG. IPC believes de-accreditation and auditing can allow for user groups; NCSG does agree with the concept of user groups.
• The linkage b/w accreditation and user groups is the primary area of disagreement b/w NCSG and IPC.
• Re: financial consideration – thought the group agreed that groups wanting accreditation would pay for accreditation

2. Review of “ideal accreditation model” proposals submitted by IPC, BC, SSAC, and GAC to cover their respective communities, outlining what the baseline accreditation requirements could be as well as the attendant benefits of accreditation within the architecture of an SSAD

• BC
• ICANN can accredit the accreditors, rather than be the sole accrediting body, particularly in light of the presentations the Team heard in Marrakech.
• As part of accreditation, there needs to be authentication – that a purpose is identified, processing will be compatible with the purpose stated.
• Graduated penalties and de-accreditation would apply if there is abuse
• Re: fees – all applicants should pay a non-refundable application fee.
• Three levels of accreditation – one-time access, intermittent users, regular access – graduated accreditation fees based on type of user
• Logging responsibility – activity would be logged by the entity providing access and The logs would include the and the accredited entity, the purpose, the query and the day
• Logs would be retained for two years in a machine-readable format and logged information would remain confidential but could be revealed with legal justification.
• A third-party firm should be chosen to randomly audit logs
• Accredited entities would agree to safeguards
• De-accreditation does not prevent the requestor from submitting manual requests for access
• SSAC
• Accreditation is required for a party to participate in the access system (SSAD).  Unaccredited parties can make data requests outside the system.
• Accreditation provides safeguards, with the goal of making the exchange of data as routine and as swift as possible within the law.
• Accreditation emphasizes the responsibilities of the data requestor (recipient), who is responsible for complying with the law.
• Accreditation will focus on the requirements of the law, such as requirements regarding data retention length, secure storage, organizational data controls, and breach notifications.   
• Therefore the accreditation guidelines should be the same across all accrediting bodies (if there is more than one).  A common and standardized set of practices and language is highly desirable to manage the accreditation and operational processes, extending to common legal documents.  There is not yet a demonstrated need for accreditation requirements to vary from one industry sector to another.  Some data requestors may participate in more than one industry sector and may make queries with different purposes (for example, cybercrime versus intellectual property disputes).  What matters more is the legitimate bases for the queries they make rather than what kind of organization they are.  
• Accreditation is granted to an organization (not specific individuals within an organization). 
• Accredited parties are authorized to participate in the SSAD system and receive the necessary access/authentication credentials from a central authority.
• Accreditation does not guarantee disclosure of the data.
• Accreditation is for a period and must be renewed occasionally.
• Any auditing of the activities of accredited parties must be performed by a neutral third party auditor.  
• Log data is confidential.
• Accreditation may be revoked by the accrediting body.
• Parties that violate the law are responsible to the state authorities responsible for enforcing the law.
• The cost of becoming accredited must not be onerous on parties that have a demonstrated need for the data but have limited means.

3. Feedback from EPDP Team

• GAC circulated a response re: the GAC’s view on accreditation. It recognizes that this is more complicated when it comes to the accreditation of public authorities. Concerns with a single entity identifying law enforcement – perhaps identification could be done by a national entity, but the credentialing aspect could be handled by a global entity.
• Accreditation can be thought of as an authentication function, but not a dispositive function. ICANN could be the accreditor of accreditors at the very least. Many potential users of the SSAD will be in multiple groups – does this mean these users would have be accredited by multiple bodies?
• One condition of the system is the user needs to make legitimate queries, or it will be kicked out
• Accrediting entities should not propose themselves as accrediting bodies – at the very least, ICANN should accredit the accreditors
• There may be different groups that have different roles, but everyone within the group has their own API or credential, so that this is trackable at the individual level, not the group level.
• For multiple accreditations – if all accreditors impose the same rules, there shouldn’t be a need for multiple accreditations.
• Re: user groups – if the first clause is removed, perhaps that language is OK. In short, it is not about law enforcement.
• As far as credentials, the organization would be accredited, and the organization receives credentials.
• Discarded the notion of self-accrediting bodies
• The Team has not agreed on user groups and accreditation bodies
• Agreed to standardized method for accrediting accreditors – by ICANN
• The Team has not covered law enforcement enough at this time

4. Confirm next steps  

• Support Staff to edit the accreditation building block in accordance with materials received and the discussion during today’s meeting by Monday, 7 October.

5.               Query Policy (building block i & l – see attached) – second/final reading (15 minutes)

a. Overview of updates made in response to input received during F2F meeting (James Bladel, Mark Svancarek)

b. Feedback from EPDP Team

c. Confirm next steps  

6.                            Retention and destruction of data (BB e) – Second reading (15 minutes)

a.                 Overview of updates made following first reading (see attached)

b.                 Feedback from EPDP Team

• The portion about the relevant data processing arrangements is unclear
• It may mean the arrangement b/w requestors and their accrediting body, but it could also apply if the requestor and data protection body entered into a data processing arrangement
• The language could mean that the agreement referenced here is part of the accreditation process
• The purpose of the broad language at this time could allow for different scenarios, as the Team has not agreed on the structure of the system.
• No objection to the fact that retention is on a case-by-case basis. Perhaps the second sentence could be reworded – it needs to be clear in what is meant.
• The retention is limited by the purpose that the data is being requested. The purpose limitation, and if the request is a 6(1)(f), part of the balancing test may be how long the data will be retained for.

c.                 Confirm next steps

• Support Staff to edit retention building block in light of today’s discussion by Tuesday, 1 October.

7.                            Lawful basis table – see https://docs.google.com/document/d/1U9jt9nOHs9QMjWTDl7UPaT--9aD2lHZI/edit [docs.google.com] (10 minutes)

a. Initial review of input provided

• RrSG is the only group to provide timely input.
• RrSG notes that while this table addresses GDPR lawful bases, the Team needs to be forward-thinking that requirements need to not just account for GDPR but also future data protection legislation
• Support staff to provide further guidance on the goal of this exercise

b. Confirm next steps

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

a)                     Thursday 3 October 2019 at 14.00 UTC

b)                     Confirm action items

c)                     Confirm questions for ICANN Org, if any