Rebekah Johnson: Welcome to Tuesday Talks, a live discussion series where we shed light and bring truth to emerging topics in the communications industry. I'm Rebekah Johnson, 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. Although we had hopes of covering What it Takes to Authenticate in one podcast session, we quickly realized during the last episode that this was a two-part series. So we covered the origination side of What it Takes to Authenticate last time, and today we will cover the termination side, including display to subscribers.
Before we get started, Rebekah, would you provide a recap of the origination side as it relates to authentication?
Rebekah Johnson: Good idea Anis, and I promise not to rehash the definition of authentication or any other word, at least not in today's episode, but I make no promises of the future. I love words so I'm bound to explore definitions again.
But for the sake of today's talk, I'll recap for an understanding of the work occurring on the origination side which feeds into the terminating side. So first and foremost, the originating service provider must establish a local policy for how they will attest to the authenticity of the calls originating on their network. Now, this will be achieved through policy and procedures with the help of identity management tools if needed. The indicator in SHAKEN that relays this authenticity is through the Attest Claim, which can be one of the following three values: A, B, or C, as defined in the ATIS Standard.
We also learned an originating service provider’s reputation is dependent upon how rigorous a local policy they implement when making the claim of A. Meaning, the identity of the caller, and authorization for use of the TN can be proven.
So, we concluded part one of What it Takes to Authenticate exploring the challenges related to the gap between the originating service provider and the identity of the caller due to the presence of call centers, BPOs, and communication platform providers. Several options were discussed, each with their respective pros and cons. The expectation is the industry will probably land with one or maybe possible multiple solutions. But for the success of authentication at origination, we concluded on the possibilities of adding rich call data (RCD) to enhance the experience for the called party on the terminating side. Should the terminating carrier trust the information provided at origination? Thus bringing us to Part Two of today's Tuesday Talks, What it Takes to Authenticate: Termination and the Green Check Mark.
Anis, where should we start on the termination side? Can we go straight to display? Or is there a layer of complexity for validation we need to explore before the terminating carrier makes the final decision of displaying the green checkmark or not?
Anis Jaffer: Well, to understand what happens at call termination, let's first talk about the various components involved. First, we have the terminating network: this is the service provider where the call is terminated. Then you have the user device which is where the call lands, however, you can also have another component used by the terminating service provider for call validation. This is the analytic service that some providers use. So, in STIR/SHAKEN when the terminating network receives the call, they would first verify the signature received as part of the SIP header. This verification service would determine whether the call received is from a trusted source or not.
We talked about Attestation Flags last time, so the attestation flags sent by the originating network will be used by the terminating side to determine whether the call can be authenticated. So assuming the call is authenticated, the verification service then would update a parameter, what is called a Verstat Parameter. If the call is authenticated the verstat parameter would be updated as “TN validation passed.” If the call is not authenticated, then the terminating service provider would set it “TN validation failed.” In this case, they can also block the call.
Rebekah Johnson: So, you mentioned various components that are involved, and that last one you mentioned was call validation. I’ve heard this referred to as CVT or Call Validation Treatment. Would you explain that portion just a little bit further?
Anis Jaffer: Correct, CVT is nothing but the analytics service that service providers can use, and it’s an optional service. CVT, as you said, stands for Call Validation Treatment. After the carrier verifies the result from the SIP Header, the CVT uses analytics and reputation data sources to determine if a number is fraudulent or spam. This information is then used as an overlay on the user device to show if a call is labeled as ‘Spam,’ ‘Scam,’ ‘Nuisance Likely,’ etc...these are all the results of the analytics. This could either be a carrier application service that's drawn as part of the verification we talked about earlier or, it can be implemented as a third-party solution. For instance, all the major U.S. carriers use third-party analytics for call labeling.
Rebekah Johnson: So at this point, you’ve established the validation process of the authenticated call in the terminating carrier network. I would say we all should accept and acknowledge that analytics will continue to exist post STIR/SHAKEN adoption, and really, all of this is contributing to the efforts of preventing calls from terminating on the subscriber's device that's fraudulent. We already see this today so you know with regards to the display, where do we go with the green checkmark? Where does this fit in?
Anis Jaffer: So we talked about carrier verification and analytics. The green checkmark is actually on the user equipment or the end device. Let's say the call terminates at the network level, verification is done by the verification service, TN validation is passed, and the verstat parameter is set as “validation passed.” At this point, CVT does its check, and let's say the number is determined as ‘Not Scam’ or ‘Not Spam. So at this point, the CVT can pass this information to the user device or an app running on the user device, which can then display a checkmark, typically a green check, or it could be a character V.
This really depends on the user equipment. In the case of smartphones, you can display the checkmark but in the case of devices with limited capabilities that display text-only, a simple indicator, like a letter V, can be used. For instance, Comcast recently announced a rollout of STIR/SHAKEN across the Xfinity Voice Over IP-network. They leverage both for displays that are capable of displaying the green check and for character or display-limited devices, they display the letter V.
Rebekah Johnson: Speaking of Xfinity, we led a proof-of-concept to test delegated certificates with Comcast, who was serving as the terminating provider, and Twilio as the originating provider. Through our Identity Management Platform™, we were able to verify the identity, authorization for use of TN, and elevate this information to Twilio via a delegate certificate provided by NetNumber. The thing about Comcast and why they seem to be progressing very quickly on the display side of termination is their control of the display on the TV and their mobile service.
So, is the display dependent upon the user and the equipment?
Anis Jaffer: Yes, and that's a very important layer that influences how the calls are displayed on the device. Assuming verification process CVT checks and calls actually land, the app running on the device can layer its data on top. It could be a green checkmark, it could be a CNAM look-up where it can pull up the caller’s name, or it could look up its own data source for logo and call reason for that number and display that. There are several apps that do this today and usually they use pre-loaded data either from an internal database or by connecting to a third-party data source. They match the number to the corresponding name, logo, and call reason, and they overlay that information on the device. Today typically it’s caller name, but more and more we are seeing rich call data and logos showing up.
Rebekah Johnson: But doesn’t the rich call data provide information, such as logo and call reason, as part of the STIR/SHAKEN certificate, like what we discussed about delegated certificates?
Anis Jaffer: There is a way to pass RCD over SIP as part of the SIP header. An originating service provider can add an RCD claim and when that information is received by the terminating service provider, they can choose to display this information on the device. However, this is not part of the BASE STIR/SHAKEN specification and the originating service provider does not have to do this. The delegated cert specification allows RCD to be added to the header, however, adoption is still early. We have to get through the STIR/SHAKEN implementation first, to take full advantage of RCD claims on the SIP header.
Rebekah Johnson: I think it’s safe to say that the terminating service providers are probably thinking more about, “What do I have to do to achieve the June 30, 2021 deadline for just getting it implemented?”; RCD is that “wonderful nice-to-have.”
It really does seem like there's definitely a lot of work yet to be done for the rich call display but, Anis, I'm already seeing solutions on the market to deliver this data. So can you explain how this is happening without STIR/SHAKEN fully deployed?
Anis Jaffer: Good question. You’re right, the STIR/SHAKEN implementation is ongoing, in the meantime, there are some other solutions that have sprung up. These are essentially using the data network to transmit rich call data to the user device by bypassing the communication network; these are called out-of-band solutions. For example, Google introduced Google Verified Calls, which works this way.
Rebekah Johnson: So out-of-band, I guess that means out-of-telecom-band, so what exactly is this and how does it work?
Anis Jaffer: In an out-of-band model the originating enterprise and its information, such as business name, logo, the numbers they are using, and the reason for those calls, are registered ahead of time with the service. Then when the business originates the call, they can attach the From: Number and the To: Number to the service right before the call is made. They have to do this right before the call because this information is short-lived and it is only alive for a few minutes. And you have to do this for every call that a business makes. As the out-of-band service knows, the business originating the call has been pre-verified and the number has been associated so they can then push this data to the specific device that the business is trying to connect to.
In the case of Google, they can push this information to a specific Google device and as soon as the call lands on the device, Google can overlay the logo and call reason when the call rings at the user device. So as the data is sent, not using the communication network but essentially using the data network, it's called out-of-band.
Rebekah Johnson: That is going to raise a lot of interesting concerns for me with regards to if it's outside of the communication network, then are they outside of the Standard?
Anis Jaffer: Yeah, that's a tricky question to answer. It's outside the Attest or STIR/SHAKEN Standard, but they are part of an IETF STIR Standard called STIR Out-of-Band. So it’s not something that's completely out of standard specification. In fact, even in the case of STIR/SHAKEN, there are networks that are not fully SIP enabled and this method can be used to pass data. Surprisingly, there are a lot of networks that are still TDM-based, and since they cannot handle SIP headers, one proposal that has been presented is to send this STIR/SHAKEN information using the data network, or basically, an out-of-band solution.
Rebekah Johnson: Anis, I really want to thank you for taking the lead on answering all my questions. Normally you’re asking me some questions but you’re the one that's living in the space more than me at this point. So you are perfect to field the questions; it was great to hear your perspectives.
What I'm trying to take away from this is there's really a massive amount of effort that has to go into authenticating a call. There are efforts on the originating side that we covered in our last talk with regards to the local policy and the owners on the originating service provider to really implement the heart of the TRACED Act, which is, “Let's keep the bad guys off the network.” So it starts at origination and all the work and effort that goes in there. Then once you do originate your call traffic, the terminating side now has to update their network to validate the information that's coming into the network to make a decision.
I view this as more of a plan B; plan A is, “let's make sure that the originating carrier has a local policy that prevents bad network from getting on the network.” But if they don't have that implemented and the traffic is traversing across their network and it gets all the way down to the terminating side, then the terminating carriers have to implement their own procedures more than just passing along the header information. That's why we still see CVT being a part of the terminating carrier side because they have a responsibility to protect their subscribers from fraudulent calls.
While I'm hopeful for a June 30th, 2021 deadline, I don't believe that we're going to see an environment where authentication from origination to termination exists throughout the network; it's going to be a mix. I think we're going to have to continue to watch the progression of where this goes and how the industry responds. Especially, it seems the terminating carrier side has a lot of control over what eventually gets displayed no matter what you do on the origination side.
Give me final thoughts on that, Anis, before we close out our topic.
Anis Jaffer: As you said, at the end of the day the call gets terminated and the user device has to display the information. You can add the information at origination, but then it needs to get transported first to the terminating service provider, and then they have to figure out how to send this data to the end device. Then we have this added complexity of multiple service providers that are not SIP-enabled, there are several TDM-based networks, so how do you pass the information through their network? Calls don’t go on a single hop, there are multiple hops that happen before the call actually goes from origination all the way down to termination, so there is also this added layer where you should be able to send data.
I think the space is going to be evolving; the first step is to implement STIR/SHAKEN and get as many carriers as possible and networks as possible to handle that. Then over a period of time, then we'll be able to add rich call data. In the meanwhile, devices also need to have the capability to display the information and how they do that, so that is also evolving. We saw Google doing something, there could be similar things done by Apple, but we don't know at this point. So it’s interesting, we’ll have to watch and see how this evolves.
Rebekah Johnson: Let's turn our attention to any audience questions. Molly, if you can help field?
Molly Weis: Absolutely. We have a really good three-part question here. I’ll go through all three quickly and then we can take it piece-by-piece. This question is about the use of STIR/SHAKEN for presenting the Verified Check Mark.
Part 1) Do you know what percentage of major providers are using the STIR/SHAKEN outcome to display a checkmark?
Part 2) Of those, what percent display the checkmark in real-time before the caller answers (versus the AT&T iPhone approach where the checkmark seems to be available only in the call log post-call)?
Part 3) What percent of providers are requiring A-Attestation to get a checkmark versus a B being good enough?
Rebekah Johnson: Yeah, we would love to know too. Just some honest answers here.
I think to the point that we covered earlier in our talk with regards to the terminating side, in the efforts to be honest with you, if I was a terminating carrier the display aspect would not be the top of my priority. My top priority would be making sure that I can comply with the June deadline and that's just to get the system implemented. You don't have to display anything just yet, you don't have to go to that level with regards to the green checkmark. However, with regards to green checkmarks used, yes, they are being used. It's very simple to do, it was one of the first ones within your own network:
(Anecdotal Example): “I’m T-Mobile and T-Mobile gave me a device, I went in and they verified my identity. They also proved that I have the authorization to use the phone number associated with me. That's why when I call my kids, the green checkmark displays and my kids won't answer because it's validated it's “Mom,” which is usually because I want them to do something.”
That's already existing today, the technology exists. What we've been discussing this whole time for over a year, is, “How do we get that information down to the Enterprise?” Because we still have the same thing: you have to verify the identity and authorization for the TN. It’s really challenging to do for Enterprises. So the system is set up and ready for that, it’s just, “How do we get that verification down with that A-Level for Enterprise calls?”
Anis, I’ll let you add some more to that.
Anis Jaffer: I think you covered it. With regards to the specificity of the question about what percentage, right now I think everybody is trying to implement this; we really do not know how many are actually doing this. But what we have seen, as you mentioned, if it's the same network whether it’s within T-Mobile or Verizon, they’re doing it. Across networks there are some interconnects that are being tested, but I think part of the challenge is that calls don't go all over SIP networks so sometimes they hop over networks that don’t support this. And because of that, it's not fully implemented. I know that Bandwidth was working with Comcast, and there were other providers that were working as interconnects to get this tested and implemented. But percentage-wise across the industry right now, at least, we don't have the stats.
Hopefully, we'll get to know soon and I think we do have a session coming up, we’ll have a special guest who would address some of these questions, so this is a question I'm going to take for that session.
Rebekah Johnson: With regards to the display, it really comes down to an iPhone versus Android, it's not necessarily carrier-specific. iPhone controls the world so they control the device and they don't allow for the real-time display, but you can go through your call log. However helpful that is to the subscriber I don't think that it is. You need to know the validation at the time-of-call so that you can make an informed decision of whether or not you want to answer the call, but we'll have to wait and see if iPhone will ever allow that to be in real-time. I think carriers are working with them to get to that point, but that is a challenge.
So again, here we have all this work and effort on the originating side, the terminating carrier has implemented, and then guess what: the device doesn’t want to display it; that’s the challenge.
Molly Weis: Let's take one that was asked pre the sessions. This one is: How do you ensure your caller IDs aren't flagged in STIR/SHAKEN?
Rebekah Johnson: To ensure that your calls are not flagged in STIR/SHAKEN, analytics will continue to exist on the terminating side because it will be part of the robocall mitigation plan for a terminating carrier; it’s smart that they do that. That means you still have to register your numbers and that is outside of STIR/SHAKEN. With Numeracle that's one of the things that we offer, and there are other providers that do the same, but you cannot get away from the registration aspect.
To be honest with you, what we're doing here is creating a connection between who's the one that's vetting and validating who this entity is and the authorization for the TN, and it creates a really tight link connection between the analytics and the one who's doing the registration. So that elevates the level of trust; this is really a trust issue here on the network. Until we get to that point where maybe delegated certificates are seen to be viewed as a trust such as registration, I think it's going to take a while for you to be able to back away from the registration aspect. That’s my recommendation based on where we are today.
Anis Jaffer: To add to that, as part of STIR/SHAKEN you would have verification, which is done to verify the actual header, and then you have the validation treatment, which is the analytics. Both are done together; the first part is verification. Once verification is done, which basically is a binary output saying whether the call can be trusted or not, and then after that, the analytics is going to determine whether that call is ‘Spam’ or not. You could still have a call that got authenticated but it could be labeled as ‘Spam,’ it could still get flagged as ‘Spam’ even though the call is authentic or it originated from a service provider that has already verified the customer. It could still happen that when the call actually lands on the device, it could be labeled as ‘Spam.’
Rebekah Johnson: And Anis, that's one of my big soapboxes that I like to get on with regards to the unwanted, which essentially means ‘Spam.’ That’s just never going to go away. Basically what the federal government is telling the industry is that some subscribers just really don't like your calls and don't want your calls. It doesn't matter if you’re a legal company and you’re following all the rules. This is going to hurt political campaigns, charities, and it can hurt some aggressive marketing tactics from legal businesses. You're just not going to be able to get around it.
This is part of why on the FCC’s Robocall Strike Force, I was sitting in the Empowering Consumer Choice, that’s exactly what got deployed: empowering consumer choice. The fraudulent is not the Consumer Choice side, it's the ‘unwanted’ that's the Consumer Choice side. And the consumer can now say, “I don't want your call, this is an unwanted call.” Now, unfortunately, I wish this would have stayed within the realm of TCPA consent. I don’t mean to put on my “regulator hat” here, but that's the consent between the one who is delivering the call and the one who is receiving it. It really should have stayed with them saying, “Business A, I don't want you to call me anymore,” so just remove your consent and we don't have this problem.
But for some reason, it's too difficult for subscribers to opt-out of some communications. So for those who perhaps ignore the opt-out request, they continue to send these deliveries and these calls, now the consumer is equipped with the power in their hands to go, ‘Spam.’ And then now that affects all of your calls, not just the one that didn’t like your call. That’s the challenge.
Anis Jaffer: Because the analytics use that as part of their data to determine whether a call is ‘Spam,’ or not. They use user-provided feedback so even if a bunch of users are tagging as ‘Unwanted,’ then that's going to get in as a part of their algorithm and that’s going to flag a call as ‘Spam,’ or ‘Unwanted.’
Rebekah Johnson: Thanks, everyone for joining us today on another episode of Tuesday Talks. We’ll see you again on Tuesday, April 6th, where we will be discussing STIR/SHAKEN progress from the service provider perspective. We hope to see you there!
.png)
