Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
|
||
On June 9, CircleID published an insightful article by Thomas Rickert entitled “Demystifying Art 28 NIS2.” In that piece, Thomas set forth two alternative interpretations of Article 28(6) of NIS2 and argued that TLD registries should not be required to maintain a separate database of the registrant data under NIS2. In my view, Thomas’ approach is inconsistent with the remainder of Article 28 and would not achieve the goals of NIS2 to improve cybersecurity across the EU member states.
Thomas identifies two interpretations of NIS2’s non-duplication language:
Thomas noted that: “The first alternative would only prevent a duplication of the interaction with the registrant, but still require maintaining multiple databases, dealing with the verification of registration data, making non-personal registration data publicly available, and providing access to non-personal registration data. Was it really the legislator’s intention to require such an approach which would not only require the duplication, but the multiplication of all but one of the obligations laid down in Art. 28 (1) to (5) NIS2?”
Thomas posited that the answer to that question was “no” and that the second interpretation was the correct one. In my view, however, the first interpretation is the correct one.
There is clear evidence that it was the EU co-legislators’ intention to require that both TLD registries and entities providing domain name registration services comply with the obligations set forth in Article 28(1) to (5) except with respect to collection of the WHOIS data from the data subject.
As Thomas noted, the language of Art 28(6) was added at the last minute. However, when it was first proposed in June 2022, following the conclusion of the trilogue among the EU co-legislators, it read as follows:
“5a. Compliance with the obligations laid down in paragraph 1 to 5 shall not result in a duplication of collecting and maintaining domain name registration data. To that effect, Member States shall require that TLD name registries and the entities providing domain name registration services cooperate for the purposes of ensuring compliance with this Article.” (See Article 23 Council’s proposal)
Following pushback by a number of organizations, including the European Union Cybercrime Task Force, this language was changed in the final text of the Directive. The avoidance of duplication only applies to “collecting domain name registration data.” The word “maintaining” was specifically deleted from this last paragraph of Article 28. Therefore, it seems clear that the first interpretation (alternative 1) of final Article 28(6) is the correct one. The only duplication that is to be avoided is collecting the data from the data subject. Registries and entities providing domain name registration services are each required to maintain their own, independent databases of “accurate and complete domain name registration data.” As Thomas correctly notes, this requires transfer of the collected data from registrars (or other registration services such as privacy/proxy services) to the TLD registries.
I do agree with Thomas that the “data minimization” principle under the GDPR may, at first glance, seem inconsistent with the Article 28’s requirement of data being held in duplicate databases. However, this principle applies to the personal data to be collected to ensure that it is “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed.” From this perspective, because NIS2 specifies the data fields necessary for collection and requires registries to have a complete, accurate, and verified database, it is necessary to have thick WHOIS in relation to the purposes for which they are processed—i.e. to comply with the law. Moreover, it is important to note that the GDPR rules are applied with flexibility and in accordance with a balancing test. As set forth in Recital 4 of the GDPR “The right to protection of personal data is not an absolute right; it must be considered in relation to its function in society and be balanced against other fundamental rights, in accordance with the principle of proportionality.”
In the NIS2 Directive, the EU has determined that the duplication of holding accurate and complete domain name registration data in dedicated databases contributes to the security, stability and resilience of the DNS. Indeed, ICANN and the multistakeholder community came to the same conclusion in 2014 when it adopted a “Thick WHOIS” policy that required all gTLD registries to maintain an independent database of complete and accurate domain name registration data. The reasons for adopting this “Thick WHOIS” policy requirements were set forth in the October 2013 Final Report on the Thick WHOIS Policy Development Process (see link). These stated reasons and benefits include: (i) improving stability, (ii) improving response consistency, (iii) improving security by more copies of escrowed data in the event of a Registrar’s failure (e.g., bankruptcy), and (iv) providing a more level playing field between registry providers.
It is important to note that in 2019, ICANN obtained a written legal opinion from its European outside counsel, Bird & Bird, concerning whether the Thick WHOIS policy complied with the GDPR, including the international transfers of registration data that would be required from EU based registrars to U.S. based registries. Bird & Bird concluded that the policy, including the required international transfers of personal data, is compatible and in accordance with the GDPR. Bird & Bird made the following clear conclusions in its written legal advice:
“The thick Whois policy is animated by a desire to improve stability, security and reliability of the gTLD registration system. These will be considered legitimate interests under the GDPR. The benefits of this policy accrue not only to registries and registrars, but also to third-parties that rely on being able to access Whois data, such as rights holders and law enforcement.” Note that this legal opinion from Bird & Bird is publicly available on ICANN’s website and may be found at this link.
The same rationales set forth by Bird & Bird apply to the requirements of Article 28 and justify the duplication of data, including personal data, being held by both registries and registrars. Indeed, given the mandates of Article 28 paragraphs (1) -(5), there is now an even stronger legal basis for this duplication. As clearly explained in Recital (109) of the NIS-2 Directive, “TLD name registries and entities providing domain name registration services should be required to process certain data necessary to achieve that purpose [maintaining accurate and complete databases of WHOIS data and providing lawful access to such data]. Such processing should constitute a legal obligation within the meaning of Article 6(1), point (c), of [the GDPR].”
For all of these reasons, in addition to the other explanations given by Michael Palage in his published comment on Thomas’ article, it appears clear that the first interpretation (alternative 1) set forth in Thomas’ article is the correct interpretation of Article 28(6).
On May 17, Belgium published its national law implementing the NIS2 Directive. (See: https://www.ejustice.just.fgov.be/eli/loi/2024/04/26/2024202344/justel ). With respect to Article 28’s requirements, Belgium sets forth in Article 94 of its law several helpful provisions, including the following:
“Compliance with the obligations referred to in this article must not result in unnecessary repetition of the collection of domain name registration data from the data subject. For this purpose, top-level domain name registries and entities providing domain name registration services cooperate with each other.” Thus, Belgium clearly understands and mandates that Article 28(6) conform to the first interpretation (alternative 1) that Thomas explained.
Belgium’s law also requires that both top-level domain name registries and entities providing domain name registration services immediately block the operation of a domain name and prevent it from being transferred if the registration/WHOIS data are incorrect, inaccurate or incomplete. Clearly for a registry to comply with this obligation, it must control and process the registration data and engage in its own verification procedures. Belgium explicitly sets forth these requirements in its national law as follows:
“If the domain name registration data listed in paragraph 1(2) [which includes the name of the domain name holder, his email address and his telephone number; and the email address and telephone number allowing you to contact the contact point which manages the domain name, if these contact details are different from those of the holder] of a domain name are incorrect, inaccurate or incomplete, top-level domain name registries and entities providing domain name registration services shall immediately block the operation of that domain name until the domain name holder corrects the registration data so that they become correct, accurate and complete. If the domain name registrant fails to do so within the time period established by the top-level domain name registry or the entity providing domain name registration services, the domain name is canceled. Transfer of a blocked domain name to another entity providing domain name registration services is prohibited.”
In providing greater detail in its national law, Belgium is fulfilling the goals of Article 28 of NIS2 and will be contributing towards a higher level of cybersecurity. Hopefully, other Member States of the EU will follow Belgium’s excellent example.
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byCSC
Sponsored byRadix
Sponsored byDNIB.com
A World-Renowned Source for Internet Developments. Serving Since 2002.
In my opinion, the NIS2 Directive does not prohibit thick WHOIS registries from transitioning to a thin WHOIS model as permitted by the ICANN RDS policy. The NIS2 Directive’s primary aim is to ensure a high level of cybersecurity across the EU, requiring entities involved in domain name registrations to collect and maintain accurate and complete domain name registration data. However, it does not specify the data management model that registries must use.
The ICANN RDS policy allows for both thick and thin WHOIS models. In a thin WHOIS model, the registry maintains a limited set of registration data, with the registrant’s contact information held by the registrar. This model is recognized as a legitimate approach to WHOIS data management and aligns with the GDPR’s principle of data minimization, as it involves fewer entities holding complete sets of personal data.
The NIS2 Directive provides flexibility in how its requirements can be implemented, allowing for different operational models, including the possibility of transitioning from a thick to a thin WHOIS model, as long as the core objectives of the Directive are met. Registrars will meet that that objective, as it has been for years, ie Verisign.
There is precedent for registries operating under a thin WHOIS model, and the practice is well-established within the domain name industry. The NIS2 Directive does not seek to disrupt established practices that comply with its objectives and data protection laws.
TLDR, while the NIS2 Directive mandates the collection and maintenance of accurate and complete domain name registration data, it does not explicitly require a thick WHOIS model. Therefore, it does not prohibit registries from adopting a thin WHOIS model, provided that the overarching goals of cybersecurity and data accuracy are upheld. Again this is all old news and nothing new.
What bugs me a little is the high focus on thick WHOIS, and yes around 2015 that database made a lot of sense to combat cyber crime.
But we are way beyond that.
What the ICANN community does not understand is we are dealing with a new problem where KYC can be easily bypassed.
https://www.usip.org/publications/2024/05/transnational-crime-southeast-asia-growing-threat-global-peace-and-security
https://www.ohchr.org/en/press-releases/2023/08/hundreds-thousands-trafficked-work-online-scammers-se-asia-says-un-report
Now we can all ignore the obvious/above here, and pretend thick WHOIS is some kind of solution. I think we have way bigger problems, but it seems the ICANN community just has an unhealthy focus on RDRS, thick WHOIS, a bunch of IP interests, and yet there is zero progress on a 9 trillion USD problem. And who is best suited to fix that problem?
The UN? nah
The ITU? nah
ICANN? well, maybe they got the MSM, smart people, cept those people seem to be short-sighted and lobby short-term focussed on their lobby goals and not the big picture.
Thank you for your comment Theo. While we disagree on whether Article 28 permits registries to go thin (I clearly think it does not), we do agree that cybercrime is an evolving and complex problem. And we also agree that Know Your Customer (KYC) is not a "silver bullet" for solving the growing and increasingly challenging problems of cybercrime.
However, I disagree that KYC is some sort of bygone useless tool. In the very interesting article you provided a link to in your comment from the United States Institute of Peace concerning Southeast Asia as a center for cybercrime, the authors state, "One of the greatest weaknesses of current law enforcement efforts and other attempts to counteract the criminal activities involved in the scamming industry is the lack of systematic and coordinated data collection. This gap must be urgently filled if law enforcement is to have a full picture of the problem, its vast and evolving network of criminal actors, and its constantly shifting dynamics."
KYC is one of the important aspects of "systematic and coordinated data collection" that assists in the prevention, detection and investigation of cybercrime. That is why, for example, it has been widely adopted in the banking industry to help address the problem of money laundering. Yes, money laundering still exists, but KYC helps address the problem.
In terms of Thick WHOIS, why should law enforcement agencies be forced to seek WHOIS data from one of more than 2,000 registrars around the world that are accredited by ICANN and Verisign to sponsor a .com or .net domain name when such agencies are investigating a particular .com or .net domain name and associated website? It adds time and hurdles to investigations, particularly when the registrar might be located in a non-cooperative country. From the perspective of increasing cybersecurity and public safety, it makes solid sense that a TLD registry that is responsible for administering domain names should also have complete and verified data about its registrants. That way law enforcement and other legitimate access seekers have a single source per TLD from which to seek this important data. In my view, that is exactly what the EU co-legislators concluded and set forth in the Article 28 obligations on TLD registries. With due respect to the multistakeholder model (MSM), I believe ICANN has mis-interpreted the law in permitting gTLD registries to transition from thick to thin.
Thank you for your detailed analysis. It is a good example for the old saying of “Two lawyers, three opinions!”. Clearly, there are good arguments for either interpretation. Article 28 is in many aspects rather vague and allows for multiple interpretations of many requirements. Which one will ultimately prevail will likely be up to the courts to decide as many (US-based) registries are now likely moving to the minimum data set required by ICANN policy.
But you seem to err when you assume that your interpretation would require duplicate databases because you interpret “entities providing registration services” as registrars when in fact it includes the entire registration value chain. This implicitly includes resellers, their resellers, and every service provider providing registration services down the chain. In the past, none of these downchain providers were required to maintain registration data databases. Now - under this interpretation - they would be. So instead of having one source of truth for registration data, you will now have multiple. I am not sure that that was what Article 28 intended.
The Belgian example also does not help interpreting the requirement as the directive is clearly intended as a floor and countries are permitted to go beyond in their transcriptions into national law.
The takedown requirement in Belgian law is misguided as it can lead to thousands of takedowns of legitimate domain names registered and used for non-malicious purposes simply because (for example) the registrant may have forgotten to update his email address in the registration data or simply did not want his personal data published for the world to see (and for spammers to abuse) back in the day when the data was still public).
Finally, please stop calling it whois. Whois is dying, it is RDS now.
Hello Volker,
While many lawyers and non-lawyers have opinions on the text of Art. 28 (6), at the end of the day the most important voice/opinion will be the Cooperation Group and their work on the Work Stream on WHOIS, and more specifically the Task Force on Verification and the Task Force of Legitimate Access. And yes ultimately courts will have the final word.
While there are arguments on both sides of this debate, as I noted in my response to Thomas’ article, I think Option/Definition 1 is the more logical decision given the historical precedence of European ccTLDs Operators. It makes no sense that EU Legislators would want to destroy a model that has resulted in TLDs with the least abuse.
I share your frustration with the continued use of the term WHOIS, but I guess I am a little more tolerant. Old habits die hard as evidenced by the Cooperation Groups’ use of the term to identify one of their Work Streams.
I think it is important for the ICANN community to educate people that WHOIS has been historically used to refer to a protocol AND a service. I have found the following approach to be helpful—- the WHOIS service is being replaced by RDDS, and the WHOIS protocol is being replaced by RDAP.
Best regards,
Michael
Hello Mike,
“a model that has resulted in TLDs with the least abuse.”
Are you sure the incidence of abusive use is caused by the verification of contact data? It seems a bit like mixing up causation with correlation.
There are other examples where an abundance of verification requirements has not resulted in a drop in abusive use, to the contrary. Since .CN has introduced some of the strictest verification requirements, abusive use of .CN has skyrocketed nonetheless.
On the other hand, .DE - a TLD with historically very loose registration requirements and no verification was up until recently not one of the leading TLDs in abuse.
Not saying there is no connection, but the connection should be proven in a study that shows direct impact of verification on the levels of abuse.
And please, lets not forget that more verification will inevitably lead to more crime: Identity theft will rise in response to stricted registration requirements.
Hello Volker, I agree that it can sometimes be difficult to distinguish between correlation and causation. But it seems that several experts conclude that verification of domain registrant data is an important element to combating abuse and cybercrime.
See, for example, the May 2023 Report by the European Union Agency for Cybersecurity (ENISA) entitled DNS Identity. The report outlines and describes various methods of verifying registrant data and recommends "Good Practices In the Verification of Domain Name Owner Identity" that include using national eIDs where available, applying risk assessments concerning registrant identity data, using existing payment tools to assist in verifying the identity of domain name owners, and "avoiding fake registration account information by supplementing other sources of verification through third-party services."
It is hard to imagine that ENISA would be recommending all these Good Practices concerning verification of domain name registrant and domain name owner data if ENISA had not found that there is a strong nexus between verification and lowering levels of abuse and fighting cybercrime. Indeed, ENISA states in the Report "the verification of data used for initial registration is an essential component of the attempt to provide accurate information for uses beyond the operation of the DNS; for instance legitimate law enforcement, dispute resolution and remediation of domain name abuse."
Similarly, the European Commission's 2020 Report entitled "Study on evaluation of practices for combating speculative and abusive domain name registrations" reached the same conclusion. The report states domain name registrant data verifications "are related to the necessity of maintaining data accuracy and preventing illegal activities which could pose cyberthreats."
Is verification of domain name registrant/owner data a 100% solution to DNS abuse and cybercrime? No it isn't; there is no silver bullet. And I agree with you, Volker, that stricter verification requirements will likely lead some cybercriminals to seek to steal valid identities. But I put my trust in ENISA and the Commission's experts that collection and rigorous verification of domain name registrant data is an important and valuable tool towards effectively combating cybercrime and reducing DNS abuse.
Hi Dean,
yes, I have read the same reports, however none of them seem to be based on testable evidence and the "experts" mostly rely on correlation as well. The recommendation is basically pulled from thin air to meet the desired result, it seems. I guess that is what happens if you commission a study from an IP lawyer and a cybersecurity researcher.
I am sure they meant well, but in the end, their factless assumption will just result in legitimate registrants being required to jump through additional hoops, registrars being required to invest heavily into enforcing an obligation that lies with the registrants and abuse continuing as it has before. If they had commissioned the study from those actually fighting on the frontlines against abuse at registries and registrars, the result would likely have been different as our experiences show that no level of verification will reduce abuse. Abuse will always find ways around any preemptive measures we put up.
Sure, it will shift from TLD to TLD depending on where the path of least resistance lies at any given moment, but as long as crime on the internet remains lucrative and as long as we continue to fight symptoms without the threat actors being caught and punished, abuse will occur on the internet and nothing we do to verify the registrants will change that.
Much ado about nothing, to quote the bard...
And do not get me started on hosting abuse...
Michael consider the following?
1.
Privacy Concerns: Rigorous verification processes can infringe on the privacy of individuals. The collection and storage of personal data could potentially be misused if data breaches occur.
2.
Effectiveness: Cybercriminals are becoming increasingly sophisticated and may find ways to bypass verification processes, such as using stolen identities or creating fake documents.
3.
Cost and Accessibility: Implementing stringent verification processes can be costly for domain registrars and may not be feasible for all, especially smaller entities. This could lead to a disparity in the application of security measures across different domains.
4.
Impact on Innovation: Overly strict verification requirements might stifle innovation by creating barriers to entry for legitimate users who wish to quickly register and use domain names for new services and startups.
5.
Global Consistency: The effectiveness of verification is also dependent on its consistent application across different jurisdictions, which is challenging given the varying legal and regulatory frameworks worldwide.
6.
False Sense of Security: Relying too heavily on verification could lead to a false sense of security, where other critical aspects of cybersecurity might be neglected. Remember the links I posted? Game changer!
Dean,
Yes we disagree.
While the points you’ve raised in support of KYC and Thick WHOIS are valid, there are several arguments that can be made against the reliance on these systems:
1.
Privacy and Data Protection: The implementation of KYC and Thick WHOIS can lead to significant privacy concerns. Collecting and storing large amounts of personal data increases the risk of data breaches and misuse of personal information.
2.
False Positives and Identity Theft: KYC processes can sometimes result in false positives, where legitimate users are incorrectly flagged as suspicious. Moreover, the data collected through KYC can be a target for identity thieves, which can lead to more sophisticated forms of cybercrime.
3.
Resource Intensive: KYC and Thick WHOIS require significant resources to implement and maintain. This can be particularly burdensome for smaller organizations and can lead to uneven enforcement across different jurisdictions.
4.
Effectiveness Against Cybercrime: While KYC can help in identifying bad actors, it is not foolproof. Cybercriminals often find ways to circumvent these measures, such as using proxies or stolen identities to register domain names.
5.
Global Consistency: The internet is a global network, and the effectiveness of KYC and WHOIS policies depends on consistent application and enforcement worldwide. This is difficult to achieve due to varying laws and regulations across countries.
6.
Impact on User Experience: Stricter KYC and WHOIS policies can negatively impact the user experience by adding additional steps and delays in the domain registration process, which could deter users from registering domains legally.
7.
Overreliance on a Single Solution: Relying too heavily on KYC and WHOIS as the primary means to combat cybercrime can lead to neglecting other important security measures and technologies that could be more effective in certain contexts.
In summary, while KYC and Thick WHOIS have their merits, they also present challenges that need to be carefully considered. A balanced approach that respects privacy, minimizes the risk of data misuse, and incorporates a variety of cybersecurity measures is essential for effectively combating cybercrime.
TL:DR, we registrars are dealing with criminals who hold 300.000 people captive. So these criminals have access to passports, digital identies, they can bypass whatever. They need a bank account? Done.
They need webhosting? Done. They need domains in countries with a heavy registrant verification? Done.
On top of that and we never talk about that within ICANN is the fact of massive use of stealer logs. I am not going to explain that one, but basically it means we cannot trust any customer. Even if that customer passed all the KYC requirements and might a customer for 20 years.
Do we see the global problem now?
Humanity invented the internet, but humanity has no clue what we created. Now we pay the price and the price will be high. Great that you looked at the links, but the problem is not something the ICANN community can solve. We are way passed the crossroads here.
If ICANN is going to do something, it means the community needs to alligned. That is not going to happen for the next 10 years.
Feel free to attend my presentation at the Global Anti Scam Alliance on this subject.
Theo,
I appreciate this exchange of ideas and perspectives and would like to see your presentation at the Global Anti Scam Alliance if possible.
I think there is a key point that we both agree upon that you stated eloquently above: Overreliance on a single solution as the primary means to combat cybercrime can lead to neglecting other important security measures and technologies that could be more effective in certain contexts. I think that is spot on and I very much agree that there is no silver bullet and no single solution. I agree that new and alternative security measures and technologies need to be continually pursued to help fight crime and abuse. We all know that criminals are embracing new measures and technologies to achieve their goals. So I believe a multi-pronged approach needs to be embraced. And furthermore, I don't think we can place all the responsibility for addressing online crime and abuse on law enforcement agencies.
From my discussions with various law enforcement agencies and cybersecurity researchers, I have learned that KYC, verification and Thick WHOIS are all valuable tools with respect to both preventing and investigating a broad array of cybercrimes. Of course they are not perfect and of course they can be circumvented. And you are correct that when personal data is collected, then such data becomes subject to the risk of hacks and data breaches. But it seems all these factors need to be weighed against one another and at this point in time, cybercrime is outpacing the current means to prevent and combat it.
According to INTERPOL's inaugural Global Crime Trend Report of 2022 "financial and cybercrimes are the world's leading crime threats and also those projected to increase the most in the future[.]" I am eager to know what you think are the appropriate responsibilities that internet infrastructure providers, including domain name registries and registrars, should take on to help address this growing threat to public safety and welfare.
Hello Theo,
Before trying to answer your questions, I thought it would be important to level set on what I believe is the general premise that you have repeatedly articulated over the past several years.
"Bad (criminal) people are really smart and any attempts to try and identify these bad people using KYC to prevent them from registering domain names is not worth the effort, so let's keep things simple and cheap."
I welcome any proposed edits or clarification to that statement.
Question 1 (Privacy) I acknowledge and embrace privacy rights afforded natural persons under the GDPR, however, those rights are not absolute per Art. 6. However, unlike ccTLD Registries that have taken a holistic approach to implementing solutions to address NIS 2.0 requirements taking into account GDPR, gTLD Registrars and Registries appear to be in denial about the changes that will be coming to the European domain name marketplace. As I said at the Contracting Party Summit, I find it odd gTLD Registrars and Registries wrapped themselves in the GDPR flag to change ICANN policy, but now you are totally ignoring the obligations of NIS 2.0. I find it disingenuous and inconsistent with the letter and spirit of the multistakeholder model to pick and choose which national laws you want to follow. Case in point, most European ccTLDs have bifurcated their registrant database between natural and legal persons. Most gTLD Registrars and Registries do not. ICANN gave them a free pass as a result of the EPDP and they have no interest in changing their business operations. At the end of the day you and I have opinions, the Cooperation Group will provide actionable guidance.
Question 2 (False Positive) I agree that they may be false positives, but that fact does not give you the option to determine which provisions of a law you want to comply with. They may be false positives in connection with PSD2 credit card payment requirements, does that mean you can voluntarily choose to ignore those requirements? Like it or not more governments around the world are recognizing the TLD registries and the DNS as national critical infrastructure. And as Spider Man says. “with great power comes great responsibility.” I find it amazing that most gTLD Registries and Registrars want to embrace a 2010 mindset to domain name registration verification when the rest of European Registries and Registrars are clearly raising the bar. Regarding your concern about your systems being hacked, I would direct appropriate entities to review Art 21. and the mandatory fines under Art. 34.
Question 3 (Resource Intensive) European Registries seem to be working with their Registrars to implement these changes. Why can’t gTLD Registrars and Registries do the same? Unfortunately, as evidenced in Thursday’s CPH session at ICANN80, they do not seem to be able to get past the reality that they have a problem.
Question 4 (Effectiveness on Cybercrime) No one is saying KYC is foolproof, but I have spoken with several European ccTLD registries that have noted certain flagged domain names that were originally identified as suspect being withheld and/or taken out of the zone when the registrant failed to provide step-up verification. So to me this is a good thing, and provides the Registrant the ability to address any false negative rejections. Again this is the work that the Cooperation Group will be undertaking to “provide guidance and exchange best practices” on NIS2 implementation.
Question 5 (Global Consistency) As I am often reminded when talking with my ccTLD colleagues, there is no single business model as you are fully aware. Some TLDs have registrant requirements, e.g. you must be a licensed bank, residency requirements, etc. I have been encouraged by the variety of business practices that various European ccTLDs have been putting forward. I think these data points will all help inform the work of the Cooperation Group as they provide guidance to the industry. Finally, and this is a point that I have raised with some of my gTLD registry colleagues. Many of the larger gTLD registries colleagues submitted RSEPs with ICANN and registered with MIIT to comply with Chinese national law regarding registrant verification requirements. I think the multistakeholder model needs to respect that national governments will sometime enact national laws to protect their national interests and that is ok. I would like to specifically call out the Australian government representative that spoke on Sunday regarding the multistakeholder model where she said “We do have to accept that regulation can be part of the solution.”
Question 6 (Impact User Experience) Respectfully, the objective of NIS2 is very clear, laying “down measures that aim to achieve a high common level of cybersecurity across the Union.” In having to choose between maximizing domain name registration sales and ensuring a high common level of cybersecurity, I think that is a clear hands-down winner. Again, I do not see these requirements being so onerous to bar domain name registrations. However, this again is where the Cooperation Group will prove invaluable.
One final comment on this point. It seems that you are taking a very backward looking view toward the User Experience. I would like to direct you to the following excerpt from Recital 111 which states in relevant part, “TLD name registries and the entities providing domain name registration services should adopt and implement proportionate procedures to verify domain name registration data. Those procedures should reflect the best practices used within the industry and, to the extent possible, the progress made in the field of electronic identification.”
One of the reasons I missed participating in person for ICANN80 was because I was attending the European Identity Cloud conference in Berlin last week. During this conference I saw the Commission and multiple national governments showcase their respective digital ID and wallet initiatives. I recently obtained my mobile digital driver's license from the state of Florida. So instead of looking at KYC as a glass empty like yourself, I view it as a glass half full and one which in the not too distant future will overflow. Another reason why I am encouraged by the “dynamic” approach that the Cooperation Group is taking.
Question 7 (Single Solution). The European ccTLD are not relying upon a single solution. In fact, DENIC is taking a very dynamic approach to leverage their Registrar’s existing capabilities. While DENIC is giving Registrars this option, the Registry is checking domain names that may indicate that they are high-risk or very high-risk, and thus flagging it for additional verification. DENIC was also very thoughtful in ensuring that Registrars provide meta data indicating the verification process they use for any auditing that may need to be done. I do not expect the Cooperation Group to recommend a single best practice, but a range of best practices based upon the information available to them.
Your "summary" is incorrect and unfair.
Here is a better and more accurate version.
"Bad (criminal) people are really smart and any attempts to try and identify these bad people using KYC to prevent them from registering domain names will likely not lead to the desired results or any noticeable effects on the levels of abuse. This does not mean that we should give up on fighting abuse, but that we should think and decide where an investment of funds to combat such activities is best spent."
You are a proponent of "KYC will solve the problem". We keep telling you that "In our experience, it makes no difference!".
We would rather invest in other mechanics to detect and deter abuse instead of building out a multi-million dollar KYC program that will ultimately do nothing and lead to further calls for more regulations.
We do not want to inconvenience our customers and throw stumbling blocks into the registration process that will deter legitimate registrants from registering their domain, but that threat actors will just code around.
Question 1: I do not understand this hang-up of the entity type of registrants. It is an absolute red herring. How many criminals will set up a company to funnel their crimes through. What problem is publishing legal entity data actually going to solve? How does differentiating between entity types preventing the publication of personal information that may be lurking in the various data fields? NIS2 recognises the problem but then asks for the impossible as it does not say "Publish all legal entity data!" but merely says "Publish the data that is not personal data and do it consistently with GDPR!". If you can write a script that determines whether every data field contains personal data or not, I'd like to see you try.
Question2: I do not feel our industry has much power, but people sure want to throw all kinds of responsibilities at us. And Art 21 does not apply to domain name registrars as such.
Question 3: Some do work with their registrars, some don't. Many just present us with a fait accompli. And it is simply untrue that gTLD registries and registrars are not joining forces to combat abuse. This year, we voluntarily agreed to new requirements to mitigate abuse. Is that nothing? I bet you that this will be much more effective than your favorite KYC toy.
Question 4: Step-up verification is not what you are asking for. All registrars already perform verification when there is reason to believe there may be an issue with the data. It's in our contracts. Ultimately, better accuracy at the start even removes a tool from our anti-abuse toolbox.
Question 5: We agree that there is no consistency, and NIS2 will also not do that as every registry and country in Europe is going to do their own thing. And if the CNNIC verification is so great, why is .CN still one of the most abused TLDs out there. High verification requirements = high levels of abuse? Or rather no matter how much you verify, abuse will find a way (apologies to Mr. Goldblum).
Question 6: The overall objective of NIS2 is clear indeed, and then they went and shoehorned in Article 28 at the last minute when the lobbyists at ICANN could not get in policy making bodies what they wanted. I remember the threat clearly: "Agree to what we want or we will force you by law!". So much for supporting the multi-stakeholder process...
EIDAS: If you knew how abysmally bad adoption of this electronic ID is in some countries... In Germany, you can get it on any new ID card, but there really is nothing to use it for, so most of us either opt out or lose the PIN on the way home.
The fact that there is value in performing KYC for risk-flagged domains doesn’t mean there is such value if done for all registrations. And the value is not the content of the KYC output, it’s just that this scares fraudsters that prefer to keep their stash of stolen IDs for things generating more revenue.
A curious side effect we are seeing is fraudsters going to consumer reviews/complaints apps/websites to bully us into accepting KYC docs we know are forged or stolen. It seems those websites should do a level of KYC too, is there an SG or AC for that ?