[Gnso-epdp-team] Notes from EPDP Meeting #34 - Tuesday, 11 Dec 2019

[Caitlin Tubergen]

Dear EPDP Team,

 

Please find below the notes from EPDP Meeting #34 on Tuesday, 10 December.

 

As a reminder, the next EPDP Team meeting will be Thursday, 12 December at 14:00 UTC.

 

Best regards,

 

Marika, Berry, and Caitlin

--

 

EPDP Phase 2 - Meeting #34

Tuesday, 10 December 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)                     Status of building blocks

 

4.                            Preliminary Rec #7 – Authorization Provider
>From the last meeting, there are three outstanding issues. 
Team members were asked to provide input, and we will go over comments received by last Sunday today.
The Leadership Team proposed paths forward based on the comments proposed by the Team.
Comments proposed after the deadline were not taken into account.
Going forward, the Team needs to follow the suggested timelines. 
Please refrain from making editorial proposals to already-agreed to text.
 

a)                      Consider outstanding items:

·                     “less invasive” retain reference or not (paragraph 5).
Proposal from leadership – leave the “less invasive” reference and include the ICO reference for clarity
EPDP feedback: 
Fine with this suggestion. If people have another place to go to for data, they should go there and not use the SSAD.
The word invasive is not on the ICO website; they use intrusive. A footnote will not give the appropriate guidance to the IRT. ‘Necessary’ means that the processing must be a targeted and proportionate way of achieving your purpose. You cannot rely on legitimate interests if there is another reasonable and less intrusive way to achieve the same result.

Who makes the decision about there being another means – if the authorizing entity is going to rely on this, it would be helpful for the authorizing entity to refer to what that source is
Fine with invasive or intrusive. This could be addressed in some respects with development of an appropriate fee structure. If there is something that is less intrusive, the fees of becoming accredited and using SSAD will act as a disincentive for using the SSAD
Agree to change to intrusive, add reasonable, and include Margie’s language
Proposed implementation advice: If the basis to deny the disclosure is based on a less intrusive means, the authorizer shall identify the less intrusive means
This proposal is troublesome to have a system we build point to a source that may be problematic.
The discloser could not understand all reasons where data is disclosed – that is up to the requestor. If the discloser does know a different source, it could point to it, but that should not be required.
This bullet is redundant – if there is a less intrusive means, that would have to be called out in the reason for denial.
Agreement to remove second bullet (less intrusive means)
·                     Geographic application (paragraph 6, sub-bullet 2 and 3)
Leadership proposal to delete the bullets re: EEA and non-EEA and replace with notion to consider if balancing test is required and proceed accordingly
EPDP Feedback: 
Important not to recommend policies that create different classes of registrants. Recommending a feasibility study is difficult to implement and also very expensive
Re: geographic issue – it is not appropriate to rehash the issues that were already resolved. The Team had already talked about in the past that CPs could make geographic distinctions. 
The distinction in paragraph 6 artificially creates 2 classes of registrants. Suggest abandoning this distinction and apply the legal bases for all disclosure requests.
Differentiating on a geographic basis could result in competitive advantages that the Team should consider
This seems to be doing two steps in 1. First, is there a legal basis? If the legal basis under 6(1)(f), then the balancing test is necessary.
The requestor has to state its legal basis. It is likely all laws will consider the same considerations. The concept of legitimate interest predates GDPR.
Focus on legal basis and stay away from the geographic basis
If I am a registrant and I live in Ireland and have an Irish registrar, the balancing test should apply. If I live in Ghana, and I have Ghanaian registrar – in that instance, should I also have the balancing test? 
That is what the language is trying to get it here.
The Phase 2 recs could overrule the Phase 1 recommendations. 
This could be a 6(1)(f)-like balancing test.
It may not be easy to determine if something is personal data at first glance.
Replace the two points with one bullet point (noted on presentation screen)
How can you determine if there is personal data?
·                     Must/should/may (paragraph 7)
[Assuming that ‘should’ cannot be enforced]: Update language to read: “If, based on consideration of the above factors, the authorization provider determines that the requestor’s legitimate interest is not outweighed by the interests or fundamental rights and freedoms of the data subject, the data is expected to be disclosed. The rationale for the approval should be documented. If all other requirements for disclosure have also been met, the data MUST be disclosed.
Cleaner from a compliance perspective that MUST is preferred
It needs to be must or shall.
“is expected to be” should be shall
Have an objection to this proposal – partly b/c we don’t know who is making the decision yet – this could mean that CPs have no wiggle room to not disclose data. Maybe need to come back to this once we have a response from DPAs.
If this policy conflicts with other laws, this will move to external venue. The entire policy would be at risk if there is a box that is too narrow and remove the ability for data controllers to have any discretion at all.
Cannot agree to language that has no certainty
The Temp Spec uses the word “must” – this would be a step back
The release valve is the qualifiers in the previous points, so the must is OK here.
The other “shoulds” should be changed to “musts”
This building block is now stabilized.
b)                     Feedback from EPDP Team

c)                      Confirm next steps

 

5.                            Preliminary Rec #11 – Terms of Use (20 minutes)

a)                      Review comments / suggestions provided by deadline 
Confused as what the privacy policy is intended to address here – isn’t this covered by the disclosure agreement?
Action: EPDP Support Staff to include additional language, clarifying the difference b/w the terms of use, privacy policy, and data protection agreement for EPDP Team review.
b)                     Feedback from EPDP Team

c)                      Confirm next steps

 

6.                            Preliminary Rec #14 - Automation

a)                      Review comments / suggestions provided by deadline 

b)                     Feedback from EPDP Team

c)                      Confirm next steps

 

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

a)                      Thursday 12 December 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/20191211/b6562e98/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/20191211/b6562e98/smime-0001.p7s>