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

1. Alex Deacon to update Accreditation Building Block Subsections G and R based on today’s discussion by Friday, 25 October.
2. EPDP Support Staff to update the Accreditation Building Block based on today’s discussion and send a clean version to the EPDP Team. (COMPLETE)
3. 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.
4. EPDP Team to provide additional edits to Building Block B (Purposes) and Building Block C (user groups) by COB Monday, 28 October.
5. 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