[Gnso-epdp-team] Notes and action items - EPDP Meeting #29 - 14 November 2019

[Caitlin Tubergen]

Dear EPDP Team,

 

Apologies for the delay, but please find below the notes and action items from EPDP Meeting #29.

 

The next EPDP Team meeting will be Thursday, 21 November at 1400 UTC.

 

Best regards,

 

Marika, Berry, and Caitlin

 

--

 

EPDP Phase 2 - Meeting #29

Thursday, 14 November 2019 at 14.00 UTC

 

Action Items
Support Staff to apply the agreed-upon edits (including deletions, where applicable) to the Logging, Auditing, and Response Requirements Building Blocks by Friday, 15 November.
EPDP Team to review updated Logging and Auditing Building Blocks by Thursday, 21 November.
 

Agenda

1.      1. Roll Call & SOI Updates (5 minutes)

2.      2. Confirmation of agenda (Chair)

3.      3. Welcome and housekeeping issues (Chair) (5 minutes)

a)                      Takeaways from ICANN66

·         Team will continue working at its current pace until early December and assess at that time whether it is ready to publish the Initial Report, or instead, if it will publish after the F2F meeting in January.

b)                     Timing of calls going forward

·         EPDP Plenary calls will remain at the same UTC time, 14:00 UTC

·         EPDP Legal Committee calls will be pushed ahead one hour to 15:00 UTC

c)                     Status of building blocks

·         Support Staff has changed the due dates for review of the building blocks. 

·         Support Staff has added the updated language on the balancing test framework

·         For some building blocks, the language has been finalized but will need to be revisited once the Team determines which entity will be making the disclosure decision

·         Reminder: please only provide comments to the building blocks; editing directly makes it very difficult for the Team to review

d)                   Reminder: Confirm with Terri travel funding requirements for ICANN67

·         With respect to the January EPDP F2F meeting, please book travel as soon as possible.

·         For travel to ICANN67, the deadline for travel support request has passed; however, if you missed the deadline, please write to gnso-secs at icann.org as soon as possible.

4.      4. Logging [docs.google.com] (building block new) – second reading continued (30 minutes)

a)                      Review comments & input provided

·         Small Team had an initial conversation about the logging building block in Montreal, which ran in parallel to the Legal Committee meeting

·         The edits made by Marika from 4 November were made as a result of the small team meeting. The other edits were made by various members of the EPDP Team. As noted previously, going forward, please only provide edits in comment form.

·         With respect to the logging, the Team aimed to assess the key activities of the SSAD system that needed to be logged: logging related to the identity provider, logging related to the entity receiving the request, and logging related to the entity authorizing the request.

b)                     Feedback from EPDP Team

·         Chapeau

·         No comments

·         Subpoint a

·         Logging should only happen in one place, so queries should be removed from the third item

·         The reason these are currently separated is because it’s unclear if the entity receiving the query will also make the disclosure decision. Once it becomes clear which entity will do what, these can be merged.

·         Subpoint b

·         Will this principle be worked out in implementation? This looks like the start of a data retention specification. There are also data protection implications of this data.

·         How long should the logs be retained? The small team did not have time to discuss this - possibly because this conversation may need to happen after review of the auditing building block

·         If the period for retention will be three years, the Team needs to provide a rationale as to why it’s three years.

·         The reason for three years is so that the logs are retained longer than contracted parties have to retain the data. 

·         The logs shall be retained for a period of time sufficient to cover the time until claims by data subjects are barred by statute according to the national law applicable for the entity keeping having disclosed the data.


·         The Team should assume that no personal information stored in these logs. If the Team is able to do that, that will remove concerns about retention.

·         Suggest changing "machine-readable format" to "in a commonly used, structured, machine-readable format accompanied by an intelligible description of all variables"


·         Team agrees to take the suggestion from Thomas re: proposed data retention language (until claims by data subjects are barred by…) and suggestion from Ayden to expand on machine-readable format as noted above

·         Subpoint D

·         If the liability is still retained by the CPs, the Team needs to keep in mind that the logs could also be released to the CPs. This could be included in a footnote.

·         Support Staff to include a footnote re: release of logs to CPs

·         Perhaps include an (s) after the controller(s)

·         Strike DPAs in (ii) with the understanding they would fall under due legal process under (iii)

·         One point not captured here is the use of the logs by the technical operator of the system - technical operators may need to review logs for the technical operation of the system

·         Propose changing “data protection authorities” to “relevant supervisory authorities”

·         “due legal process, including relevant supervisory authorities, as applicable”

·         Request to retain original language for (i)

·         Subpoint E

·         I.e., when “they” log in - that is when the accredited user logs into the system/gateway, not when they log into the identity provider

·         This parenthetical should be moved down to “authorizing the request”

·         This deals with Alex’s process flow - the individual/entity would be validated by the identity provider itself

·         This bullet will need to be revisited when more details of the system are decided to allow flexibility in implementation

·         Action: Support Staff to revisit the fourth bullet point with Alex and see if it needs to be split into two

c)                      Confirm next steps

·         Team to revisit this building block once other building blocks are finished and further decisions are made to ensure consistency.

·         This will now be changed to green.

5.      5. Auditing [docs.google.com] Requirements (building block new) – second reading (30 minutes)

a)                      Review building block

·         Similar to the logging building block, the green text added on 4 November was added as a result of the small team meeting at ICANN66

 

b)                     Feedback from EPDP Team

 

·         Auditing of the Accrediting Authority 

·         There are some terminology differences - in logging, there is an identity provider and in audits, there is an accreditation authority.

·         No, these are separate entities. 

·         Need more information on audits - if there any implementation guidance the Team could provide, that would be helpful. 

·         If ICANN is the accreditation authority, who above ICANN will sanction ICANN, and what mechanism is that? If it is the ICANN community, what is the mechanism for that?

·         An external auditor for ICANN could be a very expensive endeavor

·         May need to include something in the policy about access to the data that would be used to determine whether ICANN is doing an acceptable or unacceptable job. An audit of ICANN could be triggered under very specific circumstances, rather than including a periodic and potentially expensive audit. This conversation should be revisited when more decisions are made by this team.

·         Support Staff to reword language with the assumption that ICANN org is the accreditation authority and ICANN org can choose to outsource this function

·         It makes sense to assume for now that the assumptions in the Strawberry paper are correct, and that ICANN will retain responsibility for the central gateway

·         Audits of Identity Providers

·         The audit of the identity provider should be done by ICANN

·         It’s difficult to envision how this would work without knowing who the identity providers are

·         Disagree with removing “independent” from auditors - this should be done independently

·         The essential part here is that there needs to be some action taken periodically to ensure things are being done properly  

·         Audits of Accredited Entities/Individuals

·         This is missing some details - for example - do all accredited entities need to be audited? How often is “periodically”?

·         Do not understand how you can audit an individual request - does this involve going into someone’s home to ensure they have disposed of data properly?

·         How does one prove a negative? No, I did not misuse the data. Perhaps there could be an ongoing representation, similar to what contracted parties have to do every year

·         This would work similarly to how CPs are audited today - ICANN would ask the accredited entity or individual a series of questions, and they would have to respond and show proof. If a complainant claims misuse of data, it should have to show evidence of this in its complaint.

·         This should be based on an audit set or a complaint set.

·         It is likely very few people would make a complaint, and that would be looked badly on by DPAs.

·         CPs are audited every 3-4 years, so perhaps timing like that could be considered.

·         The logging and auditing building blocks should be compared and all relevant actors should appear in each building block

·         Bracketed text can be entered here for now, but once the model is more solidified, this can be revisited

·         The auditing of logs text is duplicative and can be deleted

 

c)                      Confirm next steps

·         Support Staff to apply the agreed-upon edits (including deletions, where applicable) and EPDP Team to review 

6.     6. Response requirements [docs.google.com] (building block g) – second reading

a)                      Review building block

 

b)                     Feedback from EPDP Team

·         Most of the text was updated by the deadline given

·         Attempted to clarify the difference b/w checking that a request is syntactically correct and complete. In the case where the request is not syntactically correct, an error response would be returned noting which areas were not completed. When the request is found to be incomplete, an incomplete request response must be returned. 

·         Might it make sense to separate out policy recommendations with implementation advice? 

·         It may be helpful to have a diagram/flow chart to explain the different tracks

 

c)                      Confirm next steps

 

7.     7. Wrap and confirm next EPDP Team meeting (5 minutes):

a)                      Thursday 21 November 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/20191119/4243fb46/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/20191119/4243fb46/smime-0001.p7s>