Full Report
Single sign-on to help address imminent threats to life, critical infrastructure, or kids
Analysis Summary
# Regulation/Compliance: ICANN Law Enforcement Access to Non-Public WHOIS Data via SAML Authentication
## Overview
ICANN is testing an authentication scheme that would let authenticated law enforcement agencies submit urgent requests for non-public WHOIS (domain registration) data. The requests are limited to imminent threats to life, serious bodily injury, critical infrastructure, or child exploitation. Registrars hide WHOIS data for privacy reasons, including under GDPR, which can make it hard for investigators to reach a domain holder whose domain is used for malware hosting, command-and-control, or phishing. The proposal is at the testing and specification stage. The Input Group on Law Enforcement Agency Authentication Mechanisms is working on it, and ICANN policy groups are expected to set the acceptable-use rules later.
## Key Details
- **Issuing Authority:** ICANN (Internet Corporation for Assigned Names and Numbers), via its Input Group on Law Enforcement Agency Authentication Mechanisms
- **Effective Date:** Not specified. ICANN is currently testing with the FBI and Interpol.
- **Jurisdiction:** Global domain name registration ecosystem, covering ICANN-accredited registrars and law enforcement agencies that request WHOIS data
- **Status:** Proposed / In Testing (not a binding regulation)
## Requirements
### Mandatory Requirements
1. **Urgency threshold:** Requests must relate to an "imminent threat to life, of serious bodily injury, to critical infrastructure, or of child exploitation," per ICANN's definition.
2. **Authenticated access:** Law enforcement users must log in through SAML (Security Assertion Markup Language) to access the Registration Data Request Service (RDRS).
3. **Nominated personnel:** Agencies must nominate specific personnel authorized to submit requests, rather than allowing all individual agents to do so.
4. **Token enforcement:** Permission is enforced with a token exchanged during the SAML handshake. The token's content is still to be finalized by policy groups.
5. **Registrar response window:** Registrars must consider each request within 24 hours, or within 72 hours for complex queries.
6. **Registrar discretion:** Registrars may deny requests they judge do not meet the urgency threshold.
### Recommended Practices
1. **Protect investigator identity:** Explore ways to shield the identities of law enforcement personnel submitting requests, since they could face harassment if email addresses are exposed. This is under consideration, not settled.
2. **Conform to the published specification:** Agencies beyond the FBI and Interpol should adopt the Input Group's spec once published.
3. **Maintain technical interoperability:** Use SAML or another authentication mechanism approved through the ICANN process.
## Affected Organizations
- **Industries:** Domain name registrars (e.g., Namecheap and Verisign were cited as supportive participants), law enforcement agencies, and ICANN-accredited entities in the domain ecosystem
- **Organization Size:** Not specified. The article notes concern about large agencies such as the FBI flooding the system, which is addressed through nominated-personnel limits.
- **Geographic Scope:** Global, with the stated goal of working across multiple jurisdictions
## Compliance Timeline
- **ICANN 87 (Bali, Indonesia, October 2026):** Input Group reported progress during the annual meeting
- **Ongoing:** Testing with FBI and Interpol
- **Future (unspecified):** Publication of the Input Group's specification for agencies
- **Future (unspecified):** Policy groups finalize acceptable use, token content, and related rules
- **Final deadline:** Not specified
## Implementation Guidance
### Assessment Phase
- Registrars: Review current WHOIS privacy and redaction processes to identify how urgent law enforcement requests would be received and triaged.
- Law enforcement agencies: Identify which personnel would be nominated to submit RDRS requests and assess current SAML or federated identity capabilities.
- Both: Track ICANN Input Group and policy-group outputs.
### Implementation Phase
- Registrars: Prepare internal workflows to handle RDRS requests within the 24-hour and 72-hour windows, and define criteria for denying requests that fail the urgency test.
- Agencies: Establish a nominated-personnel roster and integrate SAML authentication with the published specification once available.
- Both: Coordinate with privacy and legal teams to ensure GDPR and other data-protection obligations are met when disclosing non-public data.
### Validation Phase
- Confirm that SAML authentication and token enforcement work in test environments such as those used with the FBI and Interpol.
- Audit request logs for urgency-threshold compliance and response-time adherence.
- Review the final policy outputs for acceptable-use rules once they are published.
## Technical Requirements
- **Authentication:** SAML (Security Assertion Markup Language), the OASIS standard for federated identity, used for login to RDRS
- **Access control:** Token exchanged during the SAML handshake to verify that a requester is a nominated authorized user (token content not yet defined)
- **Request routing:** ICANN forwards RDRS requests to the sponsoring registrar of the domain
- **Response handling:** Registrars must process and respond within 24 hours (72 hours for complex queries)
- **Identity protection:** Under consideration; methods to shield requester contact details are not finalized
## Penalties & Enforcement
- **Fines:** Not specified in the article
- **Other Consequences:** Not specified. Registrars may deny requests they judge non-urgent, which suggests misuse of the channel would be handled through policy rules still to be developed.
- **Enforcement:** Expected to be governed through ICANN policy processes and accreditation requirements. Specific mechanisms are not described.
## Related Standards
- **SAML (OASIS):** Basis for the proposed authentication scheme
- **GDPR (EU):** Cited as the reason registrars increasingly redact WHOIS data; any disclosure mechanism must account for it
- **ICANN Registration Data Request Service (RDRS):** The platform through which requests are filed and routed
- **ICANN policy development process:** Will define acceptable-use and token rules after the technical design is complete
## Resources
- **Official Documentation:** The article does not provide links. Consult ICANN's official site for RDRS documentation and Input Group publications.
- **Guidance Documents:** Input Group on Law Enforcement Agency Authentication Mechanisms outputs (specification pending); ICANN 87 session materials
- **Tools:** Not specified
## Practical Recommendations
- **Registrars:** Build a documented process for receiving, triaging, and responding to RDRS requests within the 24/72-hour windows, and record the rationale for every denial.
- **Law enforcement agencies:** Designate a limited set of authorized requesters and prepare SAML integration in advance of the published spec.
- **Both parties:** Monitor ICANN policy outputs, since acceptable-use rules and token design are still open.
- **Compliance teams:** Assess GDPR and other privacy obligations before disclosing any non-public registration data, and document the legal basis for each disclosure.
- **Privacy and security leads:** Engage with the identity-protection discussion to ensure investigator safety is addressed in the final design.