Thanks Ashley.  I don't think the Attestation that is proposed by the LEAs in the PSWG Working Group would operate as an indemnity that the emails are always accurate.  This would be a good topic of discussion in the meeting with the GAC - to see the language of the Attestation.  It strikes me that there is nothing about the proposed short term solution that takes away the obligation of the Registrar to verify the validity of the Requestor.  I think the short term solution is proposed as just "additional information" that would be helpful to the registrars.

Been trying to catch up and now know that summary of public comment on IRT proposals actually occurred in January!.  In this regard, it does not appear to me that the summary draws a conclusion as to whether further policy work is needed as to the definition of "Authenticated Requestor" but would be very interested in others point of view on this.  Summary is linked here and also attached.

https://itp.cdn.icann.org/en/files/new-generic-top-level-domain-gtld-program/summary-report-timeline-ur-lawful-disclosure-nonpublic-registration-data-14-01-2026-en.pdf

Anne


Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com


On Mon, Feb 23, 2026 at 9:31 AM aheineman@godaddy.com <aheineman@godaddy.com> wrote:
Thanks for this background, Anne and a note to others in the original email that Anne's response added full council distro and no longer a private exchange (just wanted folks to be aware for transparency's sake).  

Anne, you provide alot of helpful context and I also have a question regarding your suggestion to the PSWG Authentication Working Group that  "appropriate disclaimers may have to be made as to the accuracy of the email addresses provided since many registrars (especially smaller ones) might not have the resources to conduct an independent investigation of authenticity of the Requestor email address on an urgent timeline."   Wouldn't such a disclaimer remove any liability from the requester and push to the registrar?  And, if the information is potentially incorrect, then little (if any) value is being offered through this schema.  

From: Anne ICANN <anneicanngnso@gmail.com>
Sent: Sunday, February 22, 2026 9:34 PM
To: farzaneh badii <farzaneh.badii@gmail.com>
Cc: Ashley Heineman <aheineman@godaddy.com>; lawrence@microboss.org <lawrence@microboss.org>; Council@icann.org <council@icann.org>
Subject: Re: Urgent Requests/LEA
 
Ashley, As far as I know (and I may not be current since some extenuating circumstances here in Tucson have forced a delay in my participation and response), the PSWG Authentication Group is looking at the terminology involved in a set of questions
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
 
ZjQcmQRYFpfptBannerEnd
Ashley,
As far as I know (and I may not be current since some extenuating circumstances here in Tucson have forced a delay in my participation and response), the PSWG Authentication Group is looking at the terminology involved in a set of questions developed by Gabriel Andrews of the FBI that seek to address concerns we all expressed about the proposed short term solution to authentication, i.e. Law Enforcement Agencies to supply email addresses they consider valid to ICANN and to attest to their view of the validity of these Requestor email addresses.  ICANN would then supply these email addresses to registrars as a first step to supply additional information that a registrar can consider when evaluating an Urgent Request.  

I remember emphasizing a need to understand how each LEA acquires, validates, reviews and purges these addresses since some in the practitioners group have pointed out that email addresses can be fabricated but still have the appearance of being official.  Farzi and I and others have been asking to be able to understand these email list practices on an LEA-by-LEA basis; ever since the initiation of the PSWG meetings on this topic.  I also suggested that in the short term solution proposed by Gabe, Interpol, and Europol, appropriate disclaimers may have to be made as to the accuracy of the email addresses provided since many registrars (especially smaller ones) might not have the resources to conduct an independent investigation of authenticity of the Requestor email address on an urgent timeline.

Gabe recently sent around the following list of questions representing his understanding of the questions the group still has and several members commented on the terminology.   I cannot update you as to any changes to terminology which may have been made.  Farzi may be more current than I. I would expect that Gabe will be presenting a slide on this at the GAC-Council meeting but I don't know for certain.

  • At a high level, what is the proposed mechanism for Law Enforcement Agencies (LEAs) to authenticate users of ICANN’s Registration Data Request Service?
  • Who is expected to serve as an Identity Provider for LEAs?
  • How does each LEA Identity Provider determine (or verify) that an agency is or isn’t a LEA?  How do they verify that the user is an actual member of that law enforcement agency? 
  • How many agencies and/or users are expected to have access to authenticated connections to RDRS via the law enforcement portals?
  • How frequently is the status (or employment) of a LEA user validated?
  • What information is expected to be passed to the data holder when an authenticated LEA requestor submits an RDRS request?
  • Are there any technical requirements expected of a data holder?
  • Is the LEA request logged?  By whom? For how long?
  • What rules govern how a LEA requestor uses the authentication portal? (i.e. what commitments are made in regards to responsible use?)
  • What recourse exists to a data holder if a LEA requestor is suspected of abuse/misuse of the RDRS?
  • Does an authenticated request carry any additional obligation to disclose data vs a non-authenticated request? 
  • What documentation is expected to exist, and where can it be found?

Jurisdictional Issues

 As to the subject of jurisdiction, we have made the point in the PSWG meetings that not every registrar is subject to the jurisdiction of every LEA.  So, as Farzi noted in a meeting last week, the question whether the registrar is actually legally required or able to respond to an LEA request is one each registrar must determine for itself even in advance of evaluating whether the request meets the Urgent Request definition in the existing policy.  As you know, the IRT on this topic noted in its request for public comment that the registrar should respond accordingly to the LEA if jurisdictional issues form the basis for a denial of disclosure in a case that would potentially qualify as an Urgent Request.  I assume public comment would have favored this recommended  approach from the IRT in recognition of the fact that the jurisdictional issues are very real.

These jurisdictional issues were covered extensively in Thomas Rickert's presentation to the GAC in Dublin on this topic. It would be a good idea to review the zoom on that meeting since some theories on the reach of jurisdiction were explored in addition to a discussion regarding EU interpretation of the applicability of MLAT provisions.  This is pretty complex stuff but I know the European Commission representative on the GAC has some knowledge on this topic and made a comment in response to Thomas' summary of the jurisdictional topic.

Policy Process

As to whether a policy process is necessary to define "Authenticated Requestor", as outlined in the material put out by the IRT for public comment, I do not know if the staff summary is available but I would certainly expect it will be before Mumbai.  My recollection is there were comments in support of a policy process and other comments saying it was not necessary, including of course by the GAC, but at least one registrar agreed no policy process was necessary.   In this regard, I think it would be better to revise the slide to state "the Policy process anticipated by the IRT" rather than saying "the anticipated Policy process" as if this were a Council official position.

Again, I am not certain of being up to date on the above topics. Wish you well in facilitating the discussion with the GAC.  I will not be in Mumbai but will be participating remotely.

Thank you,
Anne

Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026


On Wed, Feb 18, 2026 at 8:14 AM farzaneh badii <farzaneh.badii@gmail.com> wrote:
Hi Ashley,

The practitioner group is putting all sorts of questions together, I wonder if we should pose those during our meeting. Another thing is as Anne and I have been consistently saying, we need to know which protocols law enforcement use to authenticate their emails and what policies they have for requesting disclosure. I just don't know if we should put those questions forward. 

I'd like to discuss more about GAC opinion that urgent request should not go through  a round of policy and understand them better but I don't know if the council wants to pose that question. 

Farzaneh 


On Tue, Feb 17, 2026 at 2:54 PM aheineman@godaddy.com <aheineman@godaddy.com> wrote:

Hi guys.  I volunteered to be the spokesperson for the Urgent Request/LEA discussion with the GAC in Mumbai.   Below is the start of talking points from Seb, even thought this will largely be a GAC lead.  That being said, since you guys participate on the LEA group, could you kindly let me know if you think there is anything we should proactively add or question during the dialogue?  Thanks in advance!

 

  • Urgent Request/LEA Agencies
    • TOPIC LEAD - Ashley Heineman
    • The GNSO expects the GAC/PSWG to lead this discussion.
    • The Practice Group had a question over jurisdiction [get question from Lawrence, Farzaneh or Anne who were there... I was too but frankly I don't remember]
    • We acknowledge the agreed need for discretion over this topic in public/on the mic and understand the limited disclosures PSWG will be able to offer on the topic.
    • We nevertheless hope to be able to get enough of an understanding to be able to, for example, assess the anticipated Policy work to frame the outcomes.