Hi Farzenah The Supplemental Recommendations that result from this process, once approved by Council and adopted by the Board, will be consensus policy, just as the original SSAD recommendations would have been. That is the expected process and the output the Team is meant to deliver. My view is that authentication is within scope for that exercise. The SSAD recommendations include recommendations on authentication, including with respect to authentication of governmental entities. Indeed, the RDRS SC considered this very point “While the concept of authenticating government entities remains relevant, the SC suggests modifying this recommendation. For instance, it could leverage ongoing GAC/PSWG efforts to establish trusted LEA credentials and focus accreditation on such high-need users rather than building a broad system for all government entities.” Of course, if a consensus of the Supplemental Recommendations Team concludes differently, they can say so. Regarding the public comment input on the urgent requests timeline, this was not a task that fell to Council. This comment was conducted by Org in the context of its implementation work on the Registration Data Policy. Council is merely acknowledging that it has been informed that the issue of the timeline has been concluded. As a reminder of how Council agreed on the path forward to close the potential gap of authentication, this was under discussion in Council for some time. The views of all SG/Cs, via their Councillors, were requested more than once on our mailing list, prior to our reaching a decision and conveying that decision to the attending ICANN Board members, Wes Hardaker and Greg diBiase, at our Council meeting on 16 April. In particular: * Wes and Greg raised this issue during one of our working sessions<https://icann85.sched.com/event/2Gwac/gnso-work-session-1-of-3> at ICANN 85 on 8 March, and suggested three possible paths forward; * This was followed the same day by an email<https://lists.icann.org/hyperkitty/list/council@icann.org/thread/OREBJTTUBU5...> from Caitlin setting out the Board’s three options; * Council, together with SG/C Chairs, further discussed during the informal Council session on 11 March; * During Council’s discussions at ICANN 85, Samantha Demetriou suggested that Council consider the approach which has subsequently been agreed-upon; * This proposed approach was reiterated on the mailing list on 17 March, with a request for feedback before the April Council meeting; * Councillors were reminded of this action item by email <https://lists.icann.org/hyperkitty/list/council@icann.org/thread/6JQT5N4KL5I...> on 31 March and expressly asked that “If you disagree with the path proposed by Sam or believe the Council should consider one of the other alternatives, I encourage you to share this on the list in advance of the upcoming Council meeting so that we have a fulsome discussion.” * The issue was included on the agenda for the 16 April meeting, which was first circulated to Council on 2 April. With no further feedback or objection to the path proposed by Sam having been received either prior to or at the April Council meeting, that path was communicated to Wes and Greg. The letter, a draft of which I am about to share for Council’s review, is a formal confirmation of that for the record. Susan Payne Head of Legal Policy Com Laude T +44 (0) 20 7421 8250 D +44 (0) 20 74218 255 [cid:image001.png@01DCD35B.EDB0E4B0] <https://comlaude.com/> Follow us on LinkedIn<https://t-uk.xink.io/Tracking/Index/pRkAABB8AADw_RQA0> and Youtube<https://t-uk.xink.io/Tracking/Index/ZxkAABB8AADw_RQA0> From: farzaneh badii via council <council@icann.org> Sent: 22 April 2026 20:12 To: Council@icann.org Subject: [council] Authentication and supplemental review team Hello, I was reading the notes and there is this action item: Action Item: Council to formally notify the Board of the decision to incorporate authentication as part of the work on Supplemental Recommendations on SSAD and to confirm the urgent request timeline and associated policy language can be published as an update to the Registration Data Policy. In the document on ICANN org Proposed Timeline for Urgent Requests which we (NCSG) provided public comment on, under section 3.9 it says that: “Authenticated Requestor” means a law enforcement requestor or trusted/competent authority that is authenticated through an authentication mechanism implemented pursuant to ICANN Consensus Policy." But we are asking the supplemental team to come up with a consensus policy? How are you reconciling the two while supplemental team is not supposed to make new policy? Also sorry I missed this but did we ever discuss the public comments that were received on urgent request timeline? In our NCSG public comment we are clear about two things: we need more clarification on the criteria of urgent request (imminent threat etc) and we do think that for authentication we need a PDP. I have attached our public comment. Now to have a path forward, I suggest the following (have not discussed with NCSG especially number 1): 1. Ask the supplemental review team to address the urgent request timeline and criteria and a few things that need more clarification such as what it means to "respond" to law enforcement. That is not new policymaking in my opinion. We are only interpreting and clarifying the criteria and we will discuss human rights impact as well. 2. Discuss how to go about authentication in a way that the supplemental team does not come up with new policy. I know doing an EPDP is a lot of work but I just can't see any other way. Maybe we can have more suggestions by the staff on how to do the authentication piece quickly. We have mentioned in our public comment why we think a PDP on authentication is necessary. But if there are other ways to address our concerns then would love to hear them. Best regards, Farzaneh ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com<https://comlaude.com>
