Just because you can know (fsvo "know") that a call is allowed to assert a number doesn't change anything unless other actions are taken. With DKIM which is far simpler than STIR it would require reputation systems that don't seem to have been deployed, submission auth which thankfully was deployed, policy enforcement (ie ADSP) which is not deployed, and user indicators which are sporadically deployed.
In any indication, the carrier closest to the originator is signing the call metadata with their digital certificate. While this won't mean much to the active user, for those tracking down robocalls, this is the holy grail - finding the carrier who is letting the calls into the network and being able to reach out to them to stop the abusive/illegal traffic.
As I said, STIR solved the wrong problem. I know domains as a user. I have no clue about e.164 address ranges. Also: this is 2021 and e.164 address need to go the way of the dodo.
From an automated standpoint, I really don't care about whether a phone number is authentic, I care about the domain that onramped it so I can theoretically punish it. It's the people who are allowing the spoofing that is the real problem which directly analogous to email open relays.
Also: reputation is nice in theory but I am dubious that it is deployed in reality. Given the entire ARC farce which was driven by Google -- who owns gmail -- to supposedly "solve" the mailing list traversal problem but boils down to a reputation system, that strongly suggests that they don't have one either. I'm not sure why we should be optimistic about that for STIR which solves for a much harder problem which is inherently not entirely secure given SS7 gateways.
That it might say we've taken the time to verify the end user is who they say they are is just icing on the cake. The goal is to make the calls accountable to someone, which despite the patchwork of systems in the US that might prevent the signature from coming through, can help a lot since the biggest wholesalers have implemented it (Inteliquent and Lumen among many others)
The other big deal is that now all carriers are actually expected to police their network for spoofed callers who are exhibiting robocalling behavior. This is a big deal! For the first time, carriers are going to be held responsible for proactively finding the abuse, and showing what their plans are to do such a thing, and sharing information with each other (via the FCC) who can be contacted to chase down robocall traffic if another carrier sees it.
I'm not trying to say that it's not a good thing to have authentication, but as implemented by STIR it's ridiculously more complex than it needed to be had they chosen the right problem to solve which is to know the domain that is onramping the call. This could have been trivially rolled out a decade ago and I even experimented DKIM signing SIP message about 15 years ago.
It's never been entirely clear whether DKIM was the impetus for cleaning up open relays. I'd like to think it was, but the more likely explanation was that it was in the water at the time. The FCC could have at any time just clamped down on that from a regulatory standpoint without going to all of the rigamarole of STIR. Email doesn't have a similar regulatory body to lean on so we had to take it into our own hands.
Given the giant security holes caused by solving the wrong problem (ie trying to authenticate the e.164 address rather than the originating domain) it's just going to push spammers to exploit those holes. It's very much to be seen whether victory can be declared, IMO.
Fortunately, positive identification of the caller isn't the intent. Preventing people from pretending to be the IRS is the intent.
e.164 addresses don't allow me to know if something is from the IRS. irs.gov does. Also, papers have shown that UI identification is a net positive which is a shame given how sporadically they are done and how inconsistent the UI's are. If they were widespread it would probably much better.
Mike