[Gnso-epdp-team] Notes and action items: EPDP Team Call #53 - 16 April 2020

Thu Apr 16 18:06:35 UTC 2020

Dear EPDP Team:

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

The next EPDP Team meeting will be Thursday, 23 April at 14:00 UTC.

Thank you.

Best regards,

Marika, Berry, and Caitlin

--

Action Items
EPDP Support Staff to update recommendation 1, 3, and 5 based on today’s discussion.
GAC reps to review the Consolidated Rec. 1-2 document and provide input and updated text based on the clarification questions by Thursday, 23 April.
EPDP Support Staff to send updated Discussion Issues for Recommendation 8. 
EPDP Team to review:
Review Recommendation 6 (CP Authorization) PCRT and populate Discussion Table by Tuesday, 21 April
Review Recommendation 11 (Disclosure Requirement) PCRT and populate Discussion Table by Tuesday, 21 April
Review Recommendation 15 (Financial Sustainability) PCRT and populate Discussion Table by Tuesday, 21 April
Review the Updated Discussion Issues for Recommendation 8 (once received) in advance of Thursday, 23 April
EPDP Phase 2 - Meeting #53

Proposed Agenda

Thursday 16 April 2020 at 14.00 UTC

1.                            Roll Call & SOI Updates (5 minutes)

2.                            Confirmation of agenda (Chair)

3.                            Welcome and housekeeping issues (Chair) (5 minutes)
Update on public comment proceeding – RySG input has been received. Staff has been updating the PCRTs. There was also a submission from 58 organizations submitted by Franck Journoud. Where appropriate, the discussion tables will also be updated to reflect this additional input. Groups that have not been submitted yet, please also share a full copy of the comments with the staff support team as that will facilitate integrating the comments. 
Update on work plan / GAC letter – note that letter was withdrawn for now. Janis met with GNSO Chair and GAC leadership to discuss concerns expressed. Agreed to follow three elements:
The Team will continue working in steady manner according to plan and will introduce corrections as needed. One meeting per week of 2 hours but with insistence on homework. Staff will help GAC to streamline Rec2 on accreditation of public authorities;
GNSO Council informally will discuss next steps to continue progress on issues that are important but not essential for completing work on the SSAD (legal/natural, accuracy, privacy/proxy) with the goal of setting forth a clear and definite path to resolve these key issues.   The Team will submit formal request as soon as informal options are identified (in order to avoid placing the Council in a difficult position); and
Small group(s) will continue working on most difficult issues (including automated use cases and consensus on the contours of an evolutionary mechanism) to prepare ground for conversation in the Plenary.
Hope that those that voiced similar concerns to those of the GAC will also appreciate these three elements and feel more comfortable in going forward. 
Legal advice on accuracy has been received from Bird & Bird. As requested by Council, responses will be shared with GNSO Council, but legal committee will review to see if there are follow up questions that could further help inform further Council consideration of this topic. 
4.                            Recommendation #1 - Accreditation (15 minutes)
Remaining concerns flagged in EPDP Team review of recommendation #1 discussion table – discussion items 12-16
EPDP Team to consider remaining discussion items
Confirm next steps

Questions 12-14 related to definition of abuse in the context of revocation and accredited entity requirements
Consider delineating between code conduct (abuse once requestor has the data) and abuse of SSAD so that is clear.
Rec #1 should not cover system abuse, that is addressed somewhere else (e.g. query policy).  

Question 15
Confirm understanding that if function is outsourced, org would need to supervise entity to which it is outsourced. If ICANN Org performs the function, audit would be the mechanism to ensure oversight. 
Likelihood of abuse by the Accreditation Authority may be low, but there might still be potential scenarios in which abuse might take place (e.g. not following policy requirements, favoritism). 

Question 16:
Identity Validation Procedures may be clearer than using authentication as it might be confusing. 
Some suggested that any suspension should be maintained during the appeals process. Consider instead modeling it on the registrar process – there is no suspension during investigation, only if issue is not remedied is suspension invoked. Once a registrar is found in breach, the registrar is suspended. 
Note, this is about suspension of identity providers, not accredited users. 
What is the impact of suspension of an identity providers on the users that were accredited using that identity provider. Need to consider the impact – should not result in automatically de-accrediting all related users.
This is an implementation issue that should be considered if ICANN org decides to use identity providers. Could consider keeping credentials in place until re-validation has taken place of those users whose identity was confirmed by the suspended identity provider. 
Is this is a similar scenario as when an SSL authority is revoked?
Need to look at the overall context and not rehash old issues – note that further details are already in other parts of the recommendation which address some of the concerns expressed. 
Need to keep in mind the protection of the data subject, this is not about protecting requestors. 

Implementation guidance:
No further clarification needed – agreement with staff assumption. 

5.                            Recommendation #2 – Accreditation of Governmental entities (20 minutes)
Review discussion items gleaned from input provided on recommendation #2 discussion table
Confirm next steps

Note that the staff support team has reorganized rec #1 and Rec#2 to avoid duplication and ensure consistency. The color coding at the beginning of the consolidated document explains how to read the different updates to the document. 
Note that the GAC team has not had an opportunity to review this document yet – clarifying questions identified from the discussion table have been included where appropriate. Following the GAC’s feedback, further updates may be required so EPDP Team review should take place once all updates have been made. 
The GAC team is still in the process of reviewing the input and issues raised. GAC team requested to provide high level overview followed by specific changes to language for EPDP Team to review:
Important to have broad enough definition of governmental entities. Would resist unduly limiting what a governmental entity may be as there are governmental entities at many levels with different mandates. 
Valid point about mixing up private entities in this grouping – should only focus on governmental entities. 
Entities that are working at the direction of governments should be dealt with separately not to conflate how governmental entities are accredited.
No unreasonable hurdles of accreditation for governmental entities vs. non-governmental entities. There should be clear rules and proper procedures. 
How to deal with governments not represented in the GAC? Each country will need to have some latitude on how it organizes itself, as it will be impacted by jurisdiction. Countries will need to be able to act in accordance with their own legal system and local jurisdiction. 
Should there be a delegation instrument under law that would allow passing on authority to private sector? Without the necessary trust instruments this could be problematic. 
GAC team to consider what is the best way to organize – staff proposal combined the two recommendations, but if the GAC team is of the view that it is better to separate out, that could work as well. Important to put proposal forward so that the EPDP Team can review. 
Important to explain what is different in relation to accreditation of governmental entities. If accreditation authority is delegated to national entity, it needs to be further clarified, may have gotten lost in the combination. 
Objective is to avoid redundancy, but differences need to be highlighted. 
Consider deleting ‘non-public’ from requestor definition as public data may also be provided. 
Need to avoid that any groups are left out unintentionally. 
Consider using section headers from recommendation #2 as these were very clear. 

6.                            Recommendation # Recommendation #3 - Request Criteria & Content (20 minutes)
Review discussion items gleaned from input provided on recommendation #3 discussion table
Confirm next steps

Question 1. 
No concerns expressed about the takeaways identified
Re. permissible purposes – have requested Bird & Bird about this. Maybe await the response before getting into the weeds. Needs to be able to evolve – caution against creating something unnecessarily restrictive. Also note that in rec #4 a number of purposes are listed, but also made clear that these are not exhaustive. 
Need to be careful to balance standardization of request format (e.g. checkboxes, dropdowns) against the ability of requestors to simply select what they think will be most expedient rather than what is true. 
Initially there might be a number of justifications listed as well as free form, over time, certain patterns might be identified, and new rationales might be added. But potentially permissible purpose will still depend on the specific case at hand. There will always need to be an opportunity for free form input. 
Pre-defined terms that are well defined gives more specificity, free form may be more difficult to interpret or parse. But need to avoid that boxes are ticked that do not align with the request that is made. A requestor should be encouraged to explain their purpose in their own words. 

Question 2.
All elements are required, where these are not essential, those are already labelled as ‘as applicable’ – so no need to add ‘as applicable’ to the heading. 

7.                            Recommendation #5 – Acknowledgement of Receipt (20 minutes)
Review discussion items gleaned from input provided on recommendation #5 discussion table
Confirm next steps

Question 1. 
Request shouldn’t be submitted if it is not complete.
Once form is submitted, would SSAD do any further completeness checks or is it just basic form validation? Is there any back and forth foreseen between Central Gateway and requestor? If so, SLA would need to foresee this. 
Should be clear about how the system would work. Should it be impossible to submit a request if not all fields are filled out? If there is an automated query, should have way to indicate that response is not complete.  
Clarify that request cannot be submitted if not all fields are filled out. If there is automated submission, request is not accepted until all information is provided. 

8.                            Recommendation #8 – Response Requirements (20 minutes)
Review discussion items gleaned from input provided on recommendation #8 discussion table
Confirm next steps

Initial list of discussion items shared with the EPDP Team but not all input has been included yet.
EPDP Team encouraged to review the issues identified and come prepared during the next meeting to discuss these. 
Staff support team will further update the discussion items list and share with the EPDP Team ahead of next week’s meeting. 

Wrap and confirm next EPDP Team meeting (5 minutes):
Thursday 23 April at 14.00 UTC. Topic to be addressed: CP Authorization, Disclosure Requirements, Financial Sustainability 
Confirm action items
Confirm questions for ICANN Org, if any

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200416/f13e211a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200416/f13e211a/smime-0001.p7s>