Hi, Volker. You mentioned that I failed to note your concerns in the v2.00 doc. Please let me explain my reasoning, inline below, I thought I actually covered most of them. I am sorry for lack of clarity. For non-Volker-specific clarifications, please see separate email later today. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Volker Greimann Sent: Monday, February 3, 2020 2:11 AM To: gnso-epdp-team@icann.org Subject: [EXTERNAL] Re: [Gnso-epdp-team] SSAD Use Cases which are automatable Hi Mark, I think we can agree on use case 1. [Mark Svancarek] ok Use case 2 has the issues I outlined in my mail to Brian. I doubt that any TM claim can be as clear cut as you assume. [Mark Svancarek] Since Trademark is going to be Thunderdome, I selected a strawman to kick off the deathmatch. I chose Thomas’ feedback to be that strawman for several reasons, not just because it was my favorite 😉 although it was in fact my favorite Use case 3 should be ok in most cases, but it might break down in smaller towns or villages in the countryside where there are only 5-10 houses and two familiy names. Naming the city field there could already considered as providing personal information. But I give you that one as an extreme edge case, in most cases it should be fine. [Mark Svancarek] I added the safeguard that the City field can only be used for this limited purpose and discarded if the other data are to be collected. Use case 4 is generally possible, I assume, but it may be helpful to add additional safeguards here to prevent abuse of this process to circumvent the existing redactions. [Mark Svancarek] I failed to include your statement about desirability of additional safeguards. That’s my fault. Use case 5 requires ICANN accepting its controllership (as you outlined) and a need for the specific data. If the investigation is possible with redacted data, the need for this processing activity goes away. Data accuracy investigations are not an ICANN remit for example, but the investigation of a registrars obligation to the same is. [Mark Svancarek] I should have removed the example of accuracy, since we aren’t agreed on it. That’s also my fault. I do wonder if we need to be so specific here that if an investigation doesn’t require non-public data, it shouldn’t be requested – I feel like that is made clear throughout our work, so I did not explicitly include it here. (It’s our old debate whether repetition creates clarity or if it just adds redundancy.) Use case 6 only applies if the DPA is competent for the disclosing party. I think this could be merged with use case 1. [Mark Svancarek] I moved to the LEA use case and added “competent” Use case 7 could be made workable, however there should be a verification element included in the reegistry policies to avoid registrants who circumvented an unchecked policy requiry. [Mark Svancarek] I downgraded the use case to just a NOTE in another use case, and added verification safeguard Use case 8 will need to be further investigated for validity of the consent provided at registration. [Mark Svancarek] I downgraded the use case to just a NOTE in another use case, and the verification safeguard applies there as well Use case 9: You mean domain name, not TLD? The problem is that this can change at any time, and ownerchanges are not necessarily listed as a "domain updated" event. And the SSAD system would not know whether an update to the registration data has occurred. [Mark Svancarek] Fixed TLD typo. Eliminated change of ownership, replaced with change of any contact fields. I am working from assumption that UPDATED DATE field will support this. Use case 10: Same issue as UC 9. Also please detail how an automated process would detect "patently false information". [Mark Svancarek] Downgraded the use case to just a NOTE in another use case. Added caveat that the flagging requires action by the CP; failed to say that this action is not doable by the Gateway. Use case 11: There is no use case 11? [Mark Svancarek] Case 11 was lost in a tragic copy/paste accident. UC 12: "Involved in" also includes victims of website hacking? Then no. [Mark Svancarek] I didn’t think my examples included website hacking, so I am sorry if this remains unclear! Perhaps change the title to “Identify domains names comprising infrastructure involved in botnets…”? UC 13: How would the SSAD system detect phishing activity? Also see my comments in my mail to Brian. [Mark Svancarek] SSAD can’t detect it, but a requestor can assert it under penalty of losing accreditation. Bonus: UC 14: Domain flagged by disclosing party as disclosable. Not sure how this would be implemented, but I would assume we would want an ability for a data subject to consent to automated disclosure, or for a contracted party to determine whether automated disclossure is possible for any given domain name. [Mark Svancarek] I added this one. These thoughts are my own, we have not yet internally discussed on the team. Best, Volker Am 27.01.2020 um 22:16 schrieb Mark Svancarek (CELA) via Gnso-epdp-team: Feedback requested. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C05087940197a46ac3aa408d7a8917bbd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637163215109633801&sdata=uG9B%2Foi%2FIQSVC33BeTm%2BM5xwWEohJybAgd0VIxIxNi0%3D&reserved=0> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C05087940197a46ac3aa408d7a8917bbd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637163215109643796&sdata=IbNC0Cn1k%2BmV2Nb6ezzC2ztNEgDuzd4oxFNrG5s0EVY%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C05087940197a46ac3aa408d7a8917bbd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637163215109643796&sdata=H5nBxmgqOLoduOmNrZnOatSGhmPPddICnz%2F2lEdyrcQ%3D&reserved=0>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sys...> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.