The communications industry describes the STIR/SHAKEN solution as an authentication framework, which captures the ATIS IP-NNI Joint Task Force’s intent of achieving a solution based on truth. Still, the process of getting to that end state of authenticated information is a bit more complicated than that. When it comes to understanding how call delivery will change post the June 2021 STIR/SHAKEN deadline, it’s important to consider the challenges and requirements faced on both the originating side of the call (via your originating service provider or OSP) as well as the terminating side of the call (your call displayed on the called party’s device, likely on a different network from which it originated).
So, let’s dive in on the origination side of the call.
When a service provider originates a call they must implement what is known as a local policy or solution to determine how they’re going to authenticate and attest the call. This does not mean that the caller ID itself is authenticated, but if the service provider knows who the call originator is and has a direct relationship with the number, they can attest the call as Level-A.
If the service provider does not have a direct relationship with the customer or number, then they would instead attest the call as a B or C. It is important to note that the levels of attestation do not necessarily correlate to their trustworthiness, so analytics will remain in place for call validation treatment (CVT) against unwanted, scam, or illegal phone calls, which will be labeled accordingly.
Complex scenarios exist where a prescribed attestation level is not obvious, resulting in what is known as the Enterprise Challenge or Attestation Gap. To address this gap, multiple models have been presented in the Standards Group, including Delegate Certificates, sometimes referred to as Identity Certs or Enterprise Certs, a Centralized Registry or Database, and other Out-of-Band Solutions which lie outside of the Standards Group.
In the most widely discussed delegate certificate model, the originating service provider receives a delegated cert from the call originator which is used to authenticate the call. The certificate itself contains the name of the enterprise, the numbers associated, and a certificate authority who has been authorized by the STIR/SHAKEN GA. This model allows for the addition of rich call data (RCD), which can include a logo, name, and call reason that can be displayed, depending on the terminating user device.
One challenge with this model is its renewal. Needing to be refreshed at periodic intervals to prevent spoofing, the question becomes: how do you make sure that you have the most updated certificate?
The other challenge is the revocation list: what happens if a certificate is revoked or has been compromised? A revocation list would need to be synced and display real-time information for a large user base to tap into.
Similar to a traditional CNAM Database, this singular repository would house all the information related to the numbers stored within it. Enterprises who own the numbers, entities who have access to those numbers, and those who are making calls on behalf of those numbers would have access to the database to view this information.
Again, the challenge would be how to keep all this identity and phone number data in sync and consistently renew it with accuracy. In addition to questions surrounding who has access to the database, who controls the information being added? What happens if the data, or the database itself, were to be compromised?
These enterprise solutions pass the data from the origination side to the terminating side over the data network instead of using the communication or PSTN network typically used for making the call.
For example, Google has introduced their Google Verified Calling Solution where the entity and its numbers are verified beforehand and stored in a Google Call Server. Before the enterprise can make the call, they have to place a request to register the call with Google identifying who they are calling and which number they are calling from. Google then knows that a verified identity is making that call and can send the data to a Google Verified phone. Since this data is short-lived, there are fewer issues with compromised information, however, it is a solution very dependent on the Google ecosystem.
Regardless of the model that is implemented, attestation flags sent by the originating network are used by the terminating side to determine whether the call can be authenticated. When a call is being authenticated, the verification service would update a verstat parameter which is then updated as “TN validation passed,” or “TN validation failed.”
Call validation treatment is provided by an optional analytics service using reputation data sources to determine if a number is considered fraudulent or spam. This information is then used as a displayed overlay on the user device to show if a call is labeled ‘Spam,’ ‘Scam Likely,’ etc. This service could either be a carrier application service or be implemented as a third-party solution, for instance, all the major U.S. carriers use third-party analytics for call blocking.
If a call is authenticated from origination to termination with the CVT determining the status of the call as valid, the information is passed to the user device which can then display a green checkmark or [V] or call name.
It is displayed depending on the user equipment’s capability to display rich call data (RCD). With its own authentication standards after STIR/SHAKEN, RCD can deliver information to a called party that will inform them who is calling and why, however, it is not required.
Delegate certificates allow RCD to be added to the header, however, adoption of it is still early. Certain Out-of-Band solutions, like Google Verified, have already begun introducing RCD by verifying the information ahead of time and bypassing the communication network. Since there are a lot of networks that are still TDM-based and cannot handle SIP headers, the proposal that has been presented is to send this STIR/SHAKEN information using the data network, basically an out-of-band solution.
As the June 30th, 2021 deadline for STIR/SHAKEN implementation approaches, the expectation for the industry will probably be the implementation of one or possibly multiple solutions to address call authentication on the originating side and how the terminating side will update their network to validate incoming information traffic. The first step is to have STIR/SHAKEN implemented by as many carriers and networks as possible and have RCD added over some time as devices evolve to handle those complex display capabilities.
This April, the FCC created a Robocall Mitigation Database to enforce TRACED Act requirements mandating the implementation of a caller ID authentication framework at the network-level. All voice service providers must file a record in the new database before June 30, 2021, providing detailed information regarding their implementation of the STIR/SHAKEN caller ID authentication framework and/or a robocall mitigation program.
Voice service providers who have not yet implemented the STIR/SHAKEN framework may also request an extension to the deadline if they provide a comprehensive plan to implement a robocall mitigation solution in accordance with TRACED Act requirements.
Spoiler alert: you can’t.
Neither the FCC nor the IP-NNI SHAKEN standards group has defined requirements related to the presentation of a STIR/SHAKEN authenticated call with A-Level attestation. In the March 31st, 2020 Report and Order, the FCC declined to establish mandates or requirements related to the display of STIR/SHAKEN verification results and fully expects terminating voice service providers to provide the best solutions for their subscribers.
While all legitimate calling entities are right to expect and want all calls to be displayed with a green checkmark, due to the infrastructure of the network, lack of standards or federal mandates, and limitations of device manufacturers, it’s not currently possible to guarantee or fully control the display of your calls. That said - taking the steps to ensure your originating service provider has either built, in-house, or is working with an industry partner to ensure your calls properly enter the STIR/SHAKEN framework with your identity properly associated with your phone numbers is within your control.
Endeavoring to shed light and bring truth on emerging topics in the communications industry, Numeracle’s CEO and Founder, Rebekah Johnson, alongside our Chief Product Officer, Anis Jaffer, have begun a biweekly live discussion series-turned-podcast, Tuesday Talks. Our first two-part series delved into how the STIR/SHAKEN framework authenticates caller identity, beginning at origination all the way down to termination...
To listen in on these and other full episodes of Tuesday Talks, visit https://www.numeracle.com/tuesday-talks, or check out our STIR/SHAKEN Knowledge Center for additional information around the rollout of the STIR/SHAKEN call authentication framework.
