Page History
...
Tip | ||
---|---|---|
| ||
Apologies: James Bladel (RrSG), Amy Bivins (ICANN Org/ Liaison - Legal), Philippe Fouquart (GNSO Council Liaison), Becky Burr (ICANN Board) Alternates: Owen Smigelski (RrSG) |
...
Note |
---|
Notes/ Action Items Please refer to the project spreadsheet [docs.google.com] for action items. EPDP Phase 2A - Meeting #19 Proposed Agenda Tuesday 4 May 2021 at 14.00 UTC
2. Welcome & Chair updates (Chair) (5 minutes) 3. Feasibility of unique contacts (30 minutes) i. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. ii. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses.
4. Legal vs. natural (45 minutes) i. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); ii. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. 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).
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)
6. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #20 Thursday 6 May at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any |
...