Dear team, Looking at the statement from Alberto "... I would suggest that all registration be done through a Digital Signature provider. Currently, multi-million dollar contracts are signed through this system .." the statement makes sense but there is a potential huge impact that will have on the cost. RDS is meant to solve the challenge of Data accuracy and the deliberations were focused to have accurate validated data as well as security of the data. Daniel ᐧ On Mon, 17 Feb 2025 at 16:14, Alberto Soto via ALAC <alac@icann.org> wrote:
Agreed, but it should be noted that the registry will be secure, and that there are also government service providers, free of charge. Perhaps this merits a thorough survey of free digital signature providers, or to see what the implementation cost is in certain places. Perhaps even an ICANN agreement with free services.
Regards
Alberto
*De:* Steinar Grøtterød <steinar@recito.no> *Enviado el:* lunes, 17 de febrero de 2025 09:23 *Para:* alberto@soto.net.ar; 'Carlton Samuels' <carlton.samuels@gmail.com>; 'Jonathan Zuck' <JZuck@innovatorsnetwork.org> *CC:* 'CPWG' <cpwg@icann.org>; 'ALAC' <alac@atlarge-lists.icann.org>; 'Michael Palage' <michael@palage.com> *Asunto:* Re: [CPWG] Re: [ALAC] Re: Statement on Registration Data Accuracy
Please remember that some registrars operate in a global marked with registrants from all over the world. Implementing multiple Digital Signature Systems will - as a minimum - increase the registration fees.
Regards,
Steinar Grøtterød
*From: *Alberto Soto via CPWG <cpwg@icann.org> *Date: *Monday, 17 February 2025 at 12:04 *To: *'Carlton Samuels' <carlton.samuels@gmail.com>, 'Jonathan Zuck' < JZuck@innovatorsnetwork.org> *Cc: *'CPWG' <cpwg@icann.org>, 'ALAC' <alac@atlarge-lists.icann.org>, 'Michael Palage' <michael@palage.com> *Subject: *[CPWG] Re: [ALAC] Re: Statement on Registration Data Accuracy
I believe that as an ALAC Member I would suggest that all registration be done through a Digital Signature provider. Currently, multi-million dollar contracts are signed through this system. A and B want to sign that contract. But they are far away, or they do not have a way to verify the identity with correct data on the other side, and they want to make sure that they are specifically identified. Then they turn to C, a Digital Signature service provider. There are many governments that have the system and offer it for free. C is responsible for verifying both A and B, and after doing so, the contract is signed digitally with a double key (public and private), and it is sent partially encrypted to both parties. In C, the security and permanence of the contract is ensured.
I proposed it several times, but there was no repercussion.
Kind regards
Alberto
*De:* Carlton Samuels via ALAC <alac@icann.org> *Enviado el:* domingo, 16 de febrero de 2025 17:39 *Para:* Jonathan Zuck <JZuck@innovatorsnetwork.org> *CC:* Alan Greenberg <greenberg.alan@gmail.com>; CPWG <cpwg@icann.org>; ALAC <alac@atlarge-lists.icann.org>; Michael Palage <michael@palage.com> *Asunto:* [ALAC] Re: Statement on Registration Data Accuracy
I see all this and I’m still gobsmacked how easy it is to connive at error. Leading……well, um threshold questions are always intended to enforce adaption of a set narrative. That should be rejected for cause.
There is no successful contradiction for the evidence of inaccuracy in contact data and the registration system still lacks meaningful enforcement of the existing data accuracy policy for the DNS. It remains astonishing how easily errors persist—registrars are required to warrant that registrants provide valid contact details, yet verification remains weak. ICANN’s policy demands that registrars validate and periodically review phone and email contacts, even as these are constantly changing and too often left unchecked.
Here is what we know for sure. The self-regulated registration data (WHOIS) accuracy model has failed. We have undeniable proof: emails don’t resolve, phone numbers are unreachable, and registrars face no real consequences for non-compliance. What we have here is a policy that exists in theory but not in practice*.* ICANN, the supposed master regulator, has failed to enforce its own policy. Evidence of oversight is weak to non-existent, and without penalties, registrars have no incentive to comply.
Enter NIS2, which flips the script on registration data (WHOIS) accuracy. It raises the bar on verification, intends enforcement of legally binding government oversight and introduces penalties for non-compliance. So now, the hue and cry. Because if the EU enforces this directive as law, it would fragment the domain registration landscape, resulting in divergent verification standards, conflicting enforcement mechanisms, and inevitable clashes with GDPR. Lawyers will thrive with the legal grey areas now at play.
But let’s not get lost in the noise. If the true goal of the registration data (WHOIS) accuracy *is *contactability, then who the registrant claims to be is secondary. Whether they identify as Wile E. Coyote, Donald D. Duck, or Jack Schitt shouldn’t matter. So long as they can be reached via a valid phone number or email. And if they cannot be reached, there are consequences.
Carlton
============================== *Carlton A Samuels*
*Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* =============================
On Fri, 14 Feb 2025 at 14:02, Jonathan Zuck via ALAC <alac@icann.org> wrote:
Thanks for your work on this! As I read it, it seems to be missing the end user impact assessment that we have begun to incorporate in such comments. We make the point that we’re not the experts but instead rely on the expertise of others but could we site some of those experts to lay out a few bullets that tie this exercise back to our mandate and remit?
*From:* Alan Greenberg <greenberg.alan@gmail.com> *Sent:* Thursday, February 13, 2025 12:10 PM *To:* Jonathan Zuck <JZuck@innovatorsnetwork.org> *Cc:* CPWG <cpwg@icann.org>; ALAC <alac@atlarge-lists.icann.org>; Michael Palage <michael@palage.com> *Subject:* Statement on Registration Data Accuracy
Jonathan, the statement in response to the GNSO query related to registration data accuracy is not finalized.
It is a significant enhancement on the version discussed during yesterday's CPWG meeting, but is *identical *in its overall intent.
It is a much stronger and hopefully effective message.
It was a collaborative effort of Michael, Cheryl, Justine and me.
You can find it at https://docs.google.com/document/d/1uvGxFjlKMscGweIb-29UKc46ycgGKADbRA4NCp66...
Alan
_______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...) _______________________________________________ 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.
_______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...) _______________________________________________ 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.