Summary

  • ICANN revised the Registration Data Policy on 12 May 2026. Authenticated urgent requests must be acknowledged within two hours and answered without undue delay, normally within 24 hours, once Section 10.7 is effective.
  • The policy's implementation note says Section 10.7 becomes effective only when ICANN fully implements a Consensus Policy establishing requester authentication. Publication of the rule and activation of the duty are separate events.
  • ICANN's authentication Input Group is advising a proof of concept, not making policy. Its planned December 2026 testing and March 2027 findings do not themselves start the contractual clock.
  • Authentication should prove a bounded requester status. It must not decide whether a request is urgent, lawful, necessary or entitled to disclosure. A public activation receipt should join the effective event, credential scope, accepted submission surfaces, timer semantics, exceptions and compliance denominator while keeping those decisions separate.

The clock is present in the text

The Registration Data Policy now gives an urgent request an unusually clear temporal shape. Section 3.8 limits the category to requests from an Authenticated Requestor concerning an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation where disclosure is necessary to combat or address the threat. Section 3.9 defines the requester as a law-enforcement authority or trusted or competent authority authenticated through a mechanism implemented pursuant to ICANN Consensus Policy.

Section 10.7 then creates the sequence. The requester must attest that the circumstances meet the urgent definition. A registrar and a registry operator must acknowledge receipt within two hours. They must respond without undue delay and, absent exceptional circumstances, no later than 24 hours. If an exception applies, they must notify the requester within that same 24-hour window, explain the reason and state an expected response time no later than 72 hours from receipt.

The text even says what does not justify an extension. A force-majeure event or a request involving many domain names may create exceptional complexity. Calendar holidays, planned leave and planned travel do not. This is not a decorative aspiration. It is drafted as an operational obligation with a start, an intermediate receipt, a response boundary and a limited escape path.

ICANN's 12 May announcement explains why the category is narrow. These are not ordinary requests for nonpublic gTLD registration data placed in a faster queue. They concern threats in which time may matter to life, bodily safety, critical infrastructure or children. A slow or ambiguous handoff can impose real costs. A precise clock is therefore a legitimate policy objective.

Yet reading only the uppercase MUST clauses produces the wrong current answer.

The clock is waiting at an activation gate

The policy's implementation note states that the obligations under Section 10.7 become effective on the date that ICANN fully implements a Consensus Policy establishing a process for authenticating a requester. The 12 May announcement says the urgent-request language will not go into effect until a law-enforcement authentication mechanism is implemented. ICANN's GAC Advice Status page closes the advice item about the timeline because the language has been published, then expressly notes that enforcement of the 24-hour response timeline remains pending the availability of authentication.

These are not three competing descriptions. They show three different states. The policy text is published. The GAC advice about writing a timeline can be closed. The contractual obligation can still be deferred.

That distinction is easy to lose on a live policy page. A lawyer or compliance officer sees Section 10.7 in the present tense. A law-enforcement requester sees a two-hour acknowledgement and a 24-hour response. A registrar sees an implementation note farther down the page. An automated policy catalogue may index the rule but not its condition. The public record contains the necessary facts, yet does not present them as one activation state.

The problem is not that conditional effectiveness is inherently illegitimate. Distributed systems routinely prepare a rule before its dependency is available. The problem is that the dependency must travel with the rule. If the policy version, activation condition, effective event and covered cohort separate as documents are copied, summarized or implemented, the same words can create incompatible expectations.

The first discipline is therefore linguistic: do not say that ICANN's entire Registration Data Policy is ineffective. It became generally effective on 21 August 2025. The deferred condition belongs specifically to the Section 10.7 urgent-request obligations added in 2026. Equally, do not say the 24-hour duty is enforceable merely because its clauses appear in a live Consensus Policy.

A proof of concept is not the activating event

ICANN has created an Input Group on Law Enforcement Agency Authentication Mechanisms. Its task is practical. It will advise a proof of concept for authenticating law-enforcement agents using the Registration Data Request Service, or a successor system. The group is considering workflow design, technical requirements and authentication processes.

Its public schedule gives the work useful checkpoints: formation in June 2026, meetings beginning in July, RDRS wireframes in October, proof-of-concept testing in December and findings in March 2027. The group has already met. The project is real.

Its authority is also explicitly bounded. The project page says the Input Group is not a policy-development body and will not develop policy recommendations. ICANN's call for participation describes it as advisory and implementation-focused. It will work in parallel with the GNSO Supplemental Recommendations Team, which is considering changes to policy recommendations concerning requester accreditation in a future standardized access and disclosure system.

Parallel work is not merged authority. A technical group may discover how existing law-enforcement authentication systems interoperate, which attributes are needed, how revocation should work, what RDRS changes are practical and how logging can be privacy-preserving. Those findings may make a policy implementable. They do not themselves become the Consensus Policy whose full implementation activates Section 10.7.

The December test is therefore a test. The March report is a report. Neither date is identified in the reviewed sources as the effective date of the obligation. Treating either as automatic activation would repeat the very category mistake that the implementation note was designed to prevent.

Authentication opens a workflow; it does not decide a request

The word “authenticated” can carry too much institutional weight. A credential may prove that a requester belongs to a recognized law-enforcement or competent-authority class, that a particular agency controls the credential, that the credential is current and that the presenting actor is authorized to use it. Even those claims require a defined assurance model, revocation process, audit trail and privacy boundary.

They do not prove that the facts asserted in a request are true. They do not establish that the situation is urgent under Section 3.8. They do not establish jurisdiction, legal basis, necessity, proportionality or entitlement to every requested field. They do not decide whether disclosure would conflict with applicable law.

The policy preserves these distinctions. The requester must separately attest to a qualifying urgent circumstance. The implementation note says the disclosure assessment may include jurisdictional and other applicable-law factors. Section 10.6 preserves an explained response, including reasons for denial. Section 10.8 permits corrective action against abusive requests or requesters. Authentication is one condition in a chain, not a verdict on the chain.

This is where a useful global mechanism can become a dangerous gatekeeper. A narrow federation that lets a registrar trust a defined requester attribute reduces repeated identity work and may save time in a crisis. A broad authority that silently determines who is legitimate, which investigations are urgent, which jurisdictions prevail and which data must be released would centralize legal judgment behind a technical credential.

The correct design is thin. Verify the smallest reusable claim that independent decision-makers need. Make the assurance level and issuer visible. Allow revocation and correction. Minimize personal data. Then return the merits to the party that carries the policy, contractual and legal responsibility for the response.

The India exchange exposes the authority boundary

The current state appears plainly in ICANN's 11 August reply to S. Krishnan of India's Ministry of Electronics and Information Technology. ICANN's CEO says the Registration Data Policy now contains a 24-hour requirement for authenticated urgent requests, but enforcement depends on an appropriate authentication mechanism. He points to work with the GAC Public Safety Working Group, law-enforcement representatives and the new Input Group.

The same letter addresses other Indian proposals, including a 15-day verification period and additional reporting obligations. Its response is institutionally exact: new obligations for registrars and registries must go through the appropriate policy or contractual process. Under ICANN's Bylaws, the GNSO develops gTLD policy and manages the policy-development process. The CEO can support that work and implement adopted policy but cannot direct GNSO priorities or determine PDP outcomes.

That limit is not bureaucratic evasion. It is the chain of authority. A government may identify a public-safety need. The GAC may provide advice. ICANN org may supply evidence and operational expertise. An Input Group may test a mechanism. The GNSO may develop Consensus Policy. The Board may act within the Bylaws. Contracted parties then implement enforceable duties. Skipping a link may feel faster, but it makes the resulting obligation easier to contest and harder to apply consistently.

The urgent-response project should preserve this authority map in public. Otherwise a proof-of-concept screen can appear to create a duty that only policy can create, while a policy clause can appear to authorize disclosure that only a lawful case assessment can authorize.

The missing object is an activation receipt

ICANN does not need another long narrative to explain that the work is underway. It needs a compact, machine-readable and human-readable activation receipt attached to every public presentation of Section 10.7.

The receipt should identify the exact policy version and fingerprint; the Consensus Policy dependency; the decision or implementation event that satisfied it; the effective date, time and timezone; and the authoritative publication where a relying party can verify the event. It should say which requester classes are covered, which credential or federation version is accepted, what the credential proves, how status and revocation are checked and which submission surfaces start the clock.

It should define time. Does receipt occur when RDRS accepts a request, when a contracted party's endpoint receives it, or when an operator opens it? Which timestamp survives a retry? How are duplicate submissions treated? Which clock applies when RDRS is unavailable? What happens to requests already in flight at the effective moment?

It should bind the exceptional path: two-hour acknowledgement, 24-hour response, 24-hour extension notice, 72-hour outer boundary and the policy's non-exception list. It should identify when Contractual Compliance begins measuring and what its denominator contains. A request submitted before activation, a request from an unauthenticated actor and a request rejected by the intake surface cannot be silently mixed with an effective authenticated cohort.

Most important, the receipt should carry a negative statement: authentication proves the listed requester attributes only. It does not establish urgency, jurisdiction, legal basis, necessity, proportionality or a right to disclosure. Those determinations remain where policy and law place them.

This receipt is Daniel Kade's proposal, not current ICANN policy. It is not a public list of officers, agencies, targets or investigations. Its operational fields can be public while requester identities, domain names, case details and nonpublic registration data remain protected.

Measure the handoff, not the investigation

The SSAC's SAC122 advice asked ICANN to collect high-level information about urgent requests: how many arrived, how quickly they were handled, how many were spam or invalid and how many met the contractual timing requirement. Its final-policy details do not all control—the final text uses a two-hour acknowledgement rather than SAC122's proposed 30 minutes—but the measurement principle remains useful.

Public accountability does not require publishing investigations. It requires a reliable denominator and state transitions. Count authenticated requests received after activation. Separate requests that failed credential validation from requests that passed authentication but failed urgency or legal review. Record acknowledgement latency, response latency, extension use, the distribution of stated exception categories and whether a final response arrived within 72 hours. Publish aggregates with thresholds that prevent reidentification.

Do not count a denial as a missed response. Section 10.7 is a response clock, not an automatic-disclosure clock. A timely, reasoned denial may satisfy the temporal duty even though no data is disclosed. Conversely, an eventual disclosure does not erase a missed acknowledgement or response boundary. Outcome and timeliness are different axes.

The same distinction protects both sides. Law enforcement can see whether the emergency channel is responsive without exposing cases. Contracted parties can show that authentication failures, abusive requests and lawful denials are not being mislabeled as delay. Data subjects retain a record architecture in which a credential never becomes a blank cheque.

Evidence limits

This article relies on the live Registration Data Policy, ICANN's 12 May announcement, the Input Group page and call for participation, the GAC Advice Status page, ICANN's 11 August reply to the Government of India, SAC122 and ICANN's RDRS work summary. The reviewed materials do not fix the eventual activation date, final identity provider, federation model, assurance profile, transition rule or compliance denominator. They do not say that December 2026 proof-of-concept testing activates Section 10.7. This article does not infer that urgent requests cannot be processed through other lawful procedures before activation.

The proposed activation receipt and thin-authentication design are Daniel Kade's analysis.

Sources

  1. ICANN — Registration Data Policy
  2. ICANN — Urgent Requests Requirement announcement
  3. ICANN — Law Enforcement Agency Authentication Mechanisms Input Group
  4. ICANN — Call for Participation in the Authentication Input Group
  5. ICANN — GAC Advice Status
  6. ICANN — Kurt Erik Lindqvist to S. Krishnan
  7. ICANN SSAC — SAC122 Executive Summary
  8. ICANN — RDRS Work Summary