Delegate certificates improve STIR/SHAKEN for providers and enterprises

STIR/SHAKEN allows originating service providers to attest to the calling party’s authorization to use a calling number for a call. But what happens in customer-of-customer scenarios, where the provider that issued the number doesn’t know the end customer who was ultimately assigned the number? That’s a situation where delegate certificates can help.

Delegate certificates build on and extend the governance and trust that’s the foundation of STIR/SHAKEN. Here’s a quick review.

Triangle of trust

STIR/SHAKEN uses a governance model that provides a triangle of trust. Bad actors, who wish to spoof their calling numbers, cannot participate. This gives relying partners confidence in the call authentication. The triangle of trust involves the following:

  • Policy administrator (STI-PA). Vets and approves certificate authorities and service providers to participate in the SHAKEN ecosystem
  • Certificate authorities (STI-CA). Issues SHAKEN certificates to approved service providers.
  • Service providers. Creates 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 the authentication.

Triangle of trust

Triangle of trust
Delegate certificates would extend SHAKEN to more providers and enterprises


There are three defined levels of attestation that can be used by an originating service provider:

  1. Full Attestation. The signing provider has a direct authenticated association with the customer and can identify the customer. The signing provider also has established a verified association with the calling telephone number.
  2. Partial Attestation. The signing provider has a direct authenticated relationship with the customer and can identify the customer. However, the signing provider does not have verified association of the calling number with the customer.
  3. Gateway Attestation. The signing provider is responsible for putting the call onto the IP network but has neither an authenticated relationship with the customer nor a verified association of the calling telephone number.

Customer-of-customer scenarios

There are many scenarios where a SHAKEN-authorized service provider does not have the information necessary to sign a call with full attestation. However, if we follow the chain along which the telephone number was assigned, the next VoIP Entity may have the necessary information to vouch for the end customer’s use of a number.

A typical example is where an interconnected VoIP provider (i.e., VoIP Entity) obtains DIDs from a telephone number service provider and issues these numbers to their customers. The telephone number service provider doesn’t have a fully-attestable relationship with the customer, but the VoIP Entity does. This situation presents difficult problems:

  • The VoIP Entity may not be authorized to authenticate calls with SHAKEN. One of the requirements is that the originating service provider has access to numbering resources. The VoIP Entity can originate the call but cannot authenticate them with SHAKEN.
  • The VoIP Entity could arrange to have an upstream approved provider sign the calls as a value-add service. But then the signing provider might not be willing to give full attestation. Furthermore, the VoIP Entity 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 VoIP Entity.
  • 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 VoIP Entity for the reasons listed above.

These difficulties can be overcome with delegate certificates.

Delegate certificates

Delegate certificates extend the triangle of trust, described above, to VoIP Entities that originate calls where the calling numbers were issued by some other telephone number service provider.

Delegate certificates extend chain of trust

Extended chain of trust

In this situation, the telephone number service provider issues telephone numbers to the VoIP Entity. The TN service provider knows the VoIP Entity customer, and it knows the numbers. It just doesn’t know which end customers will get which numbers. Here’s how the missing information is filled in.

First, the TN service provider requests a CA certificate from a SHAKEN Certificate Authority. 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 VoIP Entity. This delegate certificate lists the telephone numbers that the TN service provider issued to the VoIP Entity. The delegate certificate also establishes a chain of trust from the delegate certificate, to the CA certificate, to the Certificate Authority root issuing certificate, to the Certificate Authority root certificate.

With the delegate certificate, the VoIP Entity can now authenticate calls for their end customers. The VoIP Entity creates a base PASSporT as an indication that they know the calling party and their association with the calling number. Alternatively, the VoIP Entity could create an rcd PASSporT if they wish to include Rich Call Data. The VoIP Entity 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 verfication process, the verification service will verify the scope of the chain of certificates and TNAuthLists 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.

Status of delegate certificates

The ATIS SIP Forum IP-NNI Task Force has been working on finalizing the standards for delegate certificates. The standards document was sent to letter ballot in July 2020. Once approved, delegate certificates will extend SHAKEN to more service providers and enterprises, improving the quality of call authentication across the network.

TransNexus STIR/SHAKEN solutions

We offer production-ready STIR/SHAKEN solutions in our ClearIP and NexOSS software products. These solutions are unique in their capabilities to combine complete STIR/SHAKEN services with flexible policy controls and a comprehensive portfolio of other services, including fraud prevention, least cost routing and much more.

Contact us today to explore how we can help you implement SHAKEN quickly and easily.

Request info about our products and services

* 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.