**Session Date/Time:** 22 Jul 2026 14:00

[00:00:19] **Chairperson**: Alright. I think we'll get started. This is the privacypass meeting. If somebody wants to pull the door shut in the back there, maybe we can cut on cut down on some of the external noise. Thanks, Chris. Let's see. Okay. You've probably all seen the note well, which kind of goes over your obligations in participating in the IETf. I'll leave it up here for a couple more seconds so people can just take a look, but pretty sure you've probably seen it. If you're here in the room, please sign in to the on-site tool so that we can record your attendance and so that you can join the queue to participate in the discussion. And if you're remote, you can keep your video and audio off unless you're speaking. That would be helpful. Alright. Here's some additional pieces of information. I think it's already covered. Okay. So we have a pretty quick agenda today. I don't expect any of these things will take as long as they say. We do have somebody who's gonna take some notes, And we have Ben online as well. Are you hooked up to audio, Ben?

[00:01:58] **Ben**: Yep. I'm here.

[00:01:59] **Chairperson**: Alright. Perfect. So, yeah, we'll have some document updates from the chairs. Then I just wanted to kinda get an update on the ARC status ARC status. And then we have some discussion of the reverse flow draft and summary, I guess, of the mole our mole meeting that we had, a side meeting that took place yesterday afternoon, I think. Yeah. Any agenda bashing? Alright. So with respect to document updates, batch token is submitted to the IESG waiting on AD review. And then we have a a couple more documents that are just about ready to go. Believe the private token HTTP authentication scheme is is all ready to go. We did have a question on the privacy pass issuance protocol with public metadata. The document is currently informational. I'm wondering it seems like it should be standards track, but I'm wondering, Chris, would do you know particularly why we have it as informational?

[00:03:24] **Thibault**: What's that?

[00:03:27] **Chris Wood**: It's a

[00:03:29] **Chairperson**: mistake. It's a mistake. Okay. So I I think we'll just is there anybody in the room right now who thinks this document should stay informational? I mean, we're pro proposing to put into standard track like the other documents. And so I'll I'll probably send something to list real quick just to confirm that nobody has any objections, and then we can get authors to publish a new doc in standards track, and that should be good. And then we can send that one as well. So that'll be kind of those documents. We do have another document that I didn't list here. That's the rate it's a token it's which one do we have in working group last call right now? Is it the Extension. The the extension? Ben, do you know which one we have in working group last call? Alright. We I Token expiration. Token expiration. Yeah. Thank you. And so those are kind of the active documents right now. What we wanna get an update on is ARC. The rumors are is that ARC is kind of reached terminal point and that don't wanna continue on with it. Is that correct? Yeah. I get a thumbs up from Chris, and a couple other people have told me the same thing. Is there anybody who has you know, thinks that we should continue on with the ARC document

[00:05:23] **Thibault**: or

[00:05:23] **Chairperson**: documents? Then we'll probably do the appropriate thing in data tracker to probably release them from the working group. Alright then. So that's the end of the chair slide, which did not take close to fifteen minutes. And so we will go on to Thibault's Okay. You should have control. And I do. Fantastic.

[00:06:14] **Thibault**: Okay. So I also hope this will not take, like, the full time, in the full twenty minutes, and we can be a bit more quick on that. This is to give you an update on the privacypass reverse flow, that has been presented first in Bangkok, last year and has been presented at the interim that we hold in May. I'm Thibault. I'm from Cloudflare. And, yeah, without further ado, we're going to go into the presentation. So private space has an architecture, and, like, it's, like, standardized in r f c 9095, '76. It looks like this. You're all familiar, and you all love it. And, therefore, we're going to move to the next slide. There's a couple of limitations that have appeared over time, like, what if the client is misbehaving? How can the origin rate limit them? If an origin has more resources, can it still allow the client to come without brinking unlinkability property? As an attester, how do I know if the client that I gave tokens to were to somehow misbehave, and what are the consequences for that? As an origin, how do I rate limit people going back to the attester to get token? How does this feedback mechanism? And as we've seen, there's been a couple of documents around anonymous credential. What are the considerations for that within the architecture that we have for privacypass? And that's where reverse flow came in. The initial version of the reverse flow essentially described that you have the regular privacy pass flow, which is on the right on this slide. Yep. It's also on the right for you. And we just instantiate an origin controlled issuer, which we call the origin issuer, which provide a second flow of privacy pass. And at the time that you do the redemption for the first privacy pass flow, you initiate a second privacy pass flow with the origin that would be able to provide you a token from the origin issuer and perform that flow. This way, the second time the client comes in, it's able to present a new token, which is unlinkable with the previous flow and rinse and repeat. It's a reverse flow because it acts kind of in the opposite way. The origin acts as the issuer so that it's able to continue the privacy pass flow. The latest version takes a bit more space, but essentially, it's really to accommodate and properly distinguish the various steps that are being taken by each actors and also to accommodate for the fact that there's more and more credential which are being used here. In this case, the few steps that we've added, we've distinguished the credential finalization from the credential presentation, meaning that if I was to present the credential multiple times, there's one step when I receive the response from the issuer, which is the finalization, and then at the time I present it, this is a different cryptographic operation, and therefore we split it here. Similarly, instead of having a token request or token challenge, which seemed to be a bit inappropriate here, some of the feedback that we've received from the group and in discussion would be nice to name it differently because it's more of a credential rather than a token, and therefore we've updated that here. Essentially, that's it. Otherwise, it's still the same two flows that we have. The differences since the last time that we presented that to the group in May, we've added a security consideration section to, like, ensure, like, what does happen and when should, like, redemption happen, like, when is it checked before doing a reassurance, some amplification consideration because, like, I might perfectly, like, get a token presented and get multiple token back or, like, token that, like, means something different, so there's some considerations here. And similarly, with replay protection, which are, like, very close to what's in the regular IC. There was one comment which was also how do we sharpen the relationship with the actual architecture RFC? So there's some consideration in terms of how do I know that origin operates an origin issuer. It might be because it already hosts a well known. It might be because of client client considerations. There are some consistency consideration which have been added because it was one of the work item in the working group in the past. I'm not sure if, like, that's something that should be added in this document, but this is, like this provide, like, some nice properties. And finally, one of the bigger comment and, like, the main change if you do, like, a comparison between, like, draft o six and draft o four is we moved the HTTP header, which was defined in draft, into its dedicated draft. So we focus, on the architecture, and there's a dedicated draft just to, like, do the instantiation via HTTP. This is important, because, like, we also, like, use a reverse flow in, like, media over quick, and media over quick doesn't have HTTP headers. So, like, this is a different instantiation of the flow. Similar with Molle, there's, like, their own dedicated instantiation, and, therefore, it, like, just makes sense to, like, split the architecture and, like, actual realization of that architecture. And that's it. I have a couple of questions for the group. Do anonymous credential work need the specific architecture guidance in here? I do believe that's the case, and it makes things a lot clearer to work through the flow, but that's something that is a different consideration. There's one thing which is not mentioned in this architecture, it's not mentioned in the privacypass architecture as well. It's like because we have, like, this reverse flow state, kind of, like, becomes a bit more important. We don't discuss it through the architecture, but maybe that's something that, like, would necessitate a dedicated section. I don't have much opinion about that. And finally, we have some privacy guarantees. How much, like, can we, like, actually, like, ensure that these privacy guarantees and considerations are actually followed? This is I think something which I could use eyes on. And, yeah, that's it. The draft is up here. And so if you have any question or any answers to the question which are here, I'm happy to take them. Tommy? Yep.

[00:12:17] **Tommy Pauly**: Tommy Pauly, Apple. Yes. I think this is useful. I have reviewed it, and I think it's a good document. I think it's the right thing to split out the header definition from the broader architecture. All the cases I'm aware of that are doing reverse flow stuff all have their own ways of doing that that are not this header, and I am sure some of them could use the header. But I think it is a principle of how you instantiate this that is separate from how you pass the bits. So that's good. For number two, the open question about client state is what would you imagine there? Because, I guess, while maybe the base documents don't talk too much about client state, they do talk about caching stuff to some degree. And I think even without reverse flow, like, do you do always have some state that you need to keep unless you're just doing purely, like, one time tokens and you spend and then you forget about it. So can you clarify what you're mentioning there?

[00:13:26] **Thibault**: Yes. So I do think there's kind of, like, two parts here. There's a fact that, like, given, like, the architecture, we'd, like, bring a bit of, like, the vocabulary from, like, anonymous credential where we split, like, the finalization, the presentation. Sure. It seems like it would be important to, like, understand, like, how that may relate to, like, the state that, like, the client has. And similar when it interact with, like, an origin issuer, there might be, like, some distinction in terms of, like, kind of, like, state partition and, like, how you do that. That might be, like, a small consideration to add on that side. I'm not sure it's, like, specifically useful because all deployment, we have that, but I do think that's something that was not in the base architecture, and that might be the few words to say. I'm not sure exactly which one. Right.

[00:14:12] **Tommy Pauly**: And that does bring up a thought. So maybe one of the points to bring up for around the state is I've seen both models for the reverse flow where you have a case where you are, you know, spending a token and you're doing the reverse flow to get an equivalent token back that you just kinda store in the same place. So you have a bucket of equivalent things, and you just kind of replace it as a full refund versus doing a reverse flow where the new thing is stored separately because it has different properties or different meaning from the other one. So that may be good to call out that your your storage may need to distinguish the things that you got from the reverse flow or may not.

[00:14:53] **Thibault**: Yes. The issue might be distinct from, like, the original one and therefore having that. Sure. Thank you. Ben, I'll see you next.

[00:15:05] **Ben**: Hi. Does this correspond to a deployed system today?

[00:15:12] **Thibault**: Yes. It does.

[00:15:15] **Ben**: What can you tell us about that?

[00:15:20] **Thibault**: I mean, data system, which, like, based on, like, the limitation that we had and we've seen with privacy pass, we needed to preserve, like, the unlinkability property of, the flow while being able to, like, have the client keep and repeat the request that it's making.

[00:15:38] **Ben**: Okay. So does that use this HTTP header?

[00:15:45] **Thibault**: It doesn't use the HTTP header.

[00:15:47] **Ben**: It does not? No. Okay. Is it running in HTTP?

[00:15:55] **Thibault**: Some are running in HTTP. Okay.

[00:15:58] **Ben**: But when but the ones that are in HTTP are are using a different header

[00:16:04] **Thibault**: or Yes. Correct. And I I I oh, go ahead.

[00:16:09] **Ben**: Okay. Are is the are those implementations relying on any special browser capabilities, like the Chrome private token, or are they essentially running above the browser and without any special privacy pass browser capabilities?

[00:16:29] **Thibault**: They are not all tied to the browser, similarly to, like, how privacy pass is not necessarily and only used in browser context.

[00:16:38] **Ben**: Okay. Thanks. That that's helpful for understanding the status here. So I see that this is referenced by an adopted document in mock. So what do you think should happen with this document in terms of working group state?

[00:17:06] **Thibault**: Yeah. I do think there's been, like, a lot of iteration, like, on this document that, like, helped to, like, sharpen it. I do think it would make sense for, the privacy pass working group to take it on. The question is because we have, like, a couple of documented, like, are moving out and, like, try ESG, I do think this would be the only active document that would be left. Is it something that we want to do as a working group? That's a question. But I do think it's, like, at least ready for adoption within the working group.

[00:17:36] **Ben**: Okay. Thank you.

[00:17:42] **Thibault**: Sam?

[00:17:48] **Sam**: Not so much of a question, more of just like an observation that I've had repeatedly and and wanna say now. It's just like if you squint at this, it sort of looks like you're using a privacy pass redemption as attestation, and you can almost see it as an instantiation of the original architecture with attestation just sort of expanded. Is it useful to spell that out explicitly or or or not is basically my question?

[00:18:10] **Thibault**: I mean, if it helps I I do think the obsession is, like, right. Like, that's essentially what we're doing, and, like, that's also why it's, like, a reverse flow. Like, we're we're using a token that, like, was using privacypass to, like, actually redeem, like, a privacypass. I do think it's a bit more complex than that because, like, you are actually using, like, the redeem token. There might be, like, some origin processing, which are, like, beyond specifically, like, the initial privacy pass token to actually reissue. I'm not sure if you have a specific wording. Definitely happy to, like, like, to take a look and and take that to the list on GitHub.

[00:18:51] **Chairperson**: Okay. I think there's there's one more

[00:18:55] **Thibault**: question, I think, from. Oh, okay. Yep. Sorry.

[00:18:59] **Presenter**: Hi, Sorry. Can you think this can be used also to at the state, the age, for example, for age assurance purposes, not, transporting directly the age, but as a gating?

[00:19:13] **Thibault**: I mean, I possibly. I haven't looked into it. Like, yeah, I don't have much truth about that. Thank you. Thank you.

[00:19:30] **Sam**: I on the state thing, I think it actually is helpful to put the state in here because there's some, like, guidance on durability and and, like, sort of transactionality that could be very helpful. And I think those things, like, overlap with all of the different things that have been considered to be deployed. And then in practice, like, the different schemes have make different choices, but, like, spelling out what those choices are and and their costs and and benefits, etcetera, etcetera, in this draft would be nice because then we won't have to spell it out again in, like, specific instantiation. So instead, I I can say in ACTs, like, here are all the in implementations of these functions, but I don't need to so right now, it spells out state management again, basically, in ACTs. It'll be the same thing for, let's say, like, v o p r f reverse flow.

[00:20:10] **Thibault**: So what you're proposing is, like, that within the draft, as we work through that, we propose kind of, like, an interface for state that, like, future draft that, like, are compliant with the reverse we could use?

[00:20:21] **Sam**: I actually don't think we need an interface. I just think we need something that says, like, you may, store, like, the fact that you tried to redeem this token before you send it out. Yep. And then if you do not have a response, you may try to send it again. And the issuer, you know, if it wants to engage with that, may store that VOPRF in its back end to, like, say, I've seen this before, and I've already reissued. Here's the exact reissuance that I gave you before so that it doesn't double mint, basically. And, like, explaining that in detail, I think, would be helpful because it'll be replicated. Okay.

[00:20:56] **Thibault**: So that might be part of, like, the replay consideration. I'm very worried about, like, saying the client might replay if, like, they don't receive a request, but that's something that, like, regarding in the replay consideration. Tommy?

[00:21:13] **Tommy Pauly**: Tommy Polyapple. So just getting to some of the discussion that was had about things having dependencies on this and adoption, etcetera. I think it yeah. I think, you know, the stuff that Sam was mentioning was good to add. But, like, in general, this is something that is pretty well understood. So I think it makes sense to I would like to see it adopted, but, like, I don't think the processing of it should take that long. Like, we shouldn't sit on it very long. Like, it's useful to say. We should just, like, do it, make sure we incorporate all the people's ideas, and then just be able to publish it quickly. So I guess as question to the chair is, like, can we get a poll in the room or some sense of an initial interest to do that, and then hopefully be able to just go quickly on it so we don't spend a lot of time?

[00:22:10] **Chairperson**: Sure. I mean, we can we can do a show of hands, for both Should we drain the queue and so that leaves you time? Oh, yeah. Yeah. Let yes. Thank you. Yeah. Let's do that first.

[00:22:24] **Thibault**: Okay. Nick Doty.

[00:22:29] **Nick Doty**: Yeah. Thanks. I I haven't read the draft closely. I'm I'm trying to catch up here, but the the client state does seem like an important detail on the privacy implications for how the client should implement this. My my my understanding is that, like, you're defining this origin issuer and token as separate from just, hey. Send some cookies back to the browser and have the browser reuse them like a session. It seems like you have a specific reason for that. You like, you have some potential privacy properties that they're unlinkable, but also some attacks where the origin could make them linkable again if they did some things with the origin issuer. So I I I guess, like, what I would would hope to see is, like, can you explain, is this something that the browser should feel safe storing even if the user tries to clear all local state, or or should they not? And and I'm not certain from skimming the draft whether that is the case, but I think it would be useful if we could decide and say so.

[00:23:35] **Thibault**: Yes. Maybe two points, like, on that. The draft doesn't try to, like, address, like, browser specifically, and this is something which is, like, out of the scope for the draft. However, I do agree that, like, having, like again, like, I take your point in, like, time constraint, like, regarding the state and, like, what that means. The privacy properties are, like, very similar to, like, privacy pass, except, like, it might be, like, a distinct issuer, and therefore, like, these would have to be taken into account. Some of them, like, are already part of the draft in, like, the privacy constraint. And if that does not completely address, like, all that, we should definitely, like, add, like, add such wording.

[00:24:16] **Nick Doty**: Thanks.

[00:24:22] **Ben**: Hi. So, actually, kind of on Nick's point, I see that the draft references the consistency draft as a possible answer for what to do with this this interesting problem of origins creating numerous issuers in order to violate the guarantees of the protocol. But, of course, the consistency draft is has long since been expired. So what is your feeling about the right solution there?

[00:25:02] **Thibault**: Yeah. I do think the consistency draft is a draft which is, like, interesting. It could be relevant here. It has not seen adoption at and by adoption, I mean, like, raw deployment for what I know. Might be because of, like, different incentives which are at play here. Again, I would, like, follow on, like, what Tommy mentioned. If, like, is something that, like, that like, it's not something which is deployed, like, today. If we can just remove it from the draft and, like, move forward, similar to, like, how privacy pass was not deployed with, like, that consistency draft even though it would would improve some of the aspects of the protocol.

[00:25:45] **Ben**: Yeah. I think it would be helpful here to, maybe pick a direction and decide is this are are we trying to go into basically a, like, very untrusted model where we need some kind of consistency enforcement, or is this really a technique that is intended to be deployed in environments that do have a sort of semi honest assumption in them, and so the consistency checking is is not part of the threat model.

[00:26:17] **Thibault**: Yep. Okay. I agree.

[00:26:19] **Ben**: Good to sort of make that decision.

[00:26:21] **Thibault**: Sure.

[00:26:28] **Sam**: I think previously, we've had deployments which are in, like, individual clients, and so the consistency hasn't been so relevant. But we need consistency across clients, And so I think consistency becomes a little more relevant if, like, as as is planned by some some of us. We wanna deploy cross browser or or cross client deployments of this. I think we should revive the consistency draft Because if you have multiple clients, then you can't just trust one of them to to do it right. And if they somehow disagree or whatever, which can happen for various reasons, then it wouldn't be great for users.

[00:27:07] **Thibault**: Chris?

[00:27:12] **Chris Wood**: Yeah. Some Ben or sorry. Nick asked what's holding up, consistency. Interested people working on it, frankly. If you're interested in it, send an email to us, contribute, whatever. I think your suggestion of removing it would also be perfectly fine. Whatever is the easiest path. We don't need to solve it now to adopt and move this document forward. Let's just please do the adoption call.

[00:27:41] **Chairperson**: Alright. So I I just wanna run a a poll here. Just a couple questions. One is, have you read the document? It should show up in this is a yeah. This is I I put up a poll, show of hands poll in the Miteko tool. And

[00:28:21] **Thibault**: for those that have not read the document, it should be rather short and rather easy to read. If it's not, definitely send comment on the list. We want that to be short and easy to read.

[00:28:34] **Chairperson**: Alright. Now I'm gonna stop the poll. We've had a good amount of people who have read the draft. Next is do you think we should adopt this draft? Alright. I think that looks also pretty good. So we have 13 yes and one no. If the person who said no would like to come to the mic to let us know why, that would be interesting. Yeah. And have you read the document? Alright. So I think we should do an adoption call on on this document, and it should be pretty quick. And then we can work on finishing it off. Any other feedback on the document or thoughts? Alright. Then let's move to let's see. I think the discussion on. Here we are. Alright.

[00:30:21] **Thibault**: Okay. It's me again. It's not my slides, want to say. This is, like, Martin Thompson that, like, did the slides. This is work from actually a lot more people than just me, and I'm just presenting on everyone's behalf. Moly. We did a site meeting yesterday about MoLE, and we've presented that work to the privacypass working group already. It was in May. We presented it as PACT, which was the private access control token, and we've defined that original problem statement on the w three c anti fraud GitHub. Right now, it's known as MoLE or Mo or however you pronounce it. I think that's something still to be figured out, but it's, like, for moderation of unlinkable endorsement. It describe the protocol that, like, we would like to conduct within the IETF. Again, all the names are just probably going to appear depending on, like, how the system gets deployed and, like, as we evolve. Does that work? Yes. So for the side meeting we had yesterday, we had, like, an agenda which where Dennis presented, like, the requirement and use cases, why I presented an architecture overview, and when where Sam walked us through, like, the feasibility and, like, the crypto side. All of these drafts have been, like, authored by us all. And after that, we went on to a discussion, which I think, like, was really productive. It's more like asking, like, actually, like, hard question that we have for this architecture, but, like, definitely moving in the right discussion and having a lot of engagement from the room. At a high level, I will pre like, reiterate what was presented yesterday in the Moly side meeting as well as what was presented to you back in May in the privacypass interim. Privacypass works with three different actors. We have the anchor that provides endorsement. It endorses the client. In this case, it's a web browser. The web browser display web pages, but it's also able to produce a proof using this endorsement against the moderator. It proves that, like, each endorsement is part of a set of anchor that the moderators trust. It does not like, the moderator does not learn which specific anchor endorsed the the browser. And then once this session is established, the browser can, like, directly communicate with the moderator in order to, like, keep the session running. So the browser holds credential, the moderator issue updates and queries for credentials. And, essentially, that's it. That's like what we had in the Moly site meeting yesterday. It's a very, very short presentation. We're hoping to, like, look if you can, like, have a transcript, and it should have happened, at least. Like, that's what the Webex interface told us. If you have any question, we have, like, three drafts, which are also up on the data tracker, both for the architecture, HTTP transport, and protocols, and we foresee that this work will, like, go and move forward. Any question? Any clarification for, like, things that are omitted here?

[00:33:32] **Chairperson**: So I guess a question kinda procedurally. What do you guys see your next steps in terms of are you gonna have a BAWF? Or, you know, is this work you're taking into the IETF and such? Yeah.

[00:33:48] **Thibault**: Yes. So at least this is what we're taking to the IETF in a way that, like, we've already used the data tracker and, like, have engaged with the community to actually, like, bring that word forward. Having the facility for having, like, signed meeting was, like, very useful. In terms of, like, the exact next step, what kind of, like, emerged yesterday, and I think David, Lelelecrypto will, like, help on that, possibly above. But I do think David, who was, like, chairing the meeting yesterday with Martin, would have, like, a bit more precise, answer on that one.

[00:34:14] **David Schinazi**: Yep. Hi. David Schinazi, cochair of the side meeting yesterday. I I think from our perspective, Martin Thompson and I, we thought things went well, and there's still plenty of open questions, plenty of work to do, but interest in this work, interest in we got a show of hands to participate, to write, review documents, all that, and a sense that this this architecture felt viable. So our current plan is we're gonna regroup with the proponents and start seeing if we can put a charter together, and we wanna have that ready well in advance of the BoF deadline for the next ITF to present it to our ADs for their pondering. And I think that's that.

[00:35:07] **Chairperson**: Okay. We I think we have Tommy's in the queue.

[00:35:15] **Tommy Pauly**: Hello. Tommy Polly, Apple. So as I mentioned, in my soapbox yesterday, I think the one place where I wanna see a strong relationship here is in terms of, like, what we have in the privacypass, like, AYANA registry and, like, the building blocks because it seems like, you know, is doing cool new things in that space that are successors, and we would like to evolve and be able to update things from, basic blind signature tokens up into these. But thinking about how that could work and just, like, speculating for folks here. Like, that doesn't require this working group to be open or do anything. Like, that's just an IANA registry. Me and Chris are the experts on it, and I I I'm very happy to, like, see that go into there. So I think, you know, one

[00:36:12] **Thibault**: could do

[00:36:13] **Tommy Pauly**: the MoLE work here and kind of revive and rebrand privacy pass, into that. It could be its own thing. It could be a lot of stuff done in w three c with some building blocks here. Are many ways to do that. And I I think just the main thing is that I like to make sure that it's still in dialogue with the building blocks in the registry, but, like, that can happen in a lot of different ways. It's still this group of people in the room who are interested. The name through which we meet can be whatever.

[00:36:45] **Thibault**: Yep. Thank you, Tommy. And, definitely, like, keeping the dialogue with, like, people in the room because, like, I do think we we know each other and can talk to each other would be very productive. Thank you.

[00:36:54] **Deb Cooley**: So so I'm Deb Cooley. I am I am your responsible AD. Just remember that you I mean, you have options here. Right? You can recharter privacy pass to incorporate this work if that makes the most sense. You can open a new working group if that makes the most sense. You don't have to have a buff. There are it is possible to charter a working group without a buff. Some sense, it's actually easier to charter a working group without a buff. Not just saying. But there needs to be community. There needs to be people interested in implementing. There needs to be an interoperability concern. There needs to be like, all of those things have to be in place. Right? Regardless of whether you do both charter or recharter, all of those things have to happen. I don't have an opinion at the moment, but this is something that the proponents need to sort of get together and figure out what you wanna do. Right? So it is up to it is up to you in some sense. I am here to surf, except I'm I don't really wanna do work for nothing. Right? So I want a working group that's, like, actually active and not sleepy. So, it's just it's that. I mean, I already have 15 working groups. Thank you very much. I don't need 16. So that's just a hint. So is that does that not is that too straightforward?

[00:38:21] **Nick Doty**: Just making it work for you. That's definitely

[00:38:24] **Deb Cooley**: A 100%. A 100%. I mean, I have enough issues. Thank you. No. No. No. And then to be fair, that's that's not that's not actually if if if it makes sense to have 16 working groups, then it makes sense to have 16 working groups. It's just be organized and be coordinated and think through all of the I want it to make sense logically. Right? So I'm here to help you if it makes sense logically. I am a mathematician. I like logic, and I like things to be. So, but you do have lot you do have choices.

[00:38:58] **Thibault**: Yeah. I do you think, like, that's something, like, we consider? And, like, again, as David mentioned, like, we'll really regroup with a participant to, like, understand what our option will be like. I I do expect interact with you and communicate in order to, like, once we, like, discuss, if we have questions, like, transfer, this is the best best forward. Absolutely.

[00:39:15] **Deb Cooley**: I mean, I'm here. Right? Yeah. I'm I'm I'm retired. I do nothing else but support the ITF. So

[00:39:21] **Thibault**: It does seem like a big joy for you. Your time. But Yeah.

[00:39:25] **Deb Cooley**: No. It's it's and it's fine. And that's what that's what you should do because that makes it easier in the long run. Right?

[00:39:31] **Chairperson**: Agree.

[00:39:33] **Deb Cooley**: Honest when I say I want this to go the the the appropriate way and to be done properly.

[00:39:39] **Thibault**: Oh, yeah. No. No. Like, I like, again, to be fair, do you think, like, we've mentioned above because of the, like, participation, because of, like, the engagement and etcetera? Maybe as we regroup, there might be, like, also pass to to consider. Like, that that's what we'll do.

[00:39:51] **Deb Cooley**: Yep. I mean, the quickest way the quickest way to do this is to recharter privacy pass because you already have a working group. There's no box. There's no nothing. Right? Just recharter the the thing. It just again, it has to make sense because I have to push the charter through. But if you wanna if a new working group makes the most sense, then so be it. Right? Yeah. And then how you get there is up to you whether you wanna direct whether you wanna do it directly, which means we have to argue how good the community is separate from a buff or whether you do it via a buff.

[00:40:20] **Thibault**: Yeah. I do think at the moment in the past, which is good. Do it by a buff to, like, like, get, like, the community engagement that goes in.

[00:40:34] **Chairperson**: Okay. Any other questions, comments on mole or molle? These are moles on the

[00:40:44] **Deb Cooley**: picture. Just

[00:40:46] **Thibault**: one sec.

[00:40:46] **Chairperson**: Yeah. And that's

[00:40:48] **Thibault**: It's not on molle, I think. Like, on the right side?

[00:40:51] **Deb Cooley**: Well, no. But it's not molle. It's

[00:40:53] **Thibault**: chocolate. Okay. Fair.

[00:40:59] **Chairperson**: It's a sauce. So it's sauce.

[00:41:01] **Sam**: Yeah. Chocolate in your mouth.

[00:41:03] **Nick Doty**: That Delicious sauce.

[00:41:04] **Thibault**: Yeah. Like, the the the the transcriber, like, was saying molle like the So

[00:41:10] **David Schinazi**: Chris Wood came up with the name, and it it's the moral of the unit of measure in chemistry, but something got lost in translation somewhere.

[00:41:25] **Chairperson**: Alright then. Alright.

[00:41:27] **Deb Cooley**: Organize that

[00:41:28] **Chairperson**: too. It's not the word for interoperability. That's fair. Okay. I think that's it. Does anybody have any other business they want to discuss today? Alright. I think we're done. Guys, get some time back. Yeah. Thanks. Thank you.

[00:42:01] **Thibault**: Next week or the 20 yep.

[00:42:04] **Chairperson**: Yeah. We'll figure it out. I mean

[00:42:06] **Thibault**: Thank you.

[00:42:07] **Chairperson**: I think there are a lot, you know, different options. You know, we can get together with David and, Yeah.

[00:42:14] **Thibault**: And I mean, that's something that we already coordinate on the opportunity to make it just even more right now to the quality of time and because we're gonna look at the calendar.

[00:42:24] **Chairperson**: Yeah. Because I think, like yeah. I think, at least from my point of view, I I don't have a particular I don't feel one way or the other. I just wanna see it move forward.

[00:42:37] **Thibault**: Yeah. Thank you. Yeah.

[00:42:39] **Chairperson**: Yeah. Thank you. Hey, Sam. Thanks for taking notes.

[00:43:22] **Sam**: It's alright. Yeah. Yeah. What?

[00:43:39] **Chairperson**: Alright. Yeah. I'm fine. I'm sure he's What's that? Real or I think it's real. But

[00:43:56] **Thibault**: It

[00:44:01] **Chairperson**: does.