Dear EPDP Team:

Please find below the notes and action items from today’s meeting.

As a reminder, the next EPDP Team meeting will be Thursday, 16 April at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. Recommendation 1: Based on today’s discussion, EPDP Support Staff to propose edits to Recommendation 1 for EPDP Team review by Tuesday, 14 April.
2. Recommendation 2: In preparation for the next meeting, EPDP Support Staff to work with GAC reps to identify the unique provisions of Recommendation 2 that require a separate recommendation (and cannot be incorporated into Recommendation 1).
3. Recommendations 3, 5, 8: EPDP Team to review all public comments (via the public comment review tools) and provide feedback into the relevant discussion table by COB Tuesday, 14 April.
4. Timeline: Rafik to reach out to GNSO Council and request guidance about a possible extension of the EPDP Team’s timeline due to COVID-19. Rafik to flag to the Council that an extension will also involve the selection of a new chair due to Janis’ availability.

EPDP Phase 2 - Meeting #52

Proposed Agenda

Thursday 9 April 2020 at 14.00 UTC

1. Roll Call & SOI Updates (5 minutes)

2. Confirmation of agenda (Chair)

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

1. Status of PCRT & Discussion Tables + deadlines & proposed timeline (see proposed timetable and https://community.icann.org/x/Hi6JBw)
• All PCRTs and Discussion Tables have been posted to the wiki
• Support Staff will start populating the review due dates from the draft schedule sent to the list this week
• As a reminder, the PCRT links are an easier form to review the comments submitted to the public comment forum, and are divided by the level of support
• The schedule may be revised as we go, but wanted to put an example forward for predictability and allow groups to self-organize their input
2. Letter from Chair of GAC
• GAC has submitted a letter, requesting a slower pace for the EPDP, in light of COVID-19
• Strongly support content of the letter – ALAC has strong concerns that EPDP Team will produce a report that the GNSO may not approve or the Board may not approve.
• Curious that this is coming from the GAC who has been advocating for a faster speed. The Team is constrained by its budget. This may just prolong discussions of topics the EPDP Team will still not agree on. Delaying the output is a lose-lose scenario for all sides. Extending the timeline is not worthwhile.
• BC supports the GAC letter. COVID-19 has changed the way that groups can respond to issues. It would be wholly inappropriate for the Board to not provide funding for this effort. The resource request is probably less since we are not asking for F2F meetings at this time. Support asking the Board for additional resources.
• Suggested prudent next step – reach out to the GNSO Council and let them know about the challenges and concerns raised here. Perhaps Rafik could pass the concerns along and ask for advice from the GNSO Council.
• Agree to make formal request to GNSO Council for advice. The homework schedule is very aggressive and many groups are likely to struggle with these deadlines given the current environment.
• The Team has been cautioned by the GNSO Council to stick to the timeline. The Team will likely not be able to change positions with more time. This is something that needs to evolve, and a lot of work needs to be done in the implementation phase. Groups should think about how they provide input and guidance to the implementation phase.
• If the pressure is removed, the Team will occupy as much time as is reallocated. The timeline puts pressure on the Team that it does have to come to an agreement and settle issues instead of constantly debating them. Preferable to miss a few comments here and there rather than take the timeline pressure off.
• Advocate for extending the timeline by a few months, not years
• Action: Rafik to reach out to GNSO Council regarding asking for an extension. The Council will also need to launch a search for a new chair of the EPDP Team, since Janis’ availability ends on 30 June.

4. Recommendation #1 - Accreditation (90 minutes)

1. Concerns flagged in EPDP Team review of recommendation #1 discussion table
2. EPDP Team to discuss how to address concerns

Signed Assertions

• The bullet points that Staff has here are on track to addressing the confusion, so support what staff says
• The last bullet: the policy recommendations may include examples of what signed assertions may be, but these are expected to be further worked out in the implementation phase, otherwise supportive.
• Concerns about what kinds of assertions entities could make
• This is a matter of convenience that assertions are linked to identifiers, but it’s not a de facto approval of a request
• Accreditation or signed assertions are no guarantee for disclosure
• The guidance with respect to how to format a request is separate – if you are a trademark group and you are accrediting your members, there are questions you ask and proof that you require – this is separate and doesn’t have to be dealt with here
• Action: Based on positive feedback, and waiting for Stephanie’s comments – request Support Staff to finetune the current language in Rec. 1 with respect to signed assertions. When the Team reviews the clean text, we can use two colors – new color for text that has been edited as a result of the public comment period.

Trusted Notifiers

• This term is a misnomer – it should be trusted requestors, not trusted notifiers. This seems very subjective – accreditation should be fact-based. Trust should not be found within the SSAD – it should be outside of the SSAD.
• Not opposed to the concept of trusted notifiers, but this should be on an individual basis. Support an idea where such trusted parties could be individually green lit for automated access or preferred access. Deep reservation against parties being mandated to be trusted by all.
• If there is such thing as a trusted requestor, this should be in a different part of the policy. This is how the team loses time – talking about something that is never going to happen.
• Just b/c the idea may not fit into accreditation does not mean that this isn’t a good idea.
• This could fit in automation, contracted party authorization – the reason this was called trusted notifier is b/c this is a concept that already exists elsewhere, but this could be called a “trusted notifier” instead
• Maybe there should be a feedback loop at some point
• This should be included somewhere in the policy – do not want to be told later on that CPs cannot attribute a trust level based on

Accreditation Authority

• The staff bullets create more confusion rather than add clarity.
• The AA is responsible for the verification, issuance, and ongoing management of the Identity Credential and Signed Assertions – thought they would rely on identity providers
• Second bullet point talks about third parties but doesn’t mention identity providers
• The fourth bullet point is incorrect.
• In response to Q4 – what is the scope of identity verification – against what standard would the identity provider be expected to verify an identity?
• The last bullet point – the first phrase is redundant. Probably what we need for group accreditations – a field that must be filed in with an ID within your company so that the SSAD can attribute a request to an individual.
• With respect to when a request would go directly to a registry, when would that be? As a default, the request would go to the registrar. If the requestor explicitly wanted to, the request could go to the registry in the alternative.
• Do not want to encourage forum shopping
• This question belongs in the request requirement selection.
• We concluded that the hybrid model would be the best b/c of legal advice received to date. If groups are not supporting this model, this needs to be said right now.
• Support for this model hinges on an evolution mechanism
• Forum shopping is a given, even outside of SSAD. The Team needs to be clear that if we start somewhere and go somewhere else – that’s OK, but we need to define the hand-off
• Approach suggested is default to registrar but ability to go to the registry if there are compliance issues

Reaccreditation Time Period

• If we use 5-year time period, we should consider why this period was chosen. The suggestion to have annual reminders is helpful.
• At this time, we don’t understand what goes into accreditation in the first place. A lot can change in five years.
• Term re-accreditation is overkill – maybe a re-affirmation is more appropriate.
• This is an implementation issue – should be relegated to the IRT
• This is not re-accreditation – this is renewal or re-affirmation.
• The five-year term should be no surprise here as registrars and compliance have used this and it has evolved over time.
• Self-certification to ICANN every year would be acceptable.

Requirements of Accreditation Authority

• Accreditation is to help free up the contracted party from authenticating each user, but should be strictly prescriptive on how that is done
• This is ultimately an implementation question – in general, the expectation is that the AA would validate as much information as they can. The long answer – amount of information to be verified depends on the requestor
• There is a lot to be worked out in implementation, but “verify everything we can” isn’t helpful without further context – could check that an email address works – could conduct interviews, DNA checks – need more guidance here.
• Do not need to reinvent the wheel here – use registrar accreditation as a baseline example
• Could consider giving more time to provide additional guidance here – talked about three largest groups of requestor types: cybersecurity researchers, IP requestors, and LEA requestors – expectation is that for each of those groups, there may be specific types of validation for those groups

Revocation Policy

• No concern, but in general when there is decision made, there should be a recourse or appeals mechanism.

Code of Conduct

• These are the expectations of what should be provided by a requestor. This is not a code of conduct for Article 40.
• AA is not the authority on data protection – when it comes to what is and what is not required – it is the responsibility of the controller
• This is a code of conduct for the accreditation authority itself, not a code of conduct under article 40. As a wider code of conduct discussion, the SSAD would be a chapter in that
• Could we consider referring to a set of rules instead of a code of conduct?
• Support Staff to provide additional clarification

Baseline Application Procedure

• The first bullet point – the definition of eligibility requirements will be revised over time

Accredited User Revocation & Abuse

• SSAD must report on abuse
• The word sanctions is concerning here – recourse spelled out is temporary or permanent restriction of access

3. Confirm next steps

• Consider remaining edits during the next meeting.
• Proposed method is something that allows us to move forward at a reasonable pace, but we need to finetune this method – together with a list of considered issues, we need to include the text of the recommendation.
• Three hours of work online, even with a break, is too much – in the future, we will stick to two hours.
• Next meeting – Rec. 1 and Rec. 2. In the meantime, ask GAC to work with the Support Staff and identify redundancies with Recommendation 1. If there is a specific element re: gov’t officials, that should stay in the rec; the rest will be captured in Rec. 1.

5. Recommendation #2 – Accreditation of Governmental entities (60 minutes)

1. Overview / run through of and recommendation #2 discussion table
2. EPDP Team to discuss how to address concerns
3. Confirm next steps

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

1. Thursday 9 April at 14.00 UTC. Topic to be addressed: Request Criteria & Content, Response Requirements, Acknowledgement of Receipt
2. Confirm action items
3. Confirm questions for ICANN Org, if any