What it Takes to Get a Green Checkmark Displayed With Your Call: Understanding Authentication

Rebekah Johnson, CEO, and Anis Jaffer, Chief Product Officer of Numeracle host a live Q&A podcast series covering all things related to call center communications, including call delivery, STIR/SHAKEN, caller ID technology, TRACED Act, brand identity, and more. In the episode below (transcript edited by insideARM; listen to the full episode here), Rebekah and Anis discuss what it takes to authenticate and achieve the elusive "green checkmark" on the end subscriber’s device.

Putting authenticate into historical context

Rebekah: I have a little confession to make: I am obsessed with words, their meanings, and the origin. So I embarked on a historical and philosophical journey leaving me speechless over where we have arrived as a society on this quest to achieve the state of authentication. I did not look at the TRACED Act or the Standards, but rather the Merriam-Webster Dictionary.

The modern definition of the word authenticate is "to improve or serve to prove to be real, true, or genuine." 

Anis: That sounds like what we discussed in previous talks about Know Your Customer. It’s a proofing phase where a service provider determines whether it can attest what it knows to be real, true, or genuine about the enterprise that is originating the call and whether they have the authorization to use the number.

Rebekah: Right. But I had more questions about the root word to find how we move from proof to acceptance of proof. This is what led me to authentic, the adjective. I view this as the state-of-being for something that has been authenticated.

Anis: When I think of authentic, I imagine a piece of artwork that’s real and authentic. And then you could have a reprint or a copy, which is not the real version. To me, this sounds like we hope the green checkmark will emanate and the certificate itself is the proof of claim. In fact, we call this a claim in the SHAKEN Standard.

Here's where definitions start to bring more to the meaning of the caller authentication framework. 

Rebekah: There are three definitions for this word, authentic. The first is worthy of acceptance or belief as conforming to or based on fact. The second is made or done in the same way as an original. The third is not false or imitation. 

Anis: The more we read about the definitions, the more closely aligned they are to the standard and objective of authenticating the call. Especially the last one, not false imitation, that's the crux of the SHAKEN ecosystem. So the IRS scams or the Social Security scams are basically imitating an entity by spoofing their number, and the industry calling this the authentication framework truly captures the intent, but the process to get us to that end state of authentication is still a challenge. 

[article_ad]

Rebekah: I couldn’t agree more. I was left quite satisfied with the definitions as I reflected on the processes within STIR/SHAKEN to achieve that state of “caller authentication,” but then I found something very perplexing. I thought for sure Merriam-Webster made a mistake.

As I scrolled through the rest of the definition of “authentic,” I came across “obsolete.” There are labels given to words when they are no longer in common use. The first is “archaic.” Archaic words are those that were once widely used but are no longer part of the English language. For example, rotary phone; that’s an archaic word. In contrast, an “obsolete” word is one that is no longer used at all within the context of the word being defined. In this case, “authentic.” So a reader encounters these words when reading texts that are centuries-old. The word next to “obsolete” was “authoritative.” 

Anis: Really? Authoritative? We keep hearing about authoritative registry, authoritative database...we hear this all the time in the telecom industry. It’s a way of saying what is being attested and holds the truth, the information being authenticated. Now I'm confused about why this word is obsolete as it relates to authentic.

Rebekah: This is why I thought it was wrong. So, I started yet again with the definition and I looked at authentic and authoritative. The difference is that authoritative is arising or originating from a figure of authority, while authentic is the same origin as claimed, it is genuine.

Anis: So with that definition, it seems that if we move towards an authoritative origin for Enterprise Identity and away from the Enterprise itself, we are losing authenticity because it's one or the other. 

One more trip back into history to find the origination of "trust" in the context of communication

Rebekah: Centuries ago someone determined a distinction between authoritative and authentic was needed. It feels like a wall was built between these two words as though people did not want to lose truth in exchange for, or because of, authority. Interestingly, the word "authentic" was introduced in the 14^th century, which is within the time that “authoritative” was made obsolete. 

My theory is that the need to distinguish the two words came from an invention by Johann Gutenberg -- the printing press – allowing thoughts, ideas, poems, philosophies, beliefs, fictional stories, or plays to be mass-produced and distributed. 

So here we are with a delivery mechanism to transport words from origination to termination in the hands of the reader. We now have a gap between the authenticator of the words and the recipient. Even without knowing our history, we live in present-day challenges of what can arise out of mass accessibility to information without some authority deeming that information authentic or not. Our 14th-century friends concluded that the two words need not be synonymous, and ever since, authenticity and authority have been at odds, with some moments of collaboration.

Back to the present, and what it takes to authenticate

Anis: Let’s return to STIR/SHAKEN and talk about what it takes to authenticate. Let's look at authenticating the originating caller and transporting this information to the destination, which is ideally the subscriber’s device with the green checkmark.

Every service provider that originates a call implements what is called a local policy to determine how they're going to authenticate and attest the call. This does not mean the caller ID itself is authenticated but if the service provider knows who the call originator is and if they have a direct relationship, they can attest the call with the flag “A”. 

If they do not have a direct relationship, it could be because there is a third-party call center involved or the enterprise brought the numbers from a different service provider using another originating service provider to originate the call. In this case, they may not be able to attest with the flag A, but instead B or C. That’s what is called an Attestation Gap. 

Rebekah: What are some of the solutions that have been proposed to address this gap so a call can be fully authenticated?

Anis: Multiple models have been presented in the Standards Group. One is called Delegated Certs, which is also sometimes referred to as Identity Certs or Enterprise Certs. The second is a Centralized Registry or Centralized Database model. The third is a Distributed Ledger model. In addition, there are some implementations that are outside of the Standards Group at this point. Let's walk through each of those, starting with the delegated certificates.

There are multiple flavors but they all leverage certificates similar to web certificates that we are so accustomed to when browsing. In the most widely discussed delegated cert model, the originating service provider receives a delegated cert from the call originator and that is used to authenticate the validity of the call. 

The cert itself has details such as the name of the enterprise, the numbers that have been associated with a certificate, and a certificate authority, who has been authorized by the STIR/SHAKEN Governance Authority. It’s basically an entity cert or a delegated cert that has been given by a service provider to an enterprise. When the call is originated, that certificate is passed to the originating service provider. Then the originating service provider can use that cert to flag that call with an Attestation A. 

The model also allows you to add rich call data (RCD), which could be a logo or a call reason, for instance. That could be used as part of the authentication framework and if the RCD data is not stripped, it can be transported all the way to termination. The terminating service provider can then choose to display that information on the device.  

The challenges associated with the different authentication models

Anis: Some of the challenges of the delegated cert model have to do with the renewal of the certificate. It must be renewed periodically. There is currently a proposal for a 24-hour renewal, as well as one for a long-time certificate. The reason the interval has to be short is so that certificates don’t get spoofed. So that's a challenge: how do you make sure you have the most updated certificate? 

The other piece is the revocation list. What happens if a certificate is actually revoked or has been compromised, and because of that, that certificate has been revoked either by the Enterprise itself or the issuing certificate provider? How do we keep that revocation list in sync? The list could be quite big, and because calls are being made in real-time and you need to have the latency to make sure that you don't have a delay in answering or making a call, processing revocation lists in real-time is a challenge.

A centralized database is similar to a traditional CNAM database in that you have a repository or a database where all the information related to numbers is stored. An Enterprise that owns the number, or that has access to the number and is making calls on behalf of somebody has to store the information in a single database. The idea is to have a single authoritative database that anybody can dip in and retrieve that information. 

Again, the challenge would be: how do you keep the data in sync? How do you make sure that the latest data is updated? Who gets access to it and who controls access to it? What happens if the database gets compromised?

Rebekah: You mentioned right at the end when you were describing some of the models, that there are implementations outside the Standards Group. What does that mean?

It gets even more complicated, with additional proposed models

Anis: All of these different models are being proposed within the SHAKEN Standards, but there are also other solutions called out-of-band solutions. These solutions essentially pass the data from the Enterprise origination side to the terminating side over the data network instead of using the communication, or PSTN, network which is used for making the call. 

For example, Google has what is called the Google Verified Caller Solution. Here the entity or the Enterprise and its numbers are verified beforehand. That information is stored with a Google call server, then, before an Enterprise actually makes a call, they have to place a request to register the call with Google identifying who they are calling and which number they are calling from. Since the entity has been pre-registered with Google, Google now knows that a verified identity is making a call to a destination device and if that destination device is a Google Verified phone, then the data can be sent to that device.

This data is short-lived so you don't have any issues of compromise. However, this is dependent on the Google ecosystem. Similar models have been proposed by Twilio, who has some kind of solution (I don't know if it’s live), and WhatsApp and Apple are looking at something similar. I would assume they have something similar on the text side and SMS, as well as messaging in the case of WhatsApp, and iMessage in the case of Apple.

Rebekah: I’m just so conditioned in the telecom space to depend on standards for uniformity, inter-operability, consistency... does this pose a challenge to the Enterprise to operate in this ecosystem?

Anis: Yes, they have to figure out who they are calling and what they are using and which ecosystem they are in. We can’t have all that data with the Enterprise. It’s going to be quite difficult to map every single one of their customers or in some cases prospects, and which ecosystem they are in. Then you have the challenge of making sure the RCD information itself is verified and validated. How do we do that?

Rebekah: RCD stands for Rich Call Data and there is a standard around defining and delivering this information through STIR/SHAKEN. The purpose is to deliver information to the called party that will inform them of who is calling and why. As you can imagine, you know we find ourselves back at the need for authenticating this information so that it can be trusted when presented. 

I have absolutely no doubt we'll find ourselves in another space of standards or best practices like we've seen with vetting the entity identity. Anytime we introduce new data to be delivered via the voice channel, or any channel, we're going to need a way to authenticate, and then hopefully we have a trusted process to be able to present the information so the end subscriber can actually trust the data. 

What's next?

Rebekah: It's no surprise that we're going to have to break this topic of what it takes to authenticate into two parts. Today we covered the originating side of the story and the different models and methods to authenticate information. The next part will cover the terminating side or delivery of the authenticated information. We’ll address the question: How do we get to a place where subscribers can trust the data that we deliver to them?