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

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.