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)
_______________________________________________ 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