[Gnso-epdp-team] FW: Responses to rr input

Wed Jul 31 17:04:20 UTC 2019

**

*Hello,*

***

Thanks for your patience as we worked through these open topics. For
ease of reading, I will include only the specific sections to which we
are responding, having already reached agreement in the other areas. 

● In section (c), there is the expectation that not only redacted data
is provided in the

SSAD, but also data which are publicly available. The SSAD should be
restricted to

providing only non-public registration data which was previously public,
and should not

include currently-public data.

> We feel this gives an increased accuracy in processing the data, could you give a reason why this data should not be given by the disclosing party.

Our initial input on this section was intended to focus disclosure
responses on the non-public data, since public registration data can be
easily obtained in various ways. That said, we do agree that it is
important to streamline this process to the greatest extent possible,
and so we can accept this requirement in the interests of providing a
prompt investigation flow.

● Section (d) indicates the “Lawful basis of entity disclosing
non-public registration data to

the requestor” as 6 (1) f (legitimate interest). This is acceptable as
the basis on which the

disclosing entity provides the data, however we do note that the
requestor needs to also

indicate the legal basis for the request itself, which is likely to be 6
(1) e (public interest)

> Legal basis for the requestor is under section e

The section (e) response says: “The GDPR explicitly recognizes the
importance of data processing for the “Prevention, investigation,
detection or prosecution of criminal offences data processing is also
permissible in the event of objection by the data subject. This interest
is also explicitly recognized for data transfers to non-EU countries,
Art. 49 (1) (e) GDPR.”  

This does not appear to specify a legal basis for the disclosure, which
we had expected to see here, other than the GDPR as a whole. However,
the purpose of this section (e) is “Supporting info to determine lawful
basis for the requestor” so perhaps it’s not necessary to specify here,
and instead this section would need to include more contextual
information including information about the alleged crime being
investigated, etc, from which a legal basis can be arrived at. 

● In section (e), jurisdiction should also be part of the supporting
info that is provided with

the disclosure request, and there are related questions that the plenary
team should

consider. E.g., does an LEA have the authority to request non-public
data from a

non-local controller and does the non-local controller have a legal

obligation/dispensation to provide such data to a foreign LEA.

> If the requestor is using 6.1f then no compulsion from the LEA is being used. Having the authority to request data would be dealt with under by accreditation /authentication but must be confirmed before release safeguard suggestion below would hopefully cover this?

Our team is having trouble understanding what is intended by the
accreditation/authentication reference here. Perhaps you could elaborate?

● In section (g), the disclosing entity should have an additional
safeguard: they must be

enabled to verify the legal authority of the LEA to make the request.

> Via a accreditation /authentication method?

Verification and authentication are two separate processes that
eventually lead to a situation where a request can be made. However, the
receiving party of the request will have to verify the request to ensure
that the requesting party does have the authority to make the request,
which may not be assumed based on their accreditation (although perhaps
it could be). The system that we create should have this built in.  

● Also in section (g), the RrSG notes the addition of this text: “The
data subject should be

able to challenge–with proper substantiation—the balancing test with
rights to object and

to erasure.” The right to erasure would seem to apply not to data
disclosed through the

SSAD but instead to the data held by the Controller; how would the right
to erasure be

operationalized here?

> Applicable to the disclosuring body so an erasure in this case would be removal of the Domain name and all related records assuming they are the rr/ry else another body would be the deletion of any records held (assuming any are held).

Does this “removal of the Domain name and all related records” mean
removal from the SSAD or from the Registrar/Registry who holds the data
which is disclosed via the SSAD? The SSAD will not necessarily hold the
registration data, instead it could pass the data through when needed
and keep logs showing what was done, without retaining the disclosed
data. In that case, there would be no data to erase from SSAD, unless
this referred to the requestor’s data? And if it referred to the erasure
from Registrar or Registry, that request would need to be directed to
them, not to the SSAD operator. The inclusion of the right to erasure
here does not seem to fit.

● Also in (h), the RrSG is pleased to note that the disclosure is
limited to the current

registration data set, and will not include historical records. We would
suggest also that

this be limited to specific domains, bulk requests should not be considered.

> By bulk do you mean unrelated or do you mean multiple domains?

We meant multiple, but unrelated applies here as well.

● Section (j) is strangely worded and the RrSG could not parse the
intent of the section;

we would appreciate clarification from the GAC team.

> From earlier input we would suggest adding jurisdiction and  legal basis to this  

That would be helpful, agreed. Does the GAC team plan to update the
redlined use case again, to incorporate this and the other input and
discussion above?

There was a further point re SLA, which was also the focus of
significant discussion a recent team call. Sorting out SLA questions
should remain as a larger issue and not be specific to one use case, so
we won’t address that further in this thread. 

For section (n), desirability of automation, we agree that further
discussion would benefit.

Thank you,

Sarah W

*

-- 
Sarah Wyld
Domains Product Team
Tucows
+1.416 535 0123 Ext. 1392

On 7/25/2019 10:09 AM, LEWIS-EVANS, Christopher wrote:
>
> *OFFICIAL *
>
>  
>
>  
>
> Afternoon all sorry for the response overlapping the meeting, please
> find responses to the questions in red below which we will cover in
> todays meeting.
>
>  
>
> Regards
>
> Chris
>
>  
>
>  
>
> The RrSG has reviewed the LEA1 use case provided by the GAC team, and
> has the following
>
> feedback.
>
> ● In section (b), the RrSG is pleased to see the request limited to
> “Non-public registration
>
> data,” and affirms that this SSAD must not be used to disclose other
> data that may be
>
> held by the Controller, it should be limited only to previously-public
> registration data.
>
>  
>
>  
>
> ● In section (c), there is the expectation that not only redacted data
> is provided in the
>
> SSAD, but also data which are publicly available. The SSAD should be
> restricted to
>
> providing only non-public registration data which was previously
> public, and should not
>
> include currently-public data.
>
> We feel this gives an increased accuracy in processing the data, could
> you give a reason why this data should not be given by the disclosing
> party.
>
>  
>
> ● For section (c), the RrSG notes that the footnote “For each request,
> the requestor will
>
> need to confirm which data elements are necessary.” is a part of the
> template, and may
>
> not be understood to be a mandatory part of the use case and any
> disclosure request. It
>
> should be clarified that the requestor must request only the minimum
> relevant data, and
>
> the Controller should disclose only the minimum relevant data.
>
> Agree change.
>
>  
>
> ● Section (d) indicates the “Lawful basis of entity disclosing
> non-public registration data to
>
> the requestor” as 6 (1) f (legitimate interest). This is acceptable as
> the basis on which the
>
> disclosing entity provides the data, however we do note that the
> requestor needs to also
>
> indicate the legal basis for the request itself, which is likely to be
> 6 (1) e (public interest)
>
> Legal basis for the requestor is under section e
>
>  
>
> ● In section (e), jurisdiction should also be part of the supporting
> info that is provided with
>
> the disclosure request, and there are related questions that the
> plenary team should
>
> consider. E.g., does an LEA have the authority to request non-public
> data from a
>
> non-local controller and does the non-local controller have a legal
>
> obligation/dispensation to provide such data to a foreign LEA.
>
> If the requestor is using 6.1f then no compulsion from the LEA is
> being used. Having the authority to request data would be dealt with
> under by accreditation /authentication but must be confirmed before
> release safeguard suggestion below would hopefully cover this?
>
>  
>
>  
>
> ● For section (f), we propose an additional safeguard: The requestor
> must be endowed
>
> with the appropriate legal authority to make such a request of a
> non-local controller.
>
> Agree change
>
>  
>
> ● In section (g), the disclosing entity should have an additional
> safeguard: they must be
>
> enabled to verify the legal authority of the LEA to make the request.
>
> Via a accreditation /authentication method?
>
>  
>
> ● Also in section (g), the RrSG notes the addition of this text: “The
> data subject should be
>
> able to challenge–with proper substantiation—the balancing test with
> rights to object and
>
> to erasure.” The right to erasure would seem to apply not to data
> disclosed through the
>
> SSAD but instead to the data held by the Controller; how would the
> right to erasure be
>
> operationalized here?
>
> Applicable to the disclosuring body so an erasure in this case would
> be removal of the Domain name and all related records assuming they
> are the rr/ry else another body would be the deletion of any records
> held (assuming any are held).
>
>  
>
> ● The section (h) description has been updated to specify an automated
> system; this is not
>
> necessarily what the SSAD will require. It may be that an SSAD
> functions best when the
>
> expectation is manual review rather than automated processing; the
> decision has not yet
>
> been made and should not be presumed.
>
> Think this and other sections are what if this was agreed
>
>  
>
> ● Also in (h), the RrSG is pleased to note that the disclosure is
> limited to the current
>
> registration data set, and will not include historical records. We
> would suggest also that
>
> this be limited to specific domains, bulk requests should not be
> considered.
>
> By bulk do you mean unrelated or do you mean multiple domains?
>
>  
>
> ● In section (i) the RrSG again objects to the addition of “automatic”
> to the section
>
> description.
>
> This and other sections are provided along the lines of what if this
> was agreed
>
>  
>
>  
>
> ● Section (j) is strangely worded and the RrSG could not parse the
> intent of the section;
>
> we would appreciate clarification from the GAC team.
>
> From earlier input we would suggest adding jurisdiction and  legal
> basis to this  
>
>  
>
> ● In section (m) the required timeframe for a substantive response is
> 2 business days. This
>
> is not a sufficient period of time to review and address requests.
> Recommendation 18 of
>
> the EPDP Phase 1 Report gives 2 business days for acknowledging
> receipt of a request;
>
> we should not now modify this to require substantial response in that
> same 2 day period.
>
> If there will be any SLA in place, there should also be an exception
> to allow for manual
>
> processing of complex or questionable requests.
>
> As this is just for LEA use cases we believe this is a viable time
> frame for the expected volume within this subset.
>
>  
>
> ● The RrSG does not agree with section (n), that automation of the
> substantive response
>
> is possible/desirable. Requests must be reviewed so that the balancing
> test can be
>
> performed, which is difficult to automate. It may be that a
> hybrid-style system is useful, in
>
> which an automated system does a first pass and then a human reviews
> the results and
>
> completes the disclosure.
>
> Worth further discussion
>
>  
>
>  
>
>  
>
>  
>
> The NCA email domain has changed to @nca.gov.uk. To ensure your email
> gets through please do not use @nca.x.gsi.gov.uk
>
> ************************
>
> This information is supplied in confidence by NCA, and is exempt from
> disclosure under the Freedom of Information Act 2000. It may also be
> subject to exemption under other UK legislation. Onward disclosure may
> be unlawful, for example, under data protection legislation. Requests
> for disclosure to the public must be referred to the NCA FOI single
> point of contact, by email on PICUEnquiries at nca.gov.uk
> <mailto:PICUEnquiries at nca.gov.uk>.
>
>  
>
> All E-Mail sent and received by NCA is scanned and subject to
> assessment. Messages sent or received by NCA staff are not private and
> may be the subject of lawful business monitoring. E-Mail may be passed
> at any time and without notice to an appropriate branch within NCA, on
> authority from the Director General or their Deputy for analysis. This
> E-Mail and any files transmitted with it are intended solely for the
> individual or entity to whom they are addressed. If you have received
> this message in error, please contact the sender as soon as possible.
>
>  
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
> _______________________________________________
> 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) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190731/9e3c0f08/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190731/9e3c0f08/signature-0001.asc>