The Need for User Verification in a Remote Society

Michael Engle:
Hello everyone. My name is Mike Engle. I'm responsible for strategy and business development here at 1Kosmos.

We're here today to talk about the latest trends in true identity. We're going to be talking about some authentication concepts that we're all familiar with, but with a twist, starting with something that we refer to as hope-based authentication.

I can almost guarantee that you have not heard about hope-based authentication before. We created this term to help shed light on the unbelievable situation that most identity and access management platforms are in today.

So, that's right. When we ask our users to use a username and a password to authenticate, we're relying on hope. In short, we hope that they can remember a username and password. You hope they've created a strong password. You hope that the password change that you make them do every 75 days does not lock them out.

And you hope that they can figure out your complex MFA system. You hope that the password was not stolen from a central database by hackers. And, you hope that the password was not man-in-the-middled or socially engineered.

These problems pop up in the news pretty much every day, these days. So, while we're not really a hundred percent sure who coined the term, it's been used since the early 20th century by the military, by Rudy Giuliani, lots of book authors. That phrase is hope is not a strategy, especially when it comes to your authentication system. Yet, it's what we rely on today.

This slide is one of those logo kind of vomit slides that tries to show the vast number of cybersecurity players that exist in the identity space. You in the audience, you're here because you care about security and you know all this stuff well. There's so many vendors in the space that it's hard to know which way is up or down when you're talking to them.

And, the reality is, over 50% of these companies exist today due to the insecurity of using usernames and passwords to guess who's accessing our systems. So, I like to call these companies password mitigation companies. They fall into a bunch of different categories, and you're familiar with most of them.

You have, of course, user ID and password, which is what we've all been using for forever. But, since that's not good enough, we augmented username and password by expiring it every few weeks or months, put some crazy complex character requirements into them. And, because that's not enough, we'll add in some two factor authentication, which includes email, SMS, one time passwords. We'll sprinkle in some MFA when 2FA is not enough.

Then, we might do some risk-based authentication or some knowledge-based authentication. Then, to make things a little easier, we'll do some single sign on, or we might introduce a password manager. This puts one big password around all of your little passwords. And, password-less solutions are popping up. These may use keys or pins some of the time.

I'm sure many of you're familiar with FIDO. This is a fancier and industry standard way to replace a password with an encryption key on a specific device. WebAuthN is another FIDO standard that works only in web browsers with USB keys. And, of course, you have biometric devices such as cameras, fingerprint sensors. These can be put onto a computer or phone.

But, again, why? We're trying to strengthen a username or password. In other words, we have better hope about who's accessing your system when you employ these cumbersome technologies.

What is the path forward from HPA? I think my cover page gave it away a few minutes ago. It's using identity. So, we're going to start there and ask ourselves what is identity?

Your real person is everything that makes you up. Your appearance, your demeanor, your language, the way you walk. But, your identity is how you prove yourself to others. So, in the physical world, it's established when you interact with society. And it's typically given to you in the form of government issued credentials.

You'll start with a birth certificate, and you'll migrate to a student ID, you'll get a driver's license, you get a passport. You present these credentials when you really need to prove who you are. You'll notice, there's no username or password in this mix yet. Not in this form of authentication. And, there's very little need for hope. When you go through the airport at TSA, they trust these credentials and they work.

Think about how this does not parallel the digital world. If we relied on usernames and passwords and 2FA every time we got pulled over, think how much of a disaster that would be for both parties. Instead, we have real credentials that are given to us. So, let's introduce this concept in the digital world.

We can apply the same principles to digital identity, thanks to a few recent technological developments, mainly around smartphones and blockchain and some industry standards that have matured over the past few years. So, I'm going to talk about these standards briefly in a minute. But, in short, the process is very similar to what we do in the quote real world.

First we'll proof the user. We'll take their government issued IDs or their corporate credentials, such as an active directory account, and validate them. There's a number of ways to do this, and there's a substantial industry maturing around these activities.

The second thing we'll do is take those credentials and turn them into digital certificates and issue the credentials back to the user. The key here is to have technology in place that keeps these credentials secure. That's where we introduce the concept of decentralized identifiers.

When you issue the credentials, you give the private key to the user so only they can use them, and I'll explain this process in a minute. Then, you let them use the identity attributes in a way that does not require the requester to see the original credential. We call this zero knowledge proofs. This is actually better than giving somebody your driver's license.

You see a few acronyms referenced here that back up the industry standards that exist around these activities. In the first box, you see a reference to a NIST concept called IAL or identity assurance level. In the second box, you have W3C decentralized identifiers. These allow the safe storage and retrieval of identity attributes. And, in the third box, you have W3C verifiable credentials. These allow someone to safely share credentials and identity attributes with third parties.

So, we're not making this stuff up. This slide shows a whole bunch of standards that exist in the identity proofing and identity usage areas. You're finding various identity and off companies referring to in a very ad hoc fashion to describe their products. For example, a lot of the MFA companies on that earlier slide will say that their product is NIST-AAL2, which calls for strong two-factor authentication. But, they do not have identity establishment, which is the IAL referenced in the first section here.

My point in all of this is these components are key pieces to an identity strategy to really know who's at the other end of a digital connection. You can't do them piecemeal. And, we're not the only one saying this. You're seeing this language come out of government RFPs, namely, recently, the DHS, Social Security Administration, and others have called for all these standards across the recent RFPs. The big boys like Microsoft and IBM have been all over decentralized identifiers for a few years, and they're trying to figure out how to work it into their IAM solutions. But, typically, they're burdened with a lot of legacy problems.

Here's two examples. FIDO has become one of the most well known technologies for using keys instead of passwords. Basically, what they do is take a username and a password and turn it into secrets that you store on a secure hardware device. And, this has a lot of benefits over a username and password, but, yet again, this is an authentication scheme that does not actually identify the users.

So, in a recent paper this April, FIDO started introducing the topic of identity. Imagine that in an identity and access management process. So, you can see here the three pillars of IAM in the middle. FIDO covers the A but not the I, and they're acknowledging this and they're starting to come up with some work on how they can start to address it.

This is kind of a call out from the top part section there. Does not provide any details about how the user can be identified. Other organizations like Gartner are saying the same thing. So, here in a recent paper, they acknowledge that this whole identity thing is really important. Those aren't not the exact words in the paper. I kind of paraphrase a little bit here.

All right. So, let's see how you can put identity at the heart of an IAM program. When you tie identity together, your flow will look something like this. Starting with identity, the center, the first thing that you can do using these standards is enroll an identity. And, more specifically, you allow someone to enroll their own digital identity via an app on their smartphone into an identity safe.

Everything in an identity safe is highly encrypted. The user's private key is stored in a secure enclave on their phone. People today, they trust the secure enclave on the phone. Not even the FBI can get the private keys or crack an iPhone, in the example of the San Bernardino shootings. So, everything in an identity safe is highly encrypted because of this store. This enrollment process follows the NIST860-3-3A identity proofing standard that I mentioned on the prior slides.

When you enroll identities this way, you can then store them using W3C decentralized identifier standard. This puts your identity data onto a private distributed ledger or a blockchain backend, which we all know is far more secure than a traditional database. So, these backends are immutable, they're highly secure, they're designed in a way to support rapid transaction execution. These are the types of things that will typically plague a public blockchain.

The second thing that an identity based system can do is allow the user to be authenticated across multiple settings or use cases using identity. Novel concept. So, that is, in situations where it's important, you can allow any third party to ascertain that this person is who he or she claims to be, not just has a username or password. So, this could be getting into an office building or going through an airport, accessing a bank account, buying something online. It really doesn't matter once you have identity at the heart of it.

The authentication is typically executed using biometrics to reveal the identity information to whoever's asking for it. Here, we adhere to the NIST AAL3 or the European eIDAS standard that they call the high level of authentication.

The third thing you do with an IBA instead of an HBA is provide third parties with credentials. So, not just is this person who he or she claims to be, but does this person really have something, really have, for example, a COVID immunity certificate or have a specific degree from a university or have the right to purchase alcohol or the license to drive a car. So, these types of verification systems can answer these questions for the requesting party by letting the user carry and present these credentials in a cryptographically secure and digitally signed way, much like how you present your credential at a point of entry at an airport.

The point in all of this, again, I mentioned once before, is consent. When you use a self-managed identity system, based on these identity principles, the user not only enrolls his or her own identity with all the checks from third parties where necessary, but every downstream interaction involves authentication or credentialization. And, it is always based on explicit user consent. So, it checks a whole bunch of boxes around user privacy. This is a critical design and operating feature of an identity system, especially today with the likes of protecting PII, GDPR, CPA, et cetera.

The final point in all this is really the reason why you do it. We're solving real world problems with identity instead of hope. Here's a quick list of some of the many identity related use cases that one can solve. There's lots of corporate use cases to enable better access to a building or digital systems, logging into a workstation, secure access to websites. And, there's also many consumer facing benefits. Once you get rid of username and passwords, you have a tremendous user experience. You can also leverage the identity from their identity safe to fill out forms and prevent a lot of problems around account abandonment when you're signing up for a service. There's a lot of intrinsic KYC or know your customer, know your employee, know your entity benefits in all this as well.

The benefits to a corporation, I know a lot of us work in the corporate world. So, as you migrate from HBA to IBA, you realize a number of immediate benefits.

First is you get rid of usernames and passwords. So, this has too many benefits to state here. We could talk about them all day, but it is the most widely talked about feature of IBA, and it's gotten a lot of traction on the web and from vendors.

The second benefit is continuous identity verification. Every time a user allows their identity data to be revealed, you have the option to check their real biometrics, so that's something they are which is stored in their identity safe. We're not just talking about touch ID and face ID here, those are device biometrics. They tell you who somebody was at a point in time when they registered their thumb on a device. Basically, it tells you which apple ID was enrolled at that time. It doesn't prove their real identity.

That brings me to the third benefit. You can always use their real biometrics to strongly reestablish or relink their identity for the purpose of, for example, setting up a new phone or if you lose a phone, these decentralized identifier benefits allow the identity portability between phones to replace when a phone is broken, et cetera. Or, something that many people do not think about when they use a touch ID or face ID authenticator, is what happens when your touch ID or face ID is compromised. And, I know you're wondering, "How can my touch ID be compromised? It's from Apple. It's super secure."

Well, the reality is you can have multiple thumbs or fingers enrolled on touch ID. And, I know this very well because my kids will get my phone, type in my six digit pin, and sneak their thumb on there. Now, there's no real way to know who it is that's providing their thumb when you authenticate. When you can go back to true identity attributes to reestablish, you can warn the user, do a zero trust check, establish the identity, and relink the proper touch ID or face ID if you have this types of standards based storage system.

Lastly, by using a decentralized identifier, you don't have to rely on a central credential database. You have a safe place to store private keys and biometric and biographic information.

So, introducing standards based identity proofing and identity usage concepts, you can also establish citizen or corporate identity and mix any of the two in any way that you need for your corporate purposes. For example, many new hires will not be going into an office for the foreseeable future, just not the world we live in today. So, how do you onboard somebody you're never going to meet in person? You're not going to mail them a credential. Giving them a credential over the phone is difficult, dangerous, in some circumstances, inconvenient if you're in 12 hour time zone differences.

Using these technologies, you can proof them remotely, the same way your HR department used to do it in person. So, you see here, there's a number of different types of credentials that are given as an example. This I9 or e-verify process is what your HR department does today to validate somebody, and they typically do it in person by asking for a copy of their driver's license or passport. There's really no limit to the type of credential that can be enrolled using the standards that we have in this system.

So, that is the end of my HBA IBA story. I'm going to hand this off to Suresh to get through the next couple slides and wrap things up. I thank you for your time. Suresh, over to you.

Suresh Sridharan:
Thank you, Mike. And, thanks everybody.

Mike, if you can continue to share your screen and help move the slides, please, that'll be great.

Michael Engle:
You bet.

Suresh Sridharan:
So, as Mike mentioned, right, you basically have the concept of establishing corporate identity, but in reality, when you start redefining what digital identity actually means, particularly if you consider remote workforces, you have people who are working from home, and, in the past, it's always been, "Okay, you're behind a wall garden." Say, for example, you've logged into your VPN and hence you get access to everything.

So, we are moving away from that concept, moving more to a zero trust environment in a corporate world where obviously users are logged in, logged into their machines. Today, you just log in using your username and password into your laptop, for example, and then get access to corporate resources.

Now, the concept of actually moving away from just purely hope-based authentication, as Mike put it, to something more identity driven and identity based essentially requires a valid identity to start with and then use that as the bedrock, the foundation, so you know who is logging in, you know that the person who is logging in or who's using the resources, there's a face behind it. There's basically some way in which you've verified that user's identity.

Then, go into an authentication phase. Again, with all the changes that are happening today, you do have single sign on applications and the kind, but what really we are moving towards is password-less access. And, as Mike mentioned, there are plenty of standards out there, but how do you actually make it frictionless and in a way that the credentials that are actually provided by the user are coming based on a verified identity?

That's part of the authentication process that's going to be built as we go forward on top of the verification process. And, once the user has been identified, you start looking at what is the credential that the user has actually provided and ensure that there is continuous verification of those credentials. So, if the user, basically, is accessing resources that are more sensitive in nature, you still want to go back and not just reauthenticate the user, as we have done in the past, which is where the MFA solutions or 2FA solutions have come in, but actually ensure that there's re-identification if necessary, depending on the sensitivity of the resource. So, not only is there verification of the credential, there's verification of the identity, and then, post that, you basically authenticate the user.

What we believe is happening, or at least in the industry today, is that there's a complete redefinition of digital identity, where you're going from just purely authentication to identification of the user, authentication of the user, and then verification of the credential that's basically provided.

Now, in order for most organizations to achieve this, invariably, they have multiple integrations that they have to go through. I think what would be interesting and ideal would have a single solution with no integrations. And, I think that is probably the world we are moving towards. Next slide, please.

In turn, in closing out, one of the interesting things that is also happening is, if you look at traditional systems in the current state, most users typically... you carry something, that is, you know something and you basically use that in order to authenticate your applications. So, essentially, what you're doing is there is an identity that is associated with the application, and you are taking any attributes that you provide and the two are matched up. If there is positive match, then you're given access to the application.

Now, with the onset of identity as service solutions, what's happened is you have an additional identity that is now maintained at the IDaaS layer, the identity as a service, like an Okta or Azure or one of those solutions, Cloud-based solutions. You have an additional identity there. What's actually hidden is the identity in the application itself. The process that is followed is still the same, which is the user provides something that they know, and, basically, that's matched up with what is in the IDaaS solution, and then the user is given access to multiple applications.

So, we are moving away from that for multiple reasons. Because, the one hand, if you look at it from a corporate perspective, the more information you store and the more identities you store, the higher the risk you actually carry. The less information I store, obviously I am de-risking myself here. That's one part.

The second thing is, if you look at the consumer use case, the scenarios, there's huge amount of privacy issues. On the one hand, the same risks about the amount of information you actually carry still exists. However, in addition to that, a user also basically feels that, "Hey, data is currency, and all these organizations are using my data without my permission for someone to use for business purposes."

Now, we have rules like privacy laws like GDPR and now CCP and more widening, different privacy rules that have come in where the user needs to be given the option to essentially provide only the attributes at the point at which they were willing to give it to a particular business. So, if you think about it that way, and if you look at it from a corporate perspective, the less you give and only what you need to provide as identity attributes for a particular transaction is actually reducing the amount of risk for a particular organization.

What we are moving towards essentially is the need for more of a decentralized identity, that is the attributes stay as close to the user as possible. The user just provides those attributes for a particular scenario. For example, if I'm going out shopping, I'll provide only what is necessary for me to buy something online. If I'm basically accessing an application in a corporate environment, obviously I don't need to provide all the attributes from my identity in order for me to access it and log in.

So, we are moving from what is very application-centric identity to a more user-centric identity and more of a decentralized identity infrastructure. I think that's really the trend that we are seeing here. When you match this up with the hope-based, you obviously are looking at attributes that the user can provide based on consent, based on the scenario, and that's already verified using different standards. The authentication happens, and there's a complete verification that can be carried out if necessary.

So, broadly, this is what we had for today. Mike, we can actually open it up the questions from the audience.

Michael Engle:
Okay.

Speaker 3:
We have several questions, folks. Let me go through a few of them. The first one, is there a way to use this without a driver's license and passport?

Michael Engle:
Yeah, I can take that one.

The identity proofing standard that I referenced, it's the NIST863-3 in the us or the eIDAS in Europe. The identity itself calls for two types of credential that have matching attributes on them that you verify with a backend. So, one of the most commonly used cases is a driver's license and a passport, as shown on the one diagram on there, and it's what is given as an example in the NIST standard itself. What it does is triangulate. So, do the names match? Do the faces match?

However, in a corporate scenario, you can really leverage any type of attribute that you want. What we're seeing companies do is they'll introduce an active directory credential, maybe some type of other out of band identifier, such as a HR credential. So, you combine AD along with an HR badge, for example, and those could be two credentials that you can leverage in the same fashion. Then, the third one that ties it together is your biometric. That is enrolled typically from the phone directly into the system.

Speaker 3:
Okay. There's a few more questions. What types of biometrics are used in these types of standards?

Michael Engle:
Yeah, the standards don't specify a certain type of biometric. What's really becoming ubiquitous is leveraging the phone as your gateway into the biometrics. So, the two biometric enablers that you have are the camera and the microphone. We're seeing what's called a live selfie. In our product, we call it live ID.

This is a interaction with the phone, almost like you would do at a live checkpoint where you'll be asked to interact with the camera in a certain way. That is by far the most common form of biometric that is done outside of touch ID and face ID, which I had mentioned are biometrics, but they're not really from the user. They're the device's ascertain of a user at a point in time. So, I would say that the live face is the most common type of biometric that's being used to augment the standards today.

Speaker 3:
Next one, what type of corporate systems are using this today?

Michael Engle:
Suresh, you want to take that one? Maybe talk about some of the platforms that you're seeing, integrating this with.

Suresh Sridharan:
Absolutely. So I think there's two dimensions to that response. One is what kind of organizations are typically adopting this [inaudible 00:28:35] category? And, the second dimension to that would be what kind of applications do they typically integrate with?

So, the first dimension, which is what kind of organizations are basically adopting this, I'd say it goes by the vertical. There are both corporate as well as consumer use cases in this. Classic one where employees, for example, are working remote, and you want to give them access to different applications, and you have integrations that need to happen. So, we've seen use cases where customers have basically said, "We want to enable our remote workforce. We want be able to onboard remote workforce."

For example, these are new employees, new contractors. There must be some level of thought, verification of these users before we give them access. That is one use case.

The other part in the consumer world is more about how do you reduce the friction associated with somebody trying to log in. Because, if you think about it, users log in using a username password. Many times, going back to the hope-based authentication theme, people forget. When they forget the username and password, you go into a password reset. Now, if you think about it from a consumer perspective, you suddenly introduce friction. And, if you introduce friction, you've lost your consumer, your customer.

On the other hand, in the corporate use case, for example, again, the theme of hope-based authentication, and we've heard scenarios where customers, where users, certain organizations say, "You should not be using the last 10 passwords or last so many more passwords."

It makes the experience of the user so much more difficult. So, obviously you remove that. There's a verified identity, there's no need for password, it basically allows a very simple, straightforward ability for the user to access what they're doing, increases productivity.

Now, the second dimension is what do you typically integrate with? And I think I will speak of speak about it from more from an industry perspective, and I will let Mike answer the specific applications.

So, typically, you would look at integrations with existing identity and access management solutions, whether it's a Cloud-based solution or an on-premise solution is one. The second, and that's typically what we see, at least what we would need from an industry perspective. But, if you put on your consumer hat, the integrations would be more about how do we integrate with backend marketing applications or your analytics kind of applications?

Anything you want to add to that, Mike?

Michael Engle:
No. Yeah. I think you nailed it. In terms of where they're being deployed today, it's where the most pain is. The most friction around passwords is the help desk, whether it's a corporate help desk or a consumer facing one. So, you're seeing a rush to try to get rid of that friction, get rid of the help desk, because it's the most tangible ROI in the first couple months of a deployment. You can cut down the number of calls, the number of lockouts, et cetera, and the user frustration, your CSATs. Your net promoter scores go way up once you start using identity instead of passwords, for example.

Speaker 3:
Leading into, I think, Suresh, you touched on this, but there's a question that asks, do you integrate with other identity solutions? And, if so, which ones?

Suresh Sridharan:
From a product perspective, I'll let Mike answer that.

But, usually what I've seen is when you think about authentication applications that look at integrations with products like an Okta or an Azure or some of the on-premise solutions like ForgeRock or Ping Identity ,from a single sign on perspective, that is one set of applications. I would say, to a large extent, depending on the kind of environment that the customer typically has, and the maturity level of that particular vertical.

So, for example, if you look at some of the more traditional manufacturing and other verticals, people are averse to changing passwords too often just truly because of the nature of the work that they do. From a specific ones, I would probably leave it to Mike to say which ones the product, BlockID, actually integrates with, but I'd say these are the broad categories of applications.

Michael Engle:
Yeah. The actual question itself is almost an oxymoron. Do you integrate with other identities solutions? If an identity solution is something like an Okta or a Ping or a ForgeRock, they're typically single sign on solutions. They don't establish identity based on these standards. You can always tell.

The best way to find out which player in the market is working with identity is to google their name along with the standard, and you'll see if they've got blog posts or webpages. It's very rare that you see the bigger single sign on players trying to embrace those standards. They've made a great business in simplifying the authentication into the target system.

For example, once you get into Okta, they've made a great business, and they're the industry standard and giant now on single sign on, but you still need an Okta username and password. Our system is typically used to establish the identity, so you don't even need that anymore. That's really where you can sit in front of these other systems to provide that missing piece.

Then, on the backside, the verifiable credentials are getting a lot of steam as well. So, we almost sit in front of them and then behind them to let somebody use the identity in a cryptographically secure way.

Speaker 3:
Got at least three more. I think digital mobile workspace solutions already align with identity management. What role does AD play in user verification in a remote environment?

Michael Engle:
AD is an active directory, I guess that would mean, right?

Yeah, active directory has been around obviously forever. I was working with it in the nineties before it was cool. Now it's like, if you have it, it's this legacy thing you have to deal with. So, Microsoft doesn't go on anywhere soon.

Microsoft has moved two Cloud versions of AD. So, it's getting easier to work with with things like Azure AD. The way we'll typically work with it is Microsoft has plugins to allow you to issue a certificate instead of an AD username and password.

So, I mentioned a couple times when I was talking about standards and how you established identity is you almost replace a username and password with a certificate, a cryptographic form of a username and password. We will take that AD username and password, exchange it with a user certificate so that you never have to use it again, and, in the rare instances where you still have old systems that rely on it, we can even leverage the identity data to reset that legacy AD use name, password. If you use it sporadically, you won't remember it, you have to change it every 75 days, you can still let that system continue to function, but get rid of the dependency on hope, just going back to my original thesis.

I think I answered the question, but anything else to add to that, Suresh?

Suresh Sridharan:
No, I think you covered it perfectly.

Michael Engle:
Great.

Speaker 3:
Next one. How does a company know their information is secure with your organization?

Michael Engle:
Well, our organization, that's kind of a just because I say it is, it probably won't cut it.

It comes down to the security of the vendor itself, which we have all kinds of certifications and testings done. But, the reality is the architecture of the system and being designed on the industry standards creates an environment that is secure by design. The real heart of the identity data is in the hands of the user, and that is that private key.

It's the same thing that keeps financial transactions secure in a cryptocurrency world. So, as we all know, Bitcoin is almost unhackable. Encryption is as solid as it gets. We leverage the same principles, and these standards leverage the same principles to protect your identity data.

Just by nature of the design, for example, if there was somebody to get into the heart of our system, they're only going to see very well encrypted traffic flowing from the requester and the originator. So, it's a combination of the actual design and our maturity as a company that I think will help people be comfortable with that question.

Speaker 3:
Okay. Last question I see is is your solution Cloud-based?

Michael Engle:
Yes. Yeah. Our solution is. We use the latest in containerization technologies with the likes of Kubernetes and Dockers. So we're Cloud-based, we run in any Cloud, gov Cloud, but we do have the ability to run on prem if they support the same containerization technologies that we have.

In fact, our implementation really allows a beautiful hybrid model where most of the heavy lifting is done in the Cloud, but a lightweight on-prem agent allows you to interact with all your on-prem services without having to stand up a whole lot of architecture. So, we make the claim that we can be authenticating into three or four systems in less than a day by leveraging our Cloud and this lightweight agent that goes on prem. Happy to show that to anybody, anytime.

Speaker 3:
That's all the questions I have from the attendees. We appreciate your presentation, Mike and Suresh. We'll give one more opportunity for the group. If you have any questions, feel free to use the Q&A or the chat option. If not, we thank you very much for attending.

Michael Engle:
Very good. Thank you everybody. It was fun presenting to you.

Speaker 3:
All right. Thank you much. Yeah.

Suresh Sridharan:
Thanks.

Speaker 3:
Thanks everyone. Thank you.

Speaker 4:
Thank you.