[ODP-SSAD] Request for verification/feedback on SSAD recommendations

Thu Oct 21 14:36:33 UTC 2021

Dear Yuko,
Thank you for clarification of the question. Pls see below my answers to
both of them:

*Automation of Disclosure Request Processing*

Per recommendation 9.4, only the following categories are considered to
meet the criteria for automated processing of data disclosure:

·  Requests from Law Enforcement in local or otherwise applicable
jurisdictions with either 1) a confirmed GDPR 6(1)e lawful basis or 2)
processing is to be carried out under a GDPR, Article 2 exemption;

·  The investigation of an infringement of the data protection legislation
allegedly committed by ICANN/Contracted Parties affecting the registrant;

·  Request for city field only, to evaluate whether to pursue a claim or
for statistical purposes;

·  No personal data on registration record that has been previously
disclosed by the Contracted Party.

*Question 2: We note the first bullet specifically references the GDPR. Our
understanding is the above categories were included in the legal guidance
provided to the EPDP Team, and the legal guidance specifically referenced
the GDPR. Our assumption is the EPDP Team considered this guidance in
developing this recommendation but did not intend to exclude privacy laws
outside the GDPR. In other words, though this first use case only
references the specific scenario in which a law enforcement requestor has a
legal basis for processing under GDPR 6(1)e (or whose processing is
explicitly exempted from GDPR’s restrictions on data processing), other law
enforcement authorities who are outside the EU might also qualify for
automated disclosure if they have a comparable legitimate interest in
processing such data under their own local law. Can you please confirm if
this assumption is correct (or if, conversely, the intention was only for
EU law enforcement requests to have the potential for automation under this
use case)? *

The assumption is correct.  Even EPDP was created to develop ICANN policy
to accommodate the GDPR requirements, the EPDP Team took broader approach
and attempted to formulate recommendations that would correspond not only
to the GDPR, but also to all existing and possible future privacy
regulations in different parts of the world. Reference to specific
provisions of GDPR in 9.4.1 is evident as it was existing regulation at the
time of the formulation of the recommendation.

The areas identified in the SSAD that interact with ICANN Contractual
Compliance, like requestor/data subject procedural complaints and
Contracted Party SLA issues, appear to integrate well within the existing
processes that ICANN Contractual Compliance employs. For instance, the
complaints from requestors and *data subjects* could come through external
facing complaint forms that would be developed, and if needed, automated
processes may be developed for processing issues such as those related to
SLA violations. From there, the complaints can be processed per ICANN
Contractual Compliance’s standard approach and processes.

*Question 1: Does the proposed approach regarding development of potential
complaint forms or automated notifications (where possible) fulfill the
intentions of the recommendations?*

Indeed, it was intention – to use the existing ICANN compliance mechanism
in case the requestors or registries/registrars could file a compliance
complaint in situations prescribed by the policy recommendations.

It was never planned, though, that data subjects would be able to use
ICANN's compliance mechanism.

On Wed, Oct 20, 2021 at 10:43 PM Yuko Yokoyama <yuko.green at icann.org> wrote:

> Dear Janis,
>
>
>
> As discussed during today’s call, here is the additional context behind
> the question 1:
>
>
>
> The areas identified in the SSAD that interact with ICANN Contractual
> Compliance, like requestor/data subject procedural complaints and
> Contracted Party SLA issues, appear to integrate well within the existing
> processes that ICANN Contractual Compliance employs. For instance, the
> complaints from requestors and data subjects could come through external
> facing complaint forms that would be developed, and if needed, automated
> processes may be developed for processing issues such as those related to
> SLA violations. From there, the complaints can be processed per ICANN
> Contractual Compliance’s standard approach and processes.
>
>
>
> *Question 1: Does the proposed approach regarding development of potential
> complaint forms or automated notifications (where possible) fulfill the
> intentions of the recommendations?*
>
>
>
> Please let me know if we may provide any further clarifications.
>
>
>
> Regards,
>
> Yuko
>
>
>
> *From: *Yuko Green <yuko.green at icann.org>
> *Date: *Monday, October 18, 2021 at 1:59 PM
> *To: *Janis Karklins <karklinsj at gmail.com>
> *Cc: *"odp-ssad at icann.org" <odp-ssad at icann.org>
> *Subject: *Request for verification/feedback on SSAD recommendations
>
>
>
> Dear Janis,
>
>
>
> As we continue to develop Org’s assessment for the SSAD ODP, we came to
> additional questions/assumptions that we would like GNSO Council’s
> confirmation and/or clarifications.
>
> *Contractual Compliance*
>
> In the SSAD, there are two areas that implicate ICANN Contractual
> Compliance intervention:
>
>    1. Alert mechanisms/complaints regarding Contracted Party behavior
>    (Recs 5.3, 5.4)
>
> The recommendation states the “alert mechanism is not an appeal mechanism
> – to contest disclosure or non-disclosure affected parties are expected to
> use available dispute resolution mechanisms such as courts or Data
> Protection Authorities…”
>
>
>
> As a result, Compliance’s role is limited to investigating complaints
> related to procedural failures by the contracted party.
>
>
>
>    1. Contracted Party SLA requirements (Rec 10)
>
>
>
> Similar to existing processes, complaints or investigations related to
> contracted party requirements for SSAD may be received and processed
> through public-facing complaint forms that feed into the Naming Services
> portal (NSp) and result in individual cases.
>
>
>
> If needed, develop automation of complaints related to violations as those
> may be triggered from internal reporting.
>
>
>
> *Question 1: Does the proposed approach regarding development of potential
> complaint forms or automated notifications (where possible) fulfill the
> intentions of the recommendations?*
>
> *Automation of Disclosure Request Processing*
>
> Per recommendation 9.4, only the following categories are considered to
> meet the criteria for automated processing of data disclosure:
>
>    - Requests from Law Enforcement in local or otherwise applicable
>    jurisdictions with either 1) a confirmed GDPR 6(1)e lawful basis or 2)
>    processing is to be carried out under a GDPR, Article 2 exemption;
>    - The investigation of an infringement of the data protection
>    legislation allegedly committed by ICANN/Contracted Parties affecting the
>    registrant;
>    - Request for city field only, to evaluate whether to pursue a claim
>    or for statistical purposes;
>    - No personal data on registration record that has been previously
>    disclosed by the Contracted Party.
>
>
>
> *Question 2: We note the first bullet specifically references the GDPR.
> Our understanding is the above categories were included in the legal
> guidance provided to the EPDP Team, and the legal guidance specifically
> referenced the GDPR. Our assumption is the EPDP Team considered this
> guidance in developing this recommendation but did not intend to exclude
> privacy laws outside the GDPR. In other words, though this first use case
> only references the specific scenario in which a law enforcement requestor
> has a legal basis for processing under GDPR 6(1)e (or whose processing is
> explicitly exempted from GDPR’s restrictions on data processing), other law
> enforcement authorities who are outside the EU might also qualify for
> automated disclosure if they have a comparable legitimate interest in
> processing such data under their own local law. Can you please confirm if
> this assumption is correct (or if, conversely, the intention was only for
> EU law enforcement requests to have the potential for automation under this
> use case)? *
>
>
>
> We would very much appreciate your help in relaying these questions to the
> GNSO Council. If you have any questions, please do not hesitate to contact
> us.
>
>
>
> Regards,
>
>
>
> Yuko Yokoyama
>
> Program Director
>
> Strategic Initiatives, Global Domains & Strategy
>
> Internet Corporation for Assigned Names and Numbers (ICANN)
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/odp-ssad/attachments/20211021/02a28358/attachment.html>