Rebekah Johnson: Welcome to Tuesday Talks, a live discussion series where we shed light and truth to emerging topics in the communications industry. I am Rebecca Johnston founder and CEO of Numeracle and I'll be co-hosting today's session with Anis Jaffer.
Anis Jaffer: Hi everyone, I am Anis Jaffer, Chief Product Officer for Numeracle. Today we are attempting to define caller ID authentication as required from the TRACED Act and how that relates to STIR/SHAKEN.
So Rebecca, what does the TRACED Act say about caller authentication? Let’s start with that.
Rebekah Johnson: So Anis, there’s seem to be so many to refer to the 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.
So what we find is actually a deadline for the FCC to define, not the term, but the best practices that providers of voice service may use as part of the implementation of their effective call authentication framework, which we covered in our podcast titled “Debunking the June 2021 STIR/SHAKEN Deadline.”
Anis Jaffer: You said a deadline? Sounds like we have more order from the FCC. Is this the same deadline as the STIR/SHAKEN one, or is this something else?
Rebekah Johnson: So 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 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.”
Anis Jaffer: So when you say “Best Practices,” we've seen this before. CTAA has a “Best Practice,” I think, for short code messages. Now, coming back to this one, is this something that's publicly available, and who wrote this “Best Practice?”
Rebekah Johnson: So they are publicly available, and at the request of the FCC’s Wireline Competition Bureau, the NANC, via its Call Authentication Trust Anchor Working Group, is the one who recommended the Best Practices.
Anis Jaffer: Call Authentication Trust Anchor Working Group. That's a lot of words, did I get this right?
Rebekah Johnson: That's right, but we can call it the CATA Working group for short.
Anis Jaffer: Right, and who are all the participants? Is this an open group or is it invite-only?
Rebekah Johnson: The members are initially nominated to the FCC and then the FCC will appoint the membership. So as far as the members that we see in this group, it's the obvious participants: it's 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, Anis, is this is the industry that we work with, these are the who's-who, and 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.
Anis Jaffer: Can you share some of the best practices?
Rebekah Johnson: When the FCC identified this group and charged them to define the Best Practices, they gave them a list of questions that they wanted them to address. The first question was basically, “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 Jaffer: So right off the bat, the FCC clearly understands that the core issue is, “How does a service provider accurately identify a caller?”
Rebekah Johnson: Exactly. So from there, the FCC inquires about the application of the accurately identified caller to the authentication framework. And Anis, these are going to be some questions that I'm going to ask you about, “how do we apply this?”
But first, let's just dig a little deeper into the Best Practices recommendations. To answer the FCC’s core question of identification, the Working Group dissects several definitions of who is actually being identified. Who knew that was going to be complex? But it was. We have 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 who the called party should be informed of who is calling.
Anis Jaffer: So when you're saying entity, just so we are all on the same page, you are referring to the Enterprises, right? Like the hospitals, the schools, the government agencies, the pharmacies, and resorts, and so far and so on, is that correct?
Rebekah Johnson: Correct. So, what we’re identifying are the types of entities as opposed to individuals. Individuals are still a requirement if you think about, for the wireless carriers that are subscribing to an individual, they have their set of vetting that they do for individuals. But for a company, a hospital, a retail pharmacy... this is a very different type of vetting. So when we look at what the service providers are going to have to do, they're going to have to collect more than just the name and address. There are business details to collect and verify such as EIN, you have the duns number for corporate website, articles of incorporation, business address, you also have regulatory and legal enforcement against the company, and the type of calls being delivered, and so on. So it’s really complicated.
Anis Jaffer: But the concept of Enterprise vetting, that itself is not new, right? I mean, we've seen this in other industries. It sounds very similar to Know Your Customer and policies that are applied to combat money laundering and illegal financing and things like in the financial landscape. So, the same concept is now being applied to communications?
Rebekah Johnson: That's right, Anis. And what's different about this whole Know Your Customers type concept is that it's the voice service providers that are the ones that have to do this. This is not a level of vetting that 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 read 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, which is great, are at the discretion of the service provider. There is a high level of expectation as stated in the FCC’s supported Best Practices. In multiple instances, there's this statement that is reiterated, and I believe it is also reiterated in the standards themselves, and it says, “A provider's reputation is tied to the rigor of its evaluation process.”
So Anis, as an industry as a whole, we need to take seriously our approach to establishing authenticated caller ID information.
Anis Jaffer: 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, is that correct?
Rebekah Johnson: 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 with understanding the burden. This really is a burden that's being placed on them to provide that accurate caller ID information with an authenticated call. I think what we have is many believing that they just have to purchase a call signing solution, which we see on the market, everyone is promoting it: implement this solution and you're done.
But Anis, that's only the mechanism, right, to deliver the authenticated and authorized identity. Am I right on that?
Anis Jaffer: Right, 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 easier to handle, it’s straightforward. You know the customer, the service provider has issued the number and you can attest with A or clearly identify the caller.
Now, the complex scenario happens when the Enterprises 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 to an extent.
But 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 if the Enterprise really has the authority to use that number.
Rebekah Johnson: Anis, before you move on, I have a question about that. With these options that are being proposed to solve this problem, do you get a sense for how service providers are going to approach this? Are you seeing service providers really exploring and trying to make a decision on what their local policy procedures are going to be?
Anis Jaffer
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 extending beyond that due to either Enterprises that got numbers from another service provider but using a provider to another provider to make a call, or if there are multiple layers. This is still a little bit of an unknown, That's the reality right now. There are models, there are local policy solutions that 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.
Rebekah Johnson: One of the interesting, I don’t know if I can call it a trend yet because it has to happen more often than what I've seen yet, but I've noticed inquiries coming into us with regards to approaches to provision their own numbers. So instead of having the policy to accept other numbers coming in, they want to change their policy to be: “You have to use the numbers that we provision.” Do you think that's a good approach? Might there be some pitfalls with that?
Anis Jaffer: Well, you're forcing the Enterprise to pick one or the other and the Enterprises have being used to taking one number and then using another provider for making calls. It’s how all their systems and infrastructure and a vast majority of them are set up to do that. And there are scenarios if you are an Enterprise and you are using another BPO or a call center to make a call, you would give them the numbers, the example 1-800 number that you want to use, you can give it to them and then they can use it and that BPO or the call center may or may not, they don't know the number, so it is going to be a lot of change if you're going to force everybody to get the number and then use a particular service provider to make a call. So that to me is going to disrupt and create more problems than actually offer a solution.
Rebekah Johnson: So if we’re going to tie this back to the TRACED Act a little bit here, we’re talking about all of the steps that you have to take to get the accurate identity and it's one of those things that if I don't get it accurate then what’s the ramifications? If there are no ramifications? How much effort am I going to put into making sure that I have all of these policies and procedures before I even sign a call?
And I think it’s something important that we need to consider. We don't have answers just yet on what happens if a call is inaccurately identified? When I looked at the TRACED Act just to try and get an idea of where we are going with this, what does Congress expect?
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. So what I'm interested to know is 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? Who's at fault for presenting inaccurate information? 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, I don't know if those are things that you’ve thought about as well, Anis, with regards to the flip side of when we get the information incorrect?
Anis Jaffer: It’s 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 think a lot of those things will play out and we'll have to see what happens and depending on what kind of input they gather, then we could see some changes or proposed regulations in terms of how do you manage that. But right now at this point, it’s still open, that's how I see it. I would, as a service provider, if I am looking at this I would try to get a local policy implemented, or a solution implemented, where you can 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 reasoning behind whether the call was labeled A, B, or C. And have that process and procedure in place so at least you would have some kind of data to back up what you did. That, I think, is what is needed and I also think that’s what the TRACED Act is trying to tell. That's what you need to do as a service provider to start with and then figure out what happens once it gets implemented.
Rebekah Johnson: That's a perfect segue, Anis, to our first question that we have from Christian. I think Molly is going to ask the question related to that.
Molly Weis: I am, thank you. This is a great question that was submitted in advance: 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) if they do get a B level attestation versus a B level, how will that impact what subscribers experience on the terminating side when called?
Rebekah Johnson: Alright, Anis there are two questions, you get the first and I get the second.
Anis Jaffer: The first one, 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.
So again it comes back to what policy they implemented and how they are treating that Enterprise as well as that number. If they believe, 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 can 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 Johnson: So the second part of that question: if it goes to a B-level attestation, how will that impact the subscriber's experience? Because it’s all about contact, right? We have to get this call delivered. From what we've seen thus far, I think this is something that 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 and a level as far as presentation to the subscriber.
Where it may make a difference is with regards to the analytics on the terminating side and I think this is still an exercise and a test for the analytics providers for them to figure out: 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.
So perhaps maybe that means something on the analytics side; we don't know what it means. A B-level, I don't feel that should be interpreted untrusted because we're going to have the scenario that you just talked about: the challenge around what an originating carrier does with a number that they did not provision. Guess what? That's the challenge for everybody. That's not unique to one service provider, so everybody in the industry has the same challenge. So I do not see terminating carriers treating a B -level attestation as though it should just be blocked, I don't see that. Unless, Anis, you have a different opinion than me/
Anis Jaffer: No, I don’t think I differ too much. It could be that A could get a verstat or a verification check, 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 her tick mark, the chances are that I would answer the first one and not the second call. 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, whether what kind of algorithms are employed at that particular subscribers 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 verstat check if you get a B-level, I would be surprised if somebody gives that check.
Rebekah Johnson: I like the way you actually stated that and I feel like it's been stated before. But there are really two things to look at. We need to look at what the experience is during the time-of-call and then what the reaction is by the subscriber. I think that's something we need to be monitoring going forward based on all these different variations.
So I think on that note, we are running out of time so let's get to some audience questions. Let’s go with your pre-submitted question, Molly.
Molly Weis: So pre-submitted online was a pretty good one: What recommendations do you make to call originators who want to make sure a hundred percent of their calls are going to be A-level attested?
Rebekah Johnson: 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 the 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, well Anis just mentioned several different options for 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. That's just something that I would like to see. Anis maybe you’ve got some thoughts around that as well.
Anis Jaffer: I would agree with what you said. It depends on the service provider. As a call originating we would have to work with your service provider to figure out what their local policy is and 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 in place. But that's where I would start, to understand how your particular service provider has implemented the solution.
Rebekah Johnson: On that note, we’d like to thank everyone for joining us on another Tuesday Talks session. We love hearing questions and appreciate your participation.
In our next session will be diving into why STIR/SHAKEN doesn't fully address authenticate caller identification information. The assumption across the industry is that implementing the STIR/SHAKEN standard will provide identity in the form of an authenticated caller ID name to the subscriber, but it's not really as simple as that. So join us on Tuesday, March 9th at 3 p.m. EST to learn more. Send in your questions and we hope to see you there! Thank you.
.png)
