Dear EPDP Team,
Please find below the proposed agenda for tomorrow’s EPDP Team meeting.
We are aware that some groups have added or are adding input after the deadline to the document for agenda item #3a, so please come prepared to speak up during the meeting. The write up that has been produced
by the Staff Support Team (see attached) is based on the input that was received by the deadline from the BC, RrSG and the SSAC; however, this does not prevent other groups from weighing in and providing specific suggestions for additions and/or changes when
this document gets posted as a google doc following Tuesday’s meeting.
Thank you.
Best regards,
Berry, Marika, and Caitlin
--
EPDP Phase 2A - Meeting #19
Proposed Agenda
Tuesday 4 May 2021 at 14.00 UTC
1.
Roll Call & SOI Updates (5 minutes)
2.
Welcome & Chair updates (Chair) (5 minutes)
3.
Feasibility of unique contacts (30 minutes)
4.
Legal vs. natural (45 minutes)
Guidance write up
Guidance #3 - As part of the implementation, Registrars
should consider using a type of flag in the RDDS or their own data sets that would indicate the type of data it concerns (personal or non-personal data)
as this could facilitate review of disclosure requests via SSAD and the return of non-personal data of legal persons by systems other than SSAD (such as Whois or RDAP). A flagging mechanism could also assist in
indicating changes to the type of data in the registration data field(s).
1.
ALAC has suggested that more specificity should be provided to Registrars about how this implementation could work especially in relation to how a ‘flag’
could be applied. Would it be helpful to provide further guidance on how this could be implemented or does that make it too prescriptive? The current guidance already includes references to the use of a type of flag – what is missing that would be helpful
for Registrars to know?
Example scenarios (note, these scenarios are intended to be illustrations for how a Registrar could apply the guidance above. These scenarios are NOT to be considered guidance in
and of itself).
2.
EPDP Team to consider whether or not these scenarios should remain or whether they should be replaced by the RrSG table as suggested by ALAC. If there
is agreement that scenarios should remain as examples, EPDP Team to consider whether scenario #3 (Registrar determines type based on data provided)
should remain as some concerns have been expressed by NCSG in relation to the Registrar making an initial assessment about whether or not the registrant is a legal or a natural person. Note, updates were made to ensure that the Registrant is requested to confirm
this assessment.
Scenario #2 - Data subject self-identification at time when registration is updated
a.
The Registrar collects Registration Data and provisionally redacts the data.
b.
The Registrar informs the Registrant (per guidance #3 above) and requests the Registrant (data subject) to designate legal or natural person type. The Registrar must also request the Registrant
to confirm whether only non-personal data is provided for legal person type.[1]
c.
Registrant (data subject) indicates legal or natural person type and whether or not the registration contains personal information after registration is completed. For example, the Registrant
may confirm person type at the time of initial data verification, in response to its receipt of the Whois data reminder email for existing registrations, or through a separate notice requesting self-identification.[2]
d.
If the data subject identifies as a legal person and confirms that the registration data does not include personal data, the Registrar should (i) contact the provided contact details to verify
the Registrant claim[3] (ii) set the registration data
set to automated disclosure in response to SSAD queries and (iii) publish the data.
3.
The GAC has suggested that it might be helpful to add some timelines to this scenario. How could/should such a timeline look?
Registrars shall not be prohibited from voluntarily utilizing a third party to verify that a registrant has correctly identified its data[4],
provided that such verification is compliant with applicable data protection regulations.
4.
Proposed language changes from Volker were applied to make clear that
third party verification is not disallowed, but neither specifically recommended. NCSG has noted its objection to this rewrite as it would make scenario 3 ten times worse. EPDP Team to consider concerns and determine if/how these can be addressed. Note, the
Bird & Bird advice specifically talks about the option to verify information provided by the registrant.
5.
Expected Homework assignments (5 minutes)
·
By Friday 7 May,
EPDP Team to review proposed feasibility of unique contacts write up for Initial Report (to be posted as google doc after meeting). Please provide comments, suggestions and proposed edits in the form of
comments.
·
By Friday 7 May, EPDP Team to review updated version of legal/natural guidance write up (to be circulated after meeting) and indicate
which aspects, if any, your group cannot live with for inclusion in the Initial Report.
·
By Friday 7 May, GAC and RrSG Team to review updated version of write up (link to be circulated after meeting) and to indicate
to EPDP Team if GAC updated proposal and RrSG table, respectively, need to be included, where it would be included and what aspects it would cover that are currently not addressed in the write up. Please provide your response via the mailing list.
6.
Wrap and confirm next EPDP Team meeting (5 minutes):
[1]
Note that the confirmation that only non-personal data is provided could also happen at a later point in time. However, until the Registrant confirms that no personal data is present in the registration data, the Registrar does not set the registration data
to automated disclosure.
[2]
Note, the implementation of EPDP Phase 1, recommendation #12 (Organization Field) may facilitate the process of self-identification.
[3]
Per the guidance
provided by Bird & Bird, “this verification method is advisable, and will help reduce risk. That risk reduction will be greatest if there is a reasonable grace period within which the objection can be lodged, before the data in question is published in the
Registration Data” and “requiring an affirmative response to verification mailings seems over-cautious, unless and until studies show that the measures adopted are failing to keep very substantial amounts of personal data out of published Registration
Data. However, if a verification email “bounces” (i.e. a Contracting Party knows it was not delivered), then it would be better if publication does not proceed”.