Anne, I think there are some misunderstandings and contradictions in your note to Becky. See comments inline below. On Tue, Jun 9, 2026 at 6:31 AM Anne ICANN via Gnso-ssad <gnso-ssad@icann.org> wrote:
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.
From the registrar's perspective, processing an Urgent Request presents two challenges. One challenge is whether to trust that person making the Urgent Request is competent, trustworthy and accountable. The second is whether the request meets the criteria for an Urgent Request. The entire purpose of having a Designatec User Group is to proactively address these challenges, thereby avoiding time delays, increased workload, and skill or information gaps needed to evaluate a request's legitimacy while reasonably protecting both the registrar and the registrant. I expect there will be one or more Designated User Groups specifically limited to supporting Urgent Requests. For example, a U.S. FBI agent might be a member of a DUG for U.S. Law enforcement personnel who are specifically trained and assigned to handle situations requiring Urgent Requests would be members of the Urgent Request Designated User Group. If someone who is not a member of the Urgent Request DUG wishes to make an Urgent Request, they must either go through a vetting process to provide credible assurance to the registrar that they are trustworthy, accountable and competent, or they need to enlist the aid of someone who has those credentials and is willing to take on the burden of making the Urgent Request. If they choose the first path, they put the registrar in the position of vetting on the spot and assuming the burden of evaluating the situation.
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.
Partly right. Yes, the DUG authenticates its members. But the DUG, as a group, has to document its criteria and process for accepting and authenticating members. Further, it must take responsibility for enforcing discipline and handling complaints. And most importantly, creating a DUG specifically devoted to Urgent Requests or any other purpose is just the first step. The registrars must also evaluate the DUG's purpose, processes and credibility before agreeing to access such requests from its members.
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.
My understanding of indemnification is complete and total protection of the registrar. I have trouble seeing how any system will provide. We should avoid that word and use wording that is closer to we actually expect. Regarding your other questions, DUGs are an efficient way for groups of potential requestors to present an organized and credible case to be registrars. See above for the basic elements. Registrars will also benefit from forming one or more groups that support their members through the process. While it might seem ICANN contracted parties are the only Data Holders in entire Internet ecosystem, ccTLDs, their registrars, and the RIRs have similar roles. The GNSO and the portion of ICANN.Org that supports the RySG and RrSG likely have a natural role to act as the Data Holder User Group that evaluates and interacts with the various Designated User Groups. O
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.)
Formation of a credible law enforcement DUG, or even one that is specific to just U.S. law enforcement agencies must review their processes and practices to determine if they meet thecriteria required by the registrars. Part of that evaluation should include deciding whether using email addresses to authenticate Requestors is adequate.
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.
The purpose of forming a DUG is to satisfy the registrars' requirements. If the registrars agree to empower ICANN to act on their behalf in this regard, that's their choice. But the fundamental criterion is satisfying the registrars, not ICANN. I do not think that would be consistent with existing Urgent Requests
policy.
ICANN's current Urgent Request policy formulation is incomplete. It's aspirational but well short of what's actually needed.
We must also take into account that Urgent Requests are not limited to Law Enforcement.
This is an important point aligns exactly with the idea that the roles, criteria, and processes of a DUG that authorizes its members to make Urgent Requests can define its membership rules. Data Holders who agree to accept such requests will have reviewed and agreed to the DUG's rules. 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?
Nothing prevents a trademark attorney from presenting their case directly to the relevant registrar. However, in doing so, both the trademark lawyer and the registrar will go through the vetting process equivalent to forming a DUG with one member (the trademark attorney), a Data Holder User Group with one member (the registrar), and an Agreement between these groups that covers this particular request. Steve 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
_______________________________________________ Gnso-ssad mailing list -- gnso-ssad@icann.org To unsubscribe send an email to gnso-ssad-leave@icann.org
-- Sent by a Verified sender