Government Affairs

STIR/SHAKEN and Robocall Compliance Seem too Complicated and Burdensome? STI-GA Announces Policy Changes that Improves the Process for Voice Service Providers and Enterprises

August 05, 2021

The Secure Telephone Identity Governance Authority (STI-GA) recently announced two policy changes that are designed to make the STIR/SHAKEN ecosystem more efficient. The first change concerns allowing optional use of delegate certificates in order to enable voice service providers (VSPs”) other than the originating carrier to provide the highest level of attestation that carrier sends an outbound call using a number assigned by another entity. The second policy revision authorizes Responsible Organizations (Resp Orgs) – the entities that assign toll-free numbers to customers – to access Service Provider tokens.

Delegate Certificates Streamline Attestation

STIR/SHAKEN allows originating service voice providers (OSVPs) to attest to the calling party’s authorization to use a telephone number for a call. Delegated certificates work in situations where the provider that issued the number doesn’t know the end customer who was assigned the number. A brief review of the STIR/SHAKEN process is instructive.

The STIR/SHAKEN governance model consists of:

  1. Governance Authority (“GA”). A “Board of Directors” that influences policies and standards. The GA is made up of industry representatives from carries and equipment manufacturers.
  2. Policy Authority (“PA”). A “steward” selected by the GA that manages the enforcement of issuing tokens to carriers. To enable STIR/SHAKEN, a carrier needs to obtain a token from the PA to ensure it is an authorized service provider.
  3. Certificate Authority (“CA”). Trusted third parties approved by the PA that issue certificates to carriers wishing to originate calls. To ensure the requester’s eligibility, the CA validates the credentials of the requester with the PA.
  4. Service Providers. Create SHAKEN PASSporTs to attest to call authentication. The PASSporT is cryptographically signed and includes a reference to the SHAKEN certificate that relying parties use to verify authentication.

STIR/SHAKEN relies on an OSVP’s attestation of a subscriber’s identity. Depending on which network a call originates, an OSVP can provide one of three different levels of attestation:

  • Full or “A” Attestation. The OSVP can confirm: (1) the identity of the subscriber making the call; and (2) that the subscriber is using its associated telephone number.
  • Partial or “B” Attestation. The OSVP can confirm the identity of the subscriber but not the telephone number.
  • Gateway or “C” Attestation. The OSVP can confirm only that it is the point of entry to the IP network for a call that originated elsewhere, such as a call that originated abroad or on a domestic network that is not STIR/SHAKEN-enabled.

There are many scenarios where a SHAKEN-authorized service provider does not have the information necessary to sign a call with full attestation. A typical example is where an interconnected voice over internet protocol provider (iVoIP) obtains direct inward dial numbers (DIDs) from a telephone number service provider and issues these numbers to its customers. The telephone number service provider doesn’t have a fully attestable relationship with the customer, but the iVoIP Entity does. This situation presents difficult problems:

  • The iVoIP may not be authorized to authenticate calls with SHAKEN. One of the requirements is that the OSVP has access to numbering resources. The iVoIP can originate the call but cannot authenticate them with SHAKEN.
  • The iVoIP could arrange to have an upstream approved provider sign the calls as a value-added service. But then the signing provider might not be willing to give full attestation. Furthermore, the iVoIP would have to send all calls through that one provider, losing the ability to do least cost routing across several upstream providers. This is a difficult business decision for the iVoIP.
  • End customers want their calls signed with full attestation. They also want affordable phone service. They’re going to have trouble getting that from the iVoIP Entity for the reasons stated herein.

Delegate certificates can help alleviate such situations. For example. the telephone number (TN) service provider issues telephone numbers to the iVoIP. The TN service provider knows the iVoIP Entity customer, and it knows the numbers. It doesn’t know which end customers will get which numbers. The missing information is provided as follows:

First, the TN service provider requests a CA certificate from the CA. A CA certificate is different from the usual SHAKEN certificates used to sign calls. The CA certificate is used only to issue delegate certificates.

Once it has received a CA certificate, the TN service provider acts as a subordinate CA and issues a delegate certificate to the iVoIP. This delegate certificate lists the telephone numbers that the TN service provider issued to the iVoIP. The delegate certificate also establishes a chain of trust from the delegate certificate, to the CA certificate, to the CA root issuing certificate, to the CA root certificate.

With the delegate certificate, the iVoIP can now authenticate calls for its end customers. The iVoIP creates a base PASSporT as an indication that they know the calling party and their association with the calling number. Alternatively, the iVoIP could create an RCD PASSporT if they wish to include Rich Call Data (RCD). The iVoIP cannot use a delegate certificate with a SHAKEN PASSporT.

The terminating service provider will verify call authentication using the base or RCD PASSporT that was signed with the delegate certificate. In addition to the usual verification process, the verification service will verify the scope of the chain of certificates and TN authentication lists to make sure the call information is within the scope of the certificates.

An intermediate SHAKEN-authorized service provider could optionally sign this call with a SHAKEN PASSporT with full attestation, although this is not required. Full attestation would be justified by relying on the base or RCD passport signed with the delegate certificate.

Use of Delegate Certificates by RespOrgs

Today, many toll free subscribers, e.g., call centers and service bureaus, display their toll free telephone number in the caller ID field for outgoing calls.  Many robocallers do the same by spoofing toll free numbers that belong to reputable entities, even including the federal government.  Therefore, it is important for these service providers to authenticate toll free numbers, just like ordinary TNs.  Under the FCC’s rules and industry standards, only the RespOrg associated with a specific toll free number can authenticate the identity of the subscriber associated with a specific number.  In other words, only the RespOrg can provide an A-level certification.

For most toll free numbers, the RespOrg is also the carrier that serves those numbers.  Authentication, thus, works the same as with ordinary TNs; the serving carrier, which is also the RespOrg, issues the token.  However, one need not be a carrier to be a RespOrg.  Some RespOrgs are simply number brokers; their toll free subscribers must also subscribe to toll free service from a carrier.

The new industry policy, affirmed by the FCC, would permit non-carrier RespOrgs to authenticate calls for their subscriber, also using a delegate certificate.  However, this is optional.  Toll free subscribers that display their toll free number in the caller ID field may wish to consider discussing call authentication with their RespOrg.

 

NEED HELP WITH ROBOCALL MITIGATION AND COMPLIANCE?

The CommLaw Group Can Help!

 

The CommLaw Group works with consultants who offer production-ready STIR/SHAKEN solutions. These solutions combine complete STIR/SHAKEN services with a comprehensive portfolio of other services, including delegate certificates, fraud prevention, least cost and much more.

Given the complexity and evolving nature of the FCC’s rules, regulations and industry policies & procedures around Robocall Mitigation and Compliance issues (e.g., Stir/Shaken, TRACED Act, FCC Rules & Regulations, US Telecom Industry group, ATIS, NECA, VoIP Numbering Waivers, Know Your Customer (effective May 6, 2021) and the private sector ecosystem), and anticipating the potential torrent of client questions and concerns, The CommLaw Group formed a “Robocall Mitigation Response Team” to help clients (old and new) tackle their unique responsibilities.  The potential blocking of your company’s voice (and other) traffic due to non-compliance is very real, and very scary.  Your company must be certain it achieves sufficient comfort knowing that it is doing everything it can, as efficiently and intelligently as it can, to achieve the level of compliance needed to avoid sleepless nights!

 

CONTACT US NOW, WE ARE STANDING BY TO GUIDE YOUR COMPANY’S COMPLIANCE EFFORTS

Rob Jackson – Tel: 703-714-1316 / E-mail: rhj@CommLawGroup.com

Ron Quirk – Tel: (703) 714-1305 / E-mail: req@CommLawGroup.com

Back to all news