Rebekah Johnson: Welcome to Tuesday Talks, a live discussion series where we shed light and bring truth to emerging topics in the communications industry. I’m Rebekah Johnson, Founder and CEO of Numeracle, and I’ll be co-hosting today's session with Anis Jaffer.
Anis Jaffer: I’m Anis Jaffer, Chief Product Officer for Numeracle.
So, we were trying to decide what topic to dive into for today’s Tuesday Talk. We kept going back to the question of "What it Takes to Authenticate: From Attestation to the elusive Green Checkmark," on the end subscriber’s device.
Rebekah Johnson: Right, and we couldn’t get away from the word authenticate; caller authentication framework. This word, authenticate, as it relates to STIR/SHAKEN, is a placeholder for so much more than the simple definition of the root word. Speaking of definitions of words, I have a little confession to make: I am obsessed with words, their meanings, and the origin.
So I went down the rabbit hole of authenticate and Anis, it turned into a philosophical journey leaving me speechless over where we have arrived as a society on this quest to achieve the state of authentication.
Anis Jaffer: I want to know more, so where did you start this journey, and what did you find?
Rebekah Johnson: So I did not look at the TRACED Act or the Standards, just Merriam-Webster Dictionary, and the modern definition of the word authenticate, which is a transitive verb, is: to improve or serve to prove to be real, true, or genuine.
Anis Jaffer: That sounds like what we discussed in previous talks, about the Know Your Customer, TN Authorization...it's basically the process of proofing. It’s a proofing phase where you come to the conclusion whether or not a service provider can attest what they know to be real, true, or genuine about the Enterprise who is originating the call and whether they have the authorization to use the number.
Rebekah Johnson: Right, and to add to that, we would look to the green checkmark to inform us that the information presented can be proven to be real, true, or genuine.
Anis Jaffer: I would agree with that. It's logical and common sense, but it really isn't that simple for a service provider to know what's true and deliver it to the subscriber and be trusted.
Rebekah Johnson: I had more questions about the root word in hopes to find how we move from proof to acceptance of proof. So this is what led me to authentic, which is the adjective, and I view this as the state-o- being for someone or something that has been authenticated.
Anis Jaffer: Well, when I think of authentic, I’m thinking of let’s say, 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. Similarly, a birth certificate could be notarized, that’s an example of being an authentic 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.
Rebekah Johnson: In essence, the meaning of authenticate is really moving us beyond the action, to the end result of being authentic. Here's where definitions start to bring more to the meaning of the caller authentication framework.
I'm going to read the definition of authentic and there are three definitions for this word: the first one is worthy of acceptance or belief as conforming to or based on fact. The second one is made or done in the same way as an original. And the last one is really simple, not false or imitation.
Anis Jaffer: So 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.
Rebekah Johnson: I couldn’t agree more with that assessment. I was left quite satisfied with the definitions I found as I reflected on the processes within STIR/SHAKEN to achieve that state of “caller authentication,” but then I found something very perplexing. It even provoked, I would say, a strong emotion of disbelief. I thought for sure Merriam-Webster made a mistake, because if this is true, I’ll now have a whole new perspective on an important part of the framework aspect of “caller authentication framework.”
We are going back in time for just a moment. So as I'm scrolling through the rest of the definition of “authentic,” feeling quite elated that Merriam-Webster seems to agree with the approach the industry has taken first for STIR/SHAKEN, I come across an “obsolete.”
Anis Jaffer: Obsolete as in obsolete meaning for a word?
Rebekah Johnson: This is something that I’m familiar with but when I first came across it I wasn't sure what this term meant. So knowing what obsolete means when you're looking at the definitions of words, is why I had a lot of concerns. As I'm sure you're aware, you know words and language are fluid and they change through time.
Therefore, there are labels given to words when they are no longer in common use. The first is “archaic,” we've heard this term before, “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 or 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. Anis, that word next to “obsolete,” was “authoritative.”
Anis Jaffer: 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 on why this word is obsolete as it relates to authentic.
Rebekah Johnson: Exactly, this is why I thought it was wrong. So I start yet again with the definition and I look at authentic and authoritative, which are both adjectives, they describe something. As adjectives, the difference between authoritative and authentic is that authoritative is arising or originating from a figure of authority, while authentic is the same origin as claimed, it is genuine.
Anis Jaffer: So with that definition, it almost 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.
Rebekah Johnson: So here's our last step to understanding, which takes us to the water's edge of the ocean of philosophy and you have to be careful to not be swept away.
So I went back to obsolete. Centuries ago when you see the word obsolete, some group looked at the English language and determined a distinction between authoritative and authentic needed to be made. It feels like a wall was built between these two words as though people did not want to lose truth in exchange for authority or because of authority.
And a question you might be asking yourself is when was the word “authentic” introduced to the English language? Interestingly enough, the word was introduced within the time that “authoritative” was made obsolete to the world, and that was the 14th century.
Anis Jaffer: So the 14th century is Europe coming out of the dark ages and then you have the Renaissance, the cultural Renaissance, and art, and there is religious turmoil going on at the same time. I don’t want to get into a lot of those details, but I’m thinking about the Church having a lot of authority and with the Renaissance happening at the same time, there's a lot of cultural and coming-of-age in Europe. That is something that triggered this?
Rebekah Johnson: It was quite fascinating, but let me expand a little further because you're going to find it brings us right back to STIR/SHAKEN.
So as you pointed out, there is a rise of authoritative figures, groups, religions, and so on. And my theory, and I couldn't find anything readily available to corroborate it, so this is just Rebekah’s thoughts, but my theory is that the need to distinguish the two words came due to an invention during the mid-century and that was by Johann Gutenberg, who invented the printing press. So thoughts, ideas, poems, philosophies, beliefs, fictional stories, plays, whatever someone needed or wanted to say, could be mass-produced and distributed.
And 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.
So in looking at our mid-century friends, they concluded for themselves that the two words need not be synonymous, and ever since then, authenticity and authoritative have been at odds with moments of some collaboration.
Anis Jaffer: That’s fascinating, but, before we turn this session into a history podcast, let’s back away and talk about what does it take to authenticate with what you just shared. Let's look at authenticating the originating caller, and transporting this information to the destination which is hopefully the subscriber’s device with the green checkmark.
Rebekah Johnson: So let’s start with that origination. So, Anis, what happens on the originating side of the STIR/SHAKEN, which is part of the authentication process?
Anis Jaffer: Every service provider that originates the call implements what is called a local policy, to determine how they're going to authenticate and attest the call. This does not mean that 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, which is A.
Now, if they do not have a direct relationship, it could be because there is a third party call center involved or if the Enterprise brought the numbers from a different service provider using another originating service provider for originating the call, then they may not be able to attest with the flag A. So that’s essentially a scenario for B or C, and that’s what is called an Attestation Gap. That’s how the authentication process itself is currently proposed.
Rebekah Johnson: So going back to what we’ve learned about “authenticate,” it’s the origin, the source of truth. So what are some of the solutions that have been proposed to address this Gap in order for this information to come together so that it can be fully authenticated?
Anis Jaffer: There have been multiple models that have been presented in the Standards Group. One is called a delegated certs; it's also sometimes referred to as identity certs or Enterprise certs. And then you have the centralized registry or a centralized database model and you also have a distributed ledger model that has also been proposed. In addition to these models that have been discussed in this Standards Group, there are also some implementations that are outside of the Standards Group at this point.
Rebekah Johnson: Let's walk through each of those; I'd like to start with the delegated certificates.
Anis Jaffer: So again, there are multiple flavors, but essentially, they all leverage certificates similar to web certificates that we are so accustomed to when you are 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.
So the cert itself has got 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 GA, who actually issues that cert. The cert basically is an entity cert or a delegated cert that has been given by a service provider to an Enterprise. When the call is actually 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.
In addition to the delegated cert, the model allows you to add rich call data, which could be a logo or a call reason. 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, and then the terminating service provider can handle that call and then choose to display that information on the device.
There are some models that are called LEMoN TWIST, there’s also a TN LOA model... they’re similar in certain areas because a certificate is still issued, but there are also some variations. The most widely discussed model is the delegated cert model.
Rebekah Johnson: So it sounds like, with that particular model, we have the ability to authenticate the identity and associated to a delivery mechanism that creates an ability to deliver the information unaltered to the terminating side. Since there are multiple models, there must be some challenges with some of them, so what are the challenges to the delegated certificate model?
Anis Jaffer: So with the delegated certificate model, some of the challenges have to do with the renewal of the certificate. The certificate has to be refreshed and renewed at periodic intervals. Right now, I think there's a proposal for a 24-hour renewal and there is also a proposal for a long-time certificate.
The reason why the interval has to be short is so that certificates don’t get spoofed. So that's one challenge: how do you make sure that you have the most updated certificate that gets refreshed?
Then 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? Now, how do we keep that revocation list in sync, especially with so many service providers looking at it?
This 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. That's the other challenge, there are ways to overcome it, but these are some of the challenges.
Rebekah Johnson: So you also mentioned the centralized database, and from how I see it based on my enlightenment with looking at these words, I look at this more of an authoritative model. So can you explain the centralized database a little bit further?
Anis Jaffer: It’s similar to a traditional CNAM database in that you have a repository or a database where all the information related to numbers is stored. So an Enterprise who owns the number, or who has the access to that number, who's making calls on behalf of somebody...all of that information has to be stored in one 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? So these are all things that need to be addressed and some of these are the challenges for the centralized database model.
Rebekah Johnson: 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?
Anis Jaffer: 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 the 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 actually making a call to a destination device and if that destination device is a Google Verified phone, then that data can be sent to that device.
This data is short-lived, so you don't have any issues of compromise it. However, this is very dependent on the Google ecosystem. Similar models have been proposed by Twilio, who has some kind of solution, I don't know if it is live, and WhatsApp and Apple are looking at something similar. I would assume they have something similar on the text side and on the SMS as well as messaging in the case of WhatsApp, and iMessage in the case of Apple. They have something similar but these are not standard and it is very specific to that ecosystem, whether it’s Google, or Apple, or WhatsApp, it’s very particular to that ecosystem.
Rebekah Johnson: I’m just so conditioned in the telecoms space to depend on standards for uniformity, inter-operability, consistency... so does this pose a challenge to the Enterprise to operate in this ecosystem?
Anis Jaffer: 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 in which ecosystem they are in.
Then you have the challenge of making sure that the RCD information itself is verified and validated. How do we do that? So there are multiple issues here, in terms of out-of-band and RCD, for that matter.
Rebekah Johnson: So RCD is another acronym that we should definitely define. 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 that we'll probably find ourselves in another space of Standards or Best Practices like we've seen with vetting the entity identity. Anytime we introduce a new concept of data to be delivered via this mechanism, which is the voice channel, or let's say any channel, we're going to have to have a place to authenticate, and then hopefully we have a trusted process to be able to present the information so that the end subscriber can actually trust the data.
So Anis, it's no surprise that we're going to have to break this topic of what it takes to authenticate into two parts. So we've covered the originating side of the story and the different models and the methods with regards to authenticating information. The next topic we will cover on the terminating side, and that's the delivery of the authenticated information. How do we get to that place where subscribers, after we do all this work for the subscribers, can trust the data that we deliver to them?
Molly do we have any questions for Anis and I?
Molly Weis: I do have one pre-submitted question, thanks.
Is there a way for contact centers to be able to test all of this prior to the June 2021 STIR/SHAKEN deadline?
Anis Jaffer: It's going to be a challenge to test. So the first thing we have to realize is the STIR/SHAKEN certificate gets attached at the communication level, meaning, the originating service provider is the one who is actually attaching the certificate. So as an Enterprise, you wouldn't have access to that part, so you don't really see what's happening on the network.
Now, with something like delegated cert, it is possible that you can download the cert and make a call and make sure that the header information has that. But even in that case, depending on how it gets implemented, it's going to be a challenge to verify whether the right information has been attached. And again, the framework is dependent on SIP invites, which means that if you have a TDM switch in between where you’re originating and the destination this could actually get lost.
And there is another framework that is being discussed for that, but bottom line it's going to be a challenge to test, at least right now I don't think there's a way for Enterprises to verify whether the right header has been attached or not.
Rebekah Johnson: Because I looked at these words and I find it fascinating that one of the arguments again, back in the mid-century, was the inclusion of the word “unaltered,” when it came to authenticated data. We are literally writing standards where issues that mid-century philosophers had struggles with understanding. And what was interesting is, “unaltered” got dropped from “authenticated,” because the unaltered was the method of delivery, which is where it belongs. So you can have something authenticated but how it gets delivered is what determines if it's altered or unaltered. Fascinating that we’re using these words all over again.
So with that, I will thank you guys for joining us today on another episode of Tuesday Talks. In our next session, we will cover Part 2 of What it Takes to Authenticate where we will address the terminating side of the authentication standard. We hope to see you all there on Tuesday, March 23rd at 3 p.m. Until next time, we’re signing off.
