_______________________________________________Hi all,
following up on our discussion in Prague Let me summarize how I think we can frame and advance the discussion in preparation for the September meeting.
ICANN and the issue of handling LEA disclosure requests at the global level.
When it comes to processing disclosure requests from law enforcement authorities (LEAs) there still seems to be a lot of confusion and different expectations by different parts of the ICANN community with respect to process and outcome.
The topic was discussed in the EPDP, in related IRT (currently with respect to urgent requests) and in the RDRS Standing Committee. The issue is also relevant to work on DNS Abuse.
The two main areas of concern seem to be:
- Authentication (and accreditation) of LEAs.
- How can Contracted Parties interact with LEAs? Some say CPs are required to disclose if an LEA and should ideally automate the process. Others say that – once authenticated – LEA requests still need to be duly substantiated and a disclosure will only occur if so possible in a legally compliant manner after a legal assessment.
Whilst the community spent considerable time discussing LEA interaction, a structured analysis of the legal implications in particular and work on solutions has never occurred. However, both questions need to be answered in order for the interactions between CPs and LEAs to work.
Even if there were a mechanism for authenticating LEAs (which does not currently exist), a distinction needs to be made between various scenarios. These are:
- CP and LEA are both in the same jurisdiction
- CP and LEA are in different jurisdiction, but a legal framework exists (e.g. a mutual legal assistance treaty)
- CP and LEA are in different jurisdictions, but no international agreement exists.
Depending on the case in question
- a CP might be legally required to disclose if a legal basis exists and legal requirements are met,
- a CP might have the option to disclose,
- an LEA might need to work with the LEA in the jurisdiction where the CP is established, or
- a disclosure might not be possible.
So far, our discussion does not seem to have that level of nuance, but it appears that it not possible to use an approach that works at the global level.
The risk for ICANN and its community
ICANN can produce policies that are binding for the CPs. However, in order for LEA interaction to work at the global level, measures need to be taken by LEAs and governments, but these cannot be obliged by ICANN to act.
Not only does the ICANN community need LEA’s / governments’ support with an authentication regime for LEAs, but it may also be the case that the legal instruments that currently exist do not allow for an efficient collaboration between LEAs and CPs at the global level.
If this issue is not flagged and worked on, we as the GNSO Council, will allow for a perception within and outside our community to be solidified that the GNSO and ICANN is not able to come to workable solutions to this issue, that the multistakeholder approach is now effective and that CPs are not willing to cooperate with LEAs.
A constructive way forward
The GNSO Council should take the initiative and invite the GAC / PSWG and the ICANN Board to a meeting or a series of meetings to flag the issue and manage expectations. If other fora should be used or the discussion should be triggered differently, we should discuss these.
We should highlight that ICANN cannot task third-parties, but that third-party support is needed. We should emphasize that ICANN and its community will continue to work on framework and technical solution that can facilitate the match-making between LEAs and CPs, but that we need to base this on a thorough analysis of the legal implications for CPs and ICANN taking into account the risks of unlawful disclosure for registrants.
Best,
Thomas
council mailing list -- council@icann.org
To unsubscribe send an email to council-leave@icann.org
_______________________________________________
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.