- Gnso-epdp-team - lists.icann.org

Proposed agenda - EPDP Team meeting #28 on Tuesday 29 October at 14.00 UTC
by Marika Konings Oct. 26, 2019

Oct. 26, 2019

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Tuesday 29 October at 14.00 UTC. Best regards, Caitlin, Berry and Marika EPDP Phase 2 - Meeting #28 Proposed Agenda Tuesday, 29 October 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) ICANN Org questions to the EDPB b) Status of building blocks<https://community.icann.org/x/k5ICBw> 4. Accreditation<https://docs.google.com/document/d/1-90NgBnkZt8mRL2acJUPOwoIkx5clvXlCaCC3RA…> (building block f and j) – second reading continued (30 minutes) a) Review comments & input provided b) Feedback from EPDP Team c) Confirm next steps 5. Auditing<https://docs.google.com/document/d/1MsvOfYu7tV97tGzQNjh52hZNxSsCw5ps4-dLvfR…> Requirements (building block New) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 6. Logging requirements<https://docs.google.com/document/d/130z5SNuYgGhlH9hnAHJcjuZ_9F5zP7uJ4P4g_Xc…> (building block NEW) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. EPDP Meetings and Proposed Agenda for ICANN66 1. Overview of meetings and proposed agenda (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-October/002711.html) 2. Reminder: EPDP Team to review all building blocks and policy principles, and provide input on those building blocks and/or parts not finalized yet as well as policy principles by Wednesday 30 October at 21.00 UTC at the latest. After that, building blocks will be considered frozen and comments received by that date will form the basis for deliberations at ICANN66. 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Saturday 2 November from 8.30 – 18.30 local time b) Confirm action items c) Confirm questions for ICANN Org, if any Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

New blog: ICANN org Seeks Input from European Data Protection Board
by Eleeza Agopian Oct. 26, 2019

Oct. 26, 2019

Dear EPDP members, We wanted to share with you a blog from Göran, published today: “ICANN org Seeks European Data Protection Board Input<ICANN%20org%20Seeks%20European%20Data%20Protection%20Board%20Input>” We hope you find this useful. I have also attached the paper the blog describes and to which the blog links. It is identical in content to the paper Janis shared with you earlier today, but appears in a different format. Thank you, Eleeza and Dan ICANN org liaisons

1 0

Accreditation Building Block - Principle "u" concerning RDAP Identifying Accredited SSAD Users
by Amr Elsadr Oct. 25, 2019

Oct. 25, 2019

Hi, I’m having trouble understanding why one of the principles in the Accreditation Building Block requires RDAP to be technically capable of identifying SSAD Accredited Users. This is included in sub-point “u” in the [Accreditation Building Block](https://docs.google.com/document/d/1-90NgBnkZt8mRL2acJUPOwoIkx5clvXl…. Isn’t SSAD meant to be the tool by which 3rd Parties will be requesting disclosure of redacted Registration Data? Accreditation of users of SSAD provides “benefits” to its users, which are specific to SSAD itself. SSAD in turn, will interface with RDAP to provide disclosure of requested redacted data following a successful conclusion to a disclosure request. I’m failing to see how requiring RDAP to be able to identify accredited users assists this in any way. If we do proceed with this principle/recommendation, wouldn’t that require significant changes being made to the RDAP profile? RDAP will need to include all domain name registration data, as well as all the data (or at least access to it) necessary to identify all SSAD-accredited users. I’m guessing this could be done by either duplicating the database of SSAD-accredited users, or allow the RDAP interface to enable RDAP operators to look up information on accredited users in SSAD. The only benefit I can think of in doing this would be to enable 3rd Parties accredited in SSAD to either submit their disclosure requests via SSAD, or directly via a Contracted Party allowing it to confirm that the Requestor is accredited. But that isn’t what we’ve agreed to do, is it? If a 3rd Party would like to seek disclosure of redacted Registration Data directly via a (for example) Registrar, then it should do so according to the Registrar’s own procedures. The Registrar should then proceed to evaluate the disclosure request based on its own evaluation of the request, and not based on any ICANN Policies we are developing concerning a standardized system. I’m guessing that adding this feature to RDAP will be both costly and burdensome, and absent justification to do so, should likely not be done at all. Unless I’m missing something, of course, which I very well might be. Thanks. Amr

4 4

Notes and action items - EPDP Meeting #27 - 24 Oct 2019
by Caitlin Tubergen Oct. 25, 2019

Oct. 25, 2019

Dear EPDP Team: Please find below the notes and action items from today’s EPDP Team meeting. As a reminder, the next EPDP Team meeting will be Tuesday, 29 October at 1400 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #27 Thursday, 24 October 2019 at 14.00 UTC Action Items Alex Deacon to update Accreditation Building Block Subsections G and R based on today’s discussion by Friday, 25 October. EPDP Support Staff to update the Accreditation Building Block based on today’s discussion and send a clean version to the EPDP Team. (COMPLETE) EPDP Team to provide additional edits to the Accreditation Building Block by COB Friday, 25 October. In providing edits, EPDP Team to consider if any policy principles belong in implementation guidance and vice versa. EPDP Team to provide additional edits to Building Block B (Purposes) and Building Block C (user groups) by COB Monday, 28 October. EPDP Team to provide input on building blocks by Wednesday, 30 October at 21:00 UTC as EPDP Leadership will freeze edit capabilities at 21:00. 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) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Status of building blocks Draft ICANN66 agenda will be circulated after this meeting 4. Accreditation (building block f and j) – second reading continued (30 minutes) a) Overview of updated version The new version reorganizes the text Eliminates unused definitions Includes IPC input IPC edit overview Added text came from the original document worked on by Milton and Alex The original framework envisioned multiple accreditors, but the new idea is one accreditation authority that could outsource identification to other entities Credentials are broken out – authorization and identifier credentials – identifier credential is static; the authorization credential could be different – one request could be for IP violation, while another request could be for a cyber security purpose Separated revocation vs. de-accreditation. Revocation applies to the revocation of a single identity credential; while de-accreditation refers to the de-accreditation authority itself (the nuclear option) In order for accreditation to add value, it needs to be more than just identity – this is now fleshed out in the benefits section b) Feedback from EPDP Team Definitions Separating the credentials is very helpful How does the authorization credential play into the automation debate? A request will be made, and there are three parts to it – 1. Associated with an identity (identity credential); 2. Authorization credentials – signed or validated assertions not directly from the requestor, but the identity provider and accreditation body; 3. Body of the request – other details in building block A that describe the nature of the request. When this request is received by the discloser, they need to validate the request as a whole to make sure it’s properly formed, complete, and then there will be logic where the authorization credentials are reviewed. The Team hasn’t yet discussed how this will work. Automation should not be discussed at this point No automation is guaranteed, but since there will be a lot of requests for data, there will likely be patterns and it will be important to consider the patterns. This is a chain of decision points – does this require human intervention or not – the team has not discussed this yet. Once certain patterns have been detected, maybe the requestor can contact the registrar and deal with the pattern outside of the SSAD system Subsections A-B Comments are visible in the old version Staff’s understanding from the group’s earlier comments is that an accreditation framework should not prevent unaccredited users from using SSAD Can unaccredited users use this system? This is a foundational question. It is not assumed that CPH would not continue to operate some form of RDS look-up service on their websites. Didn’t group had already agreed to allow unaccredited users? Three ways to deal with unaccredited users – spin up a new identity provider; could allow them to self-identify and self-assert; unaccredited users could continue to use the reasonable access mechanism in Phase 1 recommendations An unaccredited user in this process will have no automation assistance, so it will be slower. The real benefit is all uses, both accredited and unaccredited, will be tracked and logged. Main question here – is the centralized mechanism to be provided via the Phase 1 rec. 18, or is there an easy way to produce a streamed SSAD that allows a uniform mechanism to do this? Allowing unaccredited access has value- issues of evaluating GDPR and other privacy laws is very complicated, and whoever is running the SSAD will develop expertise into what is legitimate and what is not – this standardization would be helpful across the board. Important for the public at large to have an efficient and consistent mechanism – opposed to not having a centralized, uniform system >From an implementation standpoint, it would be preferred that you must be accredited to use the SSAD. SSAD, however, should be available to anyone. Accreditation, therefore, should be available to everyone. Everyone should be accredited, but there can be lower bars to some types of accreditation. A requestor who comes in once and never comes again still has to become accredited. Lower the bar for accreditation, but everyone has to be accredited on fundamentally the same terms. It’s possible to define the parameters of accreditation on the number of requests. If everyone must be accredited, the Team has also decided that accreditation is a fee-based system, and if there is a large fee, this will be problematic. There should be accreditation for frequent users of the system; in terms of one-off users – there is no agreement on how to handle this. Subpoints C and D On d – “any other data contained” is probably going to be the heavier lift on this. There should be more weight on “any other data contained”. Maybe include “and data as required in Building Block A”. Subpoint G Based on previous discussion, the last part of G may need to be removed and placed in the new building block for automation When a request is received, the identity credential will need to be checked to make sure it’s correct and not revoked. Validation needs to be defined. Action: Alex to edit Subpoint G by Friday. Subpoint H Important to define how this will work to define a code of conduct in the future The term “code of conduct” should be avoided unless as stated in the law. If that is concept behind it, that is OK, but caution using this term of art unless using as stated in the law. Subpoint P Reference to unaccredited organizations should be removed Subpoint R Reference to violation of AUPs should be added, and this point needs to be fleshed out. If the accreditation authority is de-accredited, does that revoke the accreditation of all users associated with the authority? For accredited users, there is a concept of graduated penalties, but not on the authority itself. There should probably be graduated penalties for the accreditation authority as well. What happens to outstanding credentials if the accreditation authority is de-accredited? Alex to provide more detail in Subpoint R. Fees This should be moved to the financials building block Consider cost of accrediting a one-off user may be minimal, so perhaps they would not be charged Agreement to leave one fundamental principle (a) and move the rest to the financials building block Technical Capabilities It is premature to discuss technical capabilities at this time. This should probably be moved to implementation guidance; it is difficult to define at this point. In essence, there must be a mechanism for the SSAD to communicate with the disclosing entity. The technical capabilities will be put in brackets for now and moved to implementation guidance while everything else is being defined. Action: EPDP Team to identify any elements in implementation that belong in the policy section or vice versa by COB? Action: EPDP Support Staff to clean up the text as reviewed today and clean up immediately after the call. Action: EPDP Team to provide edits by EOD Friday. Staff to post final version by Monday morning before the call on Tuesday. c) Confirm next steps 5. Terms of use / disclosure agreements / privacy policies (building block m) – first reading a) Review building block b) Feedback from EPDP Team Support Staff put together some general notes, and Hadia added some specific notes EPDP Team could draft the terms of use Brian volunteered to draft terms of use It is unclear who this applies to One thing the group will need to decide – how specific does the group want to get at this stage? It may be advantageous to wait until the rest of the building blocks are completed before addressing this building block. Team to revisit this building block once other building blocks are complete. c) Confirm next steps 6. Purposes / user groups (building block b and c) a) Consider approach to these building blocks in light of discussions to date The idea of user groups was parked until accreditation is dealt with, since accreditation may solve for this. With respect to purposes, there was originally language about categories of use cases. Is the Team spinning its wheels by trying to identify purposes- is the Team really talking about how the requestor needs to provide a rationale on why it needs disclosure of the data. If so, this could be referred to different building blocks re: what information needs to be provided. b) Feedback from EPDP Team Not comfortable with no specificity on the purposes Requestors need to identify its function – is this the requestor’s function or the SSAD’s function. Each request needs to identify the lawful basis Specificity with respect to purposes within the policy is important Action: EPDP Team to provide suggestions to Building Block b and c by Monday COB. Action: All other input on all other building blocks should be provided by Wednesday, 30 October at 21:00 at the latest. c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 29 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any

2 1

Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #26 - 22 Oct 2019
by James M. Bladel Oct. 25, 2019

Oct. 25, 2019

NOTE – This was sent to the “bounces” address in error. Sorry for the delay! - JB ------------------------------- Caitlin, Janis & ePDP Team – Chris and I have been hammering out some draft text for Building Block H, sub-bullet (h) (Caitlin’s Action Item #3, below). Chris is offline at the moment, but here’s where we have landed for discussion during tomorrow’s call: Disclosure of RDS data to the type of third parties must be made clear to the data subject. Upon a request from a data subject the exact processing activities of their data within the SSAD, should be disclosed as soon as reasonably feasible. However the nature of legal investigations or procedures may require SSAD and/or the disclosing entity keep the nature or existence of these requests confidential from the data subject. Confidential requests can be disclosed to data subjects in cooperation with the requesting authority, [and] [or] in accordance with the data subject's rights under applicable law. J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org> Date: Tuesday, October 22, 2019 at 4:26 PM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Notes and action items - EPDP Meeting #26 - 22 Oct 2019 Notice: This email is from an external sender. Dear EPDP Team: Please find below the notes and action items from today’s EPDP Team meeting. As a reminder, the next EPDP meeting will be Thursday, 24 October at 1400 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. Amr to propose new text re: Building Block d, subpoint c<https://docs.google.com/document/d/1irlBo_oE5WqxTir5URaxlpPWTn17cnjDz72L79g…> on compatible purposes – for Building Block d based on today’s discussion by Thursday, 24 October. 2. Support Staff to review subpoint d and ensure relevant points are captured in the Auditing building block by Wednesday, 23 October. 3. Chris Lewis-Evans to work with colleagues to update Building Block h, subpoint h<https://docs.google.com/document/d/1irlBo_oE5WqxTir5URaxlpPWTn17cnjDz72L79g…> by Thursday, 24 October. 4. Support staff to review and revise Building Block h, subpoint i<https://docs.google.com/document/d/1irlBo_oE5WqxTir5URaxlpPWTn17cnjDz72L79g…> based on today’s discussion by Wednesday, 23 October. 5. EPDP Team to provide concerns and objections (if any) to the Priority 2 next steps proposal by Friday, 25 October. 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 #26 Tuesday, 22 October 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. Proposed outline for EPDP Plenary Session at ICANN66 * This plenary session, previously known as the Cross-Community session, was requested by the GAC and GNSO. * EPDP Support Staff drafted questions to discuss in the plenary session. The EPDP Team is welcome to suggest targeted questions that could generate discussion during the plenary session. 1. Questions to ICANN Org (request to provide input by ICANN66) * Questions originally raised by James and edited by the EPDP Team were shared informally with ICANN org * Would the Team object to Janis asking ICANN org to respond to the questions that were already shared informally? * Should these questions be asked to the Board in addition to Org? * Janis will send these questions to Goran under his capacity as chair. 1. Status of building blocks<https://community.icann.org/x/k5ICBw> * The Team has not completed any additional building blocks since the last meeting. * Encourage Team members to make an extra effort to provide input and follow through on action items. * In the event any member is unable to complete homework by the deadline, please provide an update with an updated deadline. * In the next agenda item, Janis has requested agreed items to be highlighted in green. Text highlighted in green should not be questioned unless there was a misunderstanding. * Additionally, there are now two new building blocks for auditing and logging requests. * Input is sometimes provided very close to the call, which does not give other team members time to provide feedback. Perhaps prior to the Montreal meeting, there will be a date where all documents are frozen so that everyone can work towards a specific deadline. * IPC will provide input on the accreditation building block by EOD today. * Marc A. and Hadia to include updated text for accreditation shortly. 4. Acceptable use policy [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (building block D and H) – second reading continued 1. Overview of updates made 2. Feedback from EPDP Team Subpoint c * Still awaiting updated language from Margie and Amr for subpoint c * Margie and Amr have not yet reached agreement on language; they did agree that a requestor could make a request for disclosure under more than one purpose * Have difficulty in accepting that the disclosee could change the purpose. If the disclosee is going to state specific purposes, that needs to be the purpose under which they process the data. The requestor cannot make subtle changes to the purposes after receiving the data. * If this language is in the law, please specify the problem. * The data subject is going to be told that data will be given to people who have a specific standard and/or purpose(s) as stated. The controller/processor cannot say, “or other purposes as updated”. This dilutes the initial notice to the data subject. Also, the data subject will not know who the disclosee is until there is an access request. * Article 5 of GDPR – data is not further processed in a matter that incompatible with the purposes for which the data was collected. * Agree with the above suggestion, but for one issue. Prevent a situation where someone requests data under false pretenses. There needs to be a safeguard that prevents this. * The purposes for which a requestor may request data is not the same as the original purposes for which the data is collected. The requestor has to seek permission from the primary controller on any further processing, and the determination as to whether further processing is incompatible needs to be made by the primary controller. * The recipient of the data is now the controller; however, that recipient has no nexus with the registrant. Absent independent oversight, there is now a new controller with data. There are recent examples (like Equifax) to ensure there is a necessity test before release of data and that the recipient of the data will responsibly use the data. * The theoretical nature of this discussion is blocking resolution. When we have defined the language which will be presented to the registrant, and when we have discussed some examples of compatible/incompatible, this will be more clear.  * Action: Amr to revise the language of subpoint c and provide to the list for discussion by Thursday, 24 October. * Margie and Amr do agree that multiple purposes can be submitted for each request. Trying to solve: if after the disclosure has taken place and the requestor comes up with a new purpose that was not disclosed, can the requestor process data for the purpose that was not disclosed? Subpoint d * This should be further explained in the auditing section * What is the purpose for the requestor to submit the lawful basis for the processing to take place? The controller has to have a lawful basis. The requestor can provide a lawful basis they think the controller may use, but not sure why this is included. Building Block H Subpoint h * This has not yet been agreed, so James and Chris L-E are working to update this in advance of Thursday’s call Subpoint i * The use of double negatives in not ideal * There is one issue of releasing a name and another about releasing identity of a person that may be harmed. It is difficult for a registrar to respond to requests by local law enforcement authorities. This point should be split. How to handle human rights defenders is a difficult problem. * Local laws justify sanctions that may be disproportionate to an offense that has taken place. Disclosure requests must not go further than where MLATs are in place. Subpoint a * No disagreements from the Team to remove the word “necessary” 1. Confirm next steps 5. Query Policy [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (building block i and l) – second reading continued 1. Overview of updates made 2. Feedback from EPDP Team Subpoint a and accompanying list * This is too subjective – what is high-volume to one registrar may be low-volume to another. How can this be implemented to get something that is less subjective. * Bullet point six is troublesome – there are undefined terms “mine” and “harvest” are very subjective. * Third bullet point notes quotas – this inclusion is problematic. Additionally, rate limiting is also problematic. If someone is submitting a legitimate request, this needs to be accepted and considered. The third bullet should be deleted. * Receivers of queries now decide what frequency or number of requests they want to receive unilaterally, but that may not work in the new system. Accordingly, bullet 3 and 6 are problematic. * This list includes terms that are present in the 2013 RAA. There are two ways to resolve this: be specific as possible or secondly, roll them all up to commercially reasonable efforts to prevent abuse. Team members need to appreciate that there are bad actors, and the SSAD will be a big target. There needs to be mechanisms to safeguard this system – specific safeguards will allow for bad actors to abuse the system. The system should not handcuff providers to burdensome obligations – a small registrar may not be able to handle this, for example. * GDPR requires adequate and technical measures in place to protect data. In the legal world, the measures would not be published. There needs to be volume control. It may be helpful to look how registries did this. * One key issue here – there needs to be some reference to proportionality. Registrars range in size radically - what is high-volume to one registrar may be low-volume to another. * Just as the Team considers bad acting requestors, the Team also needs to consider bad acting registrars. * Users of data and suppliers of data need to have a common understanding. * Enumerating abuse may be problematic – perhaps the commercially reasonable approach should be used to give flexibility to the providers. * The Team needs to find middle ground so that compliance can take action against bad actors. * The commercially reasonable approach is a nonstarter. * Support Staff to determine where the “proportionate” idea can be placed. 1. Confirm next steps 6. Priority 2 items – proposed next steps (see attached) 1. Overview of leadership team proposed next steps * This document was shared with the agenda. * Recommendations factored in the small team’s proposals Privacy/Proxy * Questions around how this issue may already be addressed by the PPSAI policy * This implementation is currently on hold, but perhaps the implementation review team has taken into account this issue – proposal for support staff to reach out to colleagues on PPSAI for further information Legal vs. Natural * Confirm with colleagues re: status of the study and associated timeline. * In parallel to study being undertaken, Legal Committee could review what questions (if any) should be submitted prior to the completion of the study. City Field * Legal advice came in at the end of Phase 1 * Legal committee to review and analyze the legal advice and review additional legal questions that have been proposed Data Retention * Staff to confirm what the status of ICANN org’s work to review data retention procedures and see if the retention period recommended in Phase 1 needs to be updated. OCTO * Follow up with OCTO colleagues – and see if the position during Phase 1 has changed. Based on feedback received, Team would consider what the appropriate next steps are Uniform Anonymization * Legal Committee to review the questions received thus far for the Team to have an informed discussion on this WHOIS Accuracy and ARS * This is a topic b/w ICANN org and the GNSO Council – trying to review scope of this work – await further guidance on this before proceeding further. 1. Feedback from EPDP Team * Staff should proceed with the next steps * The legal vs. natural study is not dependent on the implementation of Phase 1 recommendations. * Would Team agree to a lunchtime presentation of the terms of reference to the legal vs. natural study. * EPDP Team to provide objections to the Priority 2 proposal by Friday, 25 October. 1. Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Thursday 24 October 2019 at 14.00 UTC 2. Confirm action items 3. Confirm questions for ICANN Org, if any

2 1

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Thursday, 24 October 2019 at 14:00 UTC
by Terri Agnew Oct. 24, 2019

Oct. 24, 2019

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Thursday, 24 October 2019 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/BYYCBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call, observers can join via audio cast, listen to the recordings and read the transcript afterwards. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Terri

1 0

Proposed agenda for ICANN66 related meetings & deadline for input on building blocks and policy principles
by Marika Konings Oct. 24, 2019

Oct. 24, 2019

Dear EPDP Team, As discussed, please find attached the proposed agenda for the EPDP Team meetings at ICANN66. Note that we do still need to confirm the availability of external speakers so the agenda is subject to change. Please take particular note of the following: * EPDP Team to review all building blocks and policy principles, and provide input on those building blocks and/or parts not finalized yet as well as policy principles by Wednesday 30 October at 21.00 UTC at the latest. After that, building blocks will be considered frozen and comments received by that date will form the basis for deliberations at ICANN66. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Tuesday, 29 October 2019
by Terri Agnew Oct. 24, 2019

Oct. 24, 2019

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Tuesday, 29 October 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) For other times: https://tinyurl.com/y6qusxhq Agenda Wiki: https://community.icann.org/x/L5ACBw The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Kind Regards, Terri If needed, an option to join via telephone has been added for this meeting. **New join information - Conference Bridge: Toll-free access number (US and Canada): 800 550 6865 and Toll 213 233 3193 Other telephone numbers found here: http://www.adigo.com/icann [adigo.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adigo.com_icann&d=D…> Enter passcode on telephone: 7349

1 0

IPC Comments on the Accreditation Building Block.
by Alex Deacon Oct. 23, 2019

Oct. 23, 2019

EPDP Colleagues, Attached are IPC's comments and suggestions on the Accreditation building block language published on the wiki at https://docs.google.com/document/d/134Vryb2H5fYzC1B_451pfzCA1VHVtreF/edit . Let me explain the main updates. *A single Accreditation Authority vs. Multiple* In my original Accreditation Framework and diagram presented in LA I defined a framework that assumed the existence of multiple Accreditation Authorities. Since then we have decided that ideally we want a single Accreditation Authority (run by ICANN) that can leverage one or more external/3rd party Identity Providers. This document (based on the doc submitted by Staff this afternoon) makes this assumption and accommodates for it. (I hope) *Identifier Credential and Authorization Credential* I added back the distinction (and definition) of an Identifier Credential and an Authorization Credential. - An Identifier Credential is "static". It identifies an individual user in the system and is valid until it either expires or is revoked. For example my SSAD Identifier Credential would identity me to the system and convey my Name (Alex Deacon) and perhaps even my email address (alex(a)colevalley.consulting) and affiliation (Cole Valley Consulting). - An Authorization Credential conveys one or more access authorizations (also known as assertions or claims) that are associated with (and bound to) the Identity Credential. Authorization Credentials are more dynamic in nature an convey information that may change per request. (things like the purpose of the request, legal basis being asserted, compliance with laws/ToS/etc., etc. (See "Benefits of Accreditation f) for a list. ) The ability to associate a dynamic set of Authorization Credentials (assertions) on a per request basis simplifies the system and removes the need to issue and manage an identity credential for each purpose/basis/etc. combination. (users don't want to have to manage 12 or more different credentials to use the system) . Note that this is a "best practice" when building/designing authentication and authorization systems. Also note that the technology suggested by the TSG, OpenID Connect, supports the separation of Identity Credentials from Authorization Credentials. *Revocation vs. De-Accreditation* We were overloading the term De-Accreditation to apply to both Identity Credentials (associated with requestors) and the Accreditation Authority itself. I found this confusing so I defined the term "Revocation" to apply to Identity Credentials and De-Accreditation to apply to the Accreditation Authority itself. Revocation of an Identity Credential only impacts a single user of the system. (e.g. we revoked Alex's Identity Credential because he no longer works at Cole Valley Consulting - or got hit by a bus!) De-Accreditation of the Accreditation Authority impacts every credential managed by the Accreditation Authority (i.e. its the Nuclear Option when there is a major/catastrophic audit failure- everything fails and all credentials managed become null and void. ) *Accreditation is more than just Identification* I've heard several folks state that Accreditation is only about Identification of requestors. In LA we made it clear that an Accreditation framework that only accomplished Identification was a waste of time. See my suggested update to the Benefits of Accreditation section which in addition to Identity lists: 1) management of Authorization Credentials, 2) How Identity Credentials and Authorization Credentials facilitate the decision to accept or reject the SSAD request, and 3) definition of a baseline code of conduct (based on EDPB guidance) Please review and let me know if you have any suggestions. There is no doubt improvements that can be made - but hopefully this moves the ball a few steps in the right direction. Happy to walk thru this on the call on thursday morning. Alex ___________ *Alex Deacon* Cole Valley Consulting alex(a)colevalleyconsulting.com +1.415.488.6009

3 2

**Reminder** Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Thursday, 24 October 2019
by Julie Bisland Oct. 23, 2019

Oct. 23, 2019

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Thursday, 24 October 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) For other times: https://tinyurl.com/y2kurmq6 [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_y2kurmq6&d…> Agenda Wiki: https://community.icann.org/x/BYYCBw The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Kind Regards, Terri If needed, an option to join via telephone has been added for this meeting. **New join information - Conference Bridge: Toll-free access number (US and Canada): 800 550 6865 and Toll 213 233 3193 Other telephone numbers found here: http://www.adigo.com/icann [adigo.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adigo.com_icann&d=D…> Enter passcode on telephone: 7349

1 0