** *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@nca.gov.uk <mailto:PICUEnquiries@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@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.