Dear EPDP Team, Please find below the notes and action items from today’s EPDP meeting. The next EPDP meeting will be Thursday, 17 October at 1400 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #24 Thursday, 10 October 2019 at 14.00 UTC Action Items Based on today’s meeting discussion, Support Staff to update the accreditation principles (Building Block F/J) via the Google Doc. EPDP Team to review and comment on updated principles by Wednesday, 16 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. 1. Roll Call & SOI Updates (5 minutes) · Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Status of letter to ICANN Board · The EPDP Team has been discussing the last sentence of the draft letter. · The circulated language was discussed by board liaisons · Is the consternation over the last sentence of the letter, or sending the letter more generally? · Issue with final sentence - it is not clear the EPDP Team needs to abandon the centralized model. If ICANN cannot answer the question, the EPDP Team will assume that ICANN is unwilling to do this, and the EPDP Team will draft policy recommendations accordingly. · The GAC has not objected to the letter, but strong language will help express the urgency of the situation. The Team should ask for a written response from ICANN. The language may be reworded so that it’s not a zero-sum situation. · In the second paragraph, the last sentence may need an update. · The original text was less definitive, and the proposed rewrite, in consultation with the board liaisons, made the question stronger. Perhaps revert to the original language. · Removing the last sentence entirely invalidates the point of sending the letter. · Time is of the essence, so the Team should not iterate indefinitely. · Action: EPDP Team members to send updated draft text to James immediately following the call. James to distribute updated version of the letter to the EPDP Team for 2 hours of silent procedure. b) Status of building blocks · Building Block A is closed and will be included in the Initial Report · Support Staff made updates to Building Block E - EPDP Team has 24 hours to flag additional issues · All other building blocks are under development 4. Accreditation [docs.google.com] (building block f and j) – second reading continued (30 minutes) a) Overview of updates made · As noted on the Team’s last call, Support Staff distributed the accreditation building block document, which incorporates input provided from the group’s submissions. The document separates policy principles and implementation-related guidance. · Nothing in the document has been agreed to; this is a Support Staff proposal based on the input received to date. · In certain areas, there may need to be further clarity on who is responsible for what. · The definitions that have been included were from Alex’s document, but the definitions have not been cross-checked with the draft text of the building block. b) Feedback from EPDP Team Principle a: · Concerned with why individuals cannot be accredited. · What is the reason for this? · Some team members argue that organizations can be more easily verified, while this is difficult to do with individuals. However, this can be removed if no agrees. · Could it be possible that only individuals or legal entities would have access to certain types of justifications for request? For example, a law enforcement officer may need to request on behalf of an LEA not on behalf of itself. There could be a distinction, not a prohibition. · Accredited entities can be both legal and natural persons. · The uniform baseline application for legal persons may be different than natural persons. · Why are non-accredited entities prohibited from sending in requests? · Oppose SSAD being limited to only certain types of users · Do not support limiting the system to accredited users only · Almost all individuals will be associated with a business · Accredited entities may be legal persons and individuals.                                 Principle b: · Pointing out a trademark requirement is not appropriate here, or come up with a better example · Remove the example · Add the point that the baseline approach may be different for individuals vs. legal persons                                 Principle c: · “Or automate” should be deleted b/c there is a logical issue in the statement · Adopt Brian K’s suggestion - “accreditation alone must not” · Review of the request could be automated, but not the disclosure of information · Accreditation is not purely for authentication of identity - it could be a wider verification than just knowing who the person is - an individual could submit to a code of conduct, for example · Is it worth starting out with the definition of terms authentication, accreditation, automation? · Staff to reword the “or automate” language Principle d: · Agree with this in principle, but more detail is needed from an operational perspective · System abuse could be an example of why de-accreditation occur, rather than having it as a definitive statement. As an example, there may be situations where trademark holder may lose a trademark - in that sense, if demonstrating that holding a valid trademark is a prerequisite to accreditation, losing the trademark could warrant de-accreditation. · Using “abuse” should not be the only reason for de-accreditation. For example, would violating the code of conduct be considered system abuse? · “in case of system abuse or in cases where pre-requisites for accreditation no longer exist” · In the BC proposal, there is a renewal procedure. The renewal process would require individuals and entities to confirm the accreditation criteria still exist. · Insert full stop after de-accreditation and insert examples of when de-accreditation may occur. Principle e: · Brian suggested changing clearinghouse to clearinghouses (no disagreement) Principle f: · No objections Principle g: · It’s not clear that this entity would be an accreditation authority or a sub-contractor. · Agree with this principle, but operationalizing this principle is subject to interpretation. More detail is needed here - for example, what information is subject to an audit, what information is not subject to an audit, etc. · With respect to auditing, the Team agreed to have a separate building block for auditing. The suggestions could be included in the new building block. Principle h: · G and H could be merged Principle i: · This should be considered in the financial considerations building block · This should be replaced completely with “the accreditation service may be part of a cost-recovery system” · Replace “must” with “likely” · Drop the second sentence, with the understanding that there are additional considerations with respect to the financial model · It is absolutely critical to have principles related to cost causation and cost recovery and the assignment of cost to specific parties; however, rates should not be determined at this stage · Individuals who are accredited and the entities who are accrediting must be self-sustaining · Elements of cost associated with accreditation need to be discussed in building block M Principle j: · Do not see the benefit of this bullet · Should be updated to entities and individuals · This does have merit b/c the Team wants to ensure that regular users are accredited to minimize the work. If there is a group such as IP attorneys or security researchers, this should be streamlined as much as possible. · What does the Team expect as the outcome of this statement? It’s unclear how to implement this. The statement should be dropped altogether. · Proposal to delete this point completely.                                 Principle k: · The idea is that after accreditation that particular entity or individual is recognized as accredited. · Support Staff to reword to clarify. · “Confirm” is confusing everyone - change this word to make this clear · Support Staff to review Hadia’s input and Marc A’s input when updating this principle                                 Principle l: · Wording needs to be tightened here · Accreditation should be renewed periodically should be added as an additional policy principle. c) Confirm next steps · Based on today’s meeting discussion, Support Staff to update the accreditation principles via the Google Doc. EPDP Team to review and comment on updated principles by Wednesday, 16 October. · EPDP Team to review Hadia’s message in advance of the next meeting. · The question regarding RDAP overlaps with principle k. 5. Receipt of acknowledgement [docs.google.com] (building block k) – second reading (15 minutes) a) Overview of updates made following first reading b) Feedback from EPDP Team · No objections to reworded text - this building block is now complete c) Confirm next steps 6. Response requirements / expectations, including timeline/SLAs [docs.google.com] (building block g) – first reading (15 minutes) a) Review building block · Does the group want to check back in on Phase 1 recommendations and Phase 1 implementation, or would the group prefer to take a clean-state approach? · Should sometime be added here about technical failures? · Would this be different if this is a centralized or decentralized model? · It may be helpful to read the questions below the building block to show what the building block is scheduled to address. b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 18 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any