The language of Recommendations 8.3 and 8.4 is fundamentally inconsistent with the picket fence. We cannot draft a policy that constrains the registrar's ability to make lawful disclosures unless doing so would undermine the stability, security, and resilience
of the DNS/Internet. We can draft a policy that says ICANN cannot obligate a CP to disclose personal information where doing so would violate globally recognized privacy principles, e.g., the OECD principles.
For example, the current draft says:
As part of its review, the Contracted Party MUST consider if the impact on the human rights of the data subject prevents disclosure and MAY conduct a balancing test as
part of its review.
We all support respect for human rights, including privacy, but ICANN does not have authority to establish a global human rights/privacy policy for registrant data disclosure.
In addition, the proposed policy is unenforceable. It literally says that ICANN Compliance can require a CP to demonstrate that it considered the human rights impact before
disclosing registrant data.
The policy is simple:
The Contracted Party must disclose the requested information if it determines that doing so is (i) compliant with applicable law and (ii) does not violate globally recognized privacy principles.
We can define “globally recognized privacy principles” to mean, for example, the OECD principles.
Note, this issue (constraining the Contracted Party’s behavior within the limits of applicable law rather than constraining ICANN’s enforcement authority) reappears throughout the straw person document.
|
|
|
Becky Burr | Senior Policy Advisor
|
|
|
|
From: Steve Crocker via Gnso-ssad <gnso-ssad@icann.org>
Date: Friday, June 19, 2026 at 12:31 PM
To: Anderson, Marc <mcanderson@verisign.com>
Cc: gnso-ssad@icann.org <gnso-ssad@icann.org>
Subject: [Gnso-ssad] Re: SSAD SRT - updated Rec 8 language
Marc,
Thanks for passing this along. Rereading the recommendation, I realized something fundamental is missing. This Recommendation focuses on the obligations and latitude the Registrar has when making a disclosure determination. In my opinion, the Registrant's
preference is missing. If the Registrant wants their contact details disclosed, that should be the only consideration. Further, if the Registrant wants their contact details disclosed to specific types of Requestors, that should be the only consideration
for requests from those types of Requestors.
This is part of a larger and peculiarly unaddressed aspect of the overall policy: why is contact information collected in the first place, and what are the obligations and authority of the people listed in each role?
I have no issue with protecting the registrant and other contacts against various forms of abuse, from human rights violations to spam, but the registrant should have the final say and not be second-guessed if they intend for their information to be available.
The above should not be misinterpreted to suggest that each request requires a decision from the registrant. That would be very expensive and inefficient if required for every disclosure decision. Instead the registrar can provide the registrant with a clear
picture of how their contact information will be handled in response to various request types. And perhaps some registrars would also be willing to give the registrants some choice when they provide their contact information.
Thanks,
Steve
Steve
SSAD SRT members,
The strawperson document has been updated with revised Rec 8 language.
https://docs.google.com/document/d/17N6Y3yYUmbfbAFO6QwR8S1u0uZY0HxKYc8HaadBQtMQ/
Please take a look and provide feedback either in the google document or on the list. If you have issues or concerns with the language; proposing new text to address is helpful. You will see
in the document that staff has kept the side-by-side text with redlines. Following that, staff has added a new section with a clean version of the proposed draft recommendation to help with review. In addition, staff has also provided the following changelog
of the high-level changes made following our discussion at ICANN 86:
Recommendation 8
- Personal Data has been capitalized and added to the glossary. (The glossary definition matches the definition in the Registration Data Policy.)
- 8.1 has been crossed out due to a comment that a Contracted Party can determine how to review requests and could determine, based on its own risk assessment, that it can review certain requests
in bulk. (In other words, the policy should not dictate this.)
- 8.3 has been modified slightly to address multiple concerns expressed during ICANN86:
- the Contracted Party MUST consider if the impact on the human rights of the data subject prevents disclosure and
- MAY conduct a balancing test as part of its review. (A footnote has been added to clarify that a Contracted Party may choose to apply a GDPR balancing test for all disclosure requests, even
those falling outside of GDPR, and this policy would not prevent this.)
- 8.4 has been modified to clarify that Contracted Parties MUST disclose if they are able to under applicable law, subject to human rights assessment and applied balancing
tests.
Thank you,
Marc Anderson
--