# GNSO: SSAD Supplemental Recommendations Session (1 of 3) Session ID: icann87-sched-2Wjf8 Start: 2026-10-17T16:30:00+08:00 End: 2026-10-17T17:30:00+08:00 Location: Nusantara 1 (GNSO) Access: public Official tracks: GNSO (Generic Names Supporting Organization) Programme state: scheduled AI-generated summary This first of three SSAD SRT working sessions focused on finalizing language for public comment on privacy proxy in Recommendations 3 and 8, then turned to proposed edits to Recommendation 1 on authentication. On privacy proxy, the group weighed a leadership compromise using “should” against GAC-proposed language requiring requests involving privacy or proxy registrations to be evaluated under the relevant consensus policy. After discussion and a short caucus, IPC, registries, BC and NCSG voiced support for the GAC text, and the chair recorded consensus to use it as the proposed path forward, replacing the earlier language at 5.7.3 (old 8.7.3). Recommendation 1 discussion covered ICANN Org’s role in accrediting authentication providers, consultation with the IRT and later Standing Committee, the meaning of “designee,” and GAC requests for flexibility for government providers. Contracted parties stressed the need for binding accountability. The chair said leadership would produce a new version for SRT review, and that without agreement the current language would go to public comment. The session closed with next steps on Recommendations 6 and 13 and an ICANN Finance cost discussion. TL;DR - The chair recorded consensus to use the GAC’s privacy proxy language for 5.7.3 in the public-comment draft, replacing the leadership compromise text. - Recommendation 1 on authentication was not closed: leadership will incorporate feedback into a new version for SRT review, while the current language is the fallback if no agreement is reached. Main discussion - Feodora reported that after Thursday’s full-day meeting no items were red, targeted work remained on authentication, privacy proxy and Recommendation 6, Recommendation 13 items remained open, and more recommendations were green and considered ready for public comment. - For privacy proxy, Mark explained leadership’s compromise: a contracted party “should” disclose data where it determines disclosure is permitted, can indicate in Rec 3.11 that it will handle SSAD requests, and is expected to point requesters elsewhere when it lacks access. IPC liked the language but conditioned support on the meaning of “should”; Volker described “should” as a presumption, and Greg quoted RFC 2119’s recommended-level meaning. - David presented GAC language that a disclosure request involving a privacy or proxy registration be evaluated and answered under the consensus policy on privacy/proxy registrations, aiming to avoid different requirements depending on whether a request comes through SSAD. - Susan challenged the GAC approach because PPSAI is an implementation review team implementing existing recommendations and, in her view, does not cover disclosure obligations; Ashley said PPSAI draft text does address disclosure but is still under discussion, and registrars found the GAC text clearer and acceptable with “must.” - After a caucus, IPC, registries, BC and NCSG expressed support for the GAC privacy proxy text; the chair took this as consensus, with the numbering clarified as 5.7.3 (old 8.7.3). The board liaison had urged assessing system usability, implementation complexity and cost across all parties, often favoring the simplest approach. - For Recommendation 1, leadership proposed clarifying IRT consultation for the authentication framework, later Standing Committee consultation for changes, public listing of recognized providers by requester category, and ICANN Org’s sole responsibility for recognition and application management. Agreements - The chair recorded consensus to proceed with the GAC privacy proxy language for 5.7.3 as the proposed path forward for the public-comment version. Disagreements - Susan argued that the GAC language points to a PPSAI policy that does not cover disclosure obligations, while Ashley said PPSAI draft text does address disclosure but remains under discussion. - On Recommendation 1, Sarah said the GAC proposal weakens binding obligations contracted parties need to rely on authentication outcomes, while David sought flexibility for governments that may be unable to enter binding ICANN contracts. Outcomes - Privacy proxy language was resolved for purposes of the public-comment draft, using the GAC text for 5.7.3 and wrapping up that agenda item. - Recommendation 1 was not closed; leadership will produce a new version reflecting SRT and GAC feedback for review. - The GAC’s proposed implementation-guidance reference on urgent requests was tabled to a later session, possibly Monday. Decisions - The group proceeded with the GAC’s proposed privacy proxy language for 5.7.3, replacing the leadership team’s proposed compromise for the public-comment version. Agreed actions - Leadership team to take the Recommendation 1 feedback into account and produce a new version for the SRT to review. - SRT members to review the outstanding Recommendation 6 and Recommendation 13 items in the control sheet and come prepared to discuss them at the 19 October meeting. - The agreed privacy proxy language is to be reflected in the draft public-comment version, and updated Recommendation 1 language is to be circulated to the full SRT when available. Possible follow-ups (inferred) - Suggested follow-up: explore a lighter-weight accountability mechanism for authentication providers, rather than only a full formal contract, to bridge contracted-party legal assurance and GAC flexibility concerns. - Suggested follow-up: clarify in Recommendation 1 how a designee is selected and how it would consult the IRT or community, and whether “if warranted” should be removed. - Suggested follow-up: if Recommendation 1 options remain difficult to choose, consider whether public comment could seek input on more than one formulation, an option raised but not adopted. - Suggested follow-up: follow up with ICANN Finance on whether a cost breakdown and explanation of cost drivers, including initial development and ongoing operational costs, will be ready for the Wednesday session. Open questions - What is the intended meaning of “should” in the leadership privacy proxy formulation? - Whether the PPSAI work actually covers disclosure obligations remains a point of contestation. - In Recommendation 1, is there to be a single authentication standard for all providers, or different requirements for providers serving different communities? - How will ICANN choose a designee, and how would that designee consult the IRT or community in establishing or changing the authentication framework? - How can the need for binding accountability and the need for flexibility for government authentication providers both be satisfied? Recording and context ## Transcript [0:03] ICANN - MTS - A/V: Hello, and welcome to the SSAD SRT session 1 of 3. Please note that this session is being recorded and is governed by the ICANN Expected Standards of Behavior, the ICANN Community Anti-Harassment Policy, and the ICANN Community Participant Code of Conduct concerning statements of interest. [0:20] ICANN - MTS - A/V: I will also post them in the chat for your reference. If you wish to speak, please raise your hand in Zoom or otherwise as directed. When speaking, please state your name for the record and speak clearly at a moderate pace. With that, I'll turn the floor over to Mark Anderson. Please begin. [0:36] ICANN - MTS - A/V: Thank you, Terry. This is Mark Anderson, chair of the SSAT SRT Working Group. [0:41] ICANN - MTS - A/V: Welcome, everybody, to this first of three meetings of the SAD SRT. [0:47] ICANN - MTS - A/V: Note for people in the room, this is a working session of the SRT, so we ask that unless you're, a member of the SRT, you refrain from. [1:00] ICANN - MTS - A/V: refrain from, coming to the microphone. We're happy to have observers here and, and welcome you, but, just to note that this is a working session of the SRT. [1:12] ICANN - MTS - A/V: We have an agenda up on the screen. The agenda flows from the work we did during Thursday's full-day session. [1:20] ICANN - MTS - A/V: So we have some outstanding items on, privacy proxy related to recommendations 3 and 8, but mostly in Rec 8, so we'll dedicate the majority of the time for today's meeting to talking through that. [1:36] ICANN - MTS - A/V: We also have some time for, REC 1. We have new language proposed around authentication, again, based on the discussion that happened during Thursday's full-day meeting. And so we'll spend the, or plan to spend the remainder of our time, on that. [1:54] ICANN - MTS - A/V: Next slide, please. [1:58] ICANN - MTS - A/V: Before we get into the substance of our work, I'd like to ask Feodora to give a little bit of a readout of what happened during our full-day face-to-face meeting. So, Feodora, over to you. [2:13] ICANN - MTS - A/V: Hi, everyone. [2:14] ICANN - MTS - A/V: This Feodora from ICANN Org, and we just wanted to… you've seen the notes and action items, and also the updated control sheet, and you can see here, as a high-level outcome from the Thursday meeting, that we don't necessarily have any red items anymore, because the group left [2:31] ICANN - MTS - A/V: on those items with an idea to resolution. However, targeted discussions remain on authentication, privacy proxy. [2:41] ICANN - MTS - A/V: And recommendation six that was considered green before, but some concerns were raised and it's also up for targeted discussion and some items remain open regarding recommendation 13. However, progress has been made because now you see more. [2:56] ICANN - MTS - A/V: Apologies. [2:58] ICANN - MTS - A/V: Recommendations in green as stable. [3:01] ICANN - MTS - A/V: Of course, they can pop up if any material concern is identified. However, based on the SRT discussion on the 15th of October. [3:09] ICANN - MTS - A/V: These seem at a very stable stage. We know that on REC 16, there was a comment that might need some attention, what overall. [3:18] ICANN - MTS - A/V: These seem, good for public comment. [3:22] ICANN - MTS - A/V: And on the next slide, just to note for the working groups, sorry, SRT's awareness, we will update the language as we go. [3:32] ICANN - MTS - A/V: Throughout these sessions, and what has been agreed. [3:35] ICANN - MTS - A/V: And we will share everything with the group along the way, but also ultimately after ICANN 87, so that the SRT can look at it from a complete perspective, and then we can take follow-up. [3:47] ICANN - MTS - A/V: after ICANN 87 in the normal working group calls. [3:52] ICANN - MTS - A/V: Back to… Mark, thank you. [3:56] ICANN - MTS - A/V: Thank you, Fedor. Next slide. [4:00] ICANN - MTS - A/V: All right. So our first topic for today will be the follow-up discussions on REC 3 and 8, specifically related to privacy proxy. [4:10] ICANN - MTS - A/V: And if you're following along on the mailing list, you'll note that we heard from, from David. David has, proposed some, GAC language as well. So as, as we go through this, I'll, give David an opportunity to speak to the language that he spent… sent to the mailing list. [4:29] ICANN - MTS - A/V: But in the meantime, I want to. [4:33] ICANN - MTS - A/V: I want to go through, sort of, what we heard during Thursday's call, as a, as a background to the new proposed language. [4:41] ICANN - MTS - A/V: And so we have, input from the GAC, and, during Thursday's call, I think, or during Thursday's in-person meeting, David, proposed the, the same language he went around to the mailing list. [4:56] ICANN - MTS - A/V: And so we've tried to incorporate that GAC feedback into the language leadership team is proposing. [5:04] ICANN - MTS - A/V: We heard from IPC regarding access to the underlying data. [5:10] ICANN - MTS - A/V: We heard concerns from registrars and NCSG about legal and operational limits, as well as data subject safeguards. [5:20] ICANN - MTS - A/V: And so, given, given all the input we received and the different, perspectives, we've taken in all that feedback and input and proposed a compromise language that we think incorporates elements to the best of our ability. [5:39] ICANN - MTS - A/V: So, next slide, please. [5:45] ICANN - MTS - A/V: As I said, the leadership proposed language proposes a middle ground. [5:51] ICANN - MTS - A/V: For, when the contracted party has access to the data, it should disclose the data. Just note that, that should is a change from, previous, May language. Should disclose if the contracted party determines that disclosure is permitted under applicable law, contracts, and policy. [6:13] ICANN - MTS - A/V: We also have language in the recommendations. [6:18] ICANN - MTS - A/V: Where the contracted party can indicate if the, in REC 3.11, [6:26] ICANN - MTS - A/V: where they will… where they're willing to handle disclosure requests via the SSAD. This was feedback from RDRS. We know that some registrars are willing to handle disclosure requests via the RDRS, and want to be able to do so via the SSAD as well. [6:46] ICANN - MTS - A/V: And, where the contract party does not have access to the data, they're expected to clearly indicate that, and where possible. [6:57] ICANN - MTS - A/V: Provide in the response the path, or the channel where the requester, can go in order to submit the request. [7:06] ICANN - MTS - A/V: So we've tried to take into account all the feedback and input we've received so far. [7:15] ICANN - MTS - A/V: And if we go to the next slide, please. [7:20] ICANN - MTS - A/V: I think this gets us to the, the proposed, leadership language. Don't worry, I'm not gonna read all this out, to everybody. We did send this language out previously, and hopefully everybody's had a chance to review it. [7:35] ICANN - MTS - A/V: What I'd like to do, to start with is just, throw it out to the, to the SRT. [7:43] ICANN - MTS - A/V: Are there questions, feedback, support, objections? [7:48] ICANN - MTS - A/V: And, John, looks like you're up first, so please, go ahead. [7:54] ICANN - MTS - A/V: Thanks, John McAwin, for the record. So the IPC was discussing this in the… actually in this room right before this, and we liked the language. I see that it incorporates the GACS language in that second paragraph. [8:07] ICANN - MTS - A/V: The big question we have, and I think, you know, our support really determines on [8:14] ICANN - MTS - A/V: What is the meaning of should? [8:18] ICANN - MTS - A/V: Thanks. [8:22] ICANN - MTS - A/V: Thanks, John. [8:25] ICANN - MTS - A/V: Any other… so I'm not sure I'm in a position to answer that question. I know should generally has very specific meaning. [8:35] ICANN - MTS - A/V: But I'm going to, Pass the mic over to Volker. Volker, go ahead. [8:42] ICANN - MTS - A/V: Hello, Volker Greimer for the RSEG. [8:46] ICANN - MTS - A/V: As a contracted party, when interpreting contracts, we would usually interpret the word should as a presumption of a certain outcome, without, final determination that it has to be that outcome. So there's a strong indication that this. [9:03] ICANN - MTS - A/V: This would be the outcome, but there might be factors that exclude that, so that's how we would interpret should. [9:12] ICANN - MTS - A/V: Thanks, Volker. John, go ahead. [9:15] ICANN - MTS - A/V: So, I'm glad to hear that, because I think that's trending in the right direction. [9:21] ICANN - MTS - A/V: you know, we… [9:23] ICANN - MTS - A/V: have some proposed definitions of should. There's been others that have been used, I think, like, subsequent procedures had… didn't define should, but it really, in the… [9:33] ICANN - MTS - A/V: Preamble, getting to the, implementation guidance, had some [9:40] ICANN - MTS - A/V: similar language to what Volker just said. I mean, I could, drop something into an email or the chat with some ideas. With respect to this. [9:51] ICANN - MTS - A/V: Again, getting along the same lines as what you see in the, subsequent procedures, discussion of this. [9:59] ICANN - MTS - A/V: To me, it's looking at, like, using, [10:01] ICANN - MTS - A/V: best efforts to, you know, follow through with the policy, unless there is another, you know, compelling reason not to, is, I mean, again, trying to get what Volker was getting at, which is not objectionable to us. But we just need to… we need to see that, and again, I'm happy to… to… [10:21] ICANN - MTS - A/V: Take a shot at drafting something, no pride of authorship for people to look at. [10:29] ICANN - MTS - A/V: Thanks, John. I'll note Sarah's pointing out, I think it should is… [10:33] ICANN - MTS - A/V: I think the use of capital should here is intended to have meaning as defined in a specific RFC. [10:40] ICANN - MTS - A/V: And I don't… Know that language off the top of my head, but, that… [10:48] ICANN - MTS - A/V: Or to the extent that that's specifically applicable, but just calling that out, as, as capital should, generally has, has meaning and as, as defined, and Sam's helpfully put a link. [11:01] ICANN - MTS - A/V: And RFC 2119. [11:04] ICANN - MTS - A/V: Greg, go ahead. [11:08] ICANN - MTS - A/V: Thanks, Greg Shatton for the record, and I was actually going to point out the same thing. [11:14] ICANN - MTS - A/V: And, RFC 2119 says this word, or the adjective recommended, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. [11:34] ICANN - MTS - A/V: I'll put that into the chat. [11:37] ICANN - MTS - A/V: Thanks, Greg. Becky, go ahead. [11:40] ICANN - MTS - A/V: Apologies if I'm missing something, but I'm now a little confused because [11:46] ICANN - MTS - A/V: David had circulated some language for 573, that basically says, where a disclosure request regards a domain registered through a privacy or proxy service, the contracted party must ensure the request is evaluated and responded to in line with the requirements of the consensus policy on privacy proxy registrations. [12:06] ICANN - MTS - A/V: I guess I'm confused as to why we're not considering that Same approach. [12:14] ICANN - MTS - A/V: Consistently, all the way through. [12:16] ICANN - MTS - A/V: I mean, I understand the language that was circulated was about 573, but… This suggests that… different standard than [12:27] ICANN - MTS - A/V: would be suggested by the language that GAC has come up with. [12:33] ICANN - MTS - A/V: Thanks, Becky. I'll note there's two pages. [12:36] ICANN - MTS - A/V: To the language, and the second… and so I just had the first page up. I think the second page, refers to what you were talking about, referencing the privacy proxy, policy. [12:54] ICANN - MTS - A/V: Theodore, do you want to jump in there? [12:58] ICANN - MTS - A/V: Hi, everyone, Feodora. Just to note, regarding this language, and based on the path that the SRT had already discussed and established, we understood that the group wants more than a may, but a must might not be possible, so that's where, we… [13:15] ICANN - MTS - A/V: thought it should… could help, taking into consideration various factors. However, we were also referencing that, this relates to what is already accessible and can be provided. However, in the language that is in black and was already in the recommendation, [13:33] ICANN - MTS - A/V: What is not accessible and cannot be provided would be subject to, the policy on privacy proxy, and also to 8.5, where [13:41] ICANN - MTS - A/V: we would need to provide a rationale or next steps to the requester where possible. So, it was kind of to see the two steps or different situations. I hope that clarifies. Otherwise, yeah. [13:57] ICANN - MTS - A/V: Happy to adjust. Thank you, Mark. [14:00] ICANN - MTS - A/V: Thanks, Feodora. Greg, is that, old hand, or… Both. [14:05] ICANN - MTS - A/V: Okay. Your mic's on, also. [14:09] ICANN - MTS - A/V: Becky, new hand? [14:12] ICANN - MTS - A/V: So I. [14:14] ICANN - MTS - A/V: I understand that, I understand the explanation, but I guess my question is. [14:21] ICANN - MTS - A/V: Doesn't it make sense to say. [14:25] ICANN - MTS - A/V: this… the… how you… how you… your obligations with respect to disclosure of privacy and proxy data should be decided in one place, and we're saying it's the PPSAI. I mean, I'm interested in what David has to say about that. I just… [14:43] ICANN - MTS - A/V: Seems like I do understand, but I guess I want to have the previous question of, doesn't it make more sense just to say it's going to be decided in one place, and that's going to be what the policy is? [14:57] ICANN - MTS - A/V: Thanks, Becky. I see David's raised his hand in the queue, and why don't I just turn the floor over to him to present his proposal, which I think is basically what you're asking, right? So, so David, floor is yours, go ahead. [15:13] ICANN - MTS - A/V: Thanks, Mark. Yes, and thanks, folks, for, considering the proposal that we circulated earlier today. So basically, the proposed text. [15:24] ICANN - MTS - A/V: is… sort of gets at the… the idea that, you know, it's very important for the GAC, first of all, that the SSAD provide meaningful consideration when a requester submits the request through the SSAD. [15:35] ICANN - MTS - A/V: So this language, we believe, is a compromised solution that recognizes, as Becky sort of points out, the ongoing policy work that's happening simultaneously through the PPSAI. [15:45] ICANN - MTS - A/V: So I think the language avoids the result of having different requirements based on whether the request comes through the SSAT or not. So, we were really hoping that we could get support for the language here today, acknowledging that, you know, we had that conversation yesterday. [16:03] ICANN - MTS - A/V: Around… or on Thursday, I suppose, around the policy requirements articulated in the RDP versus what's in the SAT, and some confusion that may arise from that, and trying to… [16:15] ICANN - MTS - A/V: trying to, marry those two things. So, we think that, sort of pointing to the policy work that's happening in the PPSAI, and that could be the policy that, that sort of articulates how that privacy proxy data would be managed would be helpful. [16:30] ICANN - MTS - A/V: Thank you. Happy to connect, offline, but, would, would, appreciate, any support if, folks do support the language. Thank you. [16:43] ICANN - MTS - A/V: Thanks, David, and we have, we have that language up on the screen now, and just, just to clarify, this, this language would, replace the language that we just looked at, right? [16:56] ICANN - MTS - A/V: And David's nodding his head for those not in the room. All right, Susan, please go ahead. [17:05] ICANN - MTS - A/V: So, although I would like to agree with that, the thing that's troubling me is that the PPSAI is… [17:11] ICANN - MTS - A/V: Is an implementation review team implementing a policy… some policy recommendations that already exist? [17:18] ICANN - MTS - A/V: But they don't deal with this. [17:20] ICANN - MTS - A/V: They deal with, you know, kind of accreditation of privacy proxy service providers and so on. They don't deal with obligations on disclosure. [17:29] ICANN - MTS - A/V: And so that's my concern, is we've… [17:32] ICANN - MTS - A/V: We're referring to a policy that isn't there. [17:38] ICANN - MTS - A/V: Thanks, Susan. David, do you want to respond to that, or I can go to Ashley, who's next in queue? Sure, just… [17:46] ICANN - MTS - A/V: Very quickly, I believe that the latest text may actually, resolve some of the questions that you might have, Susan, but I believe it does actually speak to that. [17:58] ICANN - MTS - A/V: Thanks, David. Ashley, go ahead. [18:01] ICANN - MTS - A/V: Thank you, Ashley Heineman. [18:02] ICANN - MTS - A/V: representing registrars. And just to agree with what David said, there is text in the draft policy that does look at. [18:12] ICANN - MTS - A/V: disclosure, and the PPSAI draft. But that being said, that's still under discussion. And… In terms of text. [18:21] ICANN - MTS - A/V: I just wanted to say that I think what the GAC puts forward. [18:26] ICANN - MTS - A/V: Or David. [18:27] ICANN - MTS - A/V: It's actually much clearer, much more simple. [18:31] ICANN - MTS - A/V: And I think the other text just adds a bit of. [18:35] ICANN - MTS - A/V: confusion and complication. And in this instance, the way it is drafted, the registrars are okay with the word must here. [18:47] ICANN - MTS - A/V: Okay, thanks, Ashley. [18:50] ICANN - MTS - A/V: To… [18:52] ICANN - MTS - A/V: level set for everybody else. What we're looking for here is to be able to finalize language for going out to public comment. [19:01] ICANN - MTS - A/V: And we have, sort of two proposals. We have the leadership… leadership team's proposed compromise based on our discussion, Thursday, which. [19:14] ICANN - MTS - A/V: John, said, potentially, he's supportive of, depending on interpretation of the word should. [19:21] ICANN - MTS - A/V: And then we have, David's, GAC proposed language, which. [19:28] ICANN - MTS - A/V: Ashley, on behalf of the registrars, are willing to support. Noting that, Tomas in chat is also on board with the GAC proposed language. [19:38] ICANN - MTS - A/V: What I'd like to ask, is for… I need a… I'm looking for a strong mandate for which version of the language should go into the version that goes for public comment. [19:52] ICANN - MTS - A/V: You know, so… you know, and if we're not able to agree on language, we'd revert to the previous version that we discussed on Thursday. So I do have some support for both. [20:08] ICANN - MTS - A/V: And so, I'd like to… like to ask the group to weigh in, help give me clearer direction on what version should go into the, the public comment version. [20:19] ICANN - MTS - A/V: So, Susan, you're, first up. Go ahead. [20:23] ICANN - MTS - A/V: We were just gonna say, could we have, like, a short pause to talk it over, if you're trying to reach a decision, like, as we speak? Could we… could we take a short break? [20:33] ICANN - MTS - A/V: Absolutely. Public comment isn't until November 10th, so we don't necessarily need to decide this moment. So, I mean, if we can come back on, you know, in a subsequent one of our meetings, that's fine. I thought you were trying to shut this off. [20:48] ICANN - MTS - A/V: But, yeah, but yes, I would love to have this closed today, if at all possible. So if a short break would be helpful, we can do that. [21:03] ICANN - MTS - A/V: Okay, then let's, let's take 5 to caucus, and, we'll pick back up. I see we have a queue. We'll, pick back up, in 5 minutes. [21:12] ICANN - MTS - A/V: I'm sorry, Mark, I just wanted to clarify, are we having 3 options now, or 2 options? 3 options means one is… [21:20] ICANN - MTS - A/V: We don't change anything. It was the original language. [21:24] ICANN - MTS - A/V: Second option is whatever was proposed by the leadership team. Third option is the GAC language. Is that the three we're discussing? Essentially, yes. [21:36] ICANN - MTS - A/V: you know, I'm asking… I'm asking the group to indicate, you know, is there support, for… [21:43] ICANN - MTS - A/V: either of the two new options. If there's not support, we would… we would… [21:48] ICANN - MTS - A/V: stick with the existing… the existing language. I suppose if you wanted to weigh in and support the existing language, that's… that's fine, too. So, I think… [21:57] ICANN - MTS - A/V: Essentially, the answer is yes. I'm asking the group to weigh in on the three different options. [22:03] ICANN - MTS - A/V: Anne, did you want to jump in before? Very quickly, I mean, is there some sort of prohibition in… [22:10] ICANN - MTS - A/V: a final report against asking for public comment on two different options? I mean, why can't you ask [22:19] ICANN - MTS - A/V: the community. [22:21] ICANN - MTS - A/V: Here are the two things we… Said, you know, we haven't… And we want your input. [22:28] ICANN - MTS - A/V: We absolutely could. I'm not… sure that that's necessary in this case. Certainly that is an option, and if [22:37] ICANN - MTS - A/V: You all tell me you can't decide between the two, then we could do that. [22:42] ICANN - MTS - A/V: But I think I would prefer to go to public comment with a proposed path forward. [22:52] ICANN - MTS - A/V: All right, so 5-minute break to caucus, and we'll pick back up shortly. [22:58] ICANN - MTS - A/V: Thank you. We'll pause the recording for the 5 min break. [23:04] ICANN - MTS - A/V: Please begin. [23:06] ICANN - MTS - A/V: All right, thank you everybody for bearing with us while we had a, informal breakout session. I think, before we, before we pick back up the discussion, I would, like, to invite Wes to, say a few words at the mic. Wes, go ahead. [23:26] ICANN - MTS - A/V: Thanks, Mark. This is Wes Hardaker, the board liaison to this group. [23:30] ICANN - MTS - A/V: Or one of two, I should say. [23:32] ICANN - MTS - A/V: I want to revisit sort of what I said on Thursday with respect to how to consider some of these, you know, more complex decisions, right? [23:42] ICANN - MTS - A/V: You recall on Thursday, I talked about [23:45] ICANN - MTS - A/V: Thinking about things from a bigger picture, right? [23:49] ICANN - MTS - A/V: What is the system usability gonna look like? [23:53] ICANN - MTS - A/V: And when you're thinking about weighting these different types of things, right, I don't mean just the usability from one user, I mean the usability of the entire system to all parties. [24:03] ICANN - MTS - A/V: What is the implementation going to look like? What's the complexity of that gonna look like? And what's it gonna look like for all parties that are gonna be interacting with this system? [24:14] ICANN - MTS - A/V: And as I said on Thursday, what does the cost look like? And as I indicated on Thursday, cost is not just in dollars, right? There's a number of ways that cost has to be considered, of which, you know, certainly dollars is part of it. [24:26] ICANN - MTS - A/V: But it's not even cost to ICANN, which is what I said the other day, right? There's a cost to the registrars, there's a cost to the privacy proxy services, there's a cost to the users and their ability to use the system. [24:39] ICANN - MTS - A/V: And then, you know, finally, a lot of this comes down to… What's the simple solution? [24:47] ICANN - MTS - A/V: Right? Really complex… [24:49] ICANN - MTS - A/V: you know, systems with a lot of parties that need to communicate end up to be fairly expensive in terms of all of the things I just listed. [24:58] ICANN - MTS - A/V: So… [24:59] ICANN - MTS - A/V: a lot of times, the right approach is often the simplest, right? It's the simplest for everybody, it's the simplest in cost, it's the simplest in implementation, so… [25:07] ICANN - MTS - A/V: This, to me, you know, everything I just said seems to focus a lot on the choices between these. Obviously, the board will, you know, consider anything that this group has to put forward, but from our perspective, that's, you know, that would be sort of the major concerns we have. [25:25] ICANN - MTS - A/V: Thanks, Wes, and thanks for jumping in there. I do want to reiterate that this is not the absolute last word on this. This is a decision about what version of the text we would like to send to public comment. You know, of course, we'll have. [25:40] ICANN - MTS - A/V: The ability and the option to evaluate public comments. [25:43] ICANN - MTS - A/V: And, and adjust the language as, as appropriate. [25:48] ICANN - MTS - A/V: But, I would like us to put our best possible version out to public comment as possible. So I appreciate… I know that privacy proxy has proven to be one of the most challenging topics for us to deal with, and so I appreciate everybody's time and attention to this one. [26:07] ICANN - MTS - A/V: All right, with that, having had time to caucus, who would like to weigh in? [26:15] ICANN - MTS - A/V: All right, John, thank you. [26:18] ICANN - MTS - A/V: Yeah, so John Macklin, for the record, and speaking with the GAC representatives, the IPC can support their proposal. We think it does pretty much capture what the group has been talking about. It does require, for [26:36] ICANN - MTS - A/V: the IRT working on the PPSAI to implement what is currently in place there, but provided that happens, I think it accomplishes everything that we want to have happen. Thanks. [26:51] ICANN - MTS - A/V: Thanks, John. Anyone else? [26:55] ICANN - MTS - A/V: Becky. [26:56] ICANN - MTS - A/V: Oh, sorry. Yeah, Becky, please go ahead. The registries support the GAC language. [27:03] ICANN - MTS - A/V: Thanks, Becky. [27:05] ICANN - MTS - A/V: Anyone else want to jump in or object? [27:11] ICANN - MTS - A/V: Steve, go ahead. Thank you. I finally found the, place to raise my hand there. Support the GAC. Same as… same as IPC. [27:21] ICANN - MTS - A/V: Speaking for BC. [27:23] ICANN - MTS - A/V: Thank you, Steve. Farsnet, go ahead. [27:29] ICANN - MTS - A/V: We support. [27:31] ICANN - MTS - A/V: GAC language. [27:33] ICANN - MTS - A/V: as non-commercial stakeholder group. [27:37] ICANN - MTS - A/V: And this is a moment of celebration. [27:40] ICANN - MTS - A/V: Yeah. [27:43] ICANN - MTS - A/V: Wow, thank you. I'll second that, and thank you, everybody, for weighing in on this. I'll take that as consensus to proceed with the GACS language on this. Thank you, David, for presenting this and proposing it to the group. [28:00] ICANN - MTS - A/V: So we'll use, use that as the… so we'll replace the GAC's proposed language for 5.7.3 as the, proposed path forward. [28:10] ICANN - MTS - A/V: And… Feodora, please. [28:12] Feodora Hamza - ICANN Org: Go ahead. I just have a clap. [28:18] ICANN - MTS - A/V: I think it's 8.7.3 or is it 5.7.3? Can we just clarify where you would like? [28:30] ICANN - MTS - A/V: I think… I think it's… the new number is 5.7.3, but I think it was the old 8.7.3. [28:36] ICANN - MTS - A/V: Sorry, because we were… Mark announced that we would use the old numbering, so that's why I was just confused, but thank you. [28:46] ICANN - MTS - A/V: Okay, I think we're all set on this one, and I think, John and Steve, those are, old hands. [28:54] ICANN - MTS - A/V: So, with that, I think we can go back to our slides and, pick up… [29:04] ICANN - MTS - A/V: So we'll continue, so that, that wraps up. [29:08] ICANN - MTS - A/V: That wraps up our discussion on privacy proxy, which I know we already had a round of applause, but, another one might be in order. [29:17] ICANN - MTS - A/V: So, that's, that wraps up our discussion on privacy proxy, through, through to, through public comment. So, again, privacy proxy has been, been quite a challenge, so I, I thank everybody for their, their… [29:32] ICANN - MTS - A/V: Good faith discussions on this and contributions, and, look forward to seeing how the public comments play out. [29:42] ICANN - MTS - A/V: With that, we're gonna shift gears and talk about Recommendation 1. [29:46] ICANN - MTS - A/V: Similar to the privacy proxy discussion, we have new language from leadership team based on the discussion that happened during our Thursday face-to-face. [29:57] ICANN - MTS - A/V: And we're looking for confirmation that the new language is fit for purpose to go into the public comment version. [30:07] ICANN - MTS - A/V: Next slide, please. [30:10] ICANN - MTS - A/V: I think, Theodore, do you wanna… Ts up, please. [30:18] ICANN - MTS - A/V: Hi, everyone. So, based on the SRT discussion on Thursday, we've heard different suggestions and comments on how, recommendation 1 can be adjusted. This was specifically to, REC 1.3, to make clear that the requirements, administrative and technical and so on, will be. [30:37] ICANN - MTS - A/V: done in consultation with the IRT, and later on, also, if changes need to happen with the Standing Committee, so, that is something we… [30:45] ICANN - MTS - A/V: We have tried to address. [30:48] ICANN - MTS - A/V: Furthermore, there was also a comment that the list of authentication providers should be made transparent and public. [30:55] ICANN - MTS - A/V: and the communities they serve, so that is also language that we proposed can be added there. And, furthermore, one last change on this slide deck would be [31:06] ICANN - MTS - A/V: the language on 1.4, just to make clear that ICANN Org would be responsible to manage the application process once all the requirements are set and published. [31:16] ICANN - MTS - A/V: On the next slide. [31:21] ICANN - MTS - A/V: Yes, I just talked to this. So this is just a [31:28] ICANN - MTS - A/V: The language that Mark will introduce now. [31:32] ICANN - MTS - A/V: Thanks, Feodora. If I could just highlight a couple items. The first is that we're making clear that during implementation, ICANN Org should consult with the implementation review team in establishing the framework [31:50] ICANN - MTS - A/V: for authentication entities to become accredited. [31:55] ICANN - MTS - A/V: So the framework, including administrative, technical, and security requirements, to become a recognized authentication provider. [32:03] ICANN - MTS - A/V: Likewise, we've made it clear following implementation, if there are need… if there's a need to make changes to that framework, ICANN Org should consult with the Standing Committee, which will take over from the IRT. Next slide, please. [32:22] ICANN - MTS - A/V: And then, lastly… [32:32] ICANN - MTS - A/V: Sorry. And then, we've, added clarification, to 1.9, that the list of, recognized authentication providers [32:43] ICANN - MTS - A/V: should be published and maintained for each category of requesters. [32:52] ICANN - MTS - A/V: So hopefully that language, reflects Oh, sorry, one more slide. [33:01] ICANN - MTS - A/V: On 1.4, we've also made a change, to clarify that it's ICANN's, ICANN Org's sole responsibility for determining if an authentication provider meets the criteria to become recognized. [33:18] ICANN - MTS - A/V: And so, I think there was some question during our discussion on Thursday whether that would be ICANN Org's responsibility or ICANN Org in association with the Standing Committee or IRT. [33:32] ICANN - MTS - A/V: So we added language in 1.4 to clarify that it's ICANN Org's responsibility. [33:39] ICANN - MTS - A/V: And so I think that is… yes, that's the proposed language, or the proposed edits. [33:47] ICANN - MTS - A/V: to, to REC 1. [33:51] ICANN - MTS - A/V: Now, before I close this out, I do want to note. [33:55] ICANN - MTS - A/V: We heard from the GAC. The GAC has additional feedback, I think specifically on Section 1.3. Unfortunately, that came in after we had prepared the material, for, today's meeting. [34:10] ICANN - MTS - A/V: So similarly to the language on REC 8, I'll invite the GAC to speak to those proposed changes. [34:20] ICANN - MTS - A/V: But before they do, I'd like to, ask the, group if they can weigh in on, the proposed changes to, to REC 1. And Steve, you're up first. Go ahead. [34:33] ICANN - MTS - A/V: Thank you. [34:36] ICANN - MTS - A/V: Even with all those words there, it's not 100% clear to me whether the following… what the status of the following is. Are we anticipating that there could be different requirements for authentication providers serving different communities, or is this a single standard to be applied to all authentication providers? [34:55] ICANN - MTS - A/V: So that's a question. And let me now add a comment. This is a service, the way this is written, this is a service performed by ICANN Org on behalf of the registrars. [35:09] ICANN - MTS - A/V: the criterion for appropriateness is, does this meet the needs of the registrars? So, ultimately, the consultation has to reflect [35:21] ICANN - MTS - A/V: that the registrar's needs and their processes are being supported here, ICANN [35:33] ICANN - MTS - A/V: If ICANN were operating entirely on its own and saying, well, we decided the following, then that's imposing the answers on the [35:44] ICANN - MTS - A/V: data holders, but in fact, that doesn't do any good if the data holders don't, want to use… I mean, don't trust or find that satisfactory, so there has to be a connection between what the registrars actually need and what ICANN does on their behalf. [35:59] ICANN - MTS - A/V: I'm not sure that's adequately… [36:01] ICANN - MTS - A/V: It's partially but not adequately in my mind nailed down that ICANN Org in this is operating. [36:10] ICANN - MTS - A/V: On behalf of the registrars, as opposed to imposing on the registrars. [36:16] ICANN - MTS - A/V: Thanks, Steve. Farshnate, go ahead. [36:20] ICANN - MTS - A/V: Fires anybody. [36:22] ICANN - MTS - A/V: So, my question on the first one is. [36:26] ICANN - MTS - A/V: And I have asked this before, so what do we mean by designee? ICANN Org or its designee? [36:34] ICANN - MTS - A/V: how does ICANN choose a designee? Are we talking about, like, the firms that provide the service? So that's one, question. The other thing is that after, in the red, line, the second one. [36:51] ICANN - MTS - A/V: I don't like that there's, if warranted there. [36:55] ICANN - MTS - A/V: I mean, I… I feel like it's, kind of… [36:59] ICANN - MTS - A/V: Like, we need more clarity, maybe we get rid of, if warranted. For the second one, I think it's on the second… on the next slide. [37:11] ICANN - MTS - A/V: I think, we like that kind of transparency and accountability. It's not… Can you… yeah. So. [37:22] ICANN - MTS - A/V: Yeah, I think… I think this is good. It addresses our concern. [37:27] ICANN - MTS - A/V: And for the last one, if we can pull it up, sorry. [37:34] ICANN - MTS - A/V: So we, again, we have this designee here, and how does the… how does ICANN choose this designee? That's important for us to know. Another thing is that [37:47] ICANN - MTS - A/V: That. [37:49] ICANN - MTS - A/V: So we are saying that ICANN is the only responsible party for authentication of these providers, and they don't have to do it in consultation with the community. [38:02] ICANN - MTS - A/V: That… the African, the published current. So of [38:08] ICANN - MTS - A/V: that I think that it was very useful when we talked to LEA in the LEA group, we talked to like FBI and Interpol, and they told us. [38:20] ICANN - MTS - A/V: what sort of protocols they have for, like, holding themselves accountable, and I just think that we should have those conversations, we should have those conversations with the future and potential authenticated providers. [38:36] ICANN - MTS - A/V: And maybe that way it can help also ICANN Org to make the decision of authenticating certain providers. [38:47] ICANN - MTS - A/V: And I just think that this paragraph, we might be able to say that, like, for the onboarding and stuff, the community should be consulted, or something like that. [39:02] ICANN - MTS - A/V: Okay, thanks, Farshney. [39:05] ICANN - MTS - A/V: What I'd like to do real quick is. [39:08] ICANN - MTS - A/V: If I could put, Lisa on the spot to answer Farzaneh's question about, designees. [39:15] ICANN - MTS - A/V: And then, I have Anne in the queue, I'll go to you. And then in the interest of time, I want to give David time to speak to the GAC proposal. So we'll go Lisa, Anne, and then David, if you're… [39:30] ICANN - MTS - A/V: ready, I'll ask you to speak to your proposal. So, Lisa, please go ahead. [39:36] ICANN - MTS - A/V: Thanks, Mark. This is Lisa Carter for the record. In terms of what is meant by designee, that would mean maybe a third party that ICANN might [39:46] ICANN - MTS - A/V: Assigned to do this? [39:49] ICANN - MTS - A/V: We don't have a final way that this system is going to be handled yet, so this kind of allows the flexibility if ICANN wants to outsource something for us to do that. That's what the designee language means. [40:03] ICANN - MTS - A/V: Thanks, Lisa. Anne, go ahead. [40:06] ICANN - MTS - A/V: Thanks, appreciate the changes to the language, and, on the topic of. [40:13] ICANN - MTS - A/V: you know, how this standards get… framework further gets developed. I think the intent we discussed in the all-day meeting was that there would be a, you know, direct consultation with the IRT, and the IRT, [40:30] ICANN - MTS - A/V: It does sort of raise the question of how a designee. [40:35] ICANN - MTS - A/V: consults with the IRT. I mean, I assume that it would be… [40:40] ICANN - MTS - A/V: you know, ICANN working with the IRT first, and then… issuing an RFP or whatever. [40:50] ICANN - MTS - A/V: That seems to be a little bit awkward, because the… [40:54] ICANN - MTS - A/V: are we saying the third-party designee would be consulting with the IRT? I'm not… I'm not too sure about that part. And then. [41:06] ICANN - MTS - A/V: Actually, on the slide… Yeah, the first… this slide here. [41:12] ICANN - MTS - A/V: I didn't notice it before, but when Farsanae brings up If warranted… [41:20] ICANN - MTS - A/V: Yeah, again, I'm not quite too sure about that either, and maybe we don't need, if warranted, maybe it should just be [41:29] ICANN - MTS - A/V: you know. [41:31] ICANN - MTS - A/V: If you're proposing to change the framework. [41:34] ICANN - MTS - A/V: Go ahead, consult with the Standing Committee. [41:40] ICANN - MTS - A/V: Okay, thank you. Steve, I think that's an old hand. [41:45] ICANN - MTS - A/V: Yeah. Okay. And, David, I'd like to turn the floor over to you to speak to the GAC's feedback on, I think, 1.3 specifically. David, the floor is yours. [41:56] ICANN - MTS - A/V: Thanks, Mark. [41:57] ICANN - MTS - A/V: Yeah. So, thanks everybody. I know that we submitted this, we sort of table-dropped it last minute, so I really do appreciate the group's, consideration of the request, and certainly this is a conversation that we'll have to, that will certainly be ongoing. And thanks for leadership for their proposed edits that they've circulated as well. Really appreciate it. [42:17] ICANN - MTS - A/V: So, we've provided a rationale for each change in the document, so I won't go through each red line change, but, I'm happy to talk about the change, the changes that we've made or are proposing offline if, folks have questions. [42:32] ICANN - MTS - A/V: But, just in a broad sense, firstly, there's sort of a set of edits that provides more flexibility to accommodate different approaches to authentication. [42:40] ICANN - MTS - A/V: So, for instance, the current language assumes that every authentication provider will take the exact same approach, or fixed term renewals, specifically to its users, but there are, or there probably will be cases that. [42:55] ICANN - MTS - A/V: Won't take that same approach. [42:58] ICANN - MTS - A/V: Also, the requirement for authentication providers to enter into a contract with ICANN would be challenging for governments and government entities. I think I've flagged this, when we first… one of our previous calls. [43:11] ICANN - MTS - A/V: So the GAC is really looking for flexibility on this, requirement. [43:16] ICANN - MTS - A/V: So, basically, it may be challenging for a government entity to enter into a binding contract with ICANN, specifically if they want to set up their own authentication provider, and we really don't want the recommendations to [43:33] ICANN - MTS - A/V: preemptively exclude governments from participating as an authentication provider or setting up an authentication provider should they be in the position that they are not able to actually sign a binding contract with ICANN. [43:46] ICANN - MTS - A/V: So we're looking for a little bit of flexibility in that, in that language as well. But, and then I think, we've also included some changes to the authentication tokens and some of the, the, edits that we've provided here in this document, I think reflect previous comments that we've had. [44:05] ICANN - MTS - A/V: And Feodora, I apologize, but I think maybe on Thursday you had, said that there were still waiting for, subsequent edits that might take these into consideration. So these are just edits that, we've provided in, in, previous. [44:20] ICANN - MTS - A/V: discussions as well, but they pretty much mirror the changes that we're looking for in 1.3. [44:26] ICANN - MTS - A/V: But yes, thank you again for the group and thank you to leadership for accommodating the edits. [44:34] ICANN - MTS - A/V: Great, thank you, David, and thank you for your, your feedback and, and explanation on this one. [44:40] ICANN - MTS - A/V: We're, running low on time for our session, and we have a little bit of a queue. I'll get to the queue in a second, but… [44:48] ICANN - MTS - A/V: I want to say, on… on this language, I think what leadership is proposing, we've gotten great feedback, Ann, Farsnay, Steve, thank you. [44:57] ICANN - MTS - A/V: We've got the, the GAC proposal. What we'd like to do is propose, that, leadership team take all of this, into account and turn a new version for the, the SRT to review. [45:12] ICANN - MTS - A/V: Again, happy to get to the queue here, but I think based on all the feedback we've heard, as much as I'd like to close out this REC today, I think clearly that's not going to happen, and so we'll need a new version that we can review. [45:27] ICANN - MTS - A/V: But in the meantime, let's get to the queue. Sarah, you're up. [45:32] Sarah Wyld (RrSG / Tucows): Good afternoon, this is Sarah. I hope I sound normal. I'm feeling shockingly okay. [45:40] Sarah Wyld (RrSG / Tucows): I really appreciate the GAC team working on moving us forward through this section. [45:44] Sarah Wyld (RrSG / Tucows): That said, I'm concerned that the proposal weakens the binding obligations on authentication providers to a degree that makes contracted parties unable to rely on those authentication outcomes. [45:59] Sarah Wyld (RrSG / Tucows): The way I see it, if we get investigated by a data processing or data protection authority. [46:06] Sarah Wyld (RrSG / Tucows): And we have to explain why we trusted the authentication and disclosed personal data. If we can't show that there's a contract governing how requesters are authenticated, then I think it would be hard to defend [46:19] Sarah Wyld (RrSG / Tucows): trusting that authentication. So that puts us right back to the original problem with knowing who is submitting these requests. [46:27] Sarah Wyld (RrSG / Tucows): I do think this is a great starting place, and we could consider maybe lighter weight options rather than a full-blown formal contract, which is where we were trying to get to with the binding language in the original text. [46:41] Sarah Wyld (RrSG / Tucows): Now, I know David mentioned flexibility for authentication providers or governments, and I'm really sympathetic to that, but when the contracted party has a very inflexible deadline for response to urgent requests, it becomes really important, and that's why we're looking for that legal assurance. Thank you. [47:02] ICANN - MTS - A/V: Thanks, Sarah. I have Farshne and then David. Farshne, go ahead. [47:08] ICANN - MTS - A/V: So, we've been, talking about and insisting on, authentication provider accountability, and governments is one of the stakeholders that we are really [47:21] ICANN - MTS - A/V: really, it's very important for us to hold them accountable, especially as, we have mentioned before, that some of, the, law enforcement agencies in different, governments, they abuse, different, systems to have access to data. So. [47:40] ICANN - MTS - A/V: I… we can't agree that, that the authentication provider, especially if they're the government, should not have an agreement with ICANN, but if you have other… if you have other proposals as to how we can [47:57] ICANN - MTS - A/V: hold them accountable, without the agreement, we are all ears, David. [48:06] ICANN - MTS - A/V: Thank you, Farsney. David, go ahead. [48:09] ICANN - MTS - A/V: So first off, I just want to thank, Sarah for her comments, and Farzaneh for her comments as well. I really appreciate, the openness to work together towards a workable solution, especially introducing some sort of flexible or some sort of accountability mechanism that might suit, suit us here, so I really do appreciate that. [48:28] ICANN - MTS - A/V: And just for full transparency, and I forgot to mention it in my previous intervention when I was, introducing the, the changes, we've also introduced, new implementation. [48:40] ICANN - MTS - A/V: guidance, and the GAC just wants an explicit reference to the understanding that once the SSAD recommendations are approved by the board and implemented. [48:48] ICANN - MTS - A/V: And implemented, the urgent request policy will be operationalized. [48:53] ICANN - MTS - A/V: I think that was a, from my understanding, a mutual understanding amongst the group, but I think that the GAC would be comfortable with a… or more comfortable with a explicit reference in the document. But, certainly happy to work with folks on language around, the changes that we've made to number one, so. [49:12] ICANN - MTS - A/V: So, happy to touch base. Thanks. [49:16] ICANN - MTS - A/V: Thanks, David. On that, implementation note, given where we are on time, I'll… [49:22] ICANN - MTS - A/V: propose that we table that until one of our later sessions. Maybe we can get to that during Monday's session. [49:29] ICANN - MTS - A/V: We're at the, we have about 5 minutes left. [49:34] ICANN - MTS - A/V: If we go back to the slides. [49:40] ICANN - MTS - A/V: So I thank everybody for a good discussion. I think this has, given the leadership team a bit to think about as far as new language. Thank you for the feedback. I think we can address some of it. On the point about needing [49:59] ICANN - MTS - A/V: needing binding language for, for authentication entities, versus, maximum flexibility. I'm not exactly sure how to thread that needle, so we, we may need, additional… additional consideration on that one. I'm, I'm… [50:17] ICANN - MTS - A/V: I think. [50:20] ICANN - MTS - A/V: I'll say, you know, if we… if we don't have agreed-to language on that one, we'll go with our current language for public comments, but we do have a little bit of runway still until we get to public comments, so we can [50:35] ICANN - MTS - A/V: Try and come to, to language that threads that particular needle. [50:42] ICANN - MTS - A/V: So I think I'm… [50:44] ICANN - MTS - A/V: Hearing a, you know, a clear and conflicting need for accountability, yet flexibility, which are difficult to check both boxes, but we'll do that as best we can. [50:57] ICANN - MTS - A/V: Next slide, please. [51:02] ICANN - MTS - A/V: All right, so our next SRT meeting will be, 19 October. It's, during the 3 p.m. local time slot. [51:14] ICANN - MTS - A/V: to, to prepare for the meeting, we'll, we'll be looking for, outstanding, REC 6 and REC 13 items that are in the control sheet. So please, please review those and come prepared to, to discuss and, and find resolution. I think… are these our last AMBER items? [51:36] ICANN - MTS - A/V: I think so. I think, I think these are the last, last items that we have marked as amber, on the control sheet. So it would be great if we could close those out during Monday's meeting. If not, we do have additional runway to try and do that. [51:53] ICANN - MTS - A/V: So, as, as, and then… [51:58] ICANN - MTS - A/V: Just sort of recap where we, where we landed on today. We have agreement on privacy proxy language, so we'll see that, reflected in our draft public comments, version. [52:11] ICANN - MTS - A/V: And we'll work on updating the, the REC1 language. [52:18] ICANN - MTS - A/V: And, we'll get that out to the, the full SRT as soon as we have, language available. [52:27] ICANN - MTS - A/V: Next slide. [52:31] ICANN - MTS - A/V: Any other… any other business? Any, questions, comments? [52:39] ICANN - MTS - A/V: Not seeing any hands, it looks like we can, oh, Anne, sneaking in under the wire. Go ahead, Anne. Sorry, just a question whether, we will be able to hear from finance, from ICANN Finance, this week? [52:56] ICANN - MTS - A/V: Thanks, Anne, good question. Yes, I've asked, for them to come to our Wednesday, our Wednesday meeting, and I've also… [53:05] ICANN - MTS - A/V: I've also indicated that, there's a desire to have a better, to have a better understanding of the cost breakdown. I understand that they might not be far along… enough along that they'll be able to provide that. [53:19] ICANN - MTS - A/V: But I've indicated that that is, that is what we want to talk about on Wednesday, is, better understanding of the costing and what the cost drivers are. [53:33] ICANN - MTS - A/V: initial development and ongoing operational costs. [53:36] ICANN - MTS - A/V: You know, and I, I, you know, to… I don't, you know, I can't… [53:41] ICANN - MTS - A/V: I can't promise that they'll have that available for us on Friday, but I think they, you know, I've indicated that that's what we want to talk about on… er, sorry, Wednesday, during the Wednesday session. [53:52] ICANN - MTS - A/V: Farzaneh, go ahead. Thank you for the incredible job of taking into account our feedback. We very much appreciate it. [54:03] ICANN - MTS - A/V: Thank you, Farsnay, and with that, I think we can adjourn. Thank you very much for an excellent meeting, and we can end the recording. [54:13] ICANN - MTS - A/V: And stop the recording. Official source: https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3 Revision: 41b34bc34efcba7c00d23476e7daf3a35d566dfbf994c84faec9ce0e5a313e1a Made by AgentCommunity // Balázs Némethi ## Source and processing provenance Release: a5927a53b9ef39f2958a61187665079c9843a7fc67e30af1e1996b59901a2919 Source retrieved: 2026-10-23T21:01:13.749294+00:00 Availability: null Processing: {"human_reviewed":false,"terminology":"llm_corrected","summary":"ai_generated","asr":"completed","semantic_check":"passed"} Coverage: {"primary_track":"captions","recording_seconds":3259.402375,"asr_segments":600,"caption_segments":366,"gaps":[]} - The chair recorded consensus to use the GAC’s privacy proxy language for 5.7.3 in the public-comment draft, replacing the leadership compromise text. Evidence: {"quote":"I'll take that as consensus to proceed with the GACS language on this.","start":1663.87,"cue_id":"cue-198","segment_id":198} - The chair recorded consensus to use the GAC’s privacy proxy language for 5.7.3 in the public-comment draft, replacing the leadership compromise text. Evidence: {"quote":"we'll replace the GAC's proposed language for 5.7.3 as the, proposed path forward.","start":1680.16,"cue_id":"cue-199","segment_id":199} - Recommendation 1 on authentication was not closed: leadership will incorporate feedback into a new version for SRT review, while the current language is the fallback if no agreement is reached. Evidence: {"quote":"leadership team take all of this","start":2697.84,"cue_id":"cue-312","segment_id":312} - Recommendation 1 on authentication was not closed: leadership will incorporate feedback into a new version for SRT review, while the current language is the fallback if no agreement is reached. Evidence: {"quote":"we'll need a new version that we can review.","start":2712.06,"cue_id":"cue-313","segment_id":313} - Recommendation 1 on authentication was not closed: leadership will incorporate feedback into a new version for SRT review, while the current language is the fallback if no agreement is reached. Evidence: {"quote":"if we don't have agreed-to language on that one, we'll go with our current language for public comments","start":3020.05,"cue_id":"cue-342","segment_id":342} - Feodora reported that after Thursday’s full-day meeting no items were red, targeted work remained on authentication, privacy proxy and Recommendation 6, Recommendation 13 items remained open, and more recommendations were green and considered ready for public comment. Evidence: {"quote":"we don't necessarily have any red items anymore","start":134.76,"cue_id":"cue-12","segment_id":12} - Feodora reported that after Thursday’s full-day meeting no items were red, targeted work remained on authentication, privacy proxy and Recommendation 6, Recommendation 13 items remained open, and more recommendations were green and considered ready for public comment. Evidence: {"quote":"However, targeted discussions remain on authentication, privacy proxy.","start":151.53,"cue_id":"cue-13","segment_id":13} - Feodora reported that after Thursday’s full-day meeting no items were red, targeted work remained on authentication, privacy proxy and Recommendation 6, Recommendation 13 items remained open, and more recommendations were green and considered ready for public comment. Evidence: {"quote":"recommendation six that was considered green before, but some concerns were raised","start":161.01,"cue_id":"cue-14","segment_id":14} - Feodora reported that after Thursday’s full-day meeting no items were red, targeted work remained on authentication, privacy proxy and Recommendation 6, Recommendation 13 items remained open, and more recommendations were green and considered ready for public comment. Evidence: {"quote":"These seem, good for public comment.","start":198.52,"cue_id":"cue-19","segment_id":19} - For privacy proxy, Mark explained leadership’s compromise: a contracted party “should” disclose data where it determines disclosure is permitted, can indicate in Rec 3.11 that it will handle SSAD requests, and is expected to point requesters elsewhere when it lacks access. IPC liked the language but conditioned support on the meaning of “should”; Volker described “should” as a presumption, and Greg quoted RFC 2119’s recommended-level meaning. Evidence: {"quote":"Should disclose if the contracted party determines that disclosure is permitted under applicable law, contracts, and policy.","start":351.75,"cue_id":"cue-37","segment_id":37} - For privacy proxy, Mark explained leadership’s compromise: a contracted party “should” disclose data where it determines disclosure is permitted, can indicate in Rec 3.11 that it will handle SSAD requests, and is expected to point requesters elsewhere when it lacks access. IPC liked the language but conditioned support on the meaning of “should”; Volker described “should” as a presumption, and Greg quoted RFC 2119’s recommended-level meaning. Evidence: {"quote":"some registrars are willing to handle disclosure requests via the RDRS","start":386.47,"cue_id":"cue-40","segment_id":40} - For privacy proxy, Mark explained leadership’s compromise: a contracted party “should” disclose data where it determines disclosure is permitted, can indicate in Rec 3.11 that it will handle SSAD requests, and is expected to point requesters elsewhere when it lacks access. IPC liked the language but conditioned support on the meaning of “should”; Volker described “should” as a presumption, and Greg quoted RFC 2119’s recommended-level meaning. Evidence: {"quote":"Provide in the response the path, or the channel where the requester, can go in order to submit the request.","start":417.05,"cue_id":"cue-42","segment_id":42} - For privacy proxy, Mark explained leadership’s compromise: a contracted party “should” disclose data where it determines disclosure is permitted, can indicate in Rec 3.11 that it will handle SSAD requests, and is expected to point requesters elsewhere when it lacks access. IPC liked the language but conditioned support on the meaning of “should”; Volker described “should” as a presumption, and Greg quoted RFC 2119’s recommended-level meaning. Evidence: {"quote":"and we liked the language.","start":474.55,"cue_id":"cue-49","segment_id":49} - For privacy proxy, Mark explained leadership’s compromise: a contracted party “should” disclose data where it determines disclosure is permitted, can indicate in Rec 3.11 that it will handle SSAD requests, and is expected to point requesters elsewhere when it lacks access. IPC liked the language but conditioned support on the meaning of “should”; Volker described “should” as a presumption, and Greg quoted RFC 2119’s recommended-level meaning. Evidence: {"quote":"What is the meaning of should?","start":494.24,"cue_id":"cue-51","segment_id":51} - For privacy proxy, Mark explained leadership’s compromise: a contracted party “should” disclose data where it determines disclosure is permitted, can indicate in Rec 3.11 that it will handle SSAD requests, and is expected to point requesters elsewhere when it lacks access. IPC liked the language but conditioned support on the meaning of “should”; Volker described “should” as a presumption, and Greg quoted RFC 2119’s recommended-level meaning. Evidence: {"quote":"we would usually interpret the word should as a presumption of a certain outcome","start":526.1,"cue_id":"cue-57","segment_id":57} - For privacy proxy, Mark explained leadership’s compromise: a contracted party “should” disclose data where it determines disclosure is permitted, can indicate in Rec 3.11 that it will handle SSAD requests, and is expected to point requesters elsewhere when it lacks access. IPC liked the language but conditioned support on the meaning of “should”; Volker described “should” as a presumption, and Greg quoted RFC 2119’s recommended-level meaning. Evidence: {"quote":"this word, or the adjective recommended, means that there may exist valid reasons in particular circumstances to ignore a particular item","start":674.56,"cue_id":"cue-76","segment_id":76} - David presented GAC language that a disclosure request involving a privacy or proxy registration be evaluated and answered under the consensus policy on privacy/proxy registrations, aiming to avoid different requirements depending on whether a request comes through SSAD. Evidence: {"quote":"the contracted party must ensure the request is evaluated and responded to in line with the requirements of the consensus policy on privacy proxy registrations.","start":706.7,"cue_id":"cue-80","segment_id":80} - David presented GAC language that a disclosure request involving a privacy or proxy registration be evaluated and answered under the consensus policy on privacy/proxy registrations, aiming to avoid different requirements depending on whether a request comes through SSAD. Evidence: {"quote":"the language avoids the result of having different requirements based on whether the request comes through the SSAT or not.","start":945.32,"cue_id":"cue-105","segment_id":105} - David presented GAC language that a disclosure request involving a privacy or proxy registration be evaluated and answered under the consensus policy on privacy/proxy registrations, aiming to avoid different requirements depending on whether a request comes through SSAD. Evidence: {"quote":"pointing to the policy work that's happening in the PPSAI","start":975.47,"cue_id":"cue-107","segment_id":107} - Susan challenged the GAC approach because PPSAI is an implementation review team implementing existing recommendations and, in her view, does not cover disclosure obligations; Ashley said PPSAI draft text does address disclosure but is still under discussion, and registrars found the GAC text clearer and acceptable with “must.” Evidence: {"quote":"the thing that's troubling me is that the PPSAI is","start":1025.39,"cue_id":"cue-111","segment_id":111} - Susan challenged the GAC approach because PPSAI is an implementation review team implementing existing recommendations and, in her view, does not cover disclosure obligations; Ashley said PPSAI draft text does address disclosure but is still under discussion, and registrars found the GAC text clearer and acceptable with “must.” Evidence: {"quote":"They deal with, you know, kind of accreditation of privacy proxy service providers and so on.","start":1040.569,"cue_id":"cue-114","segment_id":114} - Susan challenged the GAC approach because PPSAI is an implementation review team implementing existing recommendations and, in her view, does not cover disclosure obligations; Ashley said PPSAI draft text does address disclosure but is still under discussion, and registrars found the GAC text clearer and acceptable with “must.” Evidence: {"quote":"We're referring to a policy that isn't there.","start":1052.31,"cue_id":"cue-116","segment_id":116} - Susan challenged the GAC approach because PPSAI is an implementation review team implementing existing recommendations and, in her view, does not cover disclosure obligations; Ashley said PPSAI draft text does address disclosure but is still under discussion, and registrars found the GAC text clearer and acceptable with “must.” Evidence: {"quote":"there is text in the draft policy that does look at.","start":1082.71,"cue_id":"cue-121","segment_id":121} - Susan challenged the GAC approach because PPSAI is an implementation review team implementing existing recommendations and, in her view, does not cover disclosure obligations; Ashley said PPSAI draft text does address disclosure but is still under discussion, and registrars found the GAC text clearer and acceptable with “must.” Evidence: {"quote":"the registrars are okay with the word must here.","start":1115.09,"cue_id":"cue-127","segment_id":127} - After a caucus, IPC, registries, BC and NCSG expressed support for the GAC privacy proxy text; the chair took this as consensus, with the numbering clarified as 5.7.3 (old 8.7.3). The board liaison had urged assessing system usability, implementation complexity and cost across all parties, often favoring the simplest approach. Evidence: {"quote":"the usability of the entire system to all parties.","start":1433,"cue_id":"cue-167","segment_id":167} - After a caucus, IPC, registries, BC and NCSG expressed support for the GAC privacy proxy text; the chair took this as consensus, with the numbering clarified as 5.7.3 (old 8.7.3). The board liaison had urged assessing system usability, implementation complexity and cost across all parties, often favoring the simplest approach. Evidence: {"quote":"cost is not just in dollars","start":1454.26,"cue_id":"cue-169","segment_id":169} - After a caucus, IPC, registries, BC and NCSG expressed support for the GAC privacy proxy text; the chair took this as consensus, with the numbering clarified as 5.7.3 (old 8.7.3). The board liaison had urged assessing system usability, implementation complexity and cost across all parties, often favoring the simplest approach. Evidence: {"quote":"the right approach is often the simplest","start":1499.12,"cue_id":"cue-175","segment_id":175} - After a caucus, IPC, registries, BC and NCSG expressed support for the GAC privacy proxy text; the chair took this as consensus, with the numbering clarified as 5.7.3 (old 8.7.3). The board liaison had urged assessing system usability, implementation complexity and cost across all parties, often favoring the simplest approach. Evidence: {"quote":"the IPC can support their proposal.","start":1578.36,"cue_id":"cue-183","segment_id":183} - After a caucus, IPC, registries, BC and NCSG expressed support for the GAC privacy proxy text; the chair took this as consensus, with the numbering clarified as 5.7.3 (old 8.7.3). The board liaison had urged assessing system usability, implementation complexity and cost across all parties, often favoring the simplest approach. Evidence: {"quote":"The registries support the GAC language.","start":1616.21,"cue_id":"cue-187","segment_id":187} - After a caucus, IPC, registries, BC and NCSG expressed support for the GAC privacy proxy text; the chair took this as consensus, with the numbering clarified as 5.7.3 (old 8.7.3). The board liaison had urged assessing system usability, implementation complexity and cost across all parties, often favoring the simplest approach. Evidence: {"quote":"Support the GAC. Same as… same as IPC.","start":1631.04,"cue_id":"cue-190","segment_id":190} - After a caucus, IPC, registries, BC and NCSG expressed support for the GAC privacy proxy text; the chair took this as consensus, with the numbering clarified as 5.7.3 (old 8.7.3). The board liaison had urged assessing system usability, implementation complexity and cost across all parties, often favoring the simplest approach. Evidence: {"quote":"as non-commercial stakeholder group.","start":1653.62,"cue_id":"cue-195","segment_id":195} - After a caucus, IPC, registries, BC and NCSG expressed support for the GAC privacy proxy text; the chair took this as consensus, with the numbering clarified as 5.7.3 (old 8.7.3). The board liaison had urged assessing system usability, implementation complexity and cost across all parties, often favoring the simplest approach. Evidence: {"quote":"I'll take that as consensus to proceed with the GACS language on this.","start":1663.87,"cue_id":"cue-198","segment_id":198} - After a caucus, IPC, registries, BC and NCSG expressed support for the GAC privacy proxy text; the chair took this as consensus, with the numbering clarified as 5.7.3 (old 8.7.3). The board liaison had urged assessing system usability, implementation complexity and cost across all parties, often favoring the simplest approach. Evidence: {"quote":"the new number is 5.7.3, but I think it was the old 8.7.3.","start":1710,"cue_id":"cue-203","segment_id":203} - For Recommendation 1, leadership proposed clarifying IRT consultation for the authentication framework, later Standing Committee consultation for changes, public listing of recognized providers by requester category, and ICANN Org’s sole responsibility for recognition and application management. Evidence: {"quote":"This was specifically to, REC 1.3","start":1818.22,"cue_id":"cue-216","segment_id":216} - For Recommendation 1, leadership proposed clarifying IRT consultation for the authentication framework, later Standing Committee consultation for changes, public listing of recognized providers by requester category, and ICANN Org’s sole responsibility for recognition and application management. Evidence: {"quote":"done in consultation with the IRT","start":1837.74,"cue_id":"cue-217","segment_id":217} - For Recommendation 1, leadership proposed clarifying IRT consultation for the authentication framework, later Standing Committee consultation for changes, public listing of recognized providers by requester category, and ICANN Org’s sole responsibility for recognition and application management. Evidence: {"quote":"ICANN Org should consult with the implementation review team in establishing the framework","start":1892.69,"cue_id":"cue-225","segment_id":225} - For Recommendation 1, leadership proposed clarifying IRT consultation for the authentication framework, later Standing Committee consultation for changes, public listing of recognized providers by requester category, and ICANN Org’s sole responsibility for recognition and application management. Evidence: {"quote":"ICANN Org should consult with the Standing Committee, which will take over from the IRT.","start":1923.65,"cue_id":"cue-228","segment_id":228} - For Recommendation 1, leadership proposed clarifying IRT consultation for the authentication framework, later Standing Committee consultation for changes, public listing of recognized providers by requester category, and ICANN Org’s sole responsibility for recognition and application management. Evidence: {"quote":"the list of authentication providers should be made transparent and public.","start":1848.23,"cue_id":"cue-219","segment_id":219} - For Recommendation 1, leadership proposed clarifying IRT consultation for the authentication framework, later Standing Committee consultation for changes, public listing of recognized providers by requester category, and ICANN Org’s sole responsibility for recognition and application management. Evidence: {"quote":"ICANN Org's sole responsibility for determining if an authentication provider meets the criteria to become recognized.","start":1981.55,"cue_id":"cue-233","segment_id":233} - For Recommendation 1, leadership proposed clarifying IRT consultation for the authentication framework, later Standing Committee consultation for changes, public listing of recognized providers by requester category, and ICANN Org’s sole responsibility for recognition and application management. Evidence: {"quote":"ICANN Org would be responsible to manage the application process once all the requirements are set and published.","start":1866.65,"cue_id":"cue-221","segment_id":221} - The chair recorded consensus to proceed with the GAC privacy proxy language for 5.7.3 as the proposed path forward for the public-comment version. Evidence: {"quote":"I'll take that as consensus to proceed with the GACS language on this.","start":1663.87,"cue_id":"cue-198","segment_id":198} - The chair recorded consensus to proceed with the GAC privacy proxy language for 5.7.3 as the proposed path forward for the public-comment version. Evidence: {"quote":"we'll replace the GAC's proposed language for 5.7.3 as the, proposed path forward.","start":1680.16,"cue_id":"cue-199","segment_id":199} - Susan argued that the GAC language points to a PPSAI policy that does not cover disclosure obligations, while Ashley said PPSAI draft text does address disclosure but remains under discussion. Evidence: {"quote":"We're referring to a policy that isn't there.","start":1052.31,"cue_id":"cue-116","segment_id":116} - Susan argued that the GAC language points to a PPSAI policy that does not cover disclosure obligations, while Ashley said PPSAI draft text does address disclosure but remains under discussion. Evidence: {"quote":"there is text in the draft policy that does look at.","start":1082.71,"cue_id":"cue-121","segment_id":121} - On Recommendation 1, Sarah said the GAC proposal weakens binding obligations contracted parties need to rely on authentication outcomes, while David sought flexibility for governments that may be unable to enter binding ICANN contracts. Evidence: {"quote":"the proposal weakens the binding obligations on authentication providers","start":2744.93,"cue_id":"cue-317","segment_id":317} - On Recommendation 1, Sarah said the GAC proposal weakens binding obligations contracted parties need to rely on authentication outcomes, while David sought flexibility for governments that may be unable to enter binding ICANN contracts. Evidence: {"quote":"If we can't show that there's a contract governing how requesters are authenticated","start":2766.1,"cue_id":"cue-319","segment_id":319} - On Recommendation 1, Sarah said the GAC proposal weakens binding obligations contracted parties need to rely on authentication outcomes, while David sought flexibility for governments that may be unable to enter binding ICANN contracts. Evidence: {"quote":"the requirement for authentication providers to enter into a contract with ICANN would be challenging for governments and government entities.","start":2578.5,"cue_id":"cue-301","segment_id":301} - Privacy proxy language was resolved for purposes of the public-comment draft, using the GAC text for 5.7.3 and wrapping up that agenda item. Evidence: {"quote":"I'll take that as consensus to proceed with the GACS language on this.","start":1663.87,"cue_id":"cue-198","segment_id":198} - Privacy proxy language was resolved for purposes of the public-comment draft, using the GAC text for 5.7.3 and wrapping up that agenda item. Evidence: {"quote":"that wraps up our discussion on privacy proxy, through, through to, through public comment.","start":1757.76,"cue_id":"cue-209","segment_id":209} - Privacy proxy language was resolved for purposes of the public-comment draft, using the GAC text for 5.7.3 and wrapping up that agenda item. Evidence: {"quote":"We have agreement on privacy proxy language","start":3118.77,"cue_id":"cue-351","segment_id":351} - Recommendation 1 was not closed; leadership will produce a new version reflecting SRT and GAC feedback for review. Evidence: {"quote":"leadership team take all of this","start":2697.84,"cue_id":"cue-312","segment_id":312} - Recommendation 1 was not closed; leadership will produce a new version reflecting SRT and GAC feedback for review. Evidence: {"quote":"we'll need a new version that we can review.","start":2712.06,"cue_id":"cue-313","segment_id":313} - The GAC’s proposed implementation-guidance reference on urgent requests was tabled to a later session, possibly Monday. Evidence: {"quote":"propose that we table that until one of our later sessions","start":2962.87,"cue_id":"cue-336","segment_id":336} - The group proceeded with the GAC’s proposed privacy proxy language for 5.7.3, replacing the leadership team’s proposed compromise for the public-comment version. Evidence: {"quote":"I'll take that as consensus to proceed with the GACS language on this.","start":1663.87,"cue_id":"cue-198","segment_id":198} - The group proceeded with the GAC’s proposed privacy proxy language for 5.7.3, replacing the leadership team’s proposed compromise for the public-comment version. Evidence: {"quote":"we'll replace the GAC's proposed language for 5.7.3 as the, proposed path forward.","start":1680.16,"cue_id":"cue-199","segment_id":199} - Leadership team to take the Recommendation 1 feedback into account and produce a new version for the SRT to review. Evidence: {"quote":"leadership team take all of this","start":2697.84,"cue_id":"cue-312","segment_id":312} - Leadership team to take the Recommendation 1 feedback into account and produce a new version for the SRT to review. Evidence: {"quote":"we'll need a new version that we can review.","start":2712.06,"cue_id":"cue-313","segment_id":313} - SRT members to review the outstanding Recommendation 6 and Recommendation 13 items in the control sheet and come prepared to discuss them at the 19 October meeting. Evidence: {"quote":"outstanding, REC 6 and REC 13 items that are in the control sheet","start":3074.72,"cue_id":"cue-348","segment_id":348} - The agreed privacy proxy language is to be reflected in the draft public-comment version, and updated Recommendation 1 language is to be circulated to the full SRT when available. Evidence: {"quote":"We have agreement on privacy proxy language","start":3118.77,"cue_id":"cue-351","segment_id":351} - The agreed privacy proxy language is to be reflected in the draft public-comment version, and updated Recommendation 1 language is to be circulated to the full SRT when available. Evidence: {"quote":"we'll get that out to the, the full SRT as soon as we have, language available.","start":3138.41,"cue_id":"cue-353","segment_id":353} - Suggested follow-up: explore a lighter-weight accountability mechanism for authentication providers, rather than only a full formal contract, to bridge contracted-party legal assurance and GAC flexibility concerns. Evidence: {"quote":"we could consider maybe lighter weight options rather than a full-blown formal contract","start":2787.85,"cue_id":"cue-321","segment_id":321} - Suggested follow-up: explore a lighter-weight accountability mechanism for authentication providers, rather than only a full formal contract, to bridge contracted-party legal assurance and GAC flexibility concerns. Evidence: {"quote":"the openness to work together towards a workable solution","start":2889.02,"cue_id":"cue-329","segment_id":329} - Suggested follow-up: clarify in Recommendation 1 how a designee is selected and how it would consult the IRT or community, and whether “if warranted” should be removed. Evidence: {"quote":"maybe a third party that ICANN might","start":2376.05,"cue_id":"cue-276","segment_id":276} - Suggested follow-up: clarify in Recommendation 1 how a designee is selected and how it would consult the IRT or community, and whether “if warranted” should be removed. Evidence: {"quote":"are we saying the third-party designee would be consulting with the IRT?","start":2454.72,"cue_id":"cue-286","segment_id":286} - Suggested follow-up: clarify in Recommendation 1 how a designee is selected and how it would consult the IRT or community, and whether “if warranted” should be removed. Evidence: {"quote":"maybe we don't need, if warranted, maybe it should just be","start":2480.02,"cue_id":"cue-289","segment_id":289} - Suggested follow-up: if Recommendation 1 options remain difficult to choose, consider whether public comment could seek input on more than one formulation, an option raised but not adopted. Evidence: {"quote":"is there some sort of prohibition in","start":1323.75,"cue_id":"cue-150","segment_id":150} - Suggested follow-up: if Recommendation 1 options remain difficult to choose, consider whether public comment could seek input on more than one formulation, an option raised but not adopted. Evidence: {"quote":"We absolutely could.","start":1348.71,"cue_id":"cue-154","segment_id":154} - Suggested follow-up: if Recommendation 1 options remain difficult to choose, consider whether public comment could seek input on more than one formulation, an option raised but not adopted. Evidence: {"quote":"But I think I would prefer to go to public comment with a proposed path forward.","start":1362.98,"cue_id":"cue-156","segment_id":156} - Suggested follow-up: follow up with ICANN Finance on whether a cost breakdown and explanation of cost drivers, including initial development and ongoing operational costs, will be ready for the Wednesday session. Evidence: {"quote":"I've asked, for them to come to our Wednesday, our Wednesday meeting","start":3176.05,"cue_id":"cue-357","segment_id":357} - Suggested follow-up: follow up with ICANN Finance on whether a cost breakdown and explanation of cost drivers, including initial development and ongoing operational costs, will be ready for the Wednesday session. Evidence: {"quote":"better understanding of the costing and what the cost drivers are.","start":3199.34,"cue_id":"cue-359","segment_id":359} - Suggested follow-up: follow up with ICANN Finance on whether a cost breakdown and explanation of cost drivers, including initial development and ongoing operational costs, will be ready for the Wednesday session. Evidence: {"quote":"initial development and ongoing operational costs.","start":3213.12,"cue_id":"cue-360","segment_id":360} - What is the intended meaning of “should” in the leadership privacy proxy formulation? Evidence: {"quote":"What is the meaning of should?","start":494.24,"cue_id":"cue-51","segment_id":51} - What is the intended meaning of “should” in the leadership privacy proxy formulation? Evidence: {"quote":"we would usually interpret the word should as a presumption of a certain outcome","start":526.1,"cue_id":"cue-57","segment_id":57} - What is the intended meaning of “should” in the leadership privacy proxy formulation? Evidence: {"quote":"this word, or the adjective recommended, means that there may exist valid reasons in particular circumstances to ignore a particular item","start":674.56,"cue_id":"cue-76","segment_id":76} - Whether the PPSAI work actually covers disclosure obligations remains a point of contestation. Evidence: {"quote":"We're referring to a policy that isn't there.","start":1052.31,"cue_id":"cue-116","segment_id":116} - Whether the PPSAI work actually covers disclosure obligations remains a point of contestation. Evidence: {"quote":"there is text in the draft policy that does look at.","start":1082.71,"cue_id":"cue-121","segment_id":121} - In Recommendation 1, is there to be a single authentication standard for all providers, or different requirements for providers serving different communities? Evidence: {"quote":"Are we anticipating that there could be different requirements for authentication providers serving different communities","start":2076.33,"cue_id":"cue-243","segment_id":243} - How will ICANN choose a designee, and how would that designee consult the IRT or community in establishing or changing the authentication framework? Evidence: {"quote":"what do we mean by designee? ICANN Org or its designee?","start":2186.89,"cue_id":"cue-255","segment_id":255} - How will ICANN choose a designee, and how would that designee consult the IRT or community in establishing or changing the authentication framework? Evidence: {"quote":"are we saying the third-party designee would be consulting with the IRT?","start":2454.72,"cue_id":"cue-286","segment_id":286} - How can the need for binding accountability and the need for flexibility for government authentication providers both be satisfied? Evidence: {"quote":"a clear and conflicting need for accountability, yet flexibility","start":3044.3,"cue_id":"cue-345","segment_id":345} ## Materials and complete resources - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2Wjf8/revisions/41b34bc34efcba7c00d23476e7daf3a35d566dfbf994c84faec9ce0e5a313e1a/ai-context.md - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2Wjf8/revisions/41b34bc34efcba7c00d23476e7daf3a35d566dfbf994c84faec9ce0e5a313e1a/transcript-corrected.json - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2Wjf8/revisions/41b34bc34efcba7c00d23476e7daf3a35d566dfbf994c84faec9ce0e5a313e1a/captions-original.vtt - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2Wjf8/revisions/41b34bc34efcba7c00d23476e7daf3a35d566dfbf994c84faec9ce0e5a313e1a/context-package.zip - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2Wjf8/revisions/41b34bc34efcba7c00d23476e7daf3a35d566dfbf994c84faec9ce0e5a313e1a/wiki.wikitext - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2Wjf8/revisions/41b34bc34efcba7c00d23476e7daf3a35d566dfbf994c84faec9ce0e5a313e1a/session.json ## Source hashes - captions-original.vtt: 9e36cbf30dd49872cb7553b2225c02f0e2b45bdcb6210092791a375995d4f308 (62220 bytes); source https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3 - transcript-raw.json: 2a1e8480d69d65e7bc2ebf65e1c0ea56fa13e08e01f49e641f4c08a649dfdb8f (124148 bytes); source https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3 - transcript-corrected.json: 6acdf614c909d7cd58baf81716d45acc1af442c64e22293d9fb16f2903b22f90 (124313 bytes); source https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3 - transcript-asr.json: 64eaa6bf83ad388f7321b7fd8684c6e3bb748331eaa5241c9733b93b1875abf9 (128522 bytes); source https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3 - audio/session.mp3: d488dca391f07d53c0392949294b4ded4d462672e2b3538f4816fa63c3780450 (26075602 bytes); source http://audio.icann.org/meetings/dps87/dps87-OPEN-2026-10-17-T0815-nusantara1-en-01-GNSO-SSAD-Supplemental-Recommend_.mp3 - sources.json: 34706066af6e34f150f03da4b298728db3bf3c81168cadf8147f6f7ed452fe4e (957 bytes); source https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3 - summary.json: 40b79134027b6ada2d7bf8c958988c0f397d3b8f8ba921f997f57514b27b76bf (22445 bytes); source https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3 - summary.md: d2fc62e464e9d8dd795ac63ae82f5b8c710f9bc25a267695bc973f83a030c8ae (16907 bytes); source https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3 - wiki.wikitext: 8230b94d11baf22a45d3a190453dff00549d07b846d260b9c4d30732d115ceb0 (23896 bytes); source https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3 - ai-context.md: b6b9d8e78c19b734f9bd3f9212e9fbbbf70ba68496d80dd19d9e1cc05ca1d6c4 (72881 bytes); source https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3 - context.md: 59f7a3f14359eb82a2c6ebe354e9cfe73301296a5503de9f07b4c286716ca0f5 (73784 bytes); source https://icann87.sched.com/event/2Wjf8/gnso-ssad-supplemental-recommendations-session-1-of-3