Skip to main content
CybersecurityPrivacy & Surveillance

ICANN Tests Authentication Tech to Unlock Non-Public WHOIS Data for Law Enforcement

Law enforcement officer at a desk with laptop, in a secure setting with formal authentication elements.

"Imminent threat to life, of serious bodily injury, to critical infrastructure, or of child exploitation." That phrase — ICANN’s own definition of the circumstances that would permit urgent access to non‑public WHOIS data — is now the hinge around which a new technical effort is turning.

Input Group on Law Enforcement Agency Authentication Mechanisms explains progress in Bali

ICANN has convened an Input Group on Law Enforcement Agency Authentication Mechanisms to design ways for vetted law enforcement personnel to obtain non‑public WHOIS information when domains are implicated in time‑critical harms. The Input Group outlined its progress during ICANN’s annual meeting in Bali, Indonesia, where it framed the work as largely technical: devise an authentication mechanism and let other ICANN policy groups determine acceptable use and related safeguards.

SAML tests with the FBI and Interpol

At present, ICANN’s preferred technical approach is to use Security Assertion Markup Language (SAML). The organization is already testing SAML-based access to its Registration Data Request Service (RDRS) with two named agencies — the FBI and Interpol — while remaining open to other authentication mechanisms so additional agencies can conform to the system. The Input Group told attendees it aims to publish a specification that agencies can implement to authenticate and file requests through RDRS.

How RDRS requests will reach registrars, and the timelines involved

Under the proposed workflow, authenticated users would log into RDRS and file urgent requests; ICANN would then pass those requests to the registrar that sold the domain. Registrars would have 24 hours to consider a request, with an allowance of up to 72 hours for complex queries. Registrars retain the right to deny requests if they determine an inquiry does not meet the urgency threshold defined by ICANN.

To limit excessive or indiscriminate use, ICANN plans to require law enforcement agencies to nominate which personnel are permitted to make RDRS requests. The verification will be enforced through a token shared during the SAML handshake. The Input Group described the token mechanism as technical, while leaving the detailed content of that token — effectively the policy about who can call RDRS and under what circumstances — to other ICANN bodies to finalize.

Registrar positions, privacy trade‑offs, and the kinds of domain misuse cited

Representatives of two registrars, Namecheap and Verisign, spoke during the session and were reported to be supportive of the proposal. The discussion explicitly acknowledges the tension between privacy and investigatory access: registrars sometimes substitute their own contact details to protect customer privacy, and laws such as the GDPR already require registrars in many cases to hide WHOIS records. ICANN framed the urgent‑access effort as a response to situations where such privacy protections can impede contact with a domain holder whose resources are being misused — examples given were hosting malware, acting as command‑and‑control infrastructure for malware, or facilitating phishing.

The Input Group also flagged the safety of law enforcement personnel filing requests as a concern: ICANN is considering how to protect the identity of workers who make RDRS requests, observing they "could become targets of harassment (or worse)" if their requests expose contact addresses.

What this means for domain registrars, law enforcement agencies, and domain holders

  • Domain registrars: They will be the operational gatekeepers — receiving RDRS requests from ICANN, adjudicating urgency within 24–72 hours, and retaining the authority to deny requests that do not meet the stated threshold.
  • Law enforcement agencies: Agencies that adopt the published SAML (or alternative) spec will be able to nominate specific personnel to file urgent requests through RDRS; those agencies will also need to conform to whatever token content and nomination policies ICANN’s policy groups ultimately set.
  • Domain holders and privacy advocates: Existing privacy practices — including registrars substituting their own contacts and GDPR‑driven redaction — will remain in place for typical queries, while a narrowly defined urgent‑access path will be created for time‑sensitive threats to life, infrastructure, or children.

The work underway is deliberately divided: a technical Input Group is building an authentication mechanism, while other ICANN groups are expected to settle the policy details that determine who may use that mechanism and under what conditions. The immediate next steps called for by the Input Group are publication of the specification agencies can conform to, and subsequent policy work inside ICANN to define the token content and acceptable use rules. How registrars will operationalize adjudication across differing legal regimes, and how identity protections for requesting officers will be baked into both the technical spec and policy, remain the concrete implementation tasks ICANN and its partners have yet to resolve.

Original story