ATIS announces SHAKEN demonstration using Distributed Ledger Technology

The ATIS Distributed Ledger Technology (DLT) Focus Group recently demonstrated STIR/SHAKEN using DLT to members of the IP-NNI Task Force. Here’s a summary.

Distributed Ledger Technology

Distributed Ledger Technology (DLT) is another phrase for blockchain, which is well known for use in cryptocurrencies such as Bitcoin. With DLT, information is written to a distributed ledger. Once written, the information cannot be changed.

ATIS DLT project

ATIS formed a DLT Focus Group to investigate whether DLT could be used in telecommunications. The group published a paper, Enterprise Identity on Distributed Ledger for Authenticated Caller Use Cases (ATIS-I-0000076) to describe how DLT could be used to validate that calling parties are entitled to use a calling number in complex STIR/SHAKEN situations.

In these scenarios, brand enterprises and BPO enterprise call centers would be vetted in advance by Know-Your-Customer vetters and Telephone Number providers. The vetters would write information to the distributed ledger, which Originating and Terminating Service Providers could use in STIR/SHAKEN.

During vetting, the enterprise and vetters would have the option to provide a statement of the intended use for that calling number. For example, an airline could assign a calling number to an enterprise BPO to make calls about changes in flight schedules. The call reason could be Flight schedule change or something similar.

ATIS announces SHAKEN demonstration using Distributed Ledger Technology

DLT and STIR/SHAKEN

It’s important to note that DLT would be an additional resource used in normal STIR/SHAKEN processes described in the SHAKEN standards. It would not replace or change the existing STIR/SHAKEN processes described in the standards.

DLT SHAKEN call flow

DLT SHAKEN call flow

Image source: ATIS-I-0000076

In the call flow above, the enterprise, or enterprise call center, would have been vetted in advance. Vetting information would have been written to the Enterprise Identity Distributed Ledger, a private blockchain, by pre-authorized vetters, signed with private keys.

During SHAKEN authorization, the Originating Service Provider (OSP) would check the Enterprise DL and use the information to make local policy decisions about attestation. For example, this information could enable the OSP to provide full attestation for a call originated by an enterprise call center on behalf of another enterprise.

Having verified the enterprise caller identity and authorization to use the calling number, the OSP would authenticate the call per the SHAKEN standards.

The Terminating Service Provider (TSP) would not have to do anything special. They would receive a signed call, which they could verify per the usual SHAKEN standards. However, the TSP would have the option to check the Enterprise DL to see if there is a call reason or purpose associated with the enterprise and calling number. If they find a call reason, the TSP could present that to the called party.

Another way to do enterprise calls

You may notice that the additional capabilities provided by DLT and SHAKEN could be provided using other methods, such as Delegate Certificates and Rich Call Data (RCD). Which methods will prevail?

We don’t know yet. Each method has its advocates.

Delegate Certificates and RCD fit nicely into the current SHAKEN certificate framework. There’s very little difference; it just needs to be extended to look further down the chain of certificates and to read RCD claims.

DLT introduces a different technical framework. It has been well tested in the cryptocurrency world, and it is being investigated for supply chain applications and such. There are concerns about scalability and latency in DLT, but these worries may not be an issue with the DLT SHAKEN design, because the ledger is updated during vetting, not during calls, and is only read during calls using an enterprise identifier key to the distributed ledger, which is stored in the PASSporT origid. There would be some additional latency if the TSP checks for call reason in the distributed ledger, whereas that information could already be present in an RCD claim within the PASSporT.

It will be interesting to follow the ongoing development and discussion of both approaches.

TransNexus solutions

We offer STIR/SHAKEN and robocall prevention solutions in our ClearIP and NexOSS software platforms.

In addition, we help service providers with all aspects of STIR/SHAKEN deployment, including registering with the Policy Administrator and filing their Robocall Mitigation certification with the FCC.

Contact us today to learn more.

Request information

* required

This information will only be used to respond to your inquiry. TransNexus will not share your data with any third parties. We will retain your information for as long as needed to retain a record of your inquiry. For more information about how we use personal data, please see our privacy statement.