Becky, There should be standards (criteria as mentioned in Sarah's bullet point below) allowing individual LEAs to prove authentication when making an Urgent Request without having to join a Designated User Group. The LEA could also prove that it meets these standards prior to having to make an urgent request for the very purpose of being certain that the Urgent Request SLA timeline applies. A legitimate LEA should not be required to join a Designated User Group in order to file an Urgent Request that is met in accordance with the timeline. SSAD Supplemental Policy Recommendations need to take this fact situation into account. It seems to me that Designated User Groups carry some other problematic features. Are we saying that Registrars must be able to rely on these groups to certify that their members are "authenticated"? If so, then I would expect the risk profile to shift because the registrar will not be seeing directly into the authentication of each member. Wouldn't the registrar expect indemnification from the Designated User Group? Justine raised this issue in the Monday meeting. Moreover, how and when will such Designated User Groups be formed? Who will assume this responsibility? I believe this approach entails risk shifting and delays in implementation. We may look at the FBI, Interpol, and Europol as User Groups that are already formed but as we learned in the PSWG Authentication work, even those groups would not be considered by some to be "authenticated" since we still don't know how their email addresses are validated and purged, although we have been asking for this documentation since the very beginning of those PSWG meetings. Now we have heard that the PSWG is closing its effort and ICANN Org is taking over? (Councilors who have been participating on PSWG Authentication were not previously advised of this.) In addition, with respect to Law Enforcement requests in particular, LEAs in the Global South and other regions which are not a part of any designated group such as Interpol or Europol, should not be forced to undertake efforts to form a Designated User Group in their region just to satisfy ICANN. I do not think that would be consistent with existing Urgent Requests policy. We must also take into account that Urgent Requests are not limited to Law Enforcement. There are certainly examples of counterfeit products exploding in the hands of minors and causing severe bodily harm. Are we saying, as a matter of Supplemental Policy Recommendations, that a trademark lawyer seeking to shut down a counterfeit dangerous product, will not be able to make an Urgent Request to access registration data without first joining a Designated User Group that currently does not exist? Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Mon, Jun 8, 2026 at 5:51 AM Becky Burr <bburr@pir.org> wrote:
Anne,
I think the reason that only authenticated users can make urgent requests is because urgent requests involve strict SLAs. Certainly, unauthenticated law enforcement can submit requests, but the responder will need to authenticate the requester prior to responding, which can take quite a lot of time if the request is not coming from local law enforcement.
B
Get Outlook for iOS <https://aka.ms/o0ukef> ------------------------------ *From:* Anne ICANN via Gnso-ssad <gnso-ssad@icann.org> *Sent:* Monday, 08 June 2026 12:54:32 *To:* Sarah Wyld <swyld@tucows.com> *Cc:* gnso-ssad@icann.org <gnso-ssad@icann.org> *Subject:* [Gnso-ssad] Re: Summary of Day 0 Key Points
Hi Sarah et al. The bullet point you list below is so important:
*The responding party needs to know a requestor really is authenticated - is there a way to look them up or confirm a token or something else? Can the responding party view the existing accredited users? (This may be covered by 1.4.2)*
On the topic of Designated User Groups, these groups can help facilitate trust in the nature of the user making the request because presumably the User Group is a way to verify the credentials of the Requestor and the particular Requestor can be "pre-screened" or "pre-authenticated" by the Designated User Group.
If authentication is a requirement for processing an Urgent Request (as stated by staff)t, then I don't think Urgent Requests policy requires a Requestor to join a Designated User Group in order to get authenticated. There should be minimum criteria specified that a Requestor can satisfy without having to join a Designated User Group. Certainly the purpose of a Designated User Group would be to assure the Contracted Party that these criteria *have already been met*, but to my mind, that does not mean that an individual Requestor could not meet these criteria independently by proving them up to the CP.
As to LEAs, as far as I know, it has never been the understanding in the PSWG Authentication group that an LEA must join a Designated User Group in order to be eligible to process an Urgent Request.
However, as I understand what Marc said, the policy is as follows:
*Only authenticated Requestors are eligible to make Urgent Requests. A Requestor cannot be authenticated except by joining a Designated User Group. *
Is that the policy? Or is there a path to authentication for a Requestor, e.g. an LEA, that is NOT a member of a Designated User Group?
In the case of trademark lawyers, there are counterfeit products that can result in severe bodily injury, e.g. products that explode in the hands of the user. Are we saying that unless the trademark lawyer is part of a Designated User Group of trademark lawyers, then (s)he/they is not eligible to make an Urgent Request because the only path to authentication is to become a member of a Designated User Group?
Separately, as Justine pointed out in today's meeting, will the Designated User Group be ultimately responsible foretablishing and maintaining its list of authenticated members? Will the DUG indemnity the Contracted Party regarding the credentials of its members?
I'm sure Marc and others will be happy to correct everything that I have misunderstood and misstated in the above. So I look forward to our next meeting.
Anne
Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com
On Sun, Jun 7, 2026 at 1:20 PM Sarah Wyld via Gnso-ssad < gnso-ssad@icann.org> wrote:
Hello all,
Thank you for a productive meeting today.
Re the topic of §1.4, I think the whole section including the sub-points (1.4.1 - 1.4.4) should be moved from Implementation Notes to Policy, and we may need a note similar to the one there (about implementation) but the specifics of the note may need to change.
Most of the requirements we need in 1.4 are already there, but there are a few more things we should work through, and areas where this will connect in to other recs:
- The responding party needs to know a requestor really is authenticated - is there a way to look them up or confirm a token or something else? Can the responding party view the existing accredited users? (This may be covered by 1.4.2) - Does (should) the system track data on how the authentication is used in relation to disclosure requests? Who has access to that data? - What public reporting is done? What private reporting is done, and to whom? - This ties to Rec 17 but we may need to include relevant requirements here. - Who audits the system operator to ensure adherence to requirements? What happens if the system operator does not adhere to requirements? - This is tied to Rec 16 but again may need groundwork laid here.
Thank you,
*Sarah Wyld, CIPP/E* Pronouns: she/they
Head, Policy & Privacy Tucows #MakingTheInternetBetter
swyld@tucows.com
On 2026-06-07 7:54 p.m., Andrew Chen via Gnso-ssad wrote:
Dear SRT Members,
Thank you for your engaged participation in today’s Day 0 meeting. Please find linked a pdf copy of the key points and flowchart discussed during today’s meeting.
Please see below for our discussion questions for tomorrow’s face to face meeting. These discussion questions aim to build on the key points that were discussed today.
*Discussion questions for tomorrow’s meeting *
- What aspects of Section 1.4 should move from Implementation Guidance to Policy Recommendation? - What is the minimum information a data controller needs from an authenticated user in order to evaluate and make a disclosure decision? - Can we agree to combine recommendations 1 and 2. If yes, what information from recommendation 2 needs to be moved to recommendation 1?
Please see below for tomorrow’s meeting time and location:
Date and Time : 10:00am - 11:15am CEST
Location: FIBES Conference and Exhibition Centre in Madrid (GNSO) - Floor 3 or via zoom (see sched schedule <https://url.us.m.mimecastprotect.com/s/vd4iC732EXik2Y9C8f5copewv?domain=ican...> for zoom link)
We look forward to seeing you all tomorrow.
Sincerely,
Andrew
--
Andrew Chen
Policy Development Support Sr. Specialist, Policy Development Support
Internet Corporation for Assigned Names and Numbers (ICANN)
https://www.icann.org/ <https://url.us.m.mimecastprotect.com/s/fOgTC820GEtRWgxc1hjcyI843?domain=ican...>
_______________________________________________ Gnso-ssad mailing list -- gnso-ssad@icann.org To unsubscribe send an email to gnso-ssad-leave@icann.org
_______________________________________________ Gnso-ssad mailing list -- gnso-ssad@icann.org To unsubscribe send an email to gnso-ssad-leave@icann.org