Rich Call Data and STIR/SHAKEN

Unwanted robocalls have made consumers reluctant to answer the telephone. Enterprises struggle to reach their customers—even with calls that their customers want.

Rich Call Data (RCD) is intended to help persuade people to answer phone calls. It shows the name of the caller and other optional information, such as a logo image or a photo of the caller. RCD is especially attractive to enterprises that wish to place their calls with a consistent brand presentation.

This might sound like caller ID in another form, but there are two notable differences between RCD and standard caller ID:

RCD is managed by the calling party or enterprise and their originating service provider. Unlike conventional caller name mechanisms, it is not fetched from third party databases by the terminating service provider. This gives the calling party greater control over the presentation of their brand to the people they call.
RCD is part of the STIR/SHAKEN framework. It is included in the SHAKEN Identity token and is digitally signed using Public Key Infrastructure (PKI). This makes RCD a more accurate and trusted means of presenting caller information.

STIR/SHAKEN aims to restore trust in caller ID so users will answer more calls. RCD builds on STIR/SHAKEN to provide additional caller information, generated by the caller and signed by their originating service provider, to encourage the called party to pick up the phone.

It’s important to understand that RCD requires STIR/SHAKEN. RCD information is an additional claim in the STIR/SHAKEN identity token. RCD is part of the information that’s digitally signed by the originating service provider. If a call is not authenticated, signed and verified, then RCD cannot be used.

Here’s an overview of the contents of this whitepaper:

STIR/SHAKEN overview
Call data frameworks
Rich Call Data
STIR/SHAKEN authentication with Rich Call Data

STIR/SHAKEN verification with Rich Call Data
Rich Call Data display
Business and marketing planning

STIR/SHAKEN overview

STIR/SHAKEN is a way for originating service providers to authenticate caller ID information and relay this information securely using PKI. The terminating service provider then validates this information and signature so they can present the verification status to the called party.

STIR/SHAKEN Authenticates and Verifies Caller ID

STIR/SHAKEN standards do not prescribe a method for displaying verification results to the called party. Although not yet finalized, verification status display standards are emerging, including a proposal to show when calls are verified with a [V] in front of the caller ID on text displays and a check mark on digital displays.

With widespread adoption, proponents of STIR/SHAKEN believe that people will be more likely to answer their phones. RCD is designed to build upon STIR/SHAKEN and provide additional benefits to callers and consumers.

Call data frameworks

To understand RCD benefits, it helps to review preceding methods to provide caller information to the called party. Here’s an overview of these methods.

Caller ID

Caller ID technology was first developed in 1968 and deployed in a limited proof-of-concept trial in 1971. Market trials began in 1984, and widespread deployment began in 1988.

The technology transmits caller ID information from the switch. Typically, this is the calling number only, although the technology supports transmittal of caller name as well.

CNAM — Caller Name

Calling name display (CNAM) is sometimes offered as an added-cost feature by voice service providers. For subscribers who choose this feature, the terminating carrier looks up the calling party name in a third-party database, in what’s called a “CNAM-dip.” Display is limited to 15 characters.

Enhanced CNAM

Enhanced CNAM (eCNAM) builds on the CNAM approach by enabling the terminating service provider to retrieve additional data about the caller from trusted sources. It was developed to overcome the limitations of traditional CNAM. eCNAM provides 35 characters for the display name and can provide additional information about the caller in a SIP header field.

Like CNAM, eCNAM gets caller information from a third-party source. The information is fetched by the terminating service provider, who decides upon the final content and presentation format of this information. Proponents of eCNAM consider these factors to be advantages.

CNAM and eCNAM Are Fetched by the Terminating Provider

However, critics point out that third-party sources can be slow to collect information about calling parties. They also believe that calling parties want to decide the final content and presentation format of their information, rather than the terminating service providers. This thinking led to the development of the RCD approach.

man sitting in a meeting, looking at mobile phone

Rich Call Data

RCD is described in an IETF draft. The design builds upon the STIR framework for secure telephone identity. Caller information is attested by the originating service provider and placed in a PASSporT Identity token with a digital signature.

Like eCNAM, RCD delivers additional information to encourage the called party to answer the call.

Unlike eCNAM, RCD is controlled by the calling party and the originating service provider who authenticates and signs the call.

Network diagram showing how rich call data is controlled by the calling party and originating service provider

RCD is Controlled by the Calling Party and Originating Service Provider

This gives the calling party greater control over the content and how it’s presented to the called party, a boon to enterprises who wish to have control over how their brand is presented.

Proponents of eCNAM assert that caller information should not be left to the calling party—it should be held by a trusted third party. Proponents of RCD assert that such information can be trusted because it was authenticated and signed by the originating service provider who knows their customer.

Rich Call Data structure and content

RCD is structured as a JSON object that contains one or more key value pairs. The JSON object is inserted into the SIP Identity token and identified as an “rcd” claim.

Default key values include the following:

nam – display name (required)
icn – URL of a publicly-available website hosting an icon or logo image file (optional)
inf – URL of a publicly-available website hosting a webpage with information about the caller (optional)
jcd – jCard object with caller information. Described in RFC 7095, this is a JSON format of a vCard object. (optional, mutually exclusive with the jcl key—use one or the other, but not both)
jcl – URL of a publicly-available website hosting a jCard object (optional, mutually exclusive with the jcd key—use one or the other, but not both)

There are only a few keys, but they accommodate a wide variety of information through use of the jCard format, which is built upon the vCard standard, RFC 6350. These specifications support a broad range of information categories, including:

Identification properties (e.g., name, photo)
Communications properties (e.g., telephone number, email)
Geographical properties (e.g., location)
Organizational properties (e.g., title, role)
Explanatory properties (e.g., categories, note—such as the reason for the call)

Rich Call Data integrity

Organizations that use RCD, and the originating service providers who authenticate their calls, may wish to pre-certify the contents of RCD. Reasons may include:

Regulatory requirements
Customer service agreements
Enterprise brand policies

Neither the enterprise nor the originating service provider wants to present RCD that hasn’t been vetted or that could be changed after vetting.

The draft RCD specification describes a method to ensure the integrity of approved RCD:

The content of the RCD keys and values, including the content of keys and values hosted on external websites, are used to construct a rcd input string.
The rcd input string is hashed with base64 encoding to create a rcd output string. The first part of the string is the name of the hashing algorithm used, e.g., SHA256.
This output string is then added to the PASSporT object with a rcdi key.

From the draft specification, here is an example of a PASSporT with RCD, display name only, and a rcdi tag:

{
"orig":{"tn":"12025551000"},
"dest":{"tn":"12025551001"},
"iat":1443208345,
"rcd":{"nam":"James Bond"}
"rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52t+eX6xO"
}

By adding RCD (rcd) and RCD Integrity (rcdi) hash to the PASSporT, this information is included in the content used to generate the digital signature.

Note that it might not be necessary to add a rcdi claim to RCD if the information is hosted in such a way that it cannot be changed after-the-fact without the knowledge of the entity who signs the call.

For example, suppose an originating service provider offers to include RCD for an enterprise customer on their signed calls. The approval process requires the enterprise to submit approved RCD to the service provider, who then vets it and hosts it. As long as the enterprise cannot circumvent this review and approval process, there would be no need to use a rcdi integrity claim to ensure that the RCD cannot be changed after approval.

STIR/SHAKEN authentication with Rich Call Data

The rcd claim may be placed in the PASSporT as an optional element. In addition, the creator of the PASSporT may also add a “ppt” value of “rcd” to the PASSporT header. As a result, the PASSporT claims must include an “rcd” claim, and entities verifying the PASSporT will be required to understand the “ppt” extension in order to verify the PASSporT.

Here is an example of a PASSporT header with the “ppt” key:

{
"typ":"passport",
"ppt":"rcd",
"alg":"ES256",
"x5u":https://www.example.com/cert.cer
}

Third party considerations

In the simplest use case, RCD is provided by an enterprise caller and vetted by the voice service provider who knows them and authenticates and signs their outbound calls.

However, there are other use cases involving third parties, and these cases are more complex. The common feature is that the originating service provider performing authentication is not the telephone number provider.

For example, a DID provider might issue a DID number to an over-the-top service provider, who then issues the number to an enterprise. In this case, the DID provider does not know the enterprise customer and cannot vouch for their RCD. The over-the-top carrier knows the customer and can vet their RCD, but they may not have an OCN (Operating Company Number) required to get a Service Provider Token and signing certificate necessary to sign calls.

There are various competing suggestions, including Telephone Number Proof-of-Possession Certificate (TnPoP), Delegated Certificate, and LEMON/TWIST. All involve various methods to enable the originating service provider or enterprise to get a signing certificate so they can authenticate outbound calls.

In the U.S., the STI-GA recognizes this situation and has issued the following statement:

“Under correct conditions, a qualified service provider (SP) must be allowed to sign leased numbers as well as other numbers belonging to an OCN not assigned to that qualified SP insofar as the SP can properly verify the customer’s authorized use of that number.”

So, these scenarios will be covered, though the exact mechanisms haven’t been decided.

These scenarios will have implications for RCD.

It’s also possible for RCD to be added to the call after origination and the initial authentication. For example, a third-party service could be used either by an intermediate carrier or by the terminating provider to add RCD to the call.

A third party can add RCD to a call by following these requirements:

The call must already be authenticated. An RCD PASSporT cannot be added to a call that has not been signed.
They must put “ppt”:”rcd” in the PASSporT header for the RCD.
The “orig” calling number must match the original PASSporT.
They must put an “iss” claim to identify themselves as the source of this PASSporT.

A third-party PASSporT for RCD purposes is not assumed to have authentication authority for the original attestation. It does not have to be made by a holder of the signing certificate. It only asserts the contents of the RCD, without attesting to either the customer or the customer’s use of that calling number.

STIR/SHAKEN verification with Rich Call Data

The verification service (STI-VS) must not use RCD unless:

The call is signed and passes standard verification
If the rcd claim is in a separate PASSporT, i.e., was provided by a third party, then the following conditions must also be met:
- The calling party number in the “orig” of the PASSporTs must match
- The “iat” field of the rcd PASSporT must be within the date interval that the verification service requires.

Rich Call Data display

RCD display will be determined by handset software developers. In this hypothetical example, an iPhone call answer screen is shown with the following information:

Caller name, an existing display field, is Dr. Amy Smith
Call reason, a rich call data field, shows that this call is an “Appointment confirmation”
Caller photo, an existing display, is the doctor’s picture sent as rich call data
The green checkmark and “ Caller ID verified” reflect the SHAKEN verification status.

(Note: this mockup is for illustration purposes.)

Business and marketing planning

RCD offers tremendous value to enterprises when calling their customers, prospects and business partners. RCD tells the called party who’s calling and STIR/SHAKEN verifies that this information hasn’t been spoofed.

Because the enterprise controls the content of their RCD, it should always be brand-compliant and current, unlike third party CNAM or eCNAM content.

Originating service providers might wonder about the obligations associated with inserting RCD into SHAKEN Identity tokens.

With basic STIR/SHAKEN, the originating service provider attests to their customer’s right to use the calling number. The service provider generally has records about their customers and calling numbers. It seems natural for the provider to be able to authenticate the claimed calling ID based upon their business relationship.

However, with RCD, the service provider is also attesting to the customer’s use of RCD content. The service provider has no business records to substantiate the authenticity of the customer’s RCD claims. How can they sign off on that?

Service providers who wish to offer RCD services to their enterprise customers would be willing to do so with a contractual business agreement in place. The terms of this agreement would include the following:

The service provider agrees to accept RCD content from the enterprise customer and place the RCD content into outbound calls that the service provider signs using the STIR/SHAKEN authentication process.
The enterprise customer agrees to establish internal control to vet and approve RCD content that they provide to the service provider for use in signing calls. The vetting and approval process should ensure that RCD content conforms to brand standards of the enterprise and suitability standards of the service provider.
The enterprise customer agrees to bear responsibility for the accuracy of the RCD content so that it does not misrepresent their calls.
The service provider will charge a fee to accept RCD content and insert it into signed calls during authentication.
If the enterprise violates the terms of the agreement, then the service provider may suspend the RCD service.

The essence of an RCD service agreement is that the service provider agrees to use the RCD if the enterprise customer agrees to control, vet and approve it for accuracy and appropriateness.

Service providers are well positioned to deliver RCD services

Rich Call Data is a Win-Win for Enterprises and Service Providers

A service provider might be concerned about accepting approved RCD content that may be changed later, outside of the control of the service provider. How can the service provider mitigate this risk?

We believe that this risk can be controlled by the service provider agreeing to accept RCD content into a hosted portal that they control. This would avoid the risk of using website URLs or hosted jCards that are outside of the service provider’s control. Fees charged by the service provider for the RCD service would also cover the cost of hosting RCD content.

By hosting RCD content, the service provider would have a log of all RCD content submissions. The enterprise customer would be held accountable for content they provided. The content could not be somehow changed after the fact without a record of it.

Enterprises are hungry for ways to improve call completion so they can better communicate with their customers and prospects. RCD services would be extremely valuable to such enterprises, and voice service providers are in the perfect position to deliver this service.

TransNexus STIR/SHAKEN and RCD solutions

We have STIR/SHAKEN software solutions available within our ClearIP and NexOSS software products. These solutions are deployed at telecom service providers in production. Subscribers are seeing verified caller IDs today. And our software can be configured to put RCD into SHAKEN Identity tokens.

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.