[Gnso-epdp-team] Notes and action items - EPDP Meeting #27 - 24 Oct 2019

[Caitlin Tubergen]

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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20191024/2dc8cbfb/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/20191024/2dc8cbfb/smime-0001.p7s>