Great thoughts for discussion Sarah! 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://icann86.sched.com/event/2NQMo/gnso-ssad-supplemental-recommendations...> 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/

_______________________________________________ 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

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://icann86.sched.com/event/2NQMo/gnso-ssad-supplemental-recommendations...> 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/

_______________________________________________ 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

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

Agree with Steve. Farzaneh On Tue, Jun 9, 2026 at 12:54 PM Steve Crocker via Gnso-ssad < gnso-ssad@icann.org> wrote:

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 _______________________________________________ Gnso-ssad mailing list -- gnso-ssad@icann.org To unsubscribe send an email to gnso-ssad-leave@icann.org

Apparently I need to clarify that by referring to an "individual Requestor", I mean, for example, an individual trademark lawyer or an individual government making an Urgent Request, as opposed to, for example, an LEA which is a member of a DUG. Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Tue, Jun 9, 2026 at 4:44 AM Anne ICANN <anneicanngnso@gmail.com> wrote:

Thanks Steve - to try to simplify the issue and get clarification - I understood the Chair and others to say that the net result regarding Urgent Requests in our policy work so far is that Urgent Requests may only be made through a Designated User Group because that will be the only path to authentication for the category of Urgent Requests. Your notes below do not seem to be consistent with that view.

If an individual Requestor needs to make an Urgent Request, I would have no problem with saying the 24 hour timeline for some initial response to an Urgent Request does not kick in until the Registrar is satisfied as to the individual Requestor's authenticated credentials, but requiring the individual Requestor to be a member of a DUG is too high a barrier.

Regarding Law Enforcement Agency Urgent Requests, is the SRT proceeding on the idea that all LEAs must go through the proposed new ICANN system in order to be "Authenticated" in a manner that permits an Urgent Request?

This all relates to the definition of "Authentication". My view is that criteria for Authentication can be established outside the context of a Designated User Group. I understand the Chair to be saying something different.

If your conclusion is that an Urgent Request (with associated timelines) can still be made without being a member of a DUG, it would be good for Leadership to confirm that understanding.

And yes, it would be good to know what ICANN is willing to say about the degree to which registrars may rely on the Authentication system it is developing for Law Enforcement. And will that system include the ability for an individual Law Enforcement Agency to prove up credentials to ICANN without being a member of the FBI, Europol, or Interpol or some other DUG?

Anne

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

On Tue, Jun 9, 2026 at 3:54 AM Steve Crocker <steve@shinkuro.com> wrote:

...

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

Hi Becky. I don't think I have heard a prior agreement on a policy that trademark lawyers can't make Urgent Requests? Hopefully the IPC can enlighten the Team on this point. In the interest of clarity, it may be helpful to focus on the definition of "Authenticated Requestor" that appears in the Strawperson: See page 52 - *"Authenticated Requestor" means a law enforcement requestor or trusted/competent authority that is authenticated through a mechanism implemented by ICANN org with input from the ICANN community. For avoidance of doubt, the implementation work on an authentication mechanism is not limited to requests submitted via the SSAD."* This definition certainly makes sense to me. It strikes me that the "trusted/competent authority" can vary depending on the nature of the Requestor and this definition has implications for implementation as to the criteria to be developed around "trust". In other words, I don't think a "trusted/competent authority" always involves a "Designated User Group". For example, if an individual government has to make an Urgent Request, are we saying that the government has to be authenticated with a Designated User Group in order to invoke the Urgent Request timelines? What is the appropriate "trusted/competent authority" for an individual government Urgent Request? 2.3 from SSAD says "Eligible government entities are those that require access to non-public registration data for the exercise of their public policy task, in compliance with applicable data protection laws." There is an old reference to a territory-designated Accreditation Authority, but we aren't doing that any more (way too complicated and expensive) so how will a government request be determined to come from an "Authenticated Requestor" and be eligible to be processed in Urgent Request timelines?" Again, here we are only talking about how the registrar knows for sure who is on the other end of the line - not whether any disclosure should be made. You can call the above governmental request example a "hypothetical" or you can call it a "stress test" for the reference to a "Designated User Group". Your thoughts? Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.c <anneicanngnso@gmail.com> On Tue, Jun 9, 2026 at 9:23 AM Becky Burr <bburr@pir.org> wrote:

Not an issue for trademark lawyers as they can’t make urgent requests.

Becky Burr Sent from my iPhone

On Jun 9, 2026, at 16:36, Anne ICANN <anneicanngnso@gmail.com> wrote:

 *CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.* ------------------------------ Apparently I need to clarify that by referring to an "individual Requestor", I mean, for example, an individual trademark lawyer or an individual government making an Urgent Request, as opposed to, for example, an LEA which is a member of a DUG.

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

On Tue, Jun 9, 2026 at 4:44 AM Anne ICANN <anneicanngnso@gmail.com> wrote:

...

Thanks Steve - to try to simplify the issue and get clarification - I understood the Chair and others to say that the net result regarding Urgent Requests in our policy work so far is that Urgent Requests may only be made through a Designated User Group because that will be the only path to authentication for the category of Urgent Requests. Your notes below do not seem to be consistent with that view.

If an individual Requestor needs to make an Urgent Request, I would have no problem with saying the 24 hour timeline for some initial response to an Urgent Request does not kick in until the Registrar is satisfied as to the individual Requestor's authenticated credentials, but requiring the individual Requestor to be a member of a DUG is too high a barrier.

Regarding Law Enforcement Agency Urgent Requests, is the SRT proceeding on the idea that all LEAs must go through the proposed new ICANN system in order to be "Authenticated" in a manner that permits an Urgent Request?

This all relates to the definition of "Authentication". My view is that criteria for Authentication can be established outside the context of a Designated User Group. I understand the Chair to be saying something different.

If your conclusion is that an Urgent Request (with associated timelines) can still be made without being a member of a DUG, it would be good for Leadership to confirm that understanding.

And yes, it would be good to know what ICANN is willing to say about the degree to which registrars may rely on the Authentication system it is developing for Law Enforcement. And will that system include the ability for an individual Law Enforcement Agency to prove up credentials to ICANN without being a member of the FBI, Europol, or Interpol or some other DUG?

Anne

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

On Tue, Jun 9, 2026 at 3:54 AM Steve Crocker <steve@shinkuro.com> wrote:

...

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://url.us.m.mimecastprotect.com/s/EEfjCpYl42C8Eo4SPfQcGMB1b?domain=aka....> ------------------------------ *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/5oUQCqxmgZS56NYUXhkcEV97o?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/BjSFCrknj9Fv3ZQh4iXc4iCMO?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

Anne, You may have missed my point. See below. On Tue, Jun 9, 2026 at 1:44 PM Anne ICANN <anneicanngnso@gmail.com> wrote:

Thanks Steve - to try to simplify the issue and get clarification - I understood the Chair and others to say that the net result regarding Urgent Requests in our policy work so far is that Urgent Requests may only be made through a Designated User Group because that will be the only path to authentication for the category of Urgent Requests. Your notes below do not seem to be consistent with that view.

If an individual Requestor needs to make an Urgent Request, I would have no problem with saying the 24 hour timeline for some initial response to an Urgent Request does not kick in until the Registrar is satisfied as to the individual Requestor's authenticated credentials, but requiring the individual Requestor to be a member of a DUG is too high a barrier.

These are, in effect, the same thing. "[U]ntil the Registrar is satisfied as to Requestor's authenticated credentials" implies the Registrar has, in effect, created a new Designated User Group for Requestors to make Urgent Requests of the Registrar's data and admitted the Requestor to this newly created, self-operated Designated User Group.

Regarding Law Enforcement Agency Urgent Requests, is the SRT proceeding on the idea that all LEAs must go through the proposed new ICANN system in order to be "Authenticated" in a manner that permits an Urgent Request?

There is no reason to limit the creation of Designated User Groups only to those that ICANN Org is willing and able to create. Any Data Holder or group of Data Holders can choose to create a new DUG and determine both the criteria for membership and the kinds of requests members are authorized to make. Perhaps you are implicitly trying to have ICANN impose a policy on the contracted parties that Registrars must not only accept Urgent Requests from members of an ICANN-established DUG, they must also be willing and able to create private, ad hoc, DUGs whenever someone who is not a member of the ICANN DUG demands they do so.

This all relates to the definition of "Authentication". My view is that criteria for Authentication can be established outside the context of a Designated User Group. I understand the Chair to be saying something different.

If your conclusion is that an Urgent Request (with associated timelines) can still be made without being a member of a DUG, it would be good for Leadership to confirm that understanding.

And yes, it would be good to know what ICANN is willing to say about the degree to which registrars may rely on the Authentication system it is developing for Law Enforcement. And will that system include the ability for an individual Law Enforcement Agency to prove up credentials to ICANN without being a member of the FBI, Europol, or Interpol or some other DUG?

Anne

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

On Tue, Jun 9, 2026 at 3:54 AM Steve Crocker <steve@shinkuro.com> wrote:

...

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

-- Sent by a Verified sender

Anne, There is no reason that every Desibgnated User Group has to be created or authorized by ICANN. Data Holders ultimately determine whom they trust. Steve On Wed, Jun 10, 2026 at 11:44 AM Anne ICANN <anneicanngnso@gmail.com> wrote:

Thanks Steve. I think the term Designated User Group isn't applicable in the case of all entities that can become Authenticated Requestors. The language used on page 52 of our Strawperson document is "trusted/competent authority". That is easier to understand than policy language that says that an individual Requestor (e.g. a government) is a Designated User Group.

The ICANN system for LEAs definitely seems to be one where the database will contain Designated User Groups. This DUG terminology does not seem to apply well though, to the entities listed in Recommendation 2 other than LEAs.

Trusted/Competent Authority is great language offered by our staff on page 52 of the Strawperson. Anne

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

On Tue, Jun 9, 2026 at 8:33 PM Steve Crocker <steve@shinkuro.com> wrote:

...

Anne,

You may have missed my point. See below.

On Tue, Jun 9, 2026 at 1:44 PM Anne ICANN <anneicanngnso@gmail.com> wrote:

...

Thanks Steve - to try to simplify the issue and get clarification - I understood the Chair and others to say that the net result regarding Urgent Requests in our policy work so far is that Urgent Requests may only be made through a Designated User Group because that will be the only path to authentication for the category of Urgent Requests. Your notes below do not seem to be consistent with that view.

If an individual Requestor needs to make an Urgent Request, I would have no problem with saying the 24 hour timeline for some initial response to an Urgent Request does not kick in until the Registrar is satisfied as to the individual Requestor's authenticated credentials, but requiring the individual Requestor to be a member of a DUG is too high a barrier.

These are, in effect, the same thing. "[U]ntil the Registrar is satisfied as to Requestor's authenticated credentials" implies the Registrar has, in effect, created a new Designated User Group for Requestors to make Urgent Requests of the Registrar's data and admitted the Requestor to this newly created, self-operated Designated User Group.

...

Regarding Law Enforcement Agency Urgent Requests, is the SRT proceeding on the idea that all LEAs must go through the proposed new ICANN system in order to be "Authenticated" in a manner that permits an Urgent Request?

There is no reason to limit the creation of Designated User Groups only to those that ICANN Org is willing and able to create. Any Data Holder or group of Data Holders can choose to create a new DUG and determine both the criteria for membership and the kinds of requests members are authorized to make. Perhaps you are implicitly trying to have ICANN impose a policy on the contracted parties that Registrars must not only accept Urgent Requests from members of an ICANN-established DUG, they must also be willing and able to create private, ad hoc, DUGs whenever someone who is not a member of the ICANN DUG demands they do so.

...

This all relates to the definition of "Authentication". My view is that criteria for Authentication can be established outside the context of a Designated User Group. I understand the Chair to be saying something different.

If your conclusion is that an Urgent Request (with associated timelines) can still be made without being a member of a DUG, it would be good for Leadership to confirm that understanding.

And yes, it would be good to know what ICANN is willing to say about the degree to which registrars may rely on the Authentication system it is developing for Law Enforcement. And will that system include the ability for an individual Law Enforcement Agency to prove up credentials to ICANN without being a member of the FBI, Europol, or Interpol or some other DUG?

Anne

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

On Tue, Jun 9, 2026 at 3:54 AM Steve Crocker <steve@shinkuro.com> wrote:

...

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

-- Sent by a Verified

sender

-- Sent by a Verified sender

DUGs can come in various sizes, and they can have agreements with various collections of Data Holders. In the extreme, a DUG can have just one member and be authorized to make requests of only one Data Holder. There is very little cost to create a DUG. It's just a matter of an agreement between the members of the DUG and the group of Data Holders. Steve On Wed, Jun 10, 2026 at 11:59 AM Becky Burr <bburr@pir.org> wrote:

So that's an interesting issue.

The value of being part of a DUG is that all responders know you have been authenticated in compliance with the minimum specifications and whatever additional assurance levels the DUG provides. All responders can then use this information to decide whether or not they trust the requestor.

Of course, individuals can make requests and be authenticated by the relevant responder, but that doesn't carry over to other responders. I would think that individuals who want to be authenticated across the environment would need and want to be part of something - a DUG of otherwise unaffiliated requestors? Not clear who would provide that service, but ICANN is not likely the most efficient choice.

b ------------------------------ *From:* Steve Crocker <steve@shinkuro.com> *Sent:* Wednesday, June 10, 2026 11:49 AM *To:* Anne ICANN <anneicanngnso@gmail.com> *Cc:* Becky Burr <bburr@pir.org>; Sarah Wyld <swyld@tucows.com>; gnso-ssad@icann.org <gnso-ssad@icann.org> *Subject:* [EXTERNAL] Re: [Gnso-ssad] Re: Summary of Day 0 Key Points

*CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.* ------------------------------ Anne,

There is no reason that every Desibgnated User Group has to be created or authorized by ICANN. Data Holders ultimately determine whom they trust.

Steve

On Wed, Jun 10, 2026 at 11:44 AM Anne ICANN <anneicanngnso@gmail.com> wrote:

Thanks Steve. I think the term Designated User Group isn't applicable in the case of all entities that can become Authenticated Requestors. The language used on page 52 of our Strawperson document is "trusted/competent authority". That is easier to understand than policy language that says that an individual Requestor (e.g. a government) is a Designated User Group.

The ICANN system for LEAs definitely seems to be one where the database will contain Designated User Groups. This DUG terminology does not seem to apply well though, to the entities listed in Recommendation 2 other than LEAs.

Trusted/Competent Authority is great language offered by our staff on page 52 of the Strawperson. Anne

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

On Tue, Jun 9, 2026 at 8:33 PM Steve Crocker <steve@shinkuro.com> wrote:

Anne,

You may have missed my point. See below.

On Tue, Jun 9, 2026 at 1:44 PM Anne ICANN <anneicanngnso@gmail.com> wrote:

Thanks Steve - to try to simplify the issue and get clarification - I understood the Chair and others to say that the net result regarding Urgent Requests in our policy work so far is that Urgent Requests may only be made through a Designated User Group because that will be the only path to authentication for the category of Urgent Requests. Your notes below do not seem to be consistent with that view.

If an individual Requestor needs to make an Urgent Request, I would have no problem with saying the 24 hour timeline for some initial response to an Urgent Request does not kick in until the Registrar is satisfied as to the individual Requestor's authenticated credentials, but requiring the individual Requestor to be a member of a DUG is too high a barrier.

These are, in effect, the same thing. "[U]ntil the Registrar is satisfied as to Requestor's authenticated credentials" implies the Registrar has, in effect, created a new Designated User Group for Requestors to make Urgent Requests of the Registrar's data and admitted the Requestor to this newly created, self-operated Designated User Group.

Regarding Law Enforcement Agency Urgent Requests, is the SRT proceeding on the idea that all LEAs must go through the proposed new ICANN system in order to be "Authenticated" in a manner that permits an Urgent Request?

There is no reason to limit the creation of Designated User Groups only to those that ICANN Org is willing and able to create. Any Data Holder or group of Data Holders can choose to create a new DUG and determine both the criteria for membership and the kinds of requests members are authorized to make. Perhaps you are implicitly trying to have ICANN impose a policy on the contracted parties that Registrars must not only accept Urgent Requests from members of an ICANN-established DUG, they must also be willing and able to create private, ad hoc, DUGs whenever someone who is not a member of the ICANN DUG demands they do so.

This all relates to the definition of "Authentication". My view is that criteria for Authentication can be established outside the context of a Designated User Group. I understand the Chair to be saying something different.

If your conclusion is that an Urgent Request (with associated timelines) can still be made without being a member of a DUG, it would be good for Leadership to confirm that understanding.

And yes, it would be good to know what ICANN is willing to say about the degree to which registrars may rely on the Authentication system it is developing for Law Enforcement. And will that system include the ability for an individual Law Enforcement Agency to prove up credentials to ICANN without being a member of the FBI, Europol, or Interpol or some other DUG?

Anne

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

On Tue, Jun 9, 2026 at 3:54 AM Steve Crocker <steve@shinkuro.com> wrote:

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://icann86.sched.com/event/2NQMo/gnso-ssad-supplemental-recommendations...> 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/

_______________________________________________ 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

-- Sent by a Verified

sender

-- Sent by a Verified

sender

-- Sent by a Verified sender

Just by way of example, a few years ago, the USPTO found it was being flooded with applications from individuals claiming to be authorized to practice so it had to institute an authentication system whereby each attorney acting on behalf of a client has to submit its US State of Admission to practice and associated Bar number in order to file. State bars in the US would definitely be considered to be "trusted/competent authorities" but there is no need to set up the State Bar for each state as a Designated User Group. That involves expense and bureaucracy - which we are trying to avoid in these policy recommendations. So an attorney should be able to get "pre-authenticated" in the Registrar's system by proving up his/her/their bar admission and status in good standing. The issue of whether the attorney is authorized to act on behalf of a certain client whose interests are concerned would likely be part of the evaluation at the discretion of the Registrar. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Wed, Jun 10, 2026 at 4:17 AM Anne ICANN <anneicanngnso@gmail.com> wrote:

A DUG may end up being a type of "trusted/competed authority" but this DUG acronym should not replace a standard of "trusted/competent authority" as shown in the draft language in the Strawperson.

Not every trusted/competent authority needs to become a DUG. Anne

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

On Wed, Jun 10, 2026 at 3:04 AM Steve Crocker <steve@shinkuro.com> wrote:

...

DUGs can come in various sizes, and they can have agreements with various collections of Data Holders. In the extreme, a DUG can have just one member and be authorized to make requests of only one Data Holder. There is very little cost to create a DUG. It's just a matter of an agreement between the members of the DUG and the group of Data Holders.

Steve

On Wed, Jun 10, 2026 at 11:59 AM Becky Burr <bburr@pir.org> wrote:

...

So that's an interesting issue.

The value of being part of a DUG is that all responders know you have been authenticated in compliance with the minimum specifications and whatever additional assurance levels the DUG provides. All responders can then use this information to decide whether or not they trust the requestor.

Of course, individuals can make requests and be authenticated by the relevant responder, but that doesn't carry over to other responders. I would think that individuals who want to be authenticated across the environment would need and want to be part of something - a DUG of otherwise unaffiliated requestors? Not clear who would provide that service, but ICANN is not likely the most efficient choice.

b ------------------------------ *From:* Steve Crocker <steve@shinkuro.com> *Sent:* Wednesday, June 10, 2026 11:49 AM *To:* Anne ICANN <anneicanngnso@gmail.com> *Cc:* Becky Burr <bburr@pir.org>; Sarah Wyld <swyld@tucows.com>; gnso-ssad@icann.org <gnso-ssad@icann.org> *Subject:* [EXTERNAL] Re: [Gnso-ssad] Re: Summary of Day 0 Key Points

*CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.* ------------------------------ Anne,

There is no reason that every Desibgnated User Group has to be created or authorized by ICANN. Data Holders ultimately determine whom they trust.

Steve

On Wed, Jun 10, 2026 at 11:44 AM Anne ICANN <anneicanngnso@gmail.com> wrote:

Thanks Steve. I think the term Designated User Group isn't applicable in the case of all entities that can become Authenticated Requestors. The language used on page 52 of our Strawperson document is "trusted/competent authority". That is easier to understand than policy language that says that an individual Requestor (e.g. a government) is a Designated User Group.

The ICANN system for LEAs definitely seems to be one where the database will contain Designated User Groups. This DUG terminology does not seem to apply well though, to the entities listed in Recommendation 2 other than LEAs.

Trusted/Competent Authority is great language offered by our staff on page 52 of the Strawperson. Anne

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

On Tue, Jun 9, 2026 at 8:33 PM Steve Crocker <steve@shinkuro.com> wrote:

Anne,

You may have missed my point. See below.

On Tue, Jun 9, 2026 at 1:44 PM Anne ICANN <anneicanngnso@gmail.com> wrote:

Thanks Steve - to try to simplify the issue and get clarification - I understood the Chair and others to say that the net result regarding Urgent Requests in our policy work so far is that Urgent Requests may only be made through a Designated User Group because that will be the only path to authentication for the category of Urgent Requests. Your notes below do not seem to be consistent with that view.

If an individual Requestor needs to make an Urgent Request, I would have no problem with saying the 24 hour timeline for some initial response to an Urgent Request does not kick in until the Registrar is satisfied as to the individual Requestor's authenticated credentials, but requiring the individual Requestor to be a member of a DUG is too high a barrier.

These are, in effect, the same thing. "[U]ntil the Registrar is satisfied as to Requestor's authenticated credentials" implies the Registrar has, in effect, created a new Designated User Group for Requestors to make Urgent Requests of the Registrar's data and admitted the Requestor to this newly created, self-operated Designated User Group.

Regarding Law Enforcement Agency Urgent Requests, is the SRT proceeding on the idea that all LEAs must go through the proposed new ICANN system in order to be "Authenticated" in a manner that permits an Urgent Request?

There is no reason to limit the creation of Designated User Groups only to those that ICANN Org is willing and able to create. Any Data Holder or group of Data Holders can choose to create a new DUG and determine both the criteria for membership and the kinds of requests members are authorized to make. Perhaps you are implicitly trying to have ICANN impose a policy on the contracted parties that Registrars must not only accept Urgent Requests from members of an ICANN-established DUG, they must also be willing and able to create private, ad hoc, DUGs whenever someone who is not a member of the ICANN DUG demands they do so.

This all relates to the definition of "Authentication". My view is that criteria for Authentication can be established outside the context of a Designated User Group. I understand the Chair to be saying something different.

If your conclusion is that an Urgent Request (with associated timelines) can still be made without being a member of a DUG, it would be good for Leadership to confirm that understanding.

And yes, it would be good to know what ICANN is willing to say about the degree to which registrars may rely on the Authentication system it is developing for Law Enforcement. And will that system include the ability for an individual Law Enforcement Agency to prove up credentials to ICANN without being a member of the FBI, Europol, or Interpol or some other DUG?

Anne

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

On Tue, Jun 9, 2026 at 3:54 AM Steve Crocker <steve@shinkuro.com> wrote:

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://icann86.sched.com/event/2NQMo/gnso-ssad-supplemental-recommendations...> 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/

_______________________________________________ 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

-- Sent by a Verified

sender

-- Sent by a Verified

sender

-- Sent by a Verified

sender