Hi Farzaneh, thanks for the questions and comments. I’m responding below in-line, in blue. Susan Payne Head of Legal Policy Com Laude T +44 (0) 20 7421 8250 D +44 (0) 20 74218 255 [cid:image001.png@01DCD726.E58C0480] <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 <farzaneh.badii@gmail.com> Sent: 25 April 2026 18:51 To: Susan Payne <susan.payne@comlaude.com> Cc: Council@icann.org Subject: Re: [council] Authentication and supplemental review team Hello Susan, Farzaneh On Thu, Apr 23, 2026 at 3:01 PM Susan Payne <susan.payne@comlaude.com<mailto:susan.payne@comlaude.com>> wrote: 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. The supplemental rec team is supposed to come up with interpretation, clarification or modification of recommendations already existing. It is not supposed to come up with a "new" consensus policy. In the draft council letter you sent, we specifically mention that there is no reference to authentication in Rec. 18, which could result in an enforcement gap." Recommendation #18 on urgent requests is a recommendation that came out of the EPDP Phase 1, and which is the remaining issue outstanding on the implementation of that suite of recommendations into the Registration Data Policy. The Supplemental Recommendations Team will be tasked with dealing with the recommendations from the EPDP Phase 2 (of which there happen to be 18). Included amongst these EPDP Phase 2 recommendations, there are recommendations on authentication, including authentication of law enforcement, particularly recommendations #1 and #2. This is why Council coalesced around the approach of addressing this EPDP P1 Recommendation #18 “gap” as part of the work of the EPDP P2 Supplemental Recommendations Team, which is also in line with the view of the RDRS Standing Committee. For the avoidance of doubt, as I said previously, if a consensus of the Supplemental Recommendations Team concludes differently, they can say so. 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. So who did consider the public comments in the end? Did the Board consider them before providing us with "pathways"? I see in the draft letter that the Board thinks generally the community agrees with the timeline and associated policy. If you see our public comment we have other opinions. I think public comments should not turn into theatrical performances and the council should be aware of this. ICANN org, as the entity responsible for implementing Board-adopted GNSO policy recommendations, considered all public comments received as part of its analysis. The analysis informed the development of the potential paths forward proposed by the Board and discussed at ICANN85. Org provided its analysis of the comments here<https://itp.cdn.icann.org/en/files/new-generic-top-level-domain-gtld-program...>. 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. In March 8th, the meeting you sent the link to, I specifically mentioned in chat that NCSG wants a policy for authentication of law enforcement however you want to do it and we can't rush things. That chat was not discussed. Thank you for flagging this. The conversation of how to proceed on urgent requests was ongoing with additional opportunities to provide feedback. Based on the absence of disagreement to Sam’s proposal on the email list and lack of discussion during the Council meeting, it appears other councilors do not share this position. In the draft to the Board, we can record NCSG’s disagreement with the proposal. I clearly missed this but it shouldn't have happened. I am not blocking anything and I think authentication of law enforcement has to happen to some degree at ICANN so am ok with the supplemental review team handling it but have a few things to add to the assignment form, so I ask for an extension if possible. If not, will raise during the group's work. But since this issue is of utmost importance to NCSG and I am not comfortable at all with considering "no objection" as consent on such important matters such as law enforcement authentication I would like to raise my concern about the process. The members of the SSAD Supplemental Recommendations Team have been appointed by the groups, and so we would like to send the Assignment Form this week in order to inform the participants. In light of this, I would recommend raising your concerns during the group’s work as you suggest. So please record my concern:I wish to formally place on the record my dissatisfaction as to how this decision was handled. Authentication of law enforcement under the Registration Data Policy is not a minor procedural matter, it is a substantive policy issue of significant importance to the community and end users, and one that was well understood to be a priority agenda item for the NCSG. Given that, I find it deeply concerning that a decision of this weight was advanced without a vote and through a non-objection process. Non-objection is never full consent and should not be used for such important matters. I hope this does not set precedent for future decisions. During the Council meeting, the question was raised if this agreement could be recorded in a letter to the Board or if a vote is needed. Caitlin from GNSO Support Staff noted that the agreement could be recorded in a letter to the Board; however, if the Council felt a vote was needed, the matter could be brought to a vote. No objections were raised to proceeding with a letter, which is why the action item was captured this way. Thanks a lot Susan Payne Head of Legal Policy Com Laude T +44 (0) 20 7421 8250 D +44 (0) 20 74218 255 [cid:image001.png@01DCD726.E58C0480] <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<mailto:council@icann.org>> Sent: 22 April 2026 20:12 To: Council@icann.org<mailto: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/> ________________________________ 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/>