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

[Emmanuel Vitus]

Thanks Farzi, this is super clear. I’d say we should push for strong
accreditation standards even for non-LEAs, lightweight checks alone risk
abuse, especially in low-rights environments. Let’s also make transparency
and accountability non-negotiables in any future setup.
- Emmanuel

Le sam. 24 mai 2025 à 23:58, farzaneh badii <farzaneh.badii at gmail.com> a
écrit :

> 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
>
> *Some 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 *authentication 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/20250526/a2f8cdf0/attachment.htm>