**Session Date/Time:** 21 Jul 2026 07:00

[00:00:16] **Russ Housley**: Okay. We're gonna go ahead and get started. Could somebody pull the door at the back, please? K. Welcome to the STIR session at IETF one twenty six. This is the note well. Please read this before you contribute. This tells you what your rights, privileges, and responsibilities

[00:00:45] **John Peterson**: are.

[00:00:47] **Russ Housley**: Please make sure, especially the IPR related rules and the behavior related rules are followed here. Please treat each other well. Be nice. It's okay to disagree with an idea, but that doesn't mean you need to attack the person that offered the idea. Please make sure that you have logged in to Meetecho. If you're here, you mostly want to use the on-site tool. If you're remote, you want to use the the full service tool. And this is the way we will get attendance. Since we were last together, two RFCs have been published, and we have one document. The OCSP related document is in the RC editors queue. We have three documents now with the IESG, so, hopefully, they will be progressing steadily. Please, especially the authors, be watching out for last call comments and area director comments. This is the agenda today. This was sent to the mail list a good while ago. The first thing we'll do is discuss the charter, and then the second thing we'll do is discuss Vesper. Yeah. Go ahead. I am the one who started the tab about that. Oh. He texted me. So those are the two tasks we have before us today. Are there any agenda bashes? Okay. So, Chris, would you come on up and lead us through the Charter version three?

[00:03:44] **Chris Wendt**: I guess I didn't create any slides for that. Do you wanna Should we Okay. Let me share the Let

[00:03:52] **Russ Housley**: me find the URL. Yeah.

[00:04:05] **Chris Wendt**: So maybe to catch people up that haven't been paying attention, we discussed rechartering actually for maybe two meetings before, but we actually started that work with proposed texts after the last meeting, the interim, I guess, it was. And the general notion of it was the major discussion points on the list was about identifying the entity behind the call. And there was various discussions on different approaches and things like that. But there was rebote pretty robust discussion over that topic. There's also a few other notes that maybe didn't matter since the transparency documents already in last call. So but it does note that and a few other items that maybe once we have the text up there, can remember. But but the major point to talk about was whether we adopt something that represents the the entity behind the call as in some form. We had also a pretty robust discussion about whether we want to include in the charter the ability to extend STIR to other trust anchors and other mechanisms beyond beyond the eighty two twenty six certificates. And I think the consensus on the list, at least from my point of view, was that that was a step too far for now. Although we could consider that in the future, or that could be taken up more generally in the ITF. And and we had a addition to the the do not part of the scope of the working group to to not consider that at the moment. Hopefully, I gave a pretty good overview of what the discussion was on the list.

[00:06:31] **Russ Housley**: So what I'm gonna do is put the link into the chat because I can't seem to figure out how to share the content of it. But it's in the data tracker at this point.

[00:06:48] **Chris Wendt**: Yep. I think John has a comment. Go ahead.

[00:06:51] **John Peterson**: I was just gonna say because we're still waiting and, you know, might as well not just just be you standing there rambling. I can ramble as well if you'd like. Yeah. I think that's a fair fair assessment of what the discussion was. And, I mean, the the thing the the landmine that I was afraid we were stepping on, right, is when we started talking about, you know, we're not we're we're gonna stick to our dogmas of, like, RFC eighty two twenty six and, like, the only trust anchor for this can be, you know, the traditional trust trust anchor that we've defined. You know, I think there's frankly room for alternative trust models provided they aren't about first party authentication of, like, who the caller is. And I think that's now captured in your out of scope pretty well. I mean, you know, I mean, you endlessly bikeshed these things. I mean, I think it's very important that we tie it to the authority model rather than any specific syntax that we've defined in the ITF. Right now, it's it is pretty much still RFC 8226. That's fine. And it's not like I have some burning interest in developing alternatives to that.

[00:07:57] **Chris Wendt**: Mhmm.

[00:07:57] **John Peterson**: But the the thing that we actually wanna preserve isn't the syntax. Right? The thing we wanna preserve is the idea that somebody who actually has some relationship to the call processing machinery that determines, like, how calls get routed and, you know, who subscribers are and so on, is on the hook to be attesting for, like, the number that a call originates from. And if we get to we can do delegation and things like that so that, you know, that that power can be assigned to appropriate other entities. You know, what I what I think is a bridge too far is to say, you know, let's just let, like, anybody attest that it's okay that I'm making a call from this number. Right. And, like, you know, unfortunately, I think there were some proposals that were dancing close to that line. And that's what we wanna avoid. As long as that is ruled out, I think we're okay. I'm trying to give you as much time here as possible for us to get this text up so I can keep elaborating this if you'd like before we look at it. But, yeah, I think that that was the landmine that I I think we avoided. And, you know, I think, mister Berger actually had some helpful comments as well about the jurisdictional elements that are also in the out of scope of this, that hopefully will blissfully stay there. Because I think a lot of the problem with the discussion we were having on the list was this notion that, oh, if you can just, like, totally decouple, who's making the assertion from any administrative authority that's beholden to any regulator or jurisdiction or framework like that, that'll be great. Then suddenly cross border everything will just work. And it won't. Right? Because it is precisely those jurisdictional constraints that make these first party assertions about the uses of numbers and so on trustworthy. It's what relying parties need to be able to figure out who is calling them. And if we, you know, decouple those things to the point where, you know, that that first party authorization token is no longer the primary thing you were parsing to figure out if this originating identity is okay or not, then we've gone too far with this. I'm also not sure, Russ, how much longer I can just kind of ramble about this.

[00:10:02] **Russ Housley**: I think people have the text in front of them now. Okay. Okay.

[00:10:07] **John Peterson**: So, yeah, I I I think it's basically basically fine.

[00:10:09] **Mike Ounsworth**: Mhmm. Yeah.

[00:10:18] **Chris Wendt**: I think Meetecho.

[00:10:20] **Russ Housley**: Join Meetecho for the blue sheets.

[00:10:26] **John Peterson**: Yeah.

[00:10:29] **Chris Wendt**: Yeah. I think we actually did have a good discussion about that, and that is an important principle to be very clear about. And I agree with John on on all the points that that is critical when we talk about telephone numbers. So that is property that I feel like we need to preserve in in this group, at least.

[00:10:54] **Russ Housley**: So So does anyone have concerns with the text in the charter? I hope not because we sent it to Charles already.

[00:11:03] **John Peterson**: No. The the text is

[00:11:04] **Russ Housley**: good. Okay.

[00:11:06] **John Peterson**: I was gonna say it's not just telephone numbers. So, know, there are lots of other rented rented, I think, believe is the term of currency here, identifiers, including anything with an at sign in the middle of it that's owned by domain, and that domain determines who gets to be John and who gets to be Chris. Right? Like, any it doesn't matter what the identifier is. There there is some authority that ascertains for these things who owns it and why. And if that isn't the party that's attesting, that's okay for you to use this as identifier, you're probably not approaching STIR the right way.

[00:11:34] **Chris Wendt**: Yes. Very good point. But you're implying, just to be clear, that SIP URIs also need to be governed similarly when used in the telephone networks that we're talking about. Yeah.

[00:11:51] **John Peterson**: You know, if some random person decides it's okay to use john.Peterson@Gmail.com as, you know, their SIP address, and it's not Gmail dot com that's making that that decision, I might have a problem with that. Right. Right?

[00:12:11] **Russ Housley**: They're not gonna get a token for it. Okay. I'm hearing

[00:12:19] **John Peterson**: keep discussing this. There are things to discuss along slides. But

[00:12:24] **Russ Housley**: Not the charter tax. Right. I'm hearing we're all good with that. Okay. Charles, you need anything else from us?

[00:12:32] **Charles Eckel**: No.

[00:12:32] **Eric Burger**: Great. Alright.

[00:12:34] **Russ Housley**: Awesome. Alright. So now we're gonna move on to the Vesper part of the agenda.

[00:12:51] **Chris Wendt**: Yes. So, Vesper, we've been talking about this for a little while. You can probably go to the next slide. Yep. So as you might recall, if you've been playing along with this journey, This this journey sort of started in a a very exploratory space as a

[00:13:22] **Russ Housley**: I wanna know how your kid got the spaghetti on the wall with none on his face.

[00:13:29] **Chris Wendt**: Yeah. I'm pretty sure that's a Microsoft PowerPoint clip art, which I love that picture. And it's perfect for the discussion. But so there was, know, and I sort of admitted this a while back, there was a lot of spaghetti that was thrown on the wall initially in some of the drafts. And I think it was actually a good exercise to to sort of explore that space, or at least it was educational for myself to think about some of the other concepts being discussed and talk about wallets and selective disclosure and other things that may have a future. But as we have discussed over the past meetings and and and interims, I think we're definitely settling in in a good place for and and a clearer vision of what I think ended up being I I I guess I'm I'm starting to call it now a profile. Essentially, like, we have a bunch of great tools that we've built in STIRR. But I think it would be good to have sort of a profile that says, you know, a a definitive way that the industry can take this and go forward and have a set of guidelines of, you know, how to bring those things together in a in a in a good single document. And then round out the edges with some of the topics that we've talked about recently, like making sure that the the trust model extends to the responsible party that behind the call and and other things like that. So I'm I'm gonna talk more about that as we go through the slides, but but I think that's where we are. So where Vesper where the Vesper draft itself, Vesper eight has ended up is essentially mostly references to other normative references in STIRR and other things with only a few genuinely new normative items. One being, I mentioned there, a portable RTU token. So that's the one thing that's probably net new other than the references to the existing tools and and some of the description of how those things are pulled together, maybe more informative view of things. The other thing that we ended up with is and maybe the way it should be, is that everything now has a way to be encapsulated in the certificate the delegate certificate itself. So the TN auth list, the entity identifier, the transparency, and and all of those things. And again, I'm gonna go through that. So we've been a you know, I I include this just to sort of, like, look back. I mean, we're talking about the charter and and other things, and I think it's sort of an interesting thing to to think back to. But we did start this journey, like, with certificates per TN. But then we realized that, you know, in order to get initial adoption, we needed this service provider level thing that turned out it turned into Shaken and getting adoption and and and signing at the carrier level, which I think is actually a really good thing for the for differentiating telephone network authentication versus user level authentication at the telephone number level. And and the difference between those are important and and relevant to the trust problem. We added a diversion was another thing that we did early on. Delegate certificates, shortlist certificates, connected identity, rich call data, certificate transparency. Those are all the tools that we had previously done before the recharter. And now we're talking about the entity association. And like I said, like being explicit about not having a network level authentication versus user level authentication. So we're just enumerating here all the tools that Vesper references in its current form. There's a new draft that I created that I'm gonna talk a little bit more about, which is this TN by domain binding mechanism. I'm I'm gonna defer that conversation to the next slide. There's also TN attributes. So this is something that I think is another thing to consider about attributes that you self declare. There's no authority token needed for these because these are just attributes that are informative for what what you want to say about your telephone number specifically. So I'll talk more about that one as well. Certificate transparency, we've obviously discussed, so I don't need to go into that in-depth. And then delegate certificates is is obviously the base level for what Vesper talks about, TN specifically. Although to John's point, you know, there's no reason it couldn't be as well. We have our Acme authority tokens with TN auth list. JWT claim constraints is also in working group last call in Acme. So that will round out at least the eighty two twenty six related parts of things that should be authorized before being baked into the certificates. And then connected identity is an interesting adjunct technology for doing STIR in the backwards direction as well. So wanted to have some text around how to compose that into the the usage in general. Okay. So the version of entity identification that I've settled on. And we've had a lot of great discussions around this topic as well in the past. A lot of the industry discussion has been about KYC. How do you do that? Can we standardize how you do KYC? How can we standardize how you represent it? I think the realization that I had coming out of, I think, the last in person STR meeting that we had. We had a great discussion about do we do things related to policy and IETF and and other things? And and the answer to that is is a definite no. And I think KYC is really like a if you perform KYC as a company, you have your own way of doing that. You have your own level of depth that you go to for that. It's just a hard concept to, like, standardize and then make make that trust that you've determined through your KYC process transitive across a network through a protocol, things like that. But the one place the ITF has done a good job at figuring out that equation, ITF and others, is in the domain world where we do seem to have a a good level of trust in determining the responsible party behind the domain and associating that and using that as a second trust anchor. And as we've talked about with CPRIs, but even beyond that, in general, for email communications, the web URLs that might be included in text messages, there's an interesting property of being able to bind a TN to a domain that's behind the entity that's responsible for the the telephone number. So that's sort of the the background on why this exists. But domain validation domain control validation is also a fair a straightforward process and very well, you know, implemented. There's a spec in Acme for it. So I thought it just made sense to tie those things in. So the idea actually at the end of the day becomes very basic. Include a u a domain URL in the certificate. I'm trying to remember what

[00:23:44] **Russ Housley**: Subject alt name.

[00:23:45] **Chris Wendt**: Subject alt name. Thank you. And use the process of validation. So prove your domain control through mechanisms we've already defined. And I've listed the ACME one, but there's others. And then use the TN auth list authority token to validate the TN. This is the procedures for the CA to do to validate at issuance of the certificate. And then bind those together with the delegate certificate that includes both and essentially has both, you know, codified. And then that process, you know, using short lived can happen periodically and as as needed when the right to use needs to be determined or the association to the domain needs to be determined and the entity behind it. So that's the basic idea. I see John's in line.

[00:24:47] **John Peterson**: Yeah. I mean, really, I'm just in line, I think, to contextualize a little bit. Like, what what we're doing here is we're talking about Vesper and talking about it after the charter discussion we just had Yes. In the sense of, you know so this this is a concrete proposal for a way to address the things that are being described in the charter. Correct. And it does so in a very particular way through this in this binding, think it's got the linchpin of Chris's proposal here because it is providing that property I was complaining about earlier. Right. You know, what we don't want is to have a whole set of people who are saying, hey. I've got these claims about enterprises, and, you know, they've been vetted, and and that information is great. But if it's not bound in some way, right, to credentials that prove that this actual call event is, you know, authorized to exist by something like TN auth list or, you know, whoever whoever we're gonna we're gonna frame that, then, you know, we then I think we've gone in the weeds. So solutions that have this general form, I think, are, like, solutions in the right direction to satisfy what I see as the bullets in the charter. You know, I I think to the room here as we're looking at these proposals, I mean, I what I'm always running in the back of my head is, you know, so is this baked? Do we think this is the right direction for the entire effort? Do we think there should be an access of extensibility here that allows other possibilities than the domain name approach to this? And this is what, for example, the the whole was it OVC and VVP, right, that Dan was talking about. Like, they they are effectively a counter proposal to at least that component of this. Right. And so so going down a solution path like this creates a very tight binding between those things that, again, reuses a lot of technology we're very familiar with, which I very much approve of. And I'm sure Russ, you know, is very gladdened to see, let's just continue the cert approach for this. It works so well for WebPKI. We understand how to do extended validation. We understand how to do vetting and these kinds of things for those those certs and those instruments. So it is an extremely promising direction. You know, my question is just And this is great for framing what the work is gonna be if this recharter goes through. Mhmm. But this is a concrete proposal that that's tackling this in a very particular way. Right. And, you know, I I don't know if I personally am ready to close the door in every other way quite yet. Yep. But I think this provides all the properties that we need.

[00:27:03] **Chris Wendt**: So and and and actually, that's the reason why I made it a specific separate draft to just consider it another tool that doesn't preclude necessarily that other proposals can't be out there or other drafts can't be out there that detail other ways of doing it. I tie it into Vesper because I think, you know, just like shaking, that there probably is gonna be one direction the industry goes, like, from from a how do we do this point of view. But I'm open to certainly having other ways of doing entity identification, like you said, and I'm I'm not trying to shut the door on those things. So so that's why I made it a separate draft so that it could be a STIR tool that you can use as part of, you know, all the other tools that are that are sort of optional as well. But I do sort of use this as one of the fundamental things, at least for the Vesper profile that I'm defining in in the Vesper draft.

[00:28:07] **Russ Housley**: Brian, would you go ahead? Brian, if you're talking, you're muted.

[00:28:19] **Ryan**: No. I'm I'm here.

[00:28:21] **Russ Housley**: Come to the mic. You raised your hand.

[00:28:30] **Ryan**: I just want to I mean,

[00:28:31] **Mike Ounsworth**: let me come to the mic. Hello?

[00:28:34] **Ryan**: Yeah. Hi. Ryan here. I'm from Ghana. I just wanted to ask for I I took out some notes. I just wanted to ask one question. I didn't I wasn't yet in the beginning. Mhmm. But I just wanted to ask maybe if you've covered this already. So for for this, you might have mentioned it, but what are the practical barriers for deploying this? If, for example, outside North America, what are the practical barriers? Because in my country, I do not particularly know. But in case you you might mention a few barriers that you might have faced or might think of, I do not have to ask that.

[00:29:11] **Chris Wendt**: Yeah. So that's a very big topic. And I I think, you know, maybe we could address that here, but we could also talk afterwards and have a discussion or maybe at the end. In ITF, we define STIR, and a lot of the adoption is really more at the in in the domain of the country itself and the regulatory process to adopt. There we have a robust robust set of standards in ITF, in STIRR. Addus has built a whole profile that The US has adopted with Shaken. So I would definitely look at that Okay. As well. Other countries are adopting it. France has their version of Shaken. There's other countries potentially adopting it as well. There's other efforts around those things. But the main part that probably I would I would point you to is building the PKI around how you govern the certificates and and all the things that sort of surround the details that we're talking here. But, yeah, I if if you don't mind, I think that'd be maybe a good topic. Maybe at the end of this session also, we could talk a little bit more if there's time as well.

[00:30:43] **Russ Housley**: Okay. Yeah.

[00:30:45] **Chris Wendt**: Right. Exactly. Okay. But there yeah. There's a lot of good forums for that too. I don't There'd

[00:30:51] **Russ Housley**: be one in the room.

[00:30:53] **Ryan**: Yeah. Okay. I'll just like to ask two more questions tied to each other.

[00:30:58] **Chris Wendt**: Sure.

[00:30:58] **Ryan**: Then I can get off the mic. No worries. So one so you mentioned the the adoption of the adoption by regulators. So I I was just asking, so what role should regulators play, basically, in the caller authentication adoption, just the aspect? So as you mentioned, we'll discuss with other regulators.

[00:31:20] **Chris Wendt**: Mhmm.

[00:31:21] **Ryan**: And then from your perspective, what are then some lessons that's oh, what is that I can't see? My eyes. Okay. So what are some lessons that countries with same registration that they already exist but still experience caller ID spoofing still occurs? Like, what's from your experience or lessons that countries like this have adopted this system to help with that?

[00:31:49] **Chris Wendt**: Yeah. Yeah. So I think the the regulatory connection is generally through your country's number plan. So each country has a country code. You have a set of numbers that you have rules around how the numbers are allocated and assigned within that country code. And that is directly related to how we tie telephone numbers to the certificates that we're talking about in STIRR as well as the rules around how service providers can use those telephone numbers and route calls, all the things that John mentioned before. Okay. So the regulator really creates the rules around how you adopt a call authentication plan within the country and those types of things. Your second question was and I see Eric

[00:32:46] **Russ Housley**: set up how the trust anchors are managed.

[00:32:49] **Chris Wendt**: Exactly. Yeah. The trust anchors, the how how the certificate authorities are and the certificate policy associated with what certificate authorities follow.

[00:32:58] **John Peterson**: We

[00:33:00] **Chris Wendt**: have general guidelines, and and some countries have already gone through that process, and you're certainly probably welcome to have conversations with other regulators that have gone through that process. But but yeah. We have all the general framework. It's more just deciding how that maps to your country's regulations and rules for telephone number usage.

[00:33:24] **Ryan**: Okay. Thank you. I I don't know

[00:33:25] **Chris Wendt**: if, Eric, you had a comment. Maybe you can help as well.

[00:33:29] **Eric Burger**: Yeah. As as a recovered so I can't say recovering. A recovered regulator, a lot of those issues are, like, dealing with law, which we literally can't deal with here. You know, like like, we can write a protocol that says do only legal stuff. Well, how do we enforce that? But, definitely, you know, we should talk. We have other regulators who are current regulators, here about the experiences of how to get it done. I will say that something about the Vesper doc is it did feel like it was getting kinda into policy land. Mhmm. You know, it's good to have guidelines, but we do need to be mindful of kinda where the IETF stops and the regulators start. And so having those guideposts, like like, you know, you need to fill in the blanks here. That is important, but I don't know that we should be filling in the blanks.

[00:34:26] **Chris Wendt**: Yeah. And I agree. And if there is something that sort of goes over that borderline, I'm I'm very much willing to discuss that and and make that appropriate. I think the other your other question was more related to the enforcement part, which is here, we're trying to authenticate that someone has control of a telephone number. But that doesn't necessarily mean that they're gonna still do bad things even though they're authenticated. So so this isn't the total solution that's gonna remove all robocalls anywhere, but it's a key part of providing the evidence of who was the the responsible party for those bad calls and and hopefully make that enforceable and all the good things that we do around authentication. Charles?

[00:35:25] **Charles Eckel**: Yeah. Charles Eccle. I just had a question related to this, and it's making me think about your charter discussion too. You mentioned, like, this is a proposal you've been talking about to address the update, you know, the Mhmm. Kinda added scope to the charter. When I read the charter, I wanna see, are you intentional in saying that you're going to define a mechanism for doing this, or is the is there and is that purposeful that there'll be one mechanism? Or when you mentioned other mechanisms, would it be to do those instead of this in addition to this? Does the charter it doesn't look like you say multiple mechanisms. Do do you want one? Do you want at least one? What's the intent?

[00:36:11] **Chris Wendt**: I I don't think we were explicit. And I think, you know, you know, we don't have to take the first one that comes up. But yeah. So I'm just presenting this on its merits that that this is a good technique that the STIR working group should adopt to identify the the entity. But, John, you can expand.

[00:36:33] **John Peterson**: Yeah. I mean, like, a bunch of times I've been, hey. Should we have, like, requirement cycle in front of this and then, like, vet proposals against it? You know? I I think at this point, Chris is the only person that, you know, me me apart from Dan, who's putting forward a proposal that actually meets the you know, we always write in the charter too. It helps. Right? The charter he's writing is, like, pretty well aligned with the set of documents he's proposing. So, I mean, if nobody else is gonna step forward and suggest, you know, a solution that's actually gonna be able to hit those marks, then I don't really I think requirements process would be pointless. Right? So, I mean, I think I'm happy to entertain this in the forum that it's in. You know, again, I when we and this has been an ongoing process with Vesper. You know, Chris had his little history slide about spaghetti on the wall to where we are today. Like, you know, I think we've been gradually making it more and more modular, right, as the proposal has evolved. And it's now at a point where the parts are fairly interchangeable. Right? This though does seem to be a bit of a linchpin

[00:37:36] **Ben Campbell**: Mhmm.

[00:37:36] **John Peterson**: In the way that it's uniting 9060 and traditional, like, you know, x five zero nine, like, web search or whatever. And so that that's why when I got up earlier, it was kind of like, just making sure everybody here is listening, paying attention.

[00:37:49] **Chris Wendt**: Mhmm.

[00:37:49] **John Peterson**: Like, we go forward with this as the solution here. We are gonna bind those things quite strongly. Mhmm. And that's the point of a proposal like this, is to bind those things very tightly. And that has good security properties. And and for that reason, I, you know, I'm I'm not here expressing opposition to it. I just wanna make sure we're going in with open eyes, especially this part of the presentation, because this is really what binds all this together. It's Right. It's this slide this slide right here.

[00:38:14] **Russ Housley**: So the way I think about it, Charles, is this isn't a suggestion for how to bind a domain name. One could imagine how to buy bind a SIP URI. Right? And that would be a different binding mechanism, but would also result

[00:38:30] **John Peterson**: Maybe not.

[00:38:31] **Russ Housley**: In a subject though.

[00:38:32] **John Peterson**: Well, again, because because I wanna see service code

[00:38:35] **Russ Housley**: level or a single phone number level.

[00:38:37] **John Peterson**: Yeah. I wanna see transunion.com saying this is John Peterson. Right? People like to test this stuff.

[00:38:58] **Russ Housley**: Right? The answer is maybe, would there be other mechanisms?

[00:39:02] **Ryan**: Yeah.

[00:39:02] **Russ Housley**: Yes. And

[00:39:06] **Charles Eckel**: you want the the version of the charter that we're going to take to the IESG, you want that version of the charter to leave it open to that Correct. In case someone brings another mechanism. You want this to be the group where those proposals come, and there could be more like this in

[00:39:22] **Russ Housley**: the future.

[00:39:23] **John Peterson**: K. Right. Because so, you know, again, historically, to be clear, like, there have been a lot of third parties that have made, like, helpful judgments. And if you look at the WebPKI space, right, there's a CA or even even indeed the way the PA, GA, CA distribution works in Shaken. You know, there there's all these kind of third parties that are integral to the trust model that emerges in this. And so, you know, we're not looking at this from the perspective of we're gonna somehow be able to eliminate the notion that there is vetting that is conducted by third parties. It's really about what the authority is we think the resulting credentials project to relying parties that they can then consume and say, can trust this call or not. Right? And the flows for this and the WebPKI, you've known they are heavily mediated and, you know, are by no means first party things. They're full of checks and balances and, like, external entities that are following policies to determine whether this or that entity should be issued a credential. Like so, I mean, it's it's, you know, those things are always gonna be part of the equation here. The point of this approach, this technical approach, is just to make sure that the aggregation of those trusts comes to a point where we are binding the thing that we expect to sign for the event of a call with the thing that we expect to sign for who this entity is behind it and to give corroborating information about them. And I do agree that without that binding existing in some form, there is a serious security gap in any proposal that has this form. And that that's all I was trying to say in the list in the past, like, month.

[00:40:52] **Eric Burger**: It's Eric here. So, again, kind of a charter thing. It's okay to have multiple ways of doing things. However, you know, when I look at Shaken, Shaken is, you know, like, you know, on every off Tuesday where you get a magic number from an authority that you don't didn't even know existed even when you're at the regulator and blah blah blah blah blah, but then you end up with a certificate. And here we say, oh, you got a certificate. Okay. We can do stuff with it. I would be very careful of saying, oh, this means that, oh, we can have a certificate or we can have some magic number that somebody makes up.

[00:41:34] **Russ Housley**: I disagree with that characterization.

[00:41:36] **Eric Burger**: Of a magic number that someone makes up or that

[00:41:39] **Russ Housley**: The first you have certificate. Oh. Because what you're doing is first proving ownership of a domain

[00:41:47] **Ryan**: Mhmm.

[00:41:47] **Russ Housley**: Then using that to get your magic number and then getting

[00:41:54] **Eric Burger**: Thank you. Yeah. Yeah. Great

[00:42:05] **Chris Wendt**: discussion. I'm serious. It was a great discussion. Especially with that it was so friendly. I I like that part too.

[00:42:20] **John Peterson**: We can tell you next slide.

[00:42:26] **Chris Wendt**: Yeah. Okay. Well, yeah, I had to bring something in to argue about. So, yeah, this is also a new proposal. I I it rounds out a a few things that I think actually we don't have proper mechanisms, and the the intent here is to have these attributes be able to be tied to the certificate from a self asserted attributes. So and I don't know if this is what I I I did pop a surprise in here of reconsidering the name of the CPS since the the the call placement server, which also conflicts with the acronym certificate practice statement, which we ran into in the last draft. But I'm open to that as, you know, being knocked down as a proposal. Although, I I do sort of like the name passport placement service because I think that actually generalizes it a little more for doing out of band techniques for things beyond calls, but that is not a hill I'm gonna die on necessarily. But the I I brought in the essence of what the the previous individual draft was, which was to use the certificate and certificate transfer transparency as the discovery mechanism for discovering the out of band call placement server, passport placement sir service. I also added attributes that we haven't really talked about at all, but are generally used in the industry, like do not originate. I included it there, do not originate messaging as well to to to essentially self declare whether or not there is intent to actually originate a call from this telephone number and advertise that through certificate transparency. And then there's a new thing, authorized originators, which is a concept that we're promoting in general of actually explicitly saying that you it's sort of a form of do not originate, but it's added parameter to say, I will only originate calls from these providers. If you see calls coming from other providers that may be signed by a shaken passport, then you know that they they are not legitimate because I have not authorized those originating providers to actually originate my call. So I see John's in line. I'll let you go. And this and and and this, of course, could be extensible to other attributes that you might want to self declare. But but the rule should be that these are these are explicitly self asserted, so there's no authority as associated other than your own.

[00:46:08] **John Peterson**: Very good. Okay. So I have one kind of meta comment about this, and I'm gonna go all the way down this list and explain why I don't like each one of these. But my first meta comment is who this is just a question about where we store information and who we expect to be vouching for it. So the things that are getting baked into the CA or being baked into the CA by the c or baked in the CERT or being baked into it by the CA. Right? And the things we're actually talking about here for the most part are things that are really at the discretion of the person to whom the certificate has been issued Right. All of them are, to the provider. And, you know, we played around a lot in the original 8226 design with things like having our our constraints, right, our GWT constraints, where, you know, we knew we wanted to able to issue somebody a cert, but to prevent them from being able to sign passports with particular properties with that. All these things, I think, are things that really belong in documents that are signed by the owner of the private key of the credential that is being issued here. They do not, and probably shouldn't never be baked into the cert itself. Right? This is just a separation of authority thing of where these kinds of things belong in the overall architecture. Mhmm. Alright. So now I'm gonna take this one at a time.

[00:47:17] **Russ Housley**: So, John, I really agree with that.

[00:47:19] **Charles Eckel**: Yes. And

[00:47:21] **Russ Housley**: if you look at the shaken CPS certificate practices statement, it says don't put anything in the certificate that hasn't been authenticated.

[00:47:31] **John Peterson**: Yeah. It also says, by the way, you can't sign anything with it other than passports Right. Which is we would need to be violated in order to have the proper model of this work where you're actually signing, like, a separate document. The shaken CPS is fundamentally broken and should be changed by the people who have changed control over it. It has been since it originally was created and I haven't gotten any better since. Then going through the the next four of these. So, BPS, I I hear what you're saying. It is, overloaded with CPS. We just published an RFC. I think it was on Russ' first slide this year, but it's still using the term CPS in it. And like, it's this is not a legacy historical term that like, you know, we're we're gonna, suddenly swap out. Whatever. I mean, you know, our branded actual version of this, we run a TransUnion. We call it the CSR, the call session registry. Mhmm. It's kinda like that, as an alternative. P p s p p s. It's like, you know, when you do p s at the end of a letter and there's p p s, like post post script, I think is what it actually stands for. It's p p So I I believe that we need a requirements document and a vetting process, whatever the successor name will be to CPS. It's not gonna be a CPS anyway. But, no, that that's the joke one. The next two, though, these are also, again, fall under much the same concern that I originally expressed. Things like so first of all, DNO. DNO is something that is extremely dynamic. The the numbers that people I know because we provide DNO service to a lot of people. Right? Like the numbers that that a particular enterprise might decide they no longer want to originate calls or messages from at any given moment, quite dynamic. I wouldn't bake it into assert, like, in in any stretch of the imagination. How you best express that, it's tough to say. Again, there a lot of handholding in my experience is required to get DNO to work. And so I'm not even well, I I should say enterprises should be able to publish both of their own lists of these in some form. I'm not exactly sure why we would build that into the architecture that we're defining here overall. They are very useful functions. They they score real wins in terms of, like, fraud prevention out there in the world, so I'm not trying to denigrate either of these mechanisms.

[00:49:37] **Chris Wendt**: Right.

[00:49:38] **John Peterson**: But, like, I just don't know what our business is creating a document format, let alone a certificate format, that's gonna specify what those two things are.

[00:49:46] **Chris Wendt**: Can I give the so these declarations, the concern would be that somebody, for some reason, trusted the wrong actor to give a do not originate claim for a telephone number, and we don't really have a authentication mechanism for that and a way to validate that the that end entity actually declared that for their telephone?

[00:50:16] **John Peterson**: I I could see us developing a mechanism that would allow a a provider to delegate that power to a third party. Mhmm. In in much the same way, I think, you mean by authorized originators here. And you got something similar to that where you're like, well, okay. This person is is allowed to manage my DNOs for me.

[00:50:31] **Chris Wendt**: So so the the the overall conceptual idea was that in terms of the right to use holder, the the one that's responsible that has been assigned that number, they have the power to make their own self determination whether they're not originating the calls or or not.

[00:50:53] **John Peterson**: Yeah.

[00:50:53] **Chris Wendt**: And so

[00:50:56] **Mike Ounsworth**: But but

[00:50:57] **Chris Wendt**: I don't know. I I

[00:50:58] **John Peterson**: But although

[00:50:58] **Chris Wendt**: can I

[00:50:58] **John Peterson**: just So the point is relying party is subscribed to DNO list? This this is actually even a more fundamental data architecture question about this.

[00:51:05] **Chris Wendt**: I

[00:51:05] **John Peterson**: mean, these things are not being vetted at the originating side. It's not like an originating provider is the entity that is determining, I'm not gonna let this call proceed because it's on this person's DNO list. Right? It's relying parties in the terminating side that are aggregating these from a number of different data sources that are blocking calls based on the fact that they meet because the Oh, trust me. Look, there's a pitcher and a catcher.

[00:51:29] **Chris Wendt**: The intent is that the original No.

[00:51:32] **John Peterson**: But you just go to the incentives. There's a pitcher and a catcher, right, in the fraud and and spam business. Right? Pitcher's job is to send all the spam it can. Catcher's job is to like, you know, prevent all the spam it can. There's no incentive on the originating side to influence TNO. There's not. Trust me. I

[00:51:52] **Chris Wendt**: understand that.

[00:51:54] **John Peterson**: Intentions for that all reside in the terminating side, and so really it's a question of why does the why has the infrastructure emerged to be the way it is today? It's because relying parties want a one stop shop they can go to and say, give me all of the DNO information I need to subscribe to in order to be able to block the calls that I need to block. And so almost, you can imagine that that is a pastiche or patched together aggregation of signed blocks generated in this format that it's the job of these intermediaries to collect and make available to lying parties that they can consult through their RM technology on the terminating side. Like but but, again, I I imagine that starts to look more like delegation than than like this. And it certainly isn't in the cert. Right? It certainly is some external document you're publishing that somebody is signing and attesting. This is the proper DNO list for this particular enterprise.

[00:52:45] **Chris Wendt**: Yeah. I mean, I think everything that's been documented Last everything that's been documented for DNO, the intent was that you as an originator, if it if a number is on a DNO list, you should not originate that call. That is the that is the scope. I understand But the

[00:53:01] **John Peterson**: people who don't originate it are the bad actors who don't care about that. Right? That's the point. Understand. And so the incentives don't exist on that side to obey a d n o list. Where the d n o list actually factors in is some entity after the originating side ascertains, hey, some joker put this number out even though like no number should no calls should ever originate from this number. Right.

[00:53:21] **Chris Wendt**: But you also if if a provider is sending calls that are on the DNL list, then you know there's probably not the greatest provider in the world either. Or they're not doing KYC. Or they're not doing

[00:53:34] **John Peterson**: That's completely immaterial to my point about the data architecture, though, and where it needs to be aggregated and where the actual decision needs to be made. DNLists defend, exist to defend, you know, called parties from bad calls. And the place that defense is always going to be staged is, you know, n minus one on the terminating side, right, or even in the handset itself.

[00:53:55] **Chris Wendt**: Yeah. So Right. Yeah. And I guess this conversation's more about the declaration of DNO versus the actual usage, but but maybe that's relevant. Eric?

[00:54:06] **Eric Burger**: So oops. So I wrote Mhmm. Part of the DNO order. And what you said is correct. You know, it was targeted towards the terminating carrier. However, with a stroke of the pen, it can apply to the originating carrier, and it's more sanctions for when we string them up because they're obviously bad carriers. So it's one more thing to try to get the justice department to seize assets on. But but you're yeah.

[00:54:34] **John Peterson**: You're I think I think my my fundamental point here is getting lost, though, because this is all about where this information needs to live. Right? And, like, again, whose job it is to parcel together and figure it out. Right? And it doesn't matter. I totally agree with you. You could stage this. You could require every carrier in The US to look at this, you know, deny list of numbers that are But the point is, even if then it becomes that originating carrier's job to learn every other enterprise's list of this, because it's not just the originating carrier of whom the enterprise is a legitimate customer. It's every carrier needs, you know, who is not have a legitimate relation with this, would then need to learn and, you know, use these addresses. And so this is why, again, the question of who makes this object, where it lives, and what it's bound to, certainly not bound to the SIR. Right? Because that is the instrument that is like being used to sign legitimate things and has nothing to do with any call that is being illegitimately originated from one of these numbers necessarily. And so it's just it's the wrong place in the architecture to be thinking about where you would organize this this

[00:55:44] **Chris Wendt**: Are we saying that certificates don't have any self asserted information in them? That is correct. Ever?

[00:55:52] **John Peterson**: Necessarily. The information in a certificate is asserted by a certification authority. That is the definition of a certificate. And so there there is literally it is impossible for there to be self asserted information. There can be information that you put into, like, a CSR. It's another another version of that acronym being being used differently. You

[00:56:13] **Chris Wendt**: know, that way

[00:56:13] **John Peterson**: if you're actually gonna go, like, make a a certificate. Right? Like, you can put information into it that, like, a PA vets and determines that's okay and then will allow a certification authority to issue a cert for it. Mhmm. But there is effectively any it's always a policy decision made by the certification authority, what the fields are that are going to appear in x five zero nine.

[00:56:36] **Chris Wendt**: Okay.

[00:56:37] **John Peterson**: But it's actually, the last of these that I really got up here to talk. The authorized originators. This is this is another really interesting one, because this is in attention with, 9060 with the whole idea of, like, delegated certs. Right? And this is just a second path with authority effectively that is being defined for this. And so, you know, as long as every ninety sixty cert has the proper, you know, point pointers up and down, right, to its parent and any of its children, like, that information is at best redundant with it. But at worst, it is potentially not not properly synchronized with it. Mhmm. Right? And so we should have one way to ascertain what the relationship is between entities that are allowed to originate numbers, you know, rather originate calls for for numbers. Right? And if the SBC has, like, a couple of different ways to do this, I start to get real nervous.

[00:57:34] **Chris Wendt**: Mhmm.

[00:57:35] **John Peterson**: You know? And and there are a whole bunch of people who have looked at how complicated STIR is and said, oh, man. We should just build, like, a centralized database. Instead of doing any delegation thing, we should have a centralized database, and you just look up in the centralized database. Great. These are the set of entities that are allowed to originate calls from this number. Imagine we took something like the MPAC, and we just listed, like, the OCN of every carrier that was eligible to be able to originate calls from that particular number and populated it that way. The challenge of that, and this will face the same challenge, is that there's actually multiple parties to this question of who gets to originate what. I think not every carrier knows the set of enter, you know, the set of other carriers that a given enterprise may have contracted with to be able to originate numbers from. And so in a certificate like this, this is again another what level of the architecture and what level of authority these things need to have, Like, why would a certification authority know the set of carriers that a given enterprise at any moment had contracted with to be able to originate, you know, calls from a given number? How would they figure that out? How would they certify it? They would need the enterprise presumably to come to them and periodically just tell them, okay. Now I'm working with, you know, this particular carrier to make some outbound numbers from this. Please bake that into my certificate. Every time. Every time? Every time they change anything about which which carriers they originate. Every time they make changes to how their architecture works, that is a certification authority of the whole intervention.

[00:59:11] **Chris Wendt**: Yeah. I mean, that

[00:59:13] **John Peterson**: So there are centralized database people who think think this is a perfectly viable approach, and, like, this this is the same thing except you're just doing it distributed through the set of certification authorities you work with.

[00:59:22] **Chris Wendt**: Well, and

[00:59:22] **John Peterson**: But my point is ninety sixty is much more clear, much more crisp. I specified it and understand I take This is an end runaround ninety sixty. I

[00:59:32] **Chris Wendt**: I take your point that, yes. If you sign the call with a delegate certificate, then you should absolutely know that it came from that originator and and that mechanism. And and I'll be honest that authorized originators probably was intended more for if it's only signed with a shaken certificate.

[00:59:57] **John Peterson**: It's it's a it's a security approval from my perspective. Oh, it's an end.

[01:00:06] **Chris Wendt**: But is that any different than DNO, which also has Vesper

[01:00:13] **John Peterson**: There's nothing to do with it. Yeah. I mean, so d DNO, like I said, is something that's used primarily honorable call mitigation on the terminating side to just make very blanket decisions about this number. No call should ever originate from this this number. Right? This is a very diff this is a very different question. This would be a question like, okay, I see this is signed by OCNX. Right? And I am now, as a relying party, looking at authorized originators to ascertain whether or not but the problem is who who who is the primary? And again, staging this in the cert, it it basically it's defeating the purpose you're trying to have that work for. Because if there are 10 different certs that are signing calls from the same number that are being sent to me, and only one of them has this in it, and a given one that I get doesn't because it's not the actual number holder, like, impact wise or something. Like, what what uses this to me as our lying party? Like, this information needs

[01:01:06] **Chris Wendt**: about authenticating the fact that it was the entity themselves that declared DNO for their number.

[01:01:12] **John Peterson**: I'm not talking about DNO. No. I'm talking about authorized

[01:01:14] **Chris Wendt**: Or or or authorized. Same same problem statement.

[01:01:17] **John Peterson**: It's well, I think they're radically different. But, anyway, as I go to sorry. I know we're monopolizing the mic here, Roger, but let me get out of the way. I don't think any of this stuff ultimately belongs in the CERT, first of all. And maybe we need to have a very complicated requirements discussion. These are very different problems about, like, what we think the right way is to integrate those into the the STIR architecture. Right.

[01:01:48] **Eric Burger**: Thank you. Roger Anderson. I just have a silly question. These these are not secret attributes. Once you've bound a TN to a domain name, doesn't DNS become an opportunity to store dynamic? You just you just okay. Oh, okay. Alright. Anyway, so I I just didn't know, or if there if I didn't know if that would be I think you had talked about using DNS to tie some of these attributes originally, but I don't know if that means you're filling DNS with a lot of

[01:02:19] **Chris Wendt**: It wasn't the original proposal, but but, yeah, that's a valid path forward also. So I will take that as input for sure. There there is discussions about that.

[01:02:35] **Ryan**: Hello. Ryan again. Hi. So the discussions I've been I'm occurring right now, it's a bit high level. I got a bit confused, but I wanted to ask, whichever certificate you're signing, does it have I mean, PKI infrastructure? Does it have a set duration, a a valid duration? I just wanted to ask that. And if it does, it ties into what you said about the DNS being a way to sort of verify something. Yep. I just I was a bit confused because, as I said, this is very high level. I have the until three days ago, I didn't know anything about STIR, but. I thought it's interesting. Sure. So I wanted to you thank you. You spoke about the from being applied from telephone networks all the way to anything communication online. Yeah. And I do agree a bit by what he mentioned that this defeats the purpose in some way Mhmm. Of that. But, again, what if somebody in their own internal infrastructure would like to use something like this as a sort of certification authority for their internal communications. Yeah. That's what I was thinking about. As you mentioned, that it defeats the purpose because if internally, I can create my own SSL certification. The same way I could create my own certification server and have it locally for a certain infrastructure or a certain country.

[01:04:08] **Eric Burger**: Right.

[01:04:09] **Ryan**: Either way, I was a bit confused because I just wanted to clarify if this is just speaking about any communication online or mainly about identifying calls

[01:04:20] **Chris Wendt**: in Yeah. So

[01:04:23] **Ryan**: Just wanted to clarify that.

[01:04:24] **Chris Wendt**: Yeah. I can clarify a couple things there.

[01:04:27] **Russ Housley**: I need to do a chair thing. If we're gonna use Meetecho to do the minutes, people must raise their hand. Otherwise, it doesn't know who's speaking. Okay? Alright. So please sit down. If you want to speak again, raise your hand. Thank you.

[01:04:50] **Chris Wendt**: Yeah. So just to quickly answer your question, the primary focus of STIR has been on calls, and that's where we initiated the conversation. But we also have a messaging RFC that we can extend and stir, and the authentication of telephone numbers or SIP URIs to other communication protocols as well. The key thing to differentiate in this conversation is we have essentially talked about two sets of certificates, ones that are tied to service providers with a service provider code and the ones that we're talking about in this context, which are more associated specifically with a telephone number. And, generally, the the the general practice for service provider code based certificates has been longer lived certificates, although I think there's some push to to make them shorter and shorter as there is in general with certificates. In You're about the lifespan of them,

[01:06:02] **Russ Housley**: not the size of them.

[01:06:03] **Chris Wendt**: Yes. Lifespan of them. I'm I'm sorry.

[01:06:07] **John Peterson**: He was supposed to be the size. The

[01:06:12] **Chris Wendt**: for delegate certificates for ninety sixty based certificates, we've been talking about using short lived certificates. So very short time frame. So that and the and the basic reason was when we went through this conversation a lot, the verification part, If you have a lot of certs with telephone numbers, the revocation problem becomes sort of a scale problem. So shorter lived certs helps that because you don't necessarily have to maintain a CRL or a a CSP or other things like that. Hopefully, that helps. This is like a holster review today. It's like it's fun. Okay. So, yes, feedback received for for this draft. And thank you for the feedback. So I don't think I need to go through this slide. We've already gone through this conversation, but but I do think certificate transparency is an important property of ninety six sixty certs. And this really picture is a high level encapsulation of how Vesper composes the blocks. I think I've sort of made the case for this in general. Happy to review things again. I will bring up the one thing on this slide that I haven't talked in-depth is the ability not only to sign a passport, but I think using a token to represent right to use with a with a token that's signed by the delegate certificate is a useful thing that could be used in the ecosystem. And I've talked about it as potential ways of replacing the legacy ways of doing LOAs and other ways of proving that you have the that you've been assigned the number. And also providing ways to to to stop being able to prove that when you give up that number assignment as well as an important property, LOAs just sort of sit as a piece of paper rather than had the ability to be revoked in any way. This is a little bit of a repeat as well, but it essentially, the life cycle of we we sort of talked about making sure that the authority and the domain control are combined. And I guess this is actually a repeat of exactly what we talked about before. So I'll just quickly pass through that. I do talk about in the Vesper drafts the specific authentication and verification procedures. They're unsurprisingly very similar and and reference ninety sixty. One additional binding rule that could be interesting as well is that we have the idea of the certificate repository where the x five u points to. That could also be tied to the domain as well as a form of control of the domain and a convenient place to store the certificate. We we use the short lived draft that also talks about the use of x five c where the certificate is built in to the passport, so you don't have to do the extra round trip to retrieve that certificate. But we also talked about potentially best practices of also having x five views there, both as a fail safe as well as a that that this binding rule could actually be helpful that, you know, like, because you have hosted the certificate repository within the domain of the entity that controls it, that also gives another proof point of the domain control. And then connected identity, I also go through some of the procedures for authentication and verification on on those things as well. Thus, we're out of band. I actually took a lot of feedback from the last conversation. I actually totally removed all the API stuff because, you know, that follows essentially the pattern of the other out of band documents anyways. And I acknowledge that there's various number of APIs out there. APIs is sort of a thing that we struggle with a little bit of, IETF anyways. So I removed it. It does talk about the discovery, although, you know, that sort of ties into the last conversation. So may need to revisit that a bit. It does talk about connected identity in terms of out of band and defines essentially the the backwards procedure to to sort of codify a way of going from the reverse direction through the the call placement server. We have talked about potentially using this for messaging as well. So I I do talk about that as well. But I see, John, you have your hand up. I think I covered most of the new things in out of band. Right.

[01:12:30] **John Peterson**: So and we were talking a bit about the PPS URIs in the certs previously, and this is one of these things where, again, the question of where in the data architecture it belongs would interesting. And to get this to work, you know, all this out of band stuff has always had this kind of chicken and egg problem.

[01:12:43] **Chris Wendt**: Right.

[01:12:43] **John Peterson**: I love the what was the Addus one where we're gonna publish, like, just a list of what everybody's CPS was on a website, and you'd, go look there, try to figure out, like, where these things go. I mean but I think this is actually something really fundamentally difficult to solve. Mhmm. And, you know, the decisions we've made about out of band for the most part to date have been predicated on the notion that the PPS, CPS, whatever you wanna call it, it's kind of tied to the terminating side and that it's the originator's job to, like, discover it. So, yeah, presumably, you're there's an Oracle that lives here somewhere, and this Oracle is going to let you take an origin you know, a telephone number that, yeah, you're trying to to reach, right, and, like, go, look up the certificate that's associated with it.

[01:13:32] **Chris Wendt**: Mhmm.

[01:13:32] **John Peterson**: And, like, that is an integral part of this, you know, the that is the dimension to this that, like, needs to exist in order to enable it.

[01:13:42] **Chris Wendt**: Yeah. So and and this is a topic we can certainly discuss. But the the thing I was trying to say in here is that there's a advertising discovery thing that could be populating an Oracle or could be populating various Oracles or, you know Yeah.

[01:14:00] **John Peterson**: I wrote something about this in one of the Right. Out of band RFCs where I, like was like, hey. There's a advertisement, like, format Right. Like, object that you can sign with your certificate, and you put this object out. It's actually we were trying to tie this into our we're doing modern, like, to our forward routing version of this.

[01:14:20] **Chris Wendt**: Yeah. And that this was essentially my attempt at making it much more explicit, I guess.

[01:14:25] **John Peterson**: Yeah. Well, I guess I'd just rather say, I think that model where it's the cert that signs some kind of wrapper, you know, some kind of object that you've defined that says, for this set of numbers or whatever the things you're gonna look up against Right. Like, this is where you go look for the CPS. This is where you go look for whatever other features you need in order for this this to operate is gonna end up being better than baking it into the cert and having this be a cert discovery function. Mhmm. Because the the latter has, again, dependencies on that architecture of whether we think the CPS belongs to the originating and determining side, but the former, where it's just an object that ends up being signed, the person with authority for the number does not. Yeah. And so I think that's a cleaner division of kind of labor and clearer about who actually has the authority to create those those linkages. But to be clear, once we have those, you are pretty much doing everything you need to do forward and to do modern and all all the other stuff that we were we were talking about back in, like, 2016.

[01:15:17] **Chris Wendt**: Well, that's a whole other topic of whether we wanna revisit that or not. But, and maybe it's becoming more relevant now that we're talking about all IP and other things at least in The US. I know. Right?

[01:15:34] **Ryan**: Finally.

[01:15:36] **Ben Campbell**: Just jumping in real quick as a chair. There's fifteen minutes left in the session. It'd be nice to have some some discussion about adoption or not before we're done.

[01:15:47] **Chris Wendt**: Yeah. And I think I'm actually almost done. I do think that authenticating the fact that for the telephone number, the c p s, you know, I'm gonna go back to d n o, other things like the fact that those were authorized by the entity that holds the number. Like, I think there needs to be some sort of authenticated way of doing that rather than now we're cert is the opposite Okay. Yeah. Yeah.

[01:16:18] **John Peterson**: That was really funny.

[01:16:19] **Chris Wendt**: Yeah. And and and I'll and I'll concede to the cert mechanism, but I think there should be some mechanism to be able to authenticate those things. So hopefully, we can agree to those. I see Mike here in the queue.

[01:16:37] **Mike Ounsworth**: Hi. I'm also watching the clock. Can we have, like, three minutes to talk about Acme at the end of all this?

[01:16:41] **Chris Wendt**: Yeah. That would be a great topic to talk about. So I am on my last slide. So talking about adoption is exactly what I'm calling for here. I I guess I'm noting here also I have been maintaining a use case document sort of just as a personal, like, justification for Vesper. And I referenced it in my note to the mailing list. So I I don't know if it's something we want to talk about at all, but I'm I'm happy either way. John, you're in the queue.

[01:17:25] **John Peterson**: Charter first adopt later. None of these things are in the current scope of STRS charter. Right? So charter first adopt later. Anybody disagree?

[01:17:37] **Chris Wendt**: Can we have a

[01:17:38] **Ben Campbell**: And I I'm gonna

[01:17:40] **Chris Wendt**: I don't know.

[01:17:40] **Russ Housley**: Ben's in line. What's he wants to say?

[01:17:42] **Ben Campbell**: I'm gonna disagree with John just a little bit. I formally, that's correct. We certainly can't adopt any of this until the charter is there. That doesn't mean we can't talk about it and have a plan. So I'm not saying that we need to make a a adoption decision today. Obviously, we cannot commit a decision today. But we've been talking about best for a long time, and we need to get to the point to decide if we're really working on this or if we're not.

[01:18:13] **John Peterson**: Well, it's what takes up every STIR meetings. We're clearly working on it.

[01:18:29] **Russ Housley**: Charles?

[01:18:33] **Charles Eckel**: Yeah. Charles Eccles. So maybe I just phrase it a different way rather than asking for adoption. I'd like to know if anyone like, with the documents you have, do people have concerns or things about them that would prevent them from adopting it when when the time comes? I'd like to hear those now. But, yeah, I'd rather do that than, you know, a

[01:18:56] **Russ Housley**: I I think you said more clearly what Ben was trying to say is if you've got issues that would cause you to speak against adopting, can you share them now?

[01:19:07] **Chris Wendt**: And and Yes. That's what I meant to say. And and maybe and and and I think it it is reasonable to say, like, maybe Vesper and the t n binding, which seem to be more friendly conversations, might be better candidates to adopt now, we can have further discussions on the others. I'm happy, Yeah. To entertain that.

[01:19:26] **John Peterson**: It's not it's not monolithic. There's six documents here. Right? So I think Vesper framework four

[01:19:33] **Chris Wendt**: that I think are proposed to be adopted.

[01:19:35] **John Peterson**: Yeah. There's a yeah. I think Vesper framework is fine for us to go forward with at this point to say that that that is something we're officially working on. Like, n a the t n attributes one that I was just, like, having so much to say about, I don't think is I I I mean, I I think there might even need to be some kind of requirement process before we get into what that looks like.

[01:19:54] **Chris Wendt**: Mhmm.

[01:19:56] **John Peterson**: Binding, sure. I mean, again, it that's this, I think, is the big decision is, are we putting our eggs in the binding basket? And then that's how we're doing it. Mhmm. And that that's a you know, I just wanna make sure the working group is aware that's, like, a that's a milestone decision.

[01:20:25] **Russ Housley**: Okay. Are we done? I think Mike wants to talk about Acme. Yes.

[01:20:39] **Mike Ounsworth**: Hello. Mike Endsworth, friendly neighborhood Acme working group chair. So we've got a document in Acme, which is if I can find the right tab here, which is JWT claim constraints profile of Acme authority token, which I, like, just realized yesterday is coming from this working group, I think.

[01:20:58] **Russ Housley**: Right? You said it. Well, it is kinda related. Yeah.

[01:21:01] **Mike Ounsworth**: Okay. So Chris has been valiantly pushing this thing for a year now, March 2025, and it's currently in working group last call. I gave it a very long working group last call. It's been sitting there since July 4, has had exactly zero responses to work group last call. I am going to have to fail its working group last call. The problem with this document is nobody in Acme knows what it is or what it's for or where it's coming from or why anyone needs it. So if you would like it to not fail its working group last call, please some of you show up to Acme and speak for it. Thank you.

[01:21:37] **Russ Housley**: I think that message was obvious.

[01:21:39] **Eric Burger**: What are you doing first?

[01:21:42] **Chris Wendt**: I feel

[01:21:43] **John Peterson**: like I've already did that at least twice. But okay.

[01:21:46] **Chris Wendt**: Yeah. There was advocates in the beginning, but maybe tying Yes. But

[01:21:51] **John Peterson**: there in person.

[01:21:52] **Mike Ounsworth**: That's that's

[01:21:53] **John Peterson**: I we should do this.

[01:21:55] **Mike Ounsworth**: That's fine. Have you done that since July 4 since I opened the working group last call? Because I can't pass a thing with zero responses. Right?

[01:22:01] **Russ Housley**: Right. Okay. People go to their mailing list and speak. Read the document and then speak about it. Right.

[01:22:12] **Mike Ounsworth**: So, actually, so Russ makes a good point. So, like, specifically to pass the group last call, I need document is clear, document is implementable, document is ready, document is useful. Right? It's not just like a year and a half ago, we said we need it. It's like, yes. This current piece of text is good. Please publish. Right? This is what I need this week.

[01:22:30] **John Peterson**: Perfect. Thank you.

[01:22:32] **Chris Wendt**: And, Marty, just

[01:22:32] **Ben Campbell**: Could you send something over to the story list to ask people to do that that may not be in the meeting right now?

[01:22:39] **Russ Housley**: Can do it. Thank you.

[01:22:41] **Chris Wendt**: Awesome. And just the three second version, JWT claims constraint is essentially the pair that ties t we have TN auth list extension and JWT claim constraints extension, and we actually have extended JWT claim constraints. But it's the corresponding authority token that allows you to challenge via Acme the JWT claim constraints in the certificate signing request.

[01:23:15] **Russ Housley**: Okay. I think we're to the any other business part of the meeting? We have less than ten minutes. Does anyone have any new topics to raise? Okay. Then we're gonna let you go a little early. Thank you very much. Thanks, Ben.

[01:23:45] **Ben Campbell**: Thanks, everyone. Sorry for joining late.