For those of you who are not subscribed to the EPDP mailing list, here are some Interesting points made by the SSAC. -------- Forwarded Message -------- Subject: [Gnso-epdp-team] Consensus calls, SSAC - Bundle 3 Date: Fri, 15 Feb 2019 23:41:45 +0000 From: Ben Butler <bbutler@godaddy.com> To: Kurt Pritz <kurt@kjpritz.com> CC: gnso-epdp-team@icann.org <gnso-epdp-team@icann.org> Hi Kurt,   As requested, and after deliberating with SSAC members, here are the consensus call positions from SSAC for Bundle 3/3B.  I have grouped the recommendations based on our position.  We have provided comments on a few for inclusion/consideration in the report to GNSO Council.  SSAC will likely provide additional comments next week as well based on the extended deadline referred to in your last correspondence.     *_Supported Recommendations:_* * * *Recommendation #5*(old #4) - Data elements to be collected by Registrars – *SSAC concurs with the recommendation with the understanding that Registrars must support / process Tech Contact data if it is provided by the RNH*  *_ _* *_Explanation:_* There is some confusion whether Recommendation 5 requires registrars to offer the Tech Contact fields to their Registered Name Holders or not.  This is because Recommendation 5's table marks the Tech Contact fields as mandatory to collect, but Recommendation 5 also says "if the Registrar provides this option".    SSAC understands that there are legal requirements for collecting and transferring the Tech Contact data which will need to be discussed in the implementation phase.    SSAC believes that the ePDP Team's discussion was: Registrars MUST offer the Registered Name Holder the opportunity to provide Technical Contact data.  Technical Contact data should be optional for the Registered Name Holder to provide. If Technical Contact data is provided to the registrar, the data must be provisioned to the registry.   If that is what Recommendation 5 delivers, SSAC can endorse Recommendation 5. If Recommendation 5 does not deliver that, SSAC cannot endorse Recommendation 5.   *Recommendation #7*(old #5)– Data elements to be transferred from Registrars to Registries – *SSAC concurs with the recommendation as written*   *Recommendation #9*(old #7) – Contractual Compliance  – *SSAC concurs with the recommendation as written*   *Recommendation #10*(old #8) – Data Redaction  – *SSAC concurs with the recommendation as written*   *Recommendation #12*(old #9) – Organization field – *SSAC concurs with the recommendation as written*   *Recommendation #13*(old #10) – Email communication  – *SSAC concurs with the recommendation as written*   *Recommendation #14*  – Privacy/Proxy Registrations  – *SSAC concurs with the recommendation as written*   *Recommendation #19*(old #13) - Controller Agreement  – *SSAC concurs with the recommendation as written*   *Recommendation #20*(old #14) - Responsible Parties  – *SSAC concurs with the recommendation as written*   *Recommendation #27*(old #22) – Impact on other policies  – *SSAC concurs with the recommendation as written*   *Recommendation #29*– Admin Contact Transition  – *SSAC concurs with the recommendation as written*   *Recommendation #2*–Additional Purposes  – *SSAC concurs with the recommendation as written*     *_Dissentions:_* * * *Recommendation #16*–  Geographic Basis – *SSAC cannot support the recommendation as written (See Below)*   *Recommendation #17*–  Natural vs. legal – *SSAC cannot support the recommendation as written (See Below)*     *_Reasoning:_* Recommendations 16 and 17 have a negative effect on security and legitimate contactability.  Recommendation 16 allows significant over-redaction of data not required by GDPR (or other laws currently in place), and enables a race to the bottom, allowing venue-shopping without respect to the actual location of registrars or registrants.  Recommendation 17 enables ongoing redaction of information about legal persons that do not have the rights of natural persons.  These outcomes are not balanced, and are neither necessary nor desirable.  We believe that better, more balanced solutions are both legally and technically possible and should be discussed.    It is the SSAC's position that: * Recommendation 16: Registrars and Registry Operators must be obligated to differentiate between registrants on a geographic -- i.e. legal jurisdiction basis, after a suitable implementation period. * Recommendation 17: Registrars and Registry Operators must be obligated to differentiate between registrations of legal and natural persons, after a suitable implementation period.   Regarding Recommendation 17: * The EPDP Team will discuss the Legal vs. Natural issue in Phase 2, and SSAC looks forward to participating in that discussion. Should Recommendation 17 be adopted by Council, SSAC notes that the study criteria in section #2 are unbalanced and must be updated.  They assume that the main decision-making criteria are the costs and risks to contracted parties.  The list is missing consideration of how policy affects third parties with legitimate interests, and how the law imposes new responsibilities(and therefore costs) on the Contracted Parties .  As SAC104 notes: "The GDPR imposes certain new obligations and therefore risk and costs on registrars and registry operators. It has also imposed risk and costs on the parties who rely upon domain registration data for the wide array of legitimate purposes.  The GDPR calls for balancing and the accommodation of legitimate security interests, explicitly called out in Recital 49. ICANN policy should also provide balanced solutions. In some cases the Initial [and now the Final] Report asks what costs will be borne by the Contracted Parties, but does not also evaluate the costs on all other parties, or the cost of not putting a balanced solution into place. Cost or risk to registrars or registry operators alone is not a persuasive argument against balanced solutions."   *_Supporting Documentation:_* SAC104: https://www.icann.org/en/system/files/files/sac-104-en.pdf SAC101v2: https://www.icann.org/en/system/files/files/sac-101-v2-en.pdf   As SSAC stated in SAC104: "The GDPR states clearly that it 'does not cover processing of personal data which concerns legal persons.'  We recommend that registrars be required to deploy mechanisms that ensure a reliable declaration or determination of natural or legal person status for new registrations going forward, and to eventually obtain those declarations or determinations for existing registrations and their registrants.   "Contact data associated with natural persons should be published in RDS where such is not prohibited by local law. In SAC101, SSAC stated: 'The new policy [The Temporary Specification] allows RDDS operators complete freedom to choose when to redact domain contact data from publication, whether or not a domain contact is protected by GDPR or by any other local privacy law. The result has been blanket redactions, hiding more data than is legally called for. A more balanced and justified approach is needed.. access should not be less timely, more restricted, and less public than law requires.... We also note that as of this writing, most ccTLD operators in the European Union continue to publish some (and sometimes all) contact data fields for domains registered by legal persons. Some continue to publish some personal data for natural person registrants in public WHOIS output.'   "SAC101 also highlights RIPE-NCC's solution, which allows for the publication of data about natural persons contained in the contact data for legal persons. This process provides mechanisms that RIPE-NCC says were specifically designed to comply with GDPR.  The RIPE-NCC solution seems to be balanced in that it provides contactability and does not overapply the law. SSAC believes that RIPE's model deserves a full examination and neutral legal evaluation.... We also recommend the following: 1. Introduction of a policy requiring registrants to make a legal or natural person declaration. 2. Obtaining declaration would be mandatory for registrars to implement within a reasonable time. 3. A declaration would only be required during registration events, i.e. when a new domain is registered, or when an existing domain is renewed or transferred (by gaining registrar). This would eventually "fill in" status data about existing/historical registrations. 4. Registrar may make declaration on behalf of registrant if the registrar has reasonable knowledge of registrant's status and the registrant has not made a declaration of its own. This would be applicable to registrars with specific business models, for instance when they only process registrations on behalf of organizations where it is clear that the registrant falls into a particular category based on their relationship with the registrar. 5. Registrant may change its declaration at any time. 6. The absence of a declaration results in assumption that the registrant is a natural person; i.e. a default redaction of data. 7. Inaccurate declarations will be subject to a revised WHOIS inaccuracy complaint process."       *_Cluster #3B_* * * *Recommendation #11*City Field  – *SSAC concurs with the recommendation as written*   *Recommendation #15*(new #11) - Data retention  – *SSAC concurs with the recommendation as written*   *Recommendation #18*(old #12)  – Reasonable access  – *SSAC concurs with the recommendation as written*   *Recommendation #28*- Implementation Transition Period  – *SSAC concurs with the recommendation as written*     As always, please reach out if we can provide any additional context or clarification.     -Ben