[Gnso-epdp-team] Notes and action items - EPDP Team Meeting #28

Marika Konings marika.konings at icann.org
Tue Oct 29 19:11:28 UTC 2019


Dear EPDP Team,

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

Best regards,

Caitlin, Berry and Marika



EPDP Team Meeting #28

Tuesday, 29 October 2019, 1400 UTC


Action Items


  1.  Alex Deacon to reconcile the Accreditation BB and remove references to framework and make it clear this is the policy for the Accreditation Authority.
  2.  Registrar team to review brackets in sub-point f and confirm that it aligns with https://rrsg.org/minimum-required-information-for-whois-data-requests/.
  3.  Alex Deacon with the assistance of staff support to review EPDP Team input received re. Single identity / multiple authorizations and propose updates to section F.
  4.  Margie and Volker to propose revised language for sub-point n), consider splitting into two points, one for individuals and one for entities.
  5.  James to propose language for sub-point q).
  6.  James and Greg to work on proposed modifications to sub-point t).
  7.  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. After that, building blocks will be considered frozen and comments received by that date will form the basis for deliberations at ICANN66.
  8.  Support staff to send out calendar invites for the EPDP Team meetings at ICANN66. (COMPLETED)


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.<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.                   ICANN Org questions to the EDPB

·         Team to consider any clarifying questions for ICANN to send to the EDPB

·         Procedural question - what is the status of this letter?

·         During the Los Angeles F2F, the Strawberry Team noted it was hesitant to share questions before sending to the EDPB.

·         Thought the Strawberry Team would share the questions with the EPDP Team after they shared the questions with the European Commission

·         Suggest not attaching questions to this document - EPDP should distance itself from this document as much as possible. Many assumptions in the document do not represent consensus within the team.

·         May be helpful for the Team to consider this letter with time frames attached to it, including when the Strawberry Team is expecting to receive a response.

·         There was a need for prior consultation before getting the document to the Board. EC colleagues who were able to speak with the Belgian DPA. ICANN wanted to have answers from the Board before sending to the EPDB. The EPDB and the Belgian DPA are informed about this paper, but the response is unlikely to come in before ICANN66.

·         Unhappy with this situation. EPDP Team asked for the document to be shared prior to dispatching to EDPB. This causes frustration and burnout for volunteers to see their efforts bypassed. There is talk to defend the multi-stakeholder model at the global level, but this undermines the multi-stakeholder model. EPDP Team should put something on the record that this has not been reviewed nor endorsed by the EPDP Team.

·         The Team knew from the beginning that the Strawberry Team has been working on a set of questions to the EPDB. From the beginning, the EPDP Team was cognizant that it was developing a standard where a UAM may be one of several options. This paper is not completely contradictory to the Team’s work. The Team can factor in any response in its work.

·         Team to formulate questions for Strawberry Team and EDPB.

·         The Team should not devote time to this effort in Montreal. Every action the Strawberry Team has taken has been done without the consultation of the EPDP Team. Any time spent on this seems to legitimize an illegitimate, bootleg process.

·         Do not agree with how this process was conducted, but answers could help us.

·         Any response from the EDPB, if any, will not be helpful to the EPDP Team because it is based on assumptions the EPDP Team has no consensus on - for example, that the UAM is a benefit to registrants.

b.       Status of building blocks

·         A new google doc was added for the policy principles.



4. Accreditation - (building block f and j) – second reading continued (30

minutes)

a)            Review comments & input provided

·         Request for Team members to refrain from wordsmithing and focus on concepts.

b)            Feedback from EPDP Team

Proposed Definitions

·         Question from ICANN org - what are the criteria for selecting an accreditation authority?

·         There is still work to be done in cleaning up the language from the original framework (which assumed multiple accreditation authorities). The accreditation authority is assumed to be ICANN org. If ICANN wants to outsource this responsibility, it can. The Team has agreed that a single accreditation authority will be run by ICANN org and it can outsource identity verification to zero or more third parties.

·         How ICANN ultimately runs this is up to it, but ICANN will be ultimately responsible for the accreditation authority role.

·         Definition of credential - the terms validation and verification are clarified here. This is based on an RFC for security credentials that is standard in the industry.

·         Where this is a defined term used in the text of a definition (like validate or verification), it is capitalized.

·         Definition of de-accreditation of accreditation authority- this needs to be discussed more. What is the process to revoke or reassign the credentials.

·         While this is an implementation issue, text should be added to protect accredited users.

·         If ICANN org is the accreditation authority perhaps de-accreditation will never happen.  It may be that we need to flesh out de-accreditation of 3rd party identity providers ICANN may leverage.

·         Subpoint q, which deals with de-accreditation, fleshes out more details with respect to de-accreditation.

·         If ICANN org is going to be the accreditation authority, a framework is not needed, and this language can be removed.

·         What does this word framework mean in this context?

·         What is the difference b/w framework and policy recommendations? What is in this framework and what is the purpose of it?

·         Subpoint A

·         This is unclear - how can it accommodate single users if they have to be accredited?

·         If accreditation is added before requirements, would this address the above concern?

·         Subpoint C

·         The word preferably seems to imply this is not a requirement.

·         Action item: Alex Deacon to reconcile the document and remove references to framework.

·         Subpoint E

·         Can “must” be taken out of brackets?

·         Why does this say “benefits of accreditation”?

·         It could be that the benefits of accreditation section could be moved within this building block

·         Is accreditation just verification of identity? This section, particularly Subpoint F, tries to explain the benefits.

·         Some of these points seem to be policy recommendations, not describing the benefits of accreditation

·         Maybe the word benefits should be removed?

·         Subpoint F

·         Some of the bullet points will not be disclosed when accreditation is applied for. Some of these bullets will be disclosed at the time of the disclosure request - such as legal basis.

·         Agree that some assertions will be provided at the time of disclosure request.

·         If these assertions are associated with an identity, they would be passed on as defaults, so the purpose may be identified by the identity provider.

·         A credentialed user could select purposes not associated with that credential? If an enterprise has multiple functions and purposes - does it make sense for this type of enterprise to have multiple credentials that apply to each type of purpose it has?

·         Inextricably linking an identity credential with authorization details is a bad security process. Envisioning a single door with a combination of keys - who are you (identity credential) and what assertions are you making with regard to your request. Can limit the purposes a user can assert in a request, but it would be a mistake to require users to manage many identity credentials for different types of requests.

·         Shouldn’t technically cripple the system because we are afraid of policy decisions that could happen because the system is more capable.

·         Single identity per user, that single identity may have multiple authorizations but each authorization should be tied to one single purpose. Should not cross pollinate.

·         Registrars to confirm that requirements align with https://rrsg.org/minimum-required-information-for-whois-data-requests/.

·         Action item: Registrar team to review brackets in sub-point f and confirm that it aligns with https://rrsg.org/minimum-required-information-for-whois-data-requests/.

·         Action item: Alex with the assistance of staff support to review EPDP Team input received re. Single identity / multiple authorizations and propose updates to section F.

·         Sub-Point g) h) i) j) l) m) o)

·         No comments

·         Sub-Point n)

·         As RySG provided in its input, if someone has violated the rules, there should not be any graduated penalties for user. Access should be revoked.

·         If an individual working for an entity has credentials revoked, this should also be extended to any officers of that entity. If you have a company that has users that are accredited, is a bit much that the entire organization’s credentials are removed? Maybe consider different standard for revocation for individual vs. organization? Consider that organizational credentials should only be revoked based on a showing of systematic organizational abuse? Is trust has been breached by individual, it does apply to the whole organization - maybe there are ways to regain that trust? Organization will be responsible for legal consequences of misconduct, but punishing other parts of the organization for it is problematic, there needs to be a way to remediate. Graduated sanctions also exist under the RAA - consider applying that here? Reinstatement of individuals may not be an option / desirable. Need to ensure that repercussions are of such a nature that it deters bad behavior.

·         Action item: Margie and Volker to propose revised language for sub-point n), consider splitting into two points, one for individuals and one for entities.

·         Sub-Point p)

·         How would CPs know that someone has been de-accredited and would try to get access by going directly to a CP? This is providing a work around for a revoked entity. Either take p) out completely, or if you leave it in, there needs to be a feedback loop to CPs. Maybe publication of revocation lists similar to certs

·         Action item: delete sub-point p)

·         Sub-Point q)

·         Need to flesh out a little bit more what happens to outstanding credentials in the case of the de-accreditation of the accreditation authority.

·         May need to distinguish between policy actions vs. criminal actions. There are parallels in the Ry and Rr agreements - graduated sanctions for violation of the contract, but if you are found to be a criminal, that skips you to the end.

·         Also need to address what happens to users if/when accreditation authority is de-accredited.

·         Action item: James to propose language for sub-point q.

·         Sub-Point s)

·         Sub-point t)

·         See RrSG comment - must be limits on how many requests can be submitted. This language prevents technical operator to protect the system against abuse like a DDOS attack. Language needs to be loosened up a bit. May also be addressed in cost-recovery section? As written feels like a blanket prohibition on any access controls. The words “poses a demonstrable threat’ is intended to cover issues such as DDOS attacks. Maybe requests beyond a certain quota are not subject to SLA performance requirements? With a high volume, direct request to CP might make more sense? Not a solution as SSAD is supposed to facilitate these kinds of high volume requests. 
Need to avoid having one party decide what is abusive or decide what volume they respond to. SSAC is of the view that if a request is legitimate, it needs to be responded to. Not necessarily a technical problem but an economical problem.

·         Action item: James and Greg to work on proposed modifications to sub-point t).

·         Continue from point n) in Montreal.

c)            Confirm next steps



5. Auditing Requirements (building block New) – first reading

a.                   Review building block

b.                   Feedback from EPDP Team

c.                   Confirm next steps

Deferred



6. Logging requirements (building block NEW) – first reading

a.                   Review building block

b.                   Feedback from EPDP Team

c.                   Confirm next steps

Deferred



7. EPDP Meetings and Proposed Agenda for ICANN66

a.                   Overview of meetings and proposed agenda (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-October/002711.html)

b.                   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.


  *   See agenda circulated
  *   4 EPDP Team meetings throughout the week, plus plenary session on Monday
  *   Action item (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. After that, building blocks will be considered frozen and comments received by that date will form the basis for deliberations at ICANN66.
  *   Action item: Support staff to send out calendar invites for the EPDP Team meetings 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 at icann.org<mailto:marika.konings at 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_gnso&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=7_PQAir-9nJQ2uB2cWiTDDDo5Hfy5HL9rSTe65iXLVM&m=5DXgId95wrCsHi--pxTiJD7bMB9r-T5ytCn7od3CF2Q&s=Cg5uQf0yAfw-qlFZ0WNBfsLmmtBNUiH0SuI6Vg-gXBQ&e=> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gnso.icann.org_files_gnso_presentations_policy-2Defforts.htm-23newcomers&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=7_PQAir-9nJQ2uB2cWiTDDDo5Hfy5HL9rSTe65iXLVM&m=5DXgId95wrCsHi--pxTiJD7bMB9r-T5ytCn7od3CF2Q&s=tT-E2RoAucUb3pfL9zmlbRdq1sytaEf765KOEkBVCjk&e=>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20191029/1502a7aa/attachment-0001.html>


More information about the Gnso-epdp-team mailing list