<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
span.gmaildefault
{mso-style-name:gmail_default;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:58790620;
mso-list-template-ids:1611015558;}
@list l1
{mso-list-id:846676331;
mso-list-template-ids:-568320550;}
@list l2
{mso-list-id:1994215722;
mso-list-template-ids:-428949494;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#467886" vlink="#96607D" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt'>Hi Farzaneh<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>Thanks for the clear and concise summary.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>It seems obvious to me that all requestors will require vetting in some way, and as “strong” as possible for all requestors, due, in my view, to the potential for misuse of the data. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>Also, it is just as obvious to me that the “strength” of the authentication rests on the process put in place. I have not been following the discussion that closely, but I cannot see how an accreditation authority can operate in practice. Who will run it? At what cost? Who will oversee its operation? So, unless I am missing something, any authentication will come down to each data owner, mainly the registrars. We do not know what practices the more than 2,500 accredited registrars have in place, but it is likely that some do better than others. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>Maybe ICANN does this already, but it seems to me that ICANN would develop strict guidelines regarding how registrars should validate requests, including publishing detailed statistics regarding the requests received (which I believe the RDRS already kind of does) and then find a way to conduct audits to ensure compliance.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>Further, it may be in the interest of NCSG to consider a way to survey the industry with a view to publishing guidance notes for NCSG members regarding how registrars authenticate and handle requests, so that registrants can decide if they have confidence in their registrar. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>I’m interested in how others think about this. As you point out, the issue is of fundamental interest to our stakeholders.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>Ken<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> NCSG-Discuss <NCSG-DISCUSS@LISTSERV.SYR.EDU> <b>On Behalf Of </b>farzaneh badii<br><b>Sent:</b> Saturday, May 24, 2025 7:58 PM<br><b>To:</b> NCSG-DISCUSS@LISTSERV.SYR.EDU<br><b>Subject:</b> [Important/Question and note] Note on Accreditation and Requestor Validation in the Registration Data Request Service (RDRS)<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p><span style='font-family:"Arial",sans-serif'>As you know I am your rep on RDRS SC, which is the triage system for sending the disclosure of domain name registrants data to the registrar. It's a pilot project. </span><o:p></o:p></p><p><span class=gmaildefault><span style='font-family:"Arial",sans-serif'>We are providing our report and based on the result of the experiment we are providing the recommendations for consideration of SSAD(the disclosure policy that was adopted in the past). </span></span><o:p></o:p></p><p><span class=gmaildefault><span style='font-family:"Arial",sans-serif'>For NCSG a few things matter: privacy of the domain name registrants, accountability and transparency of the system, the requesters and the registrars.</span></span><o:p></o:p></p><p><span class=gmaildefault><span style='font-family:"Arial",sans-serif'>One of the issues that we are discussing is accreditation of non LEAs. See the brief below, and my question is: what should we decide? Should we insist on full accreditation of non LEAs or should we settle on having some lightweight authentication and ask ICANN and registrars to report on the requests. I lay out the pros and cons of the approaches below.</span></span><o:p></o:p></p><p><strong><span style='font-family:"Aptos",sans-serif'>Background:</span></strong><br>As part of the ongoing evaluation of the Registration Data Request Service (RDRS), several concerns have emerged regarding requestor validation and accreditation, particularly in relation to non-law enforcement third parties.<o:p></o:p></p><p><strong><span style='font-family:"Aptos",sans-serif'>EPDP Phase 2 Context:</span></strong><br>The EPDP Phase 2 Final Report recommended the creation or designation of an <strong><span style='font-family:"Aptos",sans-serif'>Accreditation Authority</span></strong> as a critical component of any long-term solution for lawful disclosure of domain registration data. This recommendation has significant implications for the <span class=gmaildefault><span style='font-family:"Arial",sans-serif'> disclosure system</span></span><o:p></o:p></p><p><strong><span style='font-family:"Aptos",sans-serif'>S</span></strong><span class=gmaildefault><b><span style='font-family:"Arial",sans-serif'>ome observations</span></b></span><o:p></o:p></p><p><span class=gmaildefault><b><span style='font-family:"Arial",sans-serif'>Why LEA authentication is needed:</span></b></span><o:p></o:p></p><ol start=1 type=1><li style='mso-list:l1 level1 lfo1'><strong><span style='font-family:"Aptos",sans-serif'>Misclassification of Requests:</span></strong><br>RDRS experience indicates that a number of data disclosure requests were improperly categorized as originating from law enforcement authorities, raising concerns about the accuracy and integrity of requestor self-identification.<o:p></o:p></li><li style='mso-list:l1 level1 lfo1'><b>Lack of Requestor Validation:</b><br>The absence of an accreditation or identity validation mechanism may have contributed to delayed responses from registrars, who are unable to confidently assess the requestor’s legal standing and purpose.<o:p></o:p></li><li style='mso-list:l1 level1 lfo1'><strong><span style='font-family:"Aptos",sans-serif'>Authentication vs. Disclosure Balancing:</span></strong><br>N<span class=gmaildefault><span style='font-family:"Arial",sans-serif'>ote </span></span>that authentication <span class=gmaildefault><span style='font-family:"Arial",sans-serif'>is</span></span> not inherently difficult. The core challenge lies in balancing a validated requestor’s documented purpose against the registrant’s right to privacy, particularly in borderline or ambiguous cases.<o:p></o:p></li></ol><div><div><p class=MsoNormal><b><span style='font-family:"Arial",sans-serif'>Non LEAs</span></b><span style='font-family:"Arial",sans-serif'><o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p></div><ol start=1 type=1><li style='mso-list:l0 level1 lfo2'><strong><span style='font-family:"Aptos",sans-serif'>Risk of Abuse by Authenticated Non-LEAs:</span></strong><br>W<span class=gmaildefault><span style='font-family:"Arial",sans-serif'>e have concerns </span></span>about the <strong><span style='font-family:"Aptos",sans-serif'>potential for misuse of access</span></strong> by authenticated third-party requestors, especially those operating in jurisdictions with weak human rights protections. Authentication alone does not safeguard against disproportionate or abusive requests.<o:p></o:p></li></ol><p><strong><span style='font-family:"Aptos",sans-serif'>Recommendations for Follow-up System Design:</span></strong><o:p></o:p></p><ul type=disc><li style='mso-list:l2 level1 lfo3'><strong><span style='font-family:"Aptos",sans-serif'>Initial Focus on Law Enforcement :</span></strong><br>I<span class=gmaildefault><span style='font-family:"Arial",sans-serif'> think we should</span></span> generally agree that future iterations or alternatives to RDRS should prioritize <strong><span style='font-family:"Aptos",sans-serif'>a</span></strong><span class=gmaildefault><b><span style='font-family:"Arial",sans-serif'>uthentication</span></b></span><strong><span style='font-family:"Aptos",sans-serif'> of law enforcement requestors</span></strong> as a first step, both to build trust and to test implementation.<o:p></o:p></li><li style='mso-list:l2 level1 lfo3'><b>Need for Further Policy </b><span class=gmaildefault><b><span style='font-family:"Arial",sans-serif'>refinement: </span></b></span><span class=gmaildefault><span style='font-family:"Arial",sans-serif'>Discuss how to refine accreditation for third party non LEAs so that we bring transparency and accountability but also not be entangled in a "trusted flagger" system where accreditation could lead to positive answers from the registrars without any balance of fundamental rights and disclosure. </span></span><o:p></o:p></li></ul></div><div><div><div><div><p class=MsoNormal><span style='font-family:"Verdana",sans-serif'>Farzaneh </span><o:p></o:p></p></div></div></div></div></div></div></body></html>