**Session Date/Time:** 09 Apr 2026 18:00

Here is the verbatim transcript for the STIR working group interim meeting on July 10, 2026.

**Russ Housley:** Well, I sorted them, so I guess you didn't. 

**Ben Campbell:** I guess. No, I literally pushed the button 5 minutes ago. 

**Russ Housley:** Ah, so I beat you. 

**Ben Campbell:** You did. Not by much. 

**Russ Housley:** And it is time to begin. Actually, don't have many people here. 

**Ben Campbell:** They’re still joining. So I see Chris and Sean, Daniel, and the two of us. And two in Zulip. There's Alec. Let's give people a minute. Somebody's keyboard is very close to their mic. 

**Russ Housley:** All right, let's go ahead and get started. Looks like we're going to have a small turnout, but hopefully still productive. Ben, do we have Jon? I don't see Jon, do you? 

**Ben Campbell:** He is not here at the moment. 

**Russ Housley:** I hope he plans to join for our charter discussion at least. Well, okay. So remind everyone that this is an IETF session and so the Note Well applies. These cover your rights, your privileges, and most importantly your responsibilities for contributing. Whoever's mic is on, can you turn it off if you're not talking? There's a lot of background noise for me. Ah, thank you. And so please if you're not familiar with the Note Well, please review it. This QR code will take you to the documents if you need to look them over. Please treat each other with respect. We're here to have a good technical discussion and it's okay to disagree with each other, but there's no reason to get rude or nasty. So please keep that in mind. And the agenda on this slide is as it was posted to the mailing list. We're planning to do the trivia, which is now. And then we're going to talk about draft-ietf-stir-8588bis, then Vesper, then the Verifiable Voice Protocol, then have the charter discussion. Are there any bashes to this agenda? 

**Ben Campbell:** Russ, I would suggest we reserve 30 minutes for the charter discussion regardless of where we are in the agenda when we get there. 

**Russ Housley:** Okay, we can do that. 

**Ben Campbell:** I think we have that last because the other discussions might impact it, but it's probably the thing the ADs really want us to get done first. 

**Russ Housley:** I notice Charles here to make sure we do. All right, sure. We can make sure that we have at least 30 minutes for the charter. Any other bashes? Okay, then I'm going to put up Mary's slides. Well, I don't think you sent any, did you? 

**Mary Barnes:** I did not, no. Because, you know, it's, yeah, yeah, yeah. So basically, I mean, the changes were addressing the few points that were brought up during the working group last call. I mean, if you look at the diff, it's very minor. There is still one, I just noticed an editorial nit in there that I've got to fix. Somehow there got to be a bracket hanging out in there, so. 

**Russ Housley:** But since it had been a while, we did kind of a follow-up last call for a week and that ends, I think, Monday. 

**Mary Barnes:** Yep, yep, yep. And I'll go ahead and I'll wait until that week is up and then submit the update fix and the editorial nit, so. 

**Russ Housley:** Okay. Does anyone who's been looking at this have anything to tell Mary? Something you found? Okay, seeing no hands, we're going to move to Vesper. Do I sound okay or are you still getting noise from me? 

**Chris Wendt:** It’s way better than it was. Okay, good. Thank you. 

**Russ Housley:** And let me give you slide control. 

**Chris Wendt:** Oh, yeah. Thank you. Okay, um, so I did update a number of the drafts, but I'll, I'm just going to focus on Vesper, the concept and probably the protocol draft for this meeting. Um, there has been a number of updates since the last time. Um, we had a really good discussion at IETF 124. Um, again, took some of that feedback and made sure that um, sort of took that to the heart of what what we're doing. I simplified things a lot. Um, anyway, let me let me get into the presentation. Um, what is Vesper? Vesper is intended to be essentially a profile of how we use a lot of the STIR technologies that we've been building um, beyond the base, you know, SHAKEN implementation that focuses on um, securing telephone identity. So, take the name to heart, secure the telephone identity. Um, and um, uses, you know, certificates, delegate certificates, um, certificate policies that we've talked about or that we've documented, um, the authority tokens that we did in ACME um, to allow for tokens to authorize challenges in a in certificate issuance. Um, the short-lived certificates that we've recently been working on, um, the use of transparency that we recently adopted, um, claim constraints as part of um, I guess I should have listed Rich Call Data there as an obvious thing that we would like to cover as well, um, and finally Connected Identity and pull all those things together um, as one part of essentially a document that talks specifically about how to use those technologies together. Um, so I'll take you to those topics individually on the upcoming slides. So the certificate profile, um, it, this document is opinionated about some of those things, um, about the the subject and um, the subject alt name. Um, I'll get into that discussion why I've included that there um, in in in future slides. Uh, the TNAuthList, obviously this is meant to be a profile that focuses on using how to use TN entries um, in the certificates specifically although I do have sort of a caveat about SPC entries. I'm noticing Jon you're in the queue, sorry. I didn't notice that before. 

**Jon Peterson:** Uh, no, it's quite all right. Oh, look at that. This even works. So fancy. No, I was just going to say, I mean really to your previous slide though, it's just as I think important to come in on this one. I, you know, I think because we should be using both your discussion and the discussion that's going to follow to help us understand what the charter question really is. You know, I'm kind of interested if you could say at a high level, what is Vesper trying to do? Like, okay, they they're going to tie all these components together, but why? Because I think why is is going to define what the requirement is that we're talking about chartering here today before we get into the, here's all the things that we think we can need together with this. 

**Chris Wendt:** Yeah, that's a good point. Um, yeah, and I think to that point, um, what we're trying to do is address some of the gaps that we've seen um, in um, the trust profile of using things like attestation, um, which um, often are not trusted end-to-end, and tie closer responsibility um, of who's placing the call and who's behind the telephone number and who authorized the information associated that through some process that I think we talked about shouldn't be defined in IETF like KYC or other policies, um, but have in the protocol ways of representing those things that are that are tied back that um, are sort of globally accepted ways of doing that. Um, and um, you know, and maybe I don't need to talk to this group about all the specifics about um, what we've already covered in STIR and we can and we can move quickly to the um, discussion that's that's probably to the heart of that as part of Vesper. Um, but I'll I'll continue. Hopefully I I gave you a little more context there that that works. Um, just to finish off this slide, the SCT is part of the certificate profile that that represents transparency, um, and again the JWT claim constraints uh that we've defined in 8226 and extended with what is it? 9116 I think. Um, and this document does focus on delegate certificates in terms of making sure that there's a way to tie um, TN level certs and um, the use of delegation which um, has a great property for a lot of where calls are often, you know, um, or sorry telephone numbers are often assigned to um, enterprise entities but then they also often delegate the responsibility for those calls to third parties and and other things and all the mechanisms of of using that and revoking and that um are important. Um, I don't think I need to really go through this too much, but um, you know, we talk about as part of the spec, you know, the specifics on authentication service and verification service and the ties to the various technologies um, but um, nothing too much new there as well. So this really is sort of the new thing to highlight and have the most discussion about. Um, when we talked at the last IETF face-to-face meeting 124, uh where we had a STIR meeting, uh we did talk we did get into the topic of, you know, boiling this down to what IETF and the STIR working group specifically should be talking about and I think that is actually relevant to the updated charter discussion. Um, and that got me thinking about, you know, the last version of the spec tried to use like Glue or consider TaxIDs or other glyph for other things like that and you know those are very jurisdictionally bound identifiers um at least in practice um and um that probably isn't something we should go down the path of, at least um trying to be very prescriptive about what those things are and what they represent and and the policies associated with it. Um, but something the IETF does do um and does have um specs and and and and and there is um very widely globally used um trust uh trust trust anchor for is the web PKI and domains themselves. And so the idea here is just um use that as a mechanism to identify um the domain that is associated with um an entity um in particularly, you know, there's a there's a trust association um or a non-trust association with a particular website um for a a bank or or other institution that may want to call you. Um, there's another interesting property here as well when you talk about domain is that um the domain um can also be used in other context of tying telephone numbers. So, you know, a website may have a list of telephone numbers, um, a text message may have a URL to a domain. Um, I'm not saying we specify those things in STIR, but making those that that coupling here. And and maybe the last point and then I'll go to Jon I wanted to make is that I don't think we're being prescriptive about you know that there has to be a one-to-one association of the trust of the telephone number and the right to use the trust of the right to use that telephone number and um the domain itself, they sort of exist in their own trust anchors and their own ecosystems um but having the reference um can only um enhance that trust and enhance the tie back to that and and use mechanisms that people anecdotally do use to validate that the telephone number is associated with um um that particular entity or business. Jon, you have a comment? 

**Jon Peterson:** Yeah, one second Dan I'll just get going, yeah. So, yeah and I think for the charter discussion this this is super salient in part because I think one of the common elements that seems to be emerging, you kind of listed off some identifiers candidate identifiers before settling on domain names. There there seems to be some widespread interest in coupling a new identifier with the PaSSporT, something that isn't the orig but is something else probably that we trust because we have a different trust relationship to the issuer of that identifier at least the entity signing for it than we do for the originator of the call. And that that seems to be the if it was one single thing I'd take kind of unifies all that chatter that I've been hearing about the need to extend STIR here, it's around that. But I think it's also related to presentation and you know the and to RCD and the goals of RCD, that is of trying to create more trust in general from the recipient of communications towards towards its originator by having, you know, at a at least a belt and suspenders like approach to identifying who that person is and what kind of logos or names or whatever else whatever metadata should be associated with the originator of a call, right? And like th- th- th- those two goals I I think are distinct, one being let's find another identifier behind this, the second being let's find an alternate trust root for the presentation, but the one thing that I will say about the latter is that is exactly what I think third-party RCD was supposed to do when we defined that, right? And like if there's something that people think we need in that space that third-party RCD doesn't do as it's specified in is that 9795 or 6? I don't even remember now. Whichever one it is, like, you know that that like I'd be really interested in what that requirement is that that one doesn't satisfy. But I th- I think the thing that I want to highlight here then and we'll see if VVP proposal like backs this up is that concept that it's really figuring out a way to get some additional identifier potentially one that has some cryptographic attestation associated with it separate from the originator of the call, right, that is going to then be bound into the PaSSporT and become part of the call authentication event. And as I said unless what I'm extremely skeptical of is anything that's like let's create this separate trust relationship that is NOT connected to the event of the call and to the authentication of the call in any way and it's kind of a separate silo or something. But what I hear you saying here is consistent at least with what I thought we had coming into this, that's another identifier, you're proposing domain names, that's fine, it could be there are others we're going to discuss, I'm not sure we need to solve that beauty contest before we talk about a recharter, but another identifier we're going to wrap up in the PaSSporT that is going to tell us more about the originator of the call from a different trust source. Does anybody not think that's what we're doing? 

**Chris Wendt:** Um, fundamentally I I agree with you. I think maybe there could be discussions and maybe this is beyond the charter itself about um the whether the entity is connected to the information about the call itself or whether they're connected to the telephone number that's being signed for. Um, but I think I'm not going to disagree that, you know, boiling it down to the identifier that that ties the entity that is um trusted in in in is is is probably a good goal at least from a charter perspective. Um, Pierce, I think you're next. 

**Pierce Gorman:** Yeah, thanks. So real quick real quick before Pierce talks, uh everyone do please try to remember to use the the raised hand and and join the queue. I see Daniel is is lit up so I suspect he wants to say something but he's not in the queue. I'm not sure he knew how to join it. Daniel, there's at the bottom of your screen there is a hand button that's got a slash through it, you can use that to raise and lower your hand. 

**Pierce Gorman:** He just wanted us to see his handsome face. Um, yeah so I had a question for Jon, he used the phrase third-party RCD and I didn't quite understand he what he meant by that. And so 

**Jon Peterson:** I can tell you there is a little stanza that's in, please somebody tell me is it 7976? 9796 I mean. Um, there's a there's a a few paragraphs that outline the concept that a PaSSporT could be provided by a third-party source to provide origination information about an orig that is present in a PaSSporT but it would be differentiated from an ordinary PaSSporT because it has an iss um a dot style iss in it and that iss would indicate I mean effectively who the vetter is. Think about it like this was designed to be a plug-in to I don't know some sort of KYC or vetting ecosystem that putatively could exist, right? And so the the um concept behind third-party RCD is that there would be an entirely separate PaSSporT. Now of course we have ways like the opt um PaSSporT element of embedding PaSSports within PaSSports in such a way that say the originating service provider could take one of these and like bundle it inside a PaSSporT it's about to ship to create that that um trust relationship or at least that binding that I was talking about between um, you know, some random bit of information and like the actual event of the call. But yes that we we did define all this. I don't know anybody has ever tried to use it, but like, you know, I think the point is, you know, if we're going to have a talk about new mechanisms we need, if we have a mechanism that already seems to do what we want, probably we should just use that instead of like chartering to define a new mechanism. I think this is different than that though is the point I made precisely because there may be some alternate identifier that is involved and that would be separate from the discussion we had about third-party RCD. If it's just about presentation though I think third-party RCD should do anything that we need to do in that regard. 

**Pierce Gorman:** Okay, that that answers it really well for me, Jon. You had me at iss, you know, ISS issued. Uh, but it's just on me to go back there and refresh my memory on that. Uh, as far as like the identifier, Chris and I have had conversations about that and I'm wholly in favor of a better identifier if we can, not that a TN isn't a good identifier, it's a perfect identifier for calling somebody but um I think I'll reserve any more comments on TNs for later but I I like the idea of looking for an identifier. I I like legal entity identifiers a lot, but I know they can't be used everywhere so there's no like you said there's a beauty contest and you know what's I don't know there's just more that has to be figured out. That was it for me, I'll stop now. Thank you. 

**Chris Wendt:** Yeah and I guess I wanted to note on the iss ISS um thread of discussion that that happens to be the claim that I use it in now. I think it goes back to the question we just discussed, you know should that be at the primary PaSSporT level or should that be iss um with RCD? But I I think the concept of third-party, you know whether the third-party is actually first-party um saying that they are the one that qualified uh versus a third-party on the behalf of you know I think part of the the intent I think those ideas are compatible, but I I did want to mention that because um that was part of the thought process of of conveniently using iss which also often is represented by a domain. Um, let me see what we have here. Um oh yeah so so another interesting part of this is uh the connection with the domain is the potential of you know we have um the concept of certificate repository to make it available, um could we bring in the concept that the domain itself and the trust of the the web PKI that it's connected to the entity um and therefore they made it available um through their a domain connected um TLS protected um website um also has some trust properties that are interesting as well, um you know whether that's some specific URL, whether that's you know it would always be pointed to by the X5U um and indicated by the X5U but you know we can talk about the specifics of I don't believe I have anything in there, there's well-known, there's other mechanisms we can talk about or that can just be up to the the domain owner um themselves where to put that but um I definitely wanted to bring that up as another property that um can help tie um the domain trust into this concept. Um I do reference um this uh I I wanted to mention this. This has been discussed in various industry forums about um the fragility of um letters of authorization and how a lot of them are forged and and other things like that. So this there is a a discussion as part of the Vesper draft about an RTU token which is intended to essentially be a way of signaling the right to use um and the intended usage of LOAs um as part of um a artifact that could be created um, so just another um association of the use of the delegate certificate that indicates um all the information and can tie it to some portable form uh that can be used uh for proof of the telephone number um assignment. Um I've heard comments about this uh and feedback about this about you know what about you know it's not just maybe the business but businesses have employees or carriers have customers, you know how does the human potentially get um represented? Um and I've always been sort of cautious about going going all the way to the to the human level of identification. But I think you know there is the sort of concept that we could have indicators um um and those and because they're hosted by domains, um you know a carrier like if there was some sense of well obviously for enterprise case an enterprise can host the delegate certificates that correspond to maybe particular roles or or agents or other things and can hide those in privacy-centric ways or or very explicit ways to specific humans depending on what they want to expose. Um but also you could have the concept where a a carrier or a voice provider has um human customers that they want to represent and therefore a delegate certificate could be hosted under the domain of that service provider itself. Um so again just interesting tie to why domain might be interesting um to to sort of form those bonds um depending on what information you want to expose about the caller themselves. Um Connected Identity I think hopefully most people understand this but wanted to sort of formally use that as part of the idea um which also maybe ties back to what I just talked about, you know if you want to validate um the B2C relationship of a call that you know the a human is calling a business or a business is calling a human and they can both mutually validate each other. Um I think I don't probably hopefully don't have to um express too much the very interesting properties that Connected Identity provides but um you know just sort of want to formally bring that in as part of the framework as well. Um Again I sort of went over this so I'll just go over this quickly, you know sort of this is really building upon all the work that we've been doing over the past few years to extend STIR um to have various capabilities and and that's part of the goal of Vesper is to bring that together as a very explicit framework um that's closer tied to um individual number usage and individual telephone number trust um between caller and callee. Um and I think I'll just uh wrap it up here. So thank you for listening. Any other questions, comments? 

**Jon Peterson:** Yeah, I mean I'll just say let's I think leave it to the charter discussion probably to really you know get into what whether we think there's a pony here and if so what the you know what the requirements are that we're trying to capture in the charter. 

**Chris Wendt:** Yep, agree. Um would love any specific feedback about um some of the updates I've done, but um I I hope people would agree I I did have the goal of simplifying as much as possible but still have hooks for the tools that I think are interesting to use going forward, um and um sort of trying to simplify the idea down to a simple domain association as part of connecting it um beyond um STIR. And if there's no other comments, thank you. 

**Ben Campbell:** Chris was that your entire topic? 

**Chris Wendt:** That was my entire topic. 

**Ben Campbell:** Okay, I thought there were multiple drafts, I wasn't sure. 

**Chris Wendt:** Yeah, I decided not to um present. I mean well I can maybe give a brief statement on the others. Um I did do um some updates to keep everything consistent um with the latest Vesper draft but obviously that's the anchor draft. I have been maintaining a use case document as well. Um we haven't really specifically talked about it but um but would love to get feedback on that too if we want to discuss that more. 

**Russ Housley:** I think last time we asked people to start looking at this, we said hey but it's outside of charter which led to the charter discussion. 

**Ben Campbell:** Right, exactly. 

**Russ Housley:** Right, so um I would like to hold off the the flood of comments until after that. Sounds good. Thank you. So I guess we're up for for Daniel. Russ are you running the slides or? 

**Russ Housley:** I am, I forgot that I had to take back control from Chris in order to get him to change. Daniel you have control. 

**Daniel Hardman:** Okay, um thank you very much. Um I'm a little unfamiliar with um this uh meeting interface, so as Ben pointed out I I might be a little bit clumsy. For example, I don't know what the little color dots are next to people's names and if that signals that somebody's raised their hand. Um you might have to interrupt me. Um apologize for my clumsiness in advance. 

**Russ Housley:** So if you see on the screen there's a group of hands and my name under it. That is the queue line. The little dots have to do with roles in the IETF. 

**Daniel Hardman:** Ah, okay. Okay good. Well, um I'll try to notice that but if I'm not noticing, um I'm trying to, you know, look at chat on the left and people on the right and anyway I apologize if I'm just a little bit unskilled. Um I have not been at um a lot of IETF conversations before um but I am um I have a background in other um standards organizations particularly at W3C and ISO and I've done a little bit of work at IEEE as well. So I know some of the formalisms of consensus-driven standard development but I also apologize in advance if I don't quite know exactly how um the IETF process works. Thank you for giving me an opportunity to talk about this and um I think let me just try out my arrow here. Does it? Yes, it does. Um there's two links here that I wanted to make sure everybody had. Uh one is a link to the RFC draft that um I've already shared on the mailing list um and another is a link to a demo that you might find provides interesting context. This was a demo of VVP that was given at um the Mobile World Congress in Barcelona recently. And I'll talk a little bit about what that demo included in my slides. Um essentially what VVP is is a new PaSSporT type that has two fields in it that you probably have not seen before. Um one of them is a kid header and a kid header um is a link to the key state of the signer and as such it provides something that's a little bit like X5U. The use of kid came out of some discussions with Mike Jones who wrote the uh RFCs for um the JOSE specs um and um this was happening in the context of Decentralized Identity Foundation several years back. So it may not be totally unfamiliar if some of you have seen some of the work that has been done uh with various JOSE um contexts in Decentralized Identity Foundation, but anyway that's the kid header. Um the other header is the EVD claim, or the other field is the EVD claim, and this contains a hyperlink to something that we call a dossier and I'll explain a little bit more about what a dossier is. Um the assumption is this PaSSporT type is signed by uh something that we call the accountable party, and that term is kind of carefully chosen. What we mean by that is um who would you hold legally accountable for this call, um who would a regulator hold accountable, and we also mean who does the person who receives the call think is making the call, um and those th- there could be a delta between those and that's part of what this spec gets into a little bit. Um it could also go the other way, a callee could sign and provide a PaSSporT um and there's a discussion about that in the spec also. But um in any case what happens is that this EVD claim constitutes a reference to a long-lived dossier of evidence that's stable and that evidence can exist in many different formats. Um so you can have evidence that is a uh W3C verifiable credential, you can have evidence that is in the form factor of an X509, um you can have evidence that's in the form factor of an SD-JWT as expected by the EU identity uh mechanisms that are becoming broadly used across the EU. Um it's relatively flexible on the evidence format. And then um the idea here is that anybody can verify this. Uh the picture at the bottom shows some a diagram that I'm sure everybody in the STIR working group has seen a variant of a hundred times, um but um the couple of things to note here one is that um on the right at the bottom it says this could be done by any gateway or service provider or by the handset itself. Um the demo that we did in Barcelona had a network verifier um that was I think the tip the terminating service provider or a gateway service provider, um maybe both we demoed. But it also had a demo of verification on the handset where Google had updated their default dialer to do verification there. Um anyway the other word I wanted to call out here is the idea long after phrase on my last bullet, um that verification can be done um a year later uh a regulator or an auditor can come along and say show me your call logs and the evidence that was associated with them and I want to prove or disprove the logical proposition that at the time this call was made um the caller um you know was justifiably imputed to be X. Um so that was one of the properties we were aiming for. Um these are this is a long list of market drivers and it's kind of a busy slide with a lot of word salad on it but I'll let you glance at it for a minute and maybe um this will accumulate some uh questions. I see that Jon has his hand up so I noticed at least once the hand mechanism let me be quiet and yield the microphone. 

**Jon Peterson:** Thanks, thanks. Um can you go back to the previous slide please? So I just have one one quick question about this, um which was when you're talking about your expectation that the PaSSporT would be signed by that accountable party and it sounds like you recognize precisely how fraught that concept of who the accountable party might be uh could end up being and indeed the that might be more appropriate to have a collection of signatures in some cases. But my question was why does the PaSSporT need to be signed with that as opposed to for example the dossier being signed by the accountable party? In other words, so like so I assume the dossier in some fashion is attested by someone cryptographically and has integrity properties and everything else that are verifiable by relying parties. So is is the entity that that is th- that is signing that different from the entity you imagine signing the PaSSporT? 

**Daniel Hardman:** Well the dossier is a collection of evidence that comes from uh multiple issuers. One issuer must be the accountable party because one thing that has to be in that dossier is a statement of their own intentions and only they can sign their own intentions. So at the at the outer layer the integrity guarantees on the dossier must be derived from a signature of the assembler of the dossier which is the accountable party. But inside the dossier you can have all kinds of different evidence, you could have evidence of right to use that came from somebody uh exactly using um the token that um Chris just talked about, or something like that. Um so yes the dossier must uh be protected integrity wise and it includes at the outer layer a signature by the assembler which is the accountable party. The PaSSporT must be signed by the accountable party OR the end of the phrase here their provable delegate. So you could have uh an originating service provider sign but only if the enterprise uh said in their dossier that they are actually the service provider for that company. 

**Jon Peterson:** Yeah and I mean I I guess that is one I I would poke on. But I think this is salient again to the charter-ish questions because of because this is precisely the kind of thing we're looking at, right? Do we need to create a new PaSSporT field that is you know going to provide a point that can have the dossier in it or maybe Chris's thing in it or maybe other things people mobile wallet things that people want to stick in PaSSports too, right? Like but that point of extensibility if it has implications for the signer that's a much more fundamental change to SHAKEN, right? So in other words if the originating carrier, you know who signs in the SHAKEN context effectively everything that happens in like North American SHAKEN, right? Like if that entity is no longer eligible to sign PaSSports this is kind of a non-starter. Um and 

**Daniel Hardman:** Well they could sign the PaSSporT but they would have to have delegated authority to do so. 

**Jon Peterson:** But the way that we think about delegation in STIR also is the other way around in the sense of it's surely the carrier who owns the numbering resource that is used in the event of the call that delegates to the enterprise the credential allows them to use the number who actually identifies that the enterprise can have various kinds of presentation? It's an orthogonal question to that, they don't control a numbering resource bluntly in in nowhere in the E.164 world does an enterprise actually control a numbering resource. These are controlled by governments who delegate it to carriers who then kind of rent them on the on the slide to enterprises, right? 

**Daniel Hardman:** I I understand but the thing that you're delegating here is not delegating authority to use a number, um what you're delegating when you sign a dossier is authority to use your reputation. 

**Jon Peterson:** I got it but this all this all interfaces with STIR and with SHAKEN and with placing calls in the event of a call. I keep coming back to this event of a call thing, right? And so you know again if th- th- a delegation model that assumes that something is more primal than the event of the call is potentially orthogonal entirely to STIR, right? And like you and and that may be the outcome of this discussion, right? That this is just orthogonal entirely. But like if I I don't see why it's a requirement because like if in fact the entire dossier has a cryptographic like you know integrity wrapper from the accountable party, like then additionally requiring it to be the same wrapper around the entire PaSSporT, I'm I'm really interested what you think the attack is that that hedges against. 

**Daniel Hardman:** It it doesn't have to be the same wrapper it has to have a wrapper that has a demonstrable connection, um that is either the party that is is 

**Jon Peterson:** Well um to answer that question we'd have to get deeply into the threat model um 

**Jon Peterson:** Right, I mean I'm just literally asking what the attack is that you know this prevents against because it's real hard for me to guess what that would be. 

**Daniel Hardman:** Well um what about a malicious uh service provider that um wants to say that they're issuing traffic for enterprise X and enterprise X is their customer but doesn't want them to issue traffic doesn't want to be accountable for their bad sysadmin or something that's going around and monkeying with stuff. 

**Jon Peterson:** I mean but the corollary works the other way around. I mean if you put the enterprise in charge of this like similarly what prevents an enterprise from being the bad actor that's going to represent these things? It 

**Daniel Hardman:** Oh but nothing except the fact that it's their reputation that is being uh, you know, co-opted here, right? If they're the accountable party and they can be sued, um then uh, you know, 

**Jon Peterson:** Typically regulators by the way have the carriers be the accountable parties to regulators not the enterprises in virtually all environments I'm aware of, but but yeah, 

**Daniel Hardman:** Regulators do, but individuals who are defrauded by somebody purporting to be the bank might not uh take that route. 

**Jon Peterson:** I mean we're getting a little too deep in this probably for this this level of the conversation but I guess I just wanted to poke at that one thing of the question because that is something that I think will turn out to be material to how applicable this whole thing is to STIR is the question of ARE YOU DEPRIVING THE THE OWNERS OF NUMBERING RESOURCES FROM SIGNING PASSPORTS? And if that's like off the table unless we do something very special to require like every single telephone number to have like this contract between the enterprise and the carrier, that's going to be a really hard sell everywhere that STIR is used, in the US, in France, in Brazil, because we're requiring doing everything over again all the trust relationships over again, right? 

**Daniel Hardman:** Uh, I I think when you hear how this is actually deployed in practice you'll see that this is actually quite comfortable for the party who owns the numbering resource, but maybe not. Um that's a good topic to explore. 

**Jon Peterson:** Again, it's just enterprise need to prove, you know effectively enterprises need to issue credentials to every carrier for every numbering resource that they own which is what I think I heard you saying was the alternative to being the accountable party who signs, that's a lift. 

**Daniel Hardman:** Enterprises have to declare their intentions to use particular evidence with particular numbers. The evidence that we're talking about could include evidence from the owner of the number that they um are the owners. 

**Jon Peterson:** No, no, I'm talking about who signs the PaSSporT. If you're saying carriers can't sign the PaSSporT unless they have some special document from an enterprise, that's a heavy lift. But anyway there's a lot of people in queue so let me let me get out of the way for others. 

**Pierce Gorman:** Yeah, I think I might be next. Trying to find the camera button here so I can wave at people. Did I do it right? Yep, there we go. Uh, so on the the Mobile World Congress um demonstration which I know you're you're going to get to, uh I I assume that there was a single PaSSporT in that call and that the PaSSporT was a VVP PaSSporT. Uh, now if this had been done in the United States that should have been a VVP PaSSporT in addition to a SHAKEN PaSSporT. Yes, or you could say the VVP claims could also be included inside of a SHAKEN PaSSporT like we did for RCD but uh I'll I just don't like that so anyway. But uh I think my question for Jon would be if the VVP PaSSporT was sent separately just like an RCD PaSSporT could be sent separately and could be signed by the call originator not by the service provider but by the enterprise themselves, um does if isn't VVP kind of following that same process just with additional evidence as he as he put it? 

**Jon Peterson:** I mean if you assume um so as you're aware to my eternal chagrin um SHAKEN doesn't permit this in the United States, it's the model that I would prefer that like the enterprise is actually the signer the original signer of the call, then sure. Like, you know, again I I think they need to then have something like a delegation relationship that works the opposite way from the second bullet here where like somebody is saying it's okay for them to use these numbers, right? But like, yeah, I mean in that case it might not be distinct from a third-party RCD PaSSporT and would have the added value that you then have like the enterprise's direct attestation to it as well. So I mean there are potentially ways to do this sure that are not crazy. 

**Chris Wendt:** Yeah I was just going to make the brief comment that um the model that we have is very clear that the chain of responsibility goes from the the jurisdictionally regulated service provider that has the authority to um assign the numbers to entities and then the entities um are below that um but the service provider has the ability to revoke that um and not the other way around. Um so that's a characteristic I don't think we can move away from at least from a telephone number perspective. 

**Daniel Hardman:** So just to be clear and I think we're I um I feel like we're maybe making some assumptions here. Um you can as the telephone number owner not the not the enterprise but the the range holder the entity that really you know gives to the enterprise the ability to use this number. As that party you can prevent any traffic from um flowing through a revocation mechanism anytime you want. Um so you have a revocation button. Um but what this uh requires is uh it's kind of a it's a two-way threat model, um not a one-way threat model so the the concern that you've got is handled but there's also this other concern that may or may not be a valid one um in a STIR context. But um I've got 14 slides and I'm worried about time so let me um try to move forward a little bit and uh paint a big picture and then uh maybe we'll have time to go deep uh later. So, um I see Pierce saying dossier equals verifiable presentation for those of you who know what a verifiable presentation is that's a pretty close equivalent. Um anyway um Jon revocation button means that the dossier must contain a right to use from the carrier. Yes, that is correct. Okay so um let's these this was my list of market drivers, um these are some of the goals we were trying to accomplish. Um and uh if you haven't had time to read those I I hope that the slides are available to you later but I'm going to just go on. Um this is what has happened with VVP since we first started working on it, um reading top to bottom uh chronologically. So um I first created a draft of this back in March 2025. Uh Microsoft trialed this in a context where they were making calls in Europe to the UK uh in early 2025. The Linux Foundation and the trust over P over IP started up a task force um about dossiers late last year. Um I first brought this to this group when um Pierce mentioned it in October last year. And then this GSMA Foundry project uh was done in Q4 last year and Q1 this year and you can see some of the companies and the geos where we um were doing experiments. Microsoft is going live with this uh technique in um Europe and Asia right now and expect to be done with their initial goals for that by the end of Q2 and the GSMA has created a number of follow-on uh projects from their first Foundry thing that are going to take place for the rest of this year. Um Ben is asking VVP is the set of uh protocols tech specs and OVC is the GSMA Foundry project. That is correct. Um I don't know if GSMA is forming an FASG working group because I'm not sure um this is my own unfamiliarity with the internals of GSMA structures. I know that the Foundry project that they did late last year was one thing and that the governance stuff on the bottom of my slide is like governed and organized a little bit differently, it's not just the same Foundry project thing but anyway yeah Ben's probably answered that for so I'll go on. Um there is an intent for this to be an open thing um and um in these four bullets the second one is about the VVP spec itself and this is why I wanted to talk to this group and find out if the charter would allow this particular PaSSporT type to be um processed as a STIR working group um um item. If not maybe I need to make it an info RFC or something instead, I don't know and that's where the chartering discussion will be relevant. Um the uh structure of evidence and this is um building on a comment that Jon made about identifiers. So this slide is intending to make a kind of a fine conceptual point. The familiar model as I understand it on the left is that a PaSSporT contains uh a reference uh to a certificate in the form of the X5U header and this certificate um you know has a certificate authority's signature over uh two things basically two categories of thing. Um one category is a cryptographic identity for the the emitter uh of the PaSSporT uh and the other is a set of attributes about um that party. And um I would characterize that strategy as boiling down to what I would call administrative trust. This isn't a term I came up with but I think it's a fair term that is used in some some parts of the identity literature. Um it's the idea that um you are trusting an administrative party to make an assertion um over a bunch of data and that party's behaviors and reputation and you know whatever are the basis of your trust. Um and what this requires then is that when you rotate a key you also rotate uh the certificate. What VVP does fundamentally is it separates those two things two categories of thing that are in a certificate into two buckets. One is a cryptographic identifier and this cryptographic identifier has the properties Jon was describing but it has another key characteristic that's not obvious which is that it is self-certifying. That means you can prove its key state without asking some authority somewhere, uh including like an authority that's running a blockchain or whatever, you can prove the key state um and uh know exactly what it is uh in an entirely self-service manner. And anybody who can do the math will come to the same conclusion about what the key state is. Um and the reason that that's interesting then is because um that key state um uh it can evolve but the relationship between the identifier and its key state is stable. Uh and so you can do self-service rotations and um you also don't need any certificate authority for the left branch of this uh this uh diagram, the identity side. Um you still do need uh administrative trust on the right side to assert attributes about a particular identity but because the identity is stable you don't have to rotate uh certificates. Um you can rotate the keys but the relationship uh between the identifier and the keys can always be reproven at any time um and therefore um this takes off the table the need to set up a fabric of um any kind uh infrastructure really uh for just proving identity if the identity you're talking about is cryptographic. As soon as you get into human identifiers like business names or numbers or um uh domain names or something like that, you're over on the attribute side and there you need uh a different strategy and you need administrative trust and you need to be able to revoke things um as an external party, you need some oversight because these external parties are the ones attesting to things like it could be a government attesting to the presence of a company in a business registry or a telephone uh number authority attesting to the right to use or whatever. All of those things are over on the the right side of this equation. But when we split these there's some interesting consequences for maintainability and uh centralization and deployment. So um where is VVP targeting a problem? Um the sweet spots for VVP are all kind of implied on that market drivers slide and I won't repeat them. But I wanted to explicitly say some places where VVP is NOT trying to solve a problem. Um you can see my list there. Um we uh who have been working on VVP do not particularly consider VVP to be a good fit for the exact problem that SHAKEN has carved out. We don't think that VVP addresses device-centric proof. We don't think that it's a pure branded calling thing. All of these have good solutions already. Um uh another one near the bottom here um there was a an initiative that GSMA also explored where evidence would be dynamically negotiated. So you make a call to the bank and the bank then uses an out-of-band channel and says um I feel like asking you the following things uh right now, use your wallet to prove them to me. VVP requires you to be able to predict in advance what kind of evidence would be relevant to uh initiating the phone call. And uh so VVP isn't good for dynamic negotiation. And also I've had a couple of people say well you're not really proving who's talking, you could uh actually initiate a call and then swap in a an AI agent or whatever and I agree VVP's not doing that. Um so we're also not trying to prevent, you know, man in the middle in media streaming. It's just not um a focus. Um there's a few kind of collateral facts around VVP, um if you're asking yourself what governance might be needed or what a deploy requires or what its compliance stories are. Um I I won't belabor anything on each of these but um I'll let you go look at those and ask me questions about them if you want. But um uh this is maybe the slide I want to end on which is uh how you could get more information. Uh so there's a bunch of links to those different uh sources. Um what I would say that's not on a slide is just my ask to this group. Um in the charter language that I saw um earlier, um I saw that there were some statements that um I think might rule VVP out of scope. And that could be the right answer. But specifically I would characterize VVP as being uh an attempt to uh connect the good work of STIR to some ideas that have been coming out of the decentralized identity community uh and DPKI, decentralized public key infrastructure over the last decade or so. And so it would be awesome in my opinion if um I could use um uh VVP as a test case for can we adapt STIR to um uh a world where some of the identity uh assumptions uh come from there uh as opposed to coming just from the classic PKI. This would allow us for example to do um solutions in Europe where EUDI and EIDAS and so forth are mandating certain things about how identity is proved. Um so that that's maybe where I'll stop. Uh I see that Ben and Chris need to talk. 

**Ben Campbell:** So I just wanted to to kind of jump in and say, I think this is good fodder for the conversation we're about to have on the charter. Uh, but but also please bear in mind that, you know, when we look at the charter we're going to address what problems does this working group need to solve going into the future and what do we need to work on. So that doesn't necessarily mean, you know, it would be, okay, we need to work on VVP or we need to specifically put hooks in for VVP. It may mean that, you know, we see that there are some problems in common between the two and some ideas from this might become working group items and some may not. So just uh kind of level set where we are going into this. So I would suggest people having this discussion now think of it in terms of, you know, what problem and what works what work in VVP or otherwise that we need to think about going forward. 

**Chris Wendt:** Um I just had some comments about um you know when you brought up uh right to use in a dossier I was thinking is that like a circular reference, like, you know we're doing STIR and then we're referencing a dossier and then we're right to use back to like a Um but then in some of the further discussion, um you know, I I just can't help but think a lot of this work is about building a trust anchor for identity um more generally that STIR like it's almost to me like STIR should be an input into that rather than the other way around. Um just curious what your thoughts are on that. 

**Daniel Hardman:** Well, um you know, uh the connection that goes off in my brain when you say that Chris is uh to the VCON stuff that I know you've been working on. Uh STIR is an input to VCON. Um VVP would be a STIR uh input to VCON. But whether it's VVP or Vesper or SHAKEN or anything else, BCD and RCD, all of those are inputs to um this other thing, which is a verifiable record of how people have interacted uh in a conversation context. Uh I don't think that um so identity at its deepest level means sameness. And um what we hold stable as being the same across contexts will vary according to what context we consider important. Um in the context of uh regulatory compliance, the deepest uh form of sameness has to do with legal identity I think. Um and internet identity, domain names and so forth are derivative of that legal identity and not the other way around. Um but if you're talking about telco as the governing context then I think it's certainly true that uh you have a different uh assumption about what constitutes sameness. We ran into this with uh the Microsoft trial because Microsoft is a giant global conglomerate um and all of the different legal entities in different countries have the ability to use microsoft.com as their domain name. But they're not the same legal company and um, you know, when you bring a lawsuit you have to identify which company you're talking to and there's certain kinds of reputational impacts that flow out of legal and regulatory compliance stuff that that rest at the legal identity level. 

**Jon Peterson:** I think Jon is still in the queue I'm not doing good at calling that out, sorry. No, no, no, so I mean I think we are starting to ask some of the right questions. Now I was just actually following uh the references that you had on your last slide, um which I know you put up before in looking in particular at the comparison between VVP and RCD. And I think, you know, these are the things that from a requirements perspective get interesting for me. Um you know one thing you brought up a couple of times that's also mentioned in that slide is for example that um these transactions can be verifiable long after the fact, which was kind of an anti-requirement of STIR, actually. Um we very intentionally designed it so that these PaSSports would be um that they would expire and that they, you know, we built all this kind of replay protection and things like that um based around the concept that there would be no need ever to verify these because their only salience was while a call was being placed, right? Um and I mean that's a very different requirement than we had for STIR. If people need that, if that's something that people who are looking at the STIR ecosystem are saying like this is a big problem, then definitely we should talk about that. I haven't heard that personally by the way, that there is a need to forensically be able to prove these things long after the fact, and I talk to a lot of law enforcement, anti-fraud and things like that in the Europe and in the US. and it's not one I've heard yet. So if there's a requirement for that I'm kind of interested in delving into that a bit. But more fundamentally, yeah, I mean looking at what that comparison slide shows, you know, what I'm seeing and again is a commonality across at least the two proposals we've discussed here today and as well other stuff that I'm aware of in like the mobile wallet space and whatever is this idea that there should be a better way of describing the legal entity that, you know, either is calling you or that you're calling, I think Connected Identity is a component of this and no solution of this should lack for Connected Identity, and that there should be a way to capture that in a PaSSporT. It may be as simple as having a code point that is just going to indicate here's some external resource you can look at. In fact, we could offer a menu of them because it could be that in some jurisdictions, like, you know, people will think precisely what VVP is offering is what they need to be able to trust who the originating enterprise is and it could be different in other jurisdictions. And so to truly internationalize this you might need to provide alternatives. And like, you know, if if this is indeed a requirement that we want to delve into in the charter discussion, like, I mean I'm at least seeing enough commonality that I think I can start and it's not going to look I think super different from what you had on your first slides, right? Like that sounds about right to me for, you know, there's going to be a couple code points, they're going to point to like whatever information you need to validate wh- what this is that uh you're pointing to externally and then like whatever the content of that wrapper object is. Um, you know again the places where we may get into, you know, hotter water are around more fundamental changes to the modality of the trust model, you know, because we do assume in STIR that the basic trust model is that an originator of communications is authenticating the event of a call and things like RCD were generated to give us ancillary information. Putting that into third-party RCD as as Pierce was suggesting earlier, like definitely I I I could see a path to doing that. Um and to having that be the only place that these new code points might appear doesn't seem architecturally crazy to me. Um so, you know, again I think this is helpful but I guess the reality I'm saying is looking looking at the comparison slide, yeah I think we can go down those requirements and kind of see ARE THESE THINGS FIRST OF ALL THAT STIR WANTS TO TAKE ON AND THAT IT'S APPROPRIATE FOR STIR TO TAKE ON? And then I think, you know, we can identify enough elements of commonality to be able to say here's work we could charter concrete work to go explore doing like this. 

**Chris Wendt:** Yeah, I really like that point Jon. Um because, you know, since the beginning um and maybe that's why talking about a recharter is very timely is from the beginning we th- the the resistance was mostly about like IT WAS A DAUNTING TASK TO SAY THAT EVERY TELEPHONE NUMBER HAD TO HAVE A CERTIFICATE um from the start. And that's the th- that's why SHAKEN and attestation came because it was and I and I remember saying these words exactly that like let's take a crawl walk run approach. We need to get the protocol on the network first. We need this sort of shortcut of attestation to get us over the hump where we as the telecom industry can learn how to like a lot of people in telecom industry didn't know what certificates or digital signatures were and like how do you go from from that point? So I do like that point of saying and you know I I actually made that point in my Vesper presentation that we have a lot of the tools here, um we're only trying to get back to like okay now that STIR is in the network, what is the next step to getting to the trust that you were just talking about Jon where we we do have the tools to tie these things to more specific identifiers and and things like that. and and I would wholeheartedly agree to, you know, change this text to be more in that spirit uh if if the working group agrees to that. 

**Ben Campbell:** I just wanted to jump into the audio to say what Russ just said in the chat, we've got 20 minutes left and there's more charter text to talk about. And I also want us to think about uh how do we get from this discussion to real charter text? Um so what our next step should be and and how we how we go through the process of jointly editing this proposal or whatever text we come up with. 

**Chris Wendt:** Yeah, I was going to ask that question what the general process is if we do that over email or if we interactively, I've seen both I guess so. Um or put up a Git is what Jon is suggesting also. Ben says plus one to that. Um would you like me to create a Git? Or do we we don't have an official STIR Git do we? Should we create that? We can ask the uh IESG and secretariat to set up a STIR working group Git up. That probably is a better path forward. Okay. Uh I think Pierce had his hand up. 

**Pierce Gorman:** I actually don't like bouncing back and forth between IETF uh email distribution and GitHub. But uh I think it's because I don't really know what I'm doing with the GitHub stuff. Is is it anything different than an email distribution just not on the IETF email? What gets done on the GitHub that makes it a better way to have a conversation? 

**Jon Peterson:** It’s like just a way that you can jointly communally edit a document. Think about it like having like, you know, if you've got SharePoint or like Google Docs or something and you're just editing jointly on it, it's just there's a little bit more centralization of when you accept changes from people. 

**Chris Wendt:** Yeah, I think generally there's two mechanisms. There's issues and pull requests. Pull request is you want to propose a specific change, issue is you want to discuss or ask for changes. Um and those are sort of the mechanisms that DO WE NEED A GITHUB TUTORIAL? I think I think there is some I think IETF has some tutorials if I'm not mistaken. Is that correct? Can anybody confirm that? 

**Russ Housley:** We can help, let's get to the charter text. 

**Chris Wendt:** Yes, sorry. So I put the the scope of work here. Um I'll let people read that. It does talk about extensions that enable OH JON DID YOU WANT TO SAY SOMETHING? 

**Jon Peterson:** Oh I was just going to say I really I really like the first one, yes, as I think I said on the list. Um I think defining whatever that protocol extension is sounds sounds handy to me. Um I mean that it then supports a cascading set of things that we already do like out of band and, you know, like uh other contexts like multimodal or messaging um I'm not sure those are necessarily part of the effort we've been discussing to date um but like sure it's it's you know I don't think we're going to need to change anything from what we're already doing to accomplish those two things. Um in terms of transparency like I guess we need it for this I mean I guess but we already have a document so let's have a charter that has that as a deliverable, that's fine. Um I think it's kind of orthogonal to a lot of what we've discussed though. 

**Chris Wendt:** Yeah that would be my intent since we have that as a document even though I'm not a big advocate of it. Um yeah I I I agree with the sentiment there like there's a there's a elephant in the room topic that we that we should make sure is the primary thing here but um we don't want to lose some of the scope that I I don't know what the proper thing is. ARE WE IS THE CHARTER BECOME ONLY FUTURE WORK OR DOES IT ALSO ENCAPSULATE THE CONTEXT OF WHAT THE WORKING GROUP HAS DONE? 

**Jon Peterson:** Well I mean in so far as it's the scope of work, I think it's encapsulating future work in this instance. 

**Chris Wendt:** Right. Um and that that'll that'll come down to deliverables. DOES DOES SOMEBODY ELSE OTHER THAN ME WONDER DOES ANYBODY ELSE OTHER THAN ME WONDER IF WE NEED LIKE A REQUIREMENTS PROCESS BEFORE WE DO THIS? Um I don't know. Maybe we don't but um I just maybe we don't I don't know if we do but 

**Chris Wendt:** Yeah, I mean like there's a timing aspect here too, like we don't want to talk about this forever. Um I I would hope we don't, especially if the answer is um fairly straightforward in terms of figuring out where the identifier is. Um and we're a pretty small group as well. 

**Mary Barnes:** Well I was just going to say, I mean at least at you know the documents that you're going to put together at least maybe have a requirement section up front, right? To set the context, right? Problem statement, right? 

**Chris Wendt:** Right. Ben is saying this is a requirements process, so I would agree with that. I think I think this discussion was actually very good like and and gives better context to take this draft and and craft it better. The last slide is just some of the out of scope items. Um and that was sort of based on what we discussed in the last um the last face-to-face meeting. Um but I think the bulk of it is probably here that we I feel like we talked a lot about a lot of good issues maybe it's um more about um establishing the text that we can all contribute to um given the context but I don't know if there's any other comments but I'm I'm done. 

**Jon Peterson:** Yeah I think I think wordsmithing we all acknowledge is required to make sure that we're not cutting anything else out that we don't want to cut out and uh but that wordsmithing is best not done on a call like this so. 

**Chris Wendt:** Right. 

**Ben Campbell:** So I see that Russ is uh out of band uh looking at getting the getting us a uh GitHub set up. So what I would propose then is maybe those people that have uh ideas here, which sounds like a small number of the here, might uh talk to come up with a uh next version of this that becomes the root that goes into the GitHub. Uh 

**Chris Wendt:** Yep. I'm well once it's set up I can put the current version and then we can go from there. 

**Ben Campbell:** That works too. Okay. I I would like to make sure that we're not having this discussion again at uh uh Vienna, or at least we're down the line we're not talking looking at the same text in Vienna. 

**Chris Wendt:** Yeah, I think we can agree to be interactive on the list and 

**Jon Peterson:** Yeah, but per per uh pro- pro- per uh pro-con, you know definitely we want to have um a meeting where people are going to talk about this at an official IETF capacity let's not have virtual BOFs, right? Let's not treat this like this was a virtual BOF or, you know, look at this as a as a consensus result. Um let's get let's get the charter together to get in front of some people and then we'll get some like real-time consensus in Vienna. 

**Chris Wendt:** Right. I think maybe Ben I would translate Ben's comment as let's try to see if we can get something that's pretty close going into Vienna. 

**Ben Campbell:** Right. I wasn't trying to say that we need to close this before Vienna, I just want to be further along than we are now before Vienna. 

**Chris Wendt:** Right. 

**Russ Housley:** Jon says yes. 

**Chris Wendt:** Okay. All right. I don't know if there's any other comments but I'm done. Thank you. 

**Jon Peterson:** Chairs do you want to ask DOES ANYBODY THINK THIS IS A TERRIBLE IDEA? DOES ANYBODY THINK THAT WE'RE GOING DOWN THE WRONG PATH? EVERYBODY HERE THINK THIS IS RELATIVELY COOL? I DON'T KNOW. 

**Pierce Gorman:** WELL I WAS DOES ANYONE THINK WE SHOULD CLOSE THE WORKING GROUP? 

**Russ Housley:** YEAH THAT'S THE ALTERNATIVE, RIGHT? SO I DIDN'T HEAR ANYONE SAY JUST STOP. SO UM OTHERWISE I WOULDN'T HAVE SET UP THE GITHUB, RIGHT? FOR FOR THE DISCUSSION TO CONTINUE OR THE WORDSMITHING TO REALLY TAKE HOLD. UM SO LET'S LET'S PLAN ON THAT ON THE NEXT STEP, WE'LL WE'LL SEND AN EMAIL TO THE TO THE LIST TELLING YOU WHERE IT IS SO THAT YOU CAN ALL CONTRIBUTE. UH IF YOU DON'T HAVE A GITHUB UH ACCOUNT YET YOU CAN SET THAT UP IN THE MEANTIME. I ACTUALLY DO HAVE AN ACCOUNT I JUST DON'T REALLY USE IT. OKAY. WELL, SO THAT BRINGS US TO THE ANY OTHER BUSINESS PART OF THE AGENDA. IS THERE ANY? HEARING NONE, WE'RE GOING TO GIVE YOU 9 MINUTES BACK. ALL RIGHT. TAKE CARE. WE'LL SEE YOU IN VIENNA. THANKS EVERYONE. TAKE CARE. GREAT, THANKS ALL.