What You Need to Know About Caller ID Authentication

Rebekah Johnson, CEO, and Anis Jaffer, Chief Product Officer of Numeracle host a live Q&A podcast series covering all things related to call center communications, including call delivery, STIR/SHAKEN, caller ID technology, TRACED Act, brand identity, and more. In the episode below (transcript edited by insideARM; listen to the full episode here), they define caller ID authentication as required by the TRACED Act and explain how this relates to STIR/SHAKEN. In other words, how do you get that green "checkmark" to show up on your call to a consumer?

What does caller ID authentication mean in the context of the TRACED Act?

Rebekah: There are many ways to refer to caller ID authentication, such as verified ID, verified caller, accurate identification, authenticated caller identification, and so on. So really to understand the general concept, let's look at the TRACED Act to learn where accurate caller information will come from.

What we find is actually a deadline for the FCC to define -- not the term -- but the best practices that providers of voice services may use as part of the implementation of their effective call authentication framework, which we covered in  “Debunking the June 2021 STIR/SHAKEN Deadline.” 

Anis: Sounds like we have more orders from the FCC. Is this the same deadline as the one for STIR/SHAKEN, or is this something else?

Rebekah: While there were plenty of orders that the FCC had to publish last year, this directive is more of a step back from an 'order' and is more of an industry 'best practice'. So adherence is not necessarily a requirement, but this does mean that when it comes to accurately identifying the caller as part of the caller authentication framework, basically the FCC is saying: “You know better if you try to claim that you don't.” 

We've seen 'Best Practice' before. CTIA has a 'Best Practice' for short code messages. Is this Best Practice publicly available, and who wrote it?

Rebekah: It is publicly available, and at the request of the FCC’s Wireline Competition Bureau, the NANC, via its Call Authentication Trust Anchor Working Group (or CATA Work Group), is the one who recommended the Best Practices.

Members of CATA are initially nominated to the FCC and then the FCC appoints the membership. So it's the obvious participants: AHTUC, AT&T, Comcast, CenturyLink, Verizon, T-Mobile, and other participants such as Google and Telnyx, and TransNexus, just to name a few. What I love about this group is that this is the industry we work with, these are the who's-who in the telecommunication space addressing this challenge. 

Just a little sidebar on this particular group, I had the extreme honor of being able to represent the Enterprises and the challenges that service providers have with these Best Practices, and I did see some of our recommendations get adopted into the Best Practices. It was a great group and they produced good work. 

What are some of the Best Practices?

Rebekah: When the FCC identified this group and charged it to define the Best Practices, they gave the group a list of questions that they wanted to be addressed. The first question was, “Which aspects of a subscriber’s identity should, or must, a provider collect to enable it to accurately verify the identity of a caller?”

Anis: So right off the bat, the FCC clearly understands that the core issue is, “How does a service provider accurately identify a caller?”  

Rebekah: Exactly. From there, the FCC inquired about the application of the accurately identified caller to the authentication framework.  

Let's dig a little deeper into the Best Practices recommendations. To answer the FCC’s core question of identification, the Working Group dissected several definitions of who is actually being identified. Who knew that was going to be complex? But it was. We had to answer who are we identifying? But for this conversation, I'm going to stick to the entity that's being identified as the Enterprise; the entity that the called party should be informed of who is calling, like the hospitals, the schools, the government agencies, the pharmacies, and resorts, and so far and so on.

So the service providers are going to have to collect more than just the Enterprise name and address. There are business details to collect and verify such as EIN, the duns number for a corporate website, articles of incorporation, and business address. You have regulatory and legal enforcement against the company, the type of calls being delivered, and so on. It’s really complicated. 

The concept of Enterprise vetting itself is not new, right? It sounds similar to Know Your Customer, for instance. So, the same concept is now being applied to communications?

Rebekah: That's right. And what's different about this Know Your Customer type of concept is that the voice service providers are the ones that have to do it. This is not a level of vetting they've ever had to do and this is not an easy task. So in fact, I want to call your attention to something that stuck out to me in the Best Practices because I’ve seen the FCC make similar statements, and, in fact, we kind of see the same message coming from the FTC as well. So to summarize, Best Practices are at the discretion of the service provider. There is a high level of expectation in the FCC’s supported Best Practices; this statement appears multiple times: “A provider's reputation is tied to the rigor of its evaluation process.” 

As an industry, we need to take seriously our approach to establishing authenticated caller ID information.

Anis: So it's clear to present an authenticated caller ID, a service provider has to first establish a local policy to accurately identify the Enterprise and the number on the call. The service provider can establish their own process to do that local policy but the policy itself, or the process, can be based on the Best Practices that the Working Group has built and you can use that as a foundation. But at the end of the day, the service provider’s reputation is tied to how rigorous the policy and the processes are.

Rebekah: Right, and I really don’t think that the service providers fully understand everything that you just mentioned. I don't think they've gone through the process to put it all together to understand the burden they have. This really is a burden that's being placed on them to provide accurate caller ID information with an authenticated call. I think many believe they just have to purchase a call-signing solution, which we see on the market. Everyone is promoting: implement this solution and you're done. But that's only the mechanism to deliver the authenticated and authorized identity. Am I right on that? 

Anis: That's right. The service provider, if they are originating the call and they shoot the number to the Enterprise, then the policy is relatively easy to handle. You know the customer, the service provider has issued the number and you can attest with A, or clearly identify the caller.

The complex scenario happens when the Enterprise is using a number that was issued by another provider or the Enterprise is calling on behalf of somebody else. There is no simple way to verify if the Enterprise got numbers issued by another provider. Currently, you can manage this by collecting LOA’s or letters of authorization from the Enterprise and use that as a mechanism to authenticate the call. 

Are there are other solutions that are being discussed to extend the STIR/SHAKEN framework?

Delegated search is probably the most discussed solution but there's also the centralized to DV and there's also distributed ledger model. Those are all different solutions that have been proposed. In fact, Doug Bellows of Inteliquent had proposed a model based on an LOA, so you can collect and use that as a way of authenticating the number and whether the Enterprise really has the authority to use that number.

Rebekah: Do you get a sense of how service providers are going to approach these solutions? 

Anis: I think in the current state, most service providers are implementing the Core STIR/SHAKEN. The local policy as they see it is to apply for their immediate customers and their Enterprises but not to extend beyond that to Enterprises that get numbers from one service provider and use another provider to make a call, or to situations where there are multiple layers. This is still an unknown. There are models, there are local policy solutions you can implement, there are extended mode models you can leverage and add on top of the base STIR/SHAKEN, but it’s still open. That’s where we are.

We don't have answers just yet on what happens if a call is inaccurately identified. What does Congress expect? 

Rebekah: They do require the FCC to prescribe some regulations to establish a process to streamline the ways in which a private entity can volunteer or share information regarding inaccurate caller identification information, among some other things that they want to create for this kind of information flow. But, what happens to the voice service provider if the information is inaccurate? What would be the reasons why the information is inaccurate? And who's at fault? Is it the service provider who assigned the information or could it be the terminating side? The terminating side could have an error with their system, one with a display to get subscribers. Maybe they decide they want to suppress the information.

Anis: There are a lot of unknowns there. The TRACED Act talks about penalties and if a number or unturned label or number, or a misrepresent or mislead identification of a caller, but what it means or what the repercussions are, what the penalty is...that's not described. And I also saw in several references in the Act where it talks about how in 12 months and 18 months we will probably have a report that would get built by the Working Group with recommendations and feedback and what has been learned after implementing the solution. 

I would, as a service provider, try to get a local policy or solution implemented to identify the calls that are being originated from your network and have the ability to provide some kind of traceback mechanism of how you authenticated, or the reasoning behind whether the call was labeled A, B, or C.  

What happens when a call originator makes a call through a carrier with a number they acquired from another different carrier in regards to 1) the level of attestation they can get, and 2) what the different levels look like to a subscriber? 

Anis: The first part, I'm not sure. I think it really depends on the carrier that is actually being used to originate the call. So let's assume that the call originator uses a carrier but they did not get the number from there. 

It comes down to what policy they implemented and how they are treating that Enterprise as well as that number. Let's say the carrier believes that they already know the customer or the client or the call originator, and they have a good KYC policy in place; they could theoretically attest the call as A. However, a different carrier could take a different approach: If you don't get the number from me then I would always attest as B. That is also possible. So it really depends on how the local policy is implemented by the originating carrier and that could determine whether the call is attested as A or B.

Rebekah: The second part: if it goes to a B-level attestation, how will that impact the subscriber's experience? It’s all about contact; we have to get this call delivered. I think this will change over time, but I would say what we’ve seen thus far is that there won't be a difference between how the terminating carrier treats a B or A level as far as the presentation to the subscriber. 

Where it may make a difference is with regard to the analytics on the terminating side, or what are we doing with this additional data set of a B vs an A? What does an A tell me that a B doesn't tell me? And it's that two-part of an A where we feel like we can trust that call a little better because we know that the number and the entity delivering the call is authorized to use the number. And this whole process we talked about of identifying the caller, you feel they probably have done their rigorous evaluation. 

Perhaps that means something on the analytics side; we don't know what it means on our side. I don't feel that a B-level should be interpreted as untrusted because of the scenario just mentioned: what does an originating carrier do with a number that they did not provision? That's the challenge for everybody; it's not unique to one service provider. So I do not see terminating carriers treating a B -level attestation as though it should just be blocked.

Anis: I don’t think I differ too much. It could be that A could get a verification checkmark, whereas a B-level call may not get it. And that could influence what the subscriber does with the call. So if I am getting the call as a subscriber and I get one call and it says verification check or I have a tick mark, and then there's another call that doesn't have the tick mark, chances are that I would answer the first one and not the second. So the call completion could differ depending on whether it gets a verification checkmark or not. 

It comes down to what happens at the termination -- what kind of algorithms are employed at that particular subscriber's terminating service provider, and what that algorithm does with the flag. An A-level flag should, in theory, pass verification and you’d get that verification check. A B-level flag may not get it. I don't think they would give a complete wordstat check if you get a B-level, I would be surprised if somebody gives that check.

Rebekah: I like the way you stated that. There are two things to look at: what the experience is during the time-of-call, and what the reaction is by the subscriber. I think that's something we need to be monitoring going forward. 

What recommendations do you have for call originators who want to make sure one hundred percent of their calls are going to be A-level attested?

Rebekah: So I think it's important you understand what your service provider’s requirements are. We talked about the burden of Know Your Customer and number authorization. I would love to see Enterprises working with their service providers to make sure that their identity is trusted, that they cooperate with the vetting, the Know Your Customer, and that they obtain the authorization of the number. Work with your service provider on what method they are wanting because at the end of the day your service provider will be implementing their local policy. So, understand what that local policy is and then support it. I think that will go a long way as opposed to Enterprises fighting with their service providers. 

Anis: I would agree with what you said. It depends on the service provider. As a call originator, you would have to work with your service provider to figure out what their local policy is for getting your calls attested as 'A'. We are seeing some service providers already deployed, but the vast majority are still in the process of doing it so it will take some time before everything falls into place. But that's where I would start, to understand how your particular service provider has implemented the solution.