Skip to main content
Resources

Input Group: Law Enforcement Agency Authentication Mechanisms Frequently Asked Questions

What is the purpose of the Input Group?

The Input Group will provide structured input to ICANN org on the development and testing of a proof of concept for authenticating law enforcement requestors who submit urgent requests through the Registration Data Request Service (RDRS) or a successor system.

The group is not a policy development body and will not develop policy recommendations, establish registrar disclosure obligations, or determine how registrars evaluate or respond to disclosure requests. Its role is limited to providing input that may help inform future implementation of an authentication mechanism for law enforcement requestors. Additional details on the group's scope, responsibilities, and expected outcomes are available in the Input Group Charter.

Why is ICANN forming this Input Group?

Community discussions involving the GAC Public Safety Working Group (PSWG), ICANN Board, Generic Names Supporting Organization (GNSO) Council, contracted parties, and ICANN org have highlighted the need for an operational approach to authenticating law enforcement requestors who submit urgent requests for generic top-level domain nonpublic registration data. The Input Group will help inform the development of a proof of concept to support implementation of the Registration Data Policy's requirements for urgent requests. This work will run in parallel with the GNSO's System for Standardized Access/Disclosure Supplemental Recommendations Team (SRT), which is considering revisions to policy recommendations related to requestor authentication that are expected to be submitted to the ICANN Board in March 2027.

The Input Group provides a forum for operational and technical experts to evaluate the feasibility, usability, and technical interoperability of potential authentication approaches that could connect to existing authentication systems with the RDRS or a successor system. The group is not developing a global law enforcement authentication system; rather, it is helping assess how existing authentication mechanisms might be leveraged to support future implementation efforts.

How does the Input Group's work relate to urgent requests?

The group is examining how law enforcement authentication information can be securely and reliably conveyed to registrars so they can have confidence that an urgent request originates from a verified law enforcement requestor. This work helps to prepare for implementation of anticipated policy recommendations and for the need for an authentication mechanism to support enforcement of a 24-hour timeline for ICANN's contracted parties to respond to urgent requests. Under the Registration Data Policy, urgent requests are a subset of disclosure requests where disclosure of registration data is necessary to address or mitigate a threat. These requests must involve at least one of these circumstances to be considered urgent:

  • An imminent threat to life
  • A threat of serious bodily injury
  • Threats to critical infrastructure
  • Child exploitation cases

For purposes of the Input Group's work, an authenticated requestor is a law enforcement requestor whose credentials or affiliation have been validated through an authentication mechanism. As part of the proof of concept, the Input Group is exploring how existing authentication mechanisms, including INTERPOL's Global Digital Police Identity (GDPI) platform and the FBI's Law Enforcement Enterprise Portal (LEEP), may integrate with RDRS.

Who can participate in the Input Group?

The Input Group is open to individuals and organizations with relevant expertise and perspectives who want to help inform the development of the proof of concept. Participants will contribute practical operational, technical, and implementation-focused input on authentication mechanisms for law enforcement requestors. This includes representatives from law enforcement agencies, current and future RDRS users, registrars, and interested participants from ICANN Supporting Organizations and Advisory Committees.

ICANN org issued a public call for participants. Information on how to participate, key timelines, and meeting details are available on the Input Group page. The meeting schedule is expected to be published in July 2026, with meetings anticipated to take place between July 2026 and February 2027. Interested volunteers should email [email protected] to join the group.

What outcomes are expected from the Input Group's work and proof of concept?

The proof of concept will evaluate the feasibility, usability, and technical interoperability of potential authentication approaches to help inform future implementation of authentication mechanisms that support the Registration Data Policy's requirements for urgent requests. Proof-of-concept testing is scheduled to take place in December 2026. At the conclusion of the Input Group's work, ICANN org expects to publish a summary of findings that may include: technical considerations, operational observations, lessons learned, and implementation-related feedback from participants. The findings will help inform future community discussions and implementation considerations.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."