[Important/Question and note] Note on Accreditation and Requestor Validation in the Registration Data Request Service (RDRS)

Wed May 28 09:16:52 EEST 2025

Hi Farzaneh,

Thank you for this important update.

I personally support an NCSG perspective that any system for disclosure of
domain registration data must carefully balance the need for accountability
and transparency (especially from LEAs and registrars) with strong privacy
protections for domain name registrants, especially those in vulnerable
contexts.

Since we are still in the pilot stage, I believe your recommendation for a
lightweight authentication can be a good approach for non-LEAs.

The challenge is how to provide guides on how to keep a balance in the
implementation
of the process without abuse.

Full authentication may add more overhead and bottleneck on the process and
may make it more difficult to adopt or implement.

Also, just as you have said, the emphasis for authentication should be LEAs
at the moment.

On another note, what do you think of the inDrive car-hailing app creating
a data-sharing platform for LEAs in Nigeria, just to manage the many
requests they get from the authorities? (Also, the issue of balance between
safety and user privacy was mentioned)

https://punchng.com/indrive-unveils-law-enforcement-data-request-platform/

Kind regards,

Benjamin

On Wed, May 28, 2025 at 8:58 AM Michaela Nakayama Shapiro <
00001b332dc2b5b0-dmarc-request at listserv.syr.edu> wrote:

> INTERNAL
>
> INTERNAL
>
> Hi Farzi,
>
>
>
> Thank you for sharing this update!
>
>
>
> One question that I keep coming back to is who/what are we talking about
> when we say “non-LEAs”? Having a better sense of who these entities are and
> why they would be requesting this information would be helpful to answer
> your question.
>
>
>
> Regardless, my two cents is that non-LEA accreditation is needed. I think
> the best-case scenario is that we should have both: full accreditation
> mechanisms for non-LEAs (+1 to @Emmanuel Vitus <emmanuelvitus at gmail.com>’s
> concerns here) *and* reports by registrars on these requests. That may
> not be a popular opinion in the RDRS SC, but I think it’s important and
> something we can reiterate in our session.
>
>
>
> Best,
>
>
>
> Michaela
>
>
> *Michaela Nakayama Shapiro *(she/her/hers)
> Programme Officer - Censorship
> [image: Logo.png] <https://www.article19.org> Defending freedom of
> expression
> and information
> *www.article19.org* <https://www.article19.org> Subscribe to our
> Newsletter <https://www.article19.org/ie-sign-up/>
> <https://www.article19.org/ie-sign-up>
> Follow us
> [image: Bluesky1x.png] <https://bsky.app/profile/article19.bsky.social>
> <https://www.facebook.com/article19org/>
> <https://www.youtube.com/channel/UCDB6E_x0xRSfF62b872n9YQ>
> <https://www.linkedin.com/company/article19>
> <https://www.instagram.com/article19org/>
> <https://twitter.com/intent/follow?screen_name=article19org>
> [image: women-journalists-banner.jpeg]
> <https://www.article19.org/equally-safe/?mtm_campaign=Clicks%20on%20email%20signature%20banner>
>
> *From: *NCSG-Discuss <NCSG-DISCUSS at LISTSERV.SYR.EDU> on behalf of Tomslin
> Samme-Nlar <mesumbeslin at GMAIL.COM>
> *Date: *Wednesday, 28 May 2025 at 03:35
> *To: *NCSG-DISCUSS at LISTSERV.SYR.EDU <NCSG-DISCUSS at LISTSERV.SYR.EDU>
> *Subject: *Re: [Important/Question and note] Note on Accreditation and
> Requestor Validation in the Registration Data Request Service (RDRS)
>
> Hi Farzi, all,
>
>
>
> I hope everyone is well.
>
>
>
> You asked: *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 think it depends on which problem we are trying to solve.
>
>
>
> *Problem: Time it takes for registrars to respond to request*s - Here I
> think adequate authentication is required. B3cause even if disclosure is
> denied, response of that decision will be quicker. Whether it can be
> lightweight, well, I believe will depend on the technical story of how it
> will be done.
>
>
>
> *Problem: Balancing authentication & disclosure* - Here I think policy
> should be clear that *authenticated* doesn't mean auto-disclosure.
>
>
>
> Remain blessed,
> Tomslin
>
>
>
> On Sun, 25 May 2025, 09:58 farzaneh badii, <farzaneh.badii at gmail.com>
> wrote:
>
> 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.
>
> 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).
>
> For NCSG a few things matter: privacy of the domain name registrants,
> accountability and transparency of the system, the requesters and the
> registrars.
>
> 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.
>
> *Background:*
> 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.
>
> *EPDP Phase 2 Context:*
> The EPDP Phase 2 Final Report recommended the creation or designation of
> an * Accreditation Authority* as a critical component of any long-term
> solution for lawful disclosure of domain registration data. This
> recommendation has significant implications for the  disclosure system
>
> *S**ome observations*
>
> *Why LEA authentication is needed:*
>
>    1. *Misclassification of Requests:*
>    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.
>    2. *Lack of Requestor Validation:*
>    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.
>    3. *Authentication vs. Disclosure Balancing:*
>    Note that authentication is 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.
>
> *Non LEAs*
>
>
>
>    1. *Risk of Abuse by Authenticated Non-LEAs:*
>    We have concerns about the *potential for misuse of access* 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.
>
> *Recommendations for Follow-up System Design:*
>
>    - *Initial Focus on Law Enforcement :*
>    I think we should generally agree that future iterations or
>    alternatives to RDRS should prioritize *a**uthentication** of law
>    enforcement requestors* as a first step, both to build trust and to
>    test implementation.
>    - *Need for Further Policy **refinement: *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.
>
> Farzaneh
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250528/08b36f9b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_1c766458-35ee-431a-9a22-e00b47cd2091.png
Type: image/png
Size: 6889 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250528/08b36f9b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newsletter_02744340-c607-4374-8a37-11b8b216096d.png
Type: image/png
Size: 379 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250528/08b36f9b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bluesky1x_864ef831-9476-4116-88b8-2a3410741630.png
Type: image/png
Size: 788 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250528/08b36f9b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facebook_2853baa0-f060-42e6-b448-6a8788c1b5dd.png
Type: image/png
Size: 670 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250528/08b36f9b/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: youtube_ffe95af1-d962-4acd-ab59-4eb4ea07466e.png
Type: image/png
Size: 678 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250528/08b36f9b/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin_199dc89c-14aa-41cd-b2a7-37b8ae8d667d.png
Type: image/png
Size: 720 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250528/08b36f9b/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: instagram_05fbcc72-6df2-442b-8c34-146d0e9d8c41.png
Type: image/png
Size: 840 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250528/08b36f9b/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x_d21e0607-da5a-44a7-80c7-e2d86bc18a92.png
Type: image/png
Size: 895 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250528/08b36f9b/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: women-journalists-banner_b1cece5c-a86d-452f-b9f8-9e72943680f6.jpeg
Type: image/jpeg
Size: 15471 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250528/08b36f9b/attachment.jpeg>