Dear Councilors, Please note the following update from Janis on the SSAD ODP as well as the reminder of the webinar which will take place tomorrow Thursday. It's a late addition but we will try to review this during the AOB agenda, to agree on a timeline for council to provide any feedback we may have on these assumptions. Thanks. Philippe From: Janis Karklins <karklinsj@gmail.com> Sent: Wednesday, November 17, 2021 5:15 PM To: FOUQUART Philippe INNOV/NET <philippe.fouquart@orange.com> Cc: Caitlin Tubergen <caitlin.tubergen@icann.org>; Yuko Green <yuko.green@icann.org> Subject: SSAD ODP update The SSAD ODP team reminded me of the upcoming webinar, which will take place on Thursday, 18 November 2021 at 16:00 UTC. The webinar will focus on the business process and system designs of the SSAD with the aim of soliciting feedback from the community. For those interested in joining the webinar, please be sure to register in advance by following this registration link<https://icann.zoom.us/webinar/register/WN_wJWalmmZSW2oRRJ_xkZ1yQ>. Additionally, if you missed the previous update on the SSAD ODP from ICANN72, which focused on contractual compliance and identity verification, you can read the blog recapping the webinar here<https://www.icann.org/en/blogs/details/ssad-odp-update-contractual-complianc...>. The SSAD ODP project team identified two additional questions and assumptions they wished to discuss with me regarding Recommendation 1 and Recommendation 9. The assumptions and my responses are annexed to this message for your information. As a reminder, the SSAD ODP project team plans, pending no objection from the GNSO Council, to proceed with its work on the basis of these assumptions and my responses thereto. Finally, having heard no objections or concerns to the questions and assumptions from my 26 October 2021 message<https://mm.icann.org/pipermail/council/2021-October/025119.html> to the Council, the ODP team will proceed with its work on the basis of these assumptions. I plan to meet with the SSAD ODP project team again in December and will provide another update at that time. Please let me know if you have any questions. Best regards JK Question 1: Recommendation 9.4 states: Per the legal guidance obtained (see Advice on use cases re automation in the context of disclosure of non-public registrant data<https://community.icann.org/download/attachments/111388744/ICANN_Automation%...> - April 2020), the EPDP Team recommends that the following types of disclosure requests, for which legal permissibility has been indicated under GDPR for full automation (in-take as well as processing of disclosure decision) MUST be automated from the time of the launch of the SSAD: Recommendation 9.4.4 states: No personal data on registration record that has been previously disclosed by the Contracted Party. ICANN org understands this mandatory automated use case 4 to apply only when a contracted party has notified the central gateway operator that this use case applies for a specific domain name, as the central gateway operator would not know which domain names' registration data contain no persona data, or if the CPs have previously disclosed the data on the ground of use case 4. Can you please confirm this is the intent of the Policy Recommendation? In principle your assumption is correct. Subpoints of Rec 9.4 list all cases where automation of response is possible from the first day of operation of SSAD. GDPR does not regulate access/disclosure of registration data that does not contain personal information. Question 2: As you can see in our briefing from ICANN72 presentation concerning identity verification, ICANN org understands the EPDP recommendations to contemplate two different types of accredited SSAD users who may be associated with a legal person: (a) individuals who are affiliated with an org (e.g. an employee), and (b) individuals who represent an org (such as an outside counsel, brand management firm, etc). For each of these types of individuals, we are expecting that the accreditation authority will first verify the individual's identity, and then the individual's association with the legal person. The individual's association with the legal person would be a "declaration" tied to the individual's accreditation, which takes into account that one individual could be associated with more than one legal entity who has individuals using the SSAD. This is the "signed assertion" concept referenced in the EPDP Team's Final Report. One issue we will need to resolve during implementation is how to manage multiple individuals' associations with the same legal entity. Can you let us know if the approaches we've identified are aligned with the community expectations in this regard, if not, can you share any additional thinking regarding the community expectations? The first approach we identified was that each individual's association with a legal entity will need to be individually verified (so that even if one person has demonstrated an association with an entity, the second, third, fourth, etc individuals will also need to do the same). Alternatively, a second, alternative, approach would be that once one person is accredited and associated with a legal entity in the SSAD, additional individuals claiming association with the legal entity could be added (or verified) by the initial individual to gain accreditation and be associated with the entity. However, this approach may raise operational challenges, particularly in large, global entities that may have many individuals seeking SSAD accreditation. This also may not work in cases where the first individual accredited and associated with an organization is an organizational representative, since a representative may not be able to verify individuals within the org, or other individuals who represent the org. Intention of the SSAD Team was provide a simple and efficient accreditation mechanism. It contains two elements : identity element, affiliation/ representation element. In practice, for use of SSAD each organization/company can define its own modus operandi. It can decide to be represented by one individual, or by several. Equally, an individual may interact with SSAD on behalf of one or several organizations/companies. In all cases affiliation or representation should be confirmed by a documental proof during the accreditation process. Orange Restricted _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.