The ICANN Board-adopted Human Rights Framework of Interpretation makes specific reference to the usefulness of the UN's Guiding Principles shown at this link: https://www.business-humanrights.org/en/big-issues/governing-business-human-... I'm not super familiar with these UN Guiding Principles for business but I'm guessing other on the SRT may be? Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Thu, Jun 25, 2026 at 9:10 AM Anne ICANN <anneicanngnso@gmail.com> wrote:
If we are incorporating OECD privacy principles into ICANN Policy, could someone please brief us on those principles and the nature of any obligations for Contracted Parties that we are thus incorporating?
In terms of Core Values, Becky referenced the ICANN Human Rights Core Value that was adopted by the community during the transition but states that it obligates ICANN, but not Contracted Parties. Is there any reason to reference the ICANN Human Rights Framework of Interpretation shown as the link below rather than referencing a specific global organization like OECD (34 member states.)
https://www.icann.org/en/system/files/files/ccwg-acct-ws2-annex-3-hr-foi-fin...
Anne
Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com
On Wed, Jun 24, 2026 at 7:24 AM Becky Burr via Gnso-ssad < gnso-ssad@icann.org> wrote:
Farzi -
Glad we agree on the solution!
Re the picket fence, I never invoke it lightly, but I will defend it resolutely. The picket fence is not one-sided, rather it allows ICANN to impose obligations on contracted parties without their express consent, which is generally antithetical to contractual relationships. At the same time, it absolutely protects the right of Contracted Parties to operate their businesses freely within the bounds of the law with respect to matters outside the picket fence.
Let me explain why I invoke the picket fence in this case. First, I understand the argument that uniform policies mandating reasonable access to registrant data are not necessary for the stability and security of the DNS/Internet and should not be within the picket fence. That said, access to accurate and up-to date-registrant data was part of the original bargain that led to ICANN’s creation and is explicitly identified as being within the picket fence and has been since the beginning of ICANN time, i.e., the Green and White Papers. It was incorporated into all registry and registrar agreements created since 1998 and has been part of the Bylaws since 2016, see Annex G-2, which specifies that “maintenance of and access to accurate and up to date information concerning registered domain name registrations” is within the picket fence.
That does not mean, however, that ANY policy affecting access to registration data is within the picket fence. It does not give ICANN the right to create a global human rights and/or privacy policy governing access to registration data. Having said that, Core Value (viii) does obligate ICANN (not Contracted Parties) to respect internationally recognized human rights.
Accordingly:
1. *we cannot* develop a policy that obligates a Contracted Party to comply with, for example, the OECD Privacy Principles, the Universal Declaration of Human Rights, and/or the European Convention; 2. *we** cannot *develop a policy that puts ICANN in the position of enforcing compliance with those principles; but 3. *we can and should *develop a policy that (i) creates clear readily enforceable obligations with respect to data disclosure (i.e., mandates disclosure where doing so is consistent with applicable law and does not violate the OECD privacy principles) and (ii) prohibits ICANN from interpreting "reasonable access to accurate and up-to-date registrant data” in a way that would require a Contracted Party to violate those internationally recognized articulations of human rights;.
If we stick to this path I think we will find agreement around the table. I’d like to see a careful edit of the straw person document to implement this approach.
[image: Logo] <https://www.thenew.org/> *Becky Burr **| Senior Policy Advisor* *bburr@pir.org <bburr@pir.org>* | http://www.pir.org | *Power your inspiration. Connect your world.* *[image: Image]*
*From: *farzaneh badii <farzaneh.badii@gmail.com> *Date: *Wednesday, June 24, 2026 at 12:56 AM *To: *Becky Burr <bburr@pir.org> *Cc: *Steve Crocker <steve@shinkuro.com>; Anderson, Marc < mcanderson@verisign.com>; gnso-ssad@icann.org <gnso-ssad@icann.org> *Subject: *[EXTERNAL] Re: [Gnso-ssad] Re: SSAD SRT - updated Rec 8 language
*CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.*
------------------------------ Not in a million years I thought I would get to argue with Becky Burr over the picket fence. I still wear my picket fence pin proudly and here I am a little too brave and want to disagree! But at the same time, I like Becky's suggestion. See below,
This is not a picket fence issue. If it was, this whole exercise of SSAD and disclosure would be outside of the picket fence—unless you want to make it narrow and say we only oblige the registrar to respond to requests that are about security of the Internet and DNS. I like that approach, but we aint doing that here. Not all these disclosure requests contribute to the resiliency security of the Internet/DNS. So I don't agree with it and I think invoking 'picket fence' to argue against something should be done cautiously, because frankly it comes across as a bit one-sided when applied to this exercise. But I personally can live with your solution, Becky. I think it's elegant. ICANN should not put the domain name registrant human rights and privacy at risk with its policy. I can accept that. And the OECD guidelines have impact assessment framing under their accountability and risk-management frameworks. I’d like to just add a paragraph to the text so everyone is on the same page about what this baseline entails. I don't care where exactly it can be as long as it doesn't get lost. "Globally recognized privacy principles” are frameworks such as the OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data. Implementation of these principles generally requires that any data processing or disclosure be proportionate to a specified, legitimate purpose, and subject to an accountability framework that balances fundamental rights and assesses the inherent risk of harm to the data subject’s fundamental rights.
I hope this is acceptable.
Farzaneh
On Tue, Jun 23, 2026 at 4:41 PM Becky Burr via Gnso-ssad < gnso-ssad@icann.org> wrote:
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.
[image: Logo] <https://www.thenew.org/> *Becky Burr **| Senior Policy Advisor* *bburr@pir.org* <bburr@pir.org> | http://www.pir.org | *Power your inspiration. Connect your world.* *[image: Image]*
*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
On Fri, Jun 19, 2026 at 11:18 AM Anderson, Marc via Gnso-ssad < gnso-ssad@icann.org> wrote:
SSAD SRT members,
The strawperson document has been updated with revised Rec 8 language.
https://docs.google.com/document/d/17N6Y3yYUmbfbAFO6QwR8S1u0uZY0HxKYc8HaadBQ...
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 _______________________________________________ Gnso-ssad mailing list -- gnso-ssad@icann.org To unsubscribe send an email to gnso-ssad-leave@icann.org
--
_______________________________________________ Gnso-ssad mailing list -- gnso-ssad@icann.org To unsubscribe send an email to gnso-ssad-leave@icann.org
_______________________________________________ Gnso-ssad mailing list -- gnso-ssad@icann.org To unsubscribe send an email to gnso-ssad-leave@icann.org
