EPISODE 1680 [INTRODUCTION] [0:00:00] ANNOUNCER: Almost every application or system involves some sort of user onboarding. Increasingly, companies must implement Know Your Customer and Know Your Business Compliance, or KYC and KYB as part of that process. In addition, they often handle personal identifiable information, or PII. Footprint is a developer platform that was co-founded by Alex Grinman for handling identity, security, fraud, and authentication. Alex joins the show to talk about identity verification, security, compliance, Footprint's front-end and back-end design, and much more. Gregor Vand is a security-focused technologist and is the Founder and CTO of Mailpass. Previously, Gregor was a CTO across cybersecurity, cyber insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile at vand.hk. [INTERVIEW] [0:01:09] GV: Hi, Alex. Welcome to Software Engineering Daily. [0:01:13] AG: Hey, Gregor. Great to be here. Thanks for having me. [0:01:15] GV: Yeah, Alex. It's great to have you here. You've been in the authentication and identity space for a little while now, and you're the Co-Founder and CTO now of Footprint. What was your road to becoming the co-founder and CTO of Footprint? [0:01:31] AG: I started programming when I was a kid. Started building software, actually really started building iPhone apps in high school. It's where I really started. I've always been interested in identity and security. I mean, the idea of how do you prove something to somebody without giving away all of your information was intriguing to me. I think my real intro into cryptography was, I took this very theoretical cryptography course at MIT and taught by the inventors of zero knowledge proofs. Just fell in love with how a little bit of simple math and a little bit of programming can create these pretty amazing guarantees. I started a company right out of school in the authentication space. Merged my ideas of building iPhone apps with security and identity. I thought it was pretty cool that the iPhone launched with a secure Enclave chip on device, initially built for storing things like credit cards, or other passwords. But really, you could use it to store any kind of key material. I thought, hey, it'd be pretty cool if we stored a public private key pair on one of these chips, and then the private key never left your phone, like a YubiKey, but in a much more useful form factor that everyone already has. Maybe we can use that to encrypt messages between people, or use it to authenticate using an SSH key. I ended up starting a company in that space, which led to things like FIDO2, U2F, passkeys and built that first company and we sold that company to Akamai. The startup bug bit pretty early on and yeah, here I am now. [0:02:55] GV: Yeah, awesome. Yeah, I mean, Footprint, as we'll hear very much builds on all of that. Maybe at a high level, what does Footprint do? [0:03:06] AG: At Footprint, we're helping companies automate onboarding. Onboarding is this opaque thing. What is onboarding? Every product you use has an onboarding form. The simplest product, maybe just ask you for your name and email address. Almost every onboarding form has you set up a credential, a way to authenticate yourself. When you come back later, your account is for you and no one else can access it. There's this other range of onboarding that actually many products that we use have. Think of your investing app, your credit card that you sign up for, a bank account, maybe even when you're renting a car, or booking a house to rent. These products, these marketplaces, they need to know who you are, maybe a little bit more than most other applications. They collect a lot of other personal information, like your full name, your address, your date of birth. Sometimes they ask you for your social security number if you're in the states, or a scan of your driver's license, or your passport. What they do with this information is they verify all of it, right? They try to verify as much of it as possible to make sure that the person signing up really is who they say they are and also, that they're not a criminal, or a bad person, or have a history of defrauding people, or things like that. That's a really complex process that many companies have to solve. They have to solve it on multiple different layers, everything from storing that data securely to verifying it correctly. What Footprint does is we give companies a couple lines of code and we basically take care of all of that, everything from collecting information, verifying it, storing it securely, providing an audit trail. If you're a regulated industry, sending that audit trail to third parties so that you can be in compliance. We handle all of that and basically, make it so that companies don't have to rebuild this onboarding flow from scratch. Then for consumers, what we're doing is once you onboard once to any company or product that uses Footprint, every future time will just be one click. Low-risk friction, makes it easier to use products in a trusted and verified way, which more and more products on the internet today are requiring just because of the nature of the really sensitive things that you can do online. [0:05:03] GV: Yeah. I guess, just to read that back, Footprint is taking both sides of the coin here, which is that both the user has to go through a process that is a Footprint process to sign on. At the same time, the platform has to be also, in some way communicating with Footprint, or using Footprint, like behind the scenes, like is it API-driven, or is it something that you integrate into the platform, or how does it work? [0:05:28] AG: Yeah, that's a great question. A lot of KYC identity companies, onboarding companies, they're typically just like a backend API. You send them some data, they tell you if it's verified, or some additional scores, or something. We at Footprint believe that to really verify who the user is, you have to be all the way at the edge, right? You have to actually interact with that end user directly. Companies, really, the integration touches two points. They embed some code in their frontend, and then they embed some code in their backend as well. Our frontend takes care of securely collecting all that information, verifying and doing things like dynamic step ups, right? If we determine there's some high fraud potential risk signals, we can step up the user and ask for some more information, all without any code, or any complexity that customers have to implement. On the backend, once the frontend finishes, they go ahead and they verify that exchange, that transaction for what we call a Footprint ID, or an FPID, a single token that they can then store on their side, that really encapsulates all the identity and the risk information and the overall decisioning that happened, whether or not that user is who they say they are. The integration touches both sides, but the end user really interacts directly with Footprint through this embedded onboarding experience. Then that user actually gets credentialed as well, so they set up a passkey and sure, we'll get into the details all there. Really, so we interact with both the end consumer and the business. [0:06:47] GV: Yeah. I don't know if you like this analogy or not, but is it the Stripe for identity management? Is that a good analogy, or is it different? Because I mean, all the things you've just mentioned there, where you're interacting with the Footprint platform as a token is passed back and that's what's representing the user. Sounds like Stripe, kind of. [0:07:06] AG: Yeah, exactly. Exactly. Yeah. I mean, it's interesting. A lot of people think of Stripe as this payments platform, right? That does orchestrates payments and billing. But at the very initial product that Stripe launched was that they said, okay, storing a credit card number and then charging it is very complex. We will essentially tokenize the credit card and give you back a Stripe customer ID, or payment object, whatever it is. Then we take care of charging that payment object. That's effectively what Footprint does as well, except instead of just being a credit card, which is actually a pretty complex object in its own right, but the identity is much more complicated, right? You have everything from the basic PII attributes, like name, date of birth, SSN. Then you also have things like identity documents, and those all have information that can be extracted and verified. You have information about someone's driving history that is derived from their identity. There's all sorts of identity information that we basically tokenize all into one simple string that customers store and solve that complexity for them. [0:08:08] GV: Yeah. Okay, that makes sense. There's almost three facets to this. Also, when I look at the Footprint website in the same way. We've got security, we've got vaulting and we've got compliance. Could you maybe speak to, I mean, security is obviously a big term, generally. Obviously, security is in the context of Footprint, which might be interesting to hear about. Then there's vaulting and that can be highly complex. I'm sure there's just a ton of complex stuff in there that it'd be great to hear about. Then there's the compliance piece, which I'm really curious about. Yeah, because that feels this whole problem. I wouldn't ever want to go and touch, but you guys are doing that, which is very cool. Yeah, so let's maybe hear about more of the technology technical side of these three areas. [0:08:53] AG: Yeah, absolutely. In insecurity, I would maybe bundle risk and identity. That pillar is very crucial to Footprint and our customers, especially the companies that are really heavily regulated. They need to make sure that they are actually verifying that person's identity. This involves a bunch of things, like complex integrations with the LexisNexis of the world, Experian, different credit bureaus, data sources. That actually is a fairly commoditized industry today. There's a lot of companies that do just this. At the very end, they actually boil down to maybe five or six different bureaus, like Lexis Nexis with Experian, which we connect to directly. Even though I say it's commoditized, it's actually fairly complex. Most companies should not be integrating directly with Experian, LexisNexis, right? They have some shared databases, data sources, some of this joint. Really, what it boils down to is taking these fairly legacy APIs. Sometimes it's a 400-page PDF of all the possible risk codes you can get. Boiling that down to, hey, does the information entered match each other, right? Triangulating identity. Think of does the name match the date of birth, match the address, right? Is this a recent address, or maybe it's an older address. Boiling all of that down into deciding whether or not the data is actually accurate. That's maybe step number one is does the data entered actually, is it correct? Correct, by the way, is not a binary decision, right? As you can imagine. Users sometimes miss type things. By the way, this is a core part of why Footprint's frontend helps here, because we catch a lot of the errors on the frontend that a lot of other KYC companies that are just back in APIs cannot do. For instance, if the user accidentally fat fingered their date of birth and they're off by a 100 years, our frontend will catch that. It won't let you enter in a bad date of birth. Similarly, if you're entering in a PO box, or the address of a prison, or something like that, our frontend will double check that that is correct for you, and tell you, "Hey, PO boxes are not allowed." We improve the accuracy of the overall identity risk matching. That's the baseline. The next layer on top of that is we have a fairly sophisticated decisioning and rules engine that's built. The reason is different businesses, different industries have different rules. If you're a bank, the compliance policy that you need to follow is very different than if you're, let's say, renting apartments to people. We give companies based on industry during a default, good set of rules, but every business can customize them. This is really powerful because once again, our frontend is integrated, you can create a rule that actually does a dynamic step up, which actually changes the frontend dynamically. The nice thing is that you can go from just basic, what's called EKYC or just non-documentary information, to then stepping up and doing a document verification and collecting a selfie, matching the selfie to the document. The nice thing about the front integration is that this gets into vaulting as well, is that all of this data is collected directly in the same way that Stripe provides an iframe to collect a credit card number, Footprint's iframe securely collects all this information and vaults it directly. The Footprint vaulting infrastructure will get into how that all works. That means that this data doesn't pass through your servers, your code. It essentially makes you out of scope for a lot of the security and compliance regimes with touching this very sensitive data. Footprint handles all of that as well. That is, I would say, the first line of the product. Vaulting really is the foundation for everything. I mean, all the data that we touch is vaulted. Our technology were built on top of what's called AWS Nitro Enclaves. It's a fairly recent technology from AWS. There's a couple of competing technologies on Azure and Google. If you're in the security space, you're probably thinking Intel SGX, right? That's you're probably the go-to example, the most famous. Amazon has a couple of really cool advantages over Intel SGX. A lot of it is really around developer experience, and the fact that the isolation guarantees are really nice. Just a quick primer on what Nitro Enclaves are and what guarantees they provide; essentially, it lets you take some code and run it inside of an environment that is network-gapped, memory-gapped, CPU-isolated, and attested itself. This is running on special hardware, where you can get a cryptographic attestation that it's running on untampered, AWS Nitro Enclaves hardware that you've signed. The idea is that no one else can deploy additional malicious code. Even if you have a malicious dependency that you accidentally introduced, well, because it's network-gapped, that can't escape. What we've done at Footprint is we've designed, essentially, our entire vaulting infrastructure around Nitro Enclaves. At a very simple level, we have what's called a user vault. Every single user in the Footprint system has their own, what we call a vault. That really is just a public-private key pair. As soon as data enters Footprint, it's encrypted with the public key, and the corresponding private key that can be used to decrypt that data is only accessible within these Nitro Enclaves environments. Whenever you need to process data, compute on it, you actually have to send not only the encrypted data, the end-to-end encrypted data to the Enclave, but also send this encrypted private key that can only be decrypted by the Enclaves itself. This lets us, in a very small footprint that is isolated by the Nitro Enclaves isolation guarantees with our assigned code do computations on that data. A very simple example, if you need to compute somebody's age, you don't need to send their date of birth and then do that computation inside of a bunch of application code that might accidentally exfiltrate that data. You can actually send the encrypted date of birth, decrypt it, compute the age from that, send the age back out. We essentially can guarantee that data, the minimum amount of information that is needed is what leaves the Enclave. Furthermore, the Enclave can decrypt and then re-encrypt. If you need to send data to a third party, you can decrypt it and then re-encrypt it to a new public key that only the third party has access to the corresponding private key. This way, you can ensure that as data moves from the Enclave through untrusted, un-isolated sources, it is still end-to-end encrypted to its destination. This really powerful building block lets us provide things like vault proxy functions. Let's our customers send data to third parties securely, without ever having to see that data or touch that data and ensure that it's end-to-end encrypted to the actual destination. That's really important, because companies that do onboarding, that touch this really sensitive data, they often - what they really end up doing is sending that data somewhere else anyways. They have baking partners. They have compliance auditors, third-party auditors that look at all this information. Making it really easy to move data securely that doesn't really put you in scope for a lot of security compliance regimes is pretty important. I've said the word compliance many times. Compliance is boiled through everything in Footprint and also, really what our customers need. This is everything from data security compliance, making sure that you're holding onto credit card numbers, or SSNs, you're compatible with the associated privacy framework, or PCI framework that you need to in order to run your business. But it also touches the identity and risk compliance part of it. Our customers have what's called typically, we call them CIPs, or it's an industry phrase, which is customer identification policy. It is essentially a set of rules that says, these are the things that we've checked before we've opened a new account for a user. Banks, for instance, have very intense CIP policies. Brokerages have pretty intense CIP policies. If you're renting apartment rental, you might have to create their own that is not based in financial regulations. What Footprint lets you do is we have this concept called playbooks, which not only define the information you collect, but also, as mentioned, the rules and decisioning logic that you use to actually decide whether you want to approve a user, or reject a user, or maybe reject a user, but put them in a manual review queue, because they might be over - that decision might be overridden by one of your customer support folks. The idea is that these playbooks let you, essentially, map the banks, or your third party, or whoever's deciding - maybe it's just you, what your CIP policy is. You map that to a playbook and Footprint not only takes care of collecting all that information, but also putting that user in the right stack of approved, rejected, or manual review to make sure that you're compliant. Some new product, and I'll stop talking in a second, but it's a new product that we're launching pretty soon is a compliance product similar to the Vantas and Dratas of the world, but really focused on onboarding, which lets you show evidence that you're following that CIP policy. You can basically give access to a third-party auditor, and without them having to see any sensitive data, they can actually audit your manual review process. They can audit how things are being approved and verify that, hey, the bank's CIP policy is actually being met by sampling a bunch of different onboarding cases and providing that on a real-time basis. Basically, alleviating the company from doing all of this manual, or approving of their compliance, which they have to do basically, on a quarterly basis, sometimes more often even. [0:18:22] GV: Yeah, very fascinating. Yeah, just to touch on that last bit there to start with the new product, was that a clear ask from existing customers, or is it just a natural evolution of where this technology can go, or a combo, or? [0:18:38] AG: Yeah. I mean, it's a combination. I think, what we've seen is that there's two things that we've seen in the market that let us build this. The first is that data security and security in general used to not really be part of the conversation with financial compliance, but it really is now. Banks not only want to see that you're identifying customers properly, but that you're also storing that data properly. That's because of all the breaches and leaks that have been happening. As you can imagine, the more data that it's leaked, the harder it is to actually prove that the person that's onboarding is who they say they are. These things are really married at the hip, and that's why we believe at Footprint, it makes sense to not only prove that a customer is storing that data securely, identifying that person correctly, but also, that they're storing that data properly as well. That's why the vaulting technology is so core to what we do. The second piece that has been pretty interesting, and mostly in effect of the market is there's been a lot more scrutiny. You can see all the banks that have gone under, that have ticked off fintechs from their platform, banking as a service providers that have struggled with losing partner banks. We've seen a lot of our customers have to switch partner banks, for instance, in order to keep their business running. It's been pretty obvious that if you switch to a different banking provider, now you have to go through a completely new audit process. Footprint can really make that really simple, and it makes it easy even to be onboard to multiple banking partners as well, without having to change and do a bunch of manual work to prove that you're in compliance. [0:20:03] GV: Yeah, because just to, again, maybe read back once on the user side, the user has used Footprint once through some platform. If another platform is also using Footprint, does that become a breeze for that user to move through? Is that how it works? [0:20:21] AG: Yeah, exactly. This works actually both from the end user and consumer point of view, but also, from the Footprint customer, the business onboarding onto multiple partner banks, right? From the end consumer point of view, if you're onboarding to multiple products that use Footprint, you don't have to - you confirm your information, right? Because we authenticate you and we basically can auto-fill a lot of your information, we skip past that, but we also get a lot of feedback and labels from how you are as a user across different platforms. If you do fraudulent activity in one place, you shouldn't just be able to create a new account and redo that same fraudulent activity somewhere else. There's basically infinite number of bad actors, right? Because a single fraudster, or bad actor can create a bunch of different synthetic identities, or steal a bunch of real people's identities and onboard a bunch of different accounts. Good actors are much more valuable to spot. The way to think about it is if you're a good actor across a number of platforms, you should have a much easier time onboarding somewhere else and basically, jumping through less hoops, because you've proven to yourself to be a good actor. Footprint can do that in a way that's both secure and also compliant, because we can also prove that in a lot of our reporting. [0:21:33] GV: I'm going to come back to the technology in a second, because I've jumped away, but this is just really interesting. Is that almost like a user can have almost - I know this is a slightly loaded term, so I appreciate about, like a credit score. A credit score almost with Footprint. That now, suddenly, someone is, we're able to see the stats on someone across multiple platforms, multiple companies and understand this user has a pretty good history of being a reputable user, I guess. [0:22:03] AG: I would say, it's not so much around - we're not trying to build a credit score across, like a social credit score, or anything like that. It's much more around, if you're doing obviously bad activity, right? For instance, if you're onboard to one platform and you've created this identity and you've associated it essentially with your devices, and then you go ahead and you onboard onto another platform using the same device, but now you're using a different identity, or using different information, we can actually detect that you're using the same devices that were previously associated with a different identity in Footprint. That's one way we can catch bad actors, which the typical fraudster, we call it duplicate fraud, right? Is I go on Telegram and I go into some group and I purchase a packet of 50 stolen identities. That might even include driver's licenses, by the way, right? Then I go into Robinhood and I go into a couple of different apps. Maybe there's some signup perks, like invest in your first stock for free, or something. I go and I create a bunch of accounts and then I do a bunch of bad activity with those accounts and then essentially, just abandon them later. It's something that's really hard to stop. There's a lot of different tools that companies have to string together in order to even try to stop them. Then there's always that risk that they're preventing a good person from just using their product, which is a horrible experience. What Footprint does is because we have this concept of shared identity and we credential the user, we can, and we actually associate that through various device intelligence that we collect as well using app clips and snaps, and we can get into the tech specs of how we're building that. The idea is that we can essentially detect duplicate fraud happening in real-time and we can determine that the same person, because we're at the frontend, because we're all the way at the edge of where the user actually participates on onboarding flow, we can detect that the same person is onboarding multiple different identities and essentially block them really quickly, and provide those risk signals to our customers that this might be a duplicate fraud attack and that actually helps prevent a lot of bad acting. The other spectrum, and this is something that we're still developing, is around fraud labels. You can tell us, "Hey, we've off-boarded this user for fraud." The reason this is a tricky problem in general is sometimes people commit fraud with their real identities. Fraud on one platform might not mean you want to not allow that user out to a different platform, right? If I rent a car and then don't return it or something, I mean, that's pretty bad. That actual translation of how you commit fraud on different platforms, for us, what we're trying to do is really solve the onboarding fraud. We want to determine the information that somebody's providing really is their information. If we can detect that you're using data from somebody else across the same device, those are the kinds of fraudulent actions that we want to stop in real time, and they're pretty hard to stop with today's tools. [0:24:50] GV: Yeah, got it. Okay, so back to just the technology side. The vaulting is such a core piece to the whole Footprint platform. It sounds like from your past experience, etc., you were pretty familiar with even just the idea of the concept of enclaves. I imagine finding other engineers with this knowledge, how easy is that? How easy has it been to get onboard other engineers into what sounds like a fairly esoteric system, or having to think quite a different way about how to build a platform? [0:25:27] AG: It's interesting. I think one of the toughest problems with working in security and cryptography in general is this concept of threat models. A lot of people operate with different threat models in their mind. What is a threat model? A threat model is basically, what powers an adversary has, right? It's a set of assumptions you make that if an adversary could break, let's say, Amazon's root of Nitro Enclave, root of trust, if they could manufacture those signatures, forge those signatures, well, that would defeat the Nitro Enclave guarantees, or at least some part of them. We assume in our threat model that the adversary doesn't have the ability to forge, let's say, global CA is like, the Amazon's root CA for Nitro Enclave trust. The real threat model that I think affects a lot of businesses today that is very reasonable that I think a lot of businesses don't actually consider is this idea of, okay, database encryption, data encryption. Today, the standard is you store some data in your database and then you turn on encryption at rest, which is essentially, a switch on whatever database provider they're using that says, okay, when the hard disk starts up and loads into memory, it will decrypt this data usually with a symmetric key. What that really means is that if somebody runs into the data center, sticks their hand in the cage, rips out a hard drive, hopefully, that hard drive will be end-to-end encrypted with a key that is not anywhere to be found. This protects that data in those kinds of cases. The reality is that these data centers are actually fairly well protected. I mean, it's really and they likely, they have cameras everywhere. They have locks on cages. While this protection is great and important, we should still do it. By the way, we do use this protection as well, even though it's redundant in some cases, it doesn't really solve the much more realistic problem, which is how many different services are talking to your database? In modern cloud-based company, yes, you have your applications, your microservices that all have access to connect to the database. You might also have third-party tools, like retool, or business intelligence dashboards. They all essentially have access to this data. It becomes really difficult for businesses to limit okay, no one should be able to see the social security number, or the credit card number. That's why in general, vaulting is important. The threat model that Footprint operates under is that if we made our database read-only on the Internet, publicly available to everybody, you should not be able to learn about people's private information, or SSN, or documents. That's the core threat model that we operate under. I would say, to go back to the original question, I think the first hurdle when you're bringing on folks into working in security and enclaves, the entire area in general is just to be really clear about what threat model you're fighting. The main threat model that we're trying to fight with enclaves is the application surface area, right? The 99% of the code, or 95% of the code that everyone on the team is constantly writing to is out of scope for being able to really abuse this very sensitive data. A malicious dependency there, or some bad code that was committed, we do the maximal amount of protection to separate that from leaking any sensitive PII data, card data, things like that. The good news about Nitro Enclaves is that the actual service area is really small. I would say, our Nitro Enclave related code is 6,000 to 8,000 lines of code, which and the grand scheme of things is pretty small. The number of engineers that actually have to write Enclave code is fairly small. The really nice thing is that when you hire a third-party pen testing, auditing firm, it's a small service area for them to go through as well. The nice thing is that it's not so much about arming a team of 100 engineers to go and work on this one part of the code. Just having a small team that really understands the threat model, really understands the security guarantees that you're trying to build. Then, of course, going deep into the fundamentals, like, actually understanding the elliptic curve algorithm that you're using and making sure that everything is up to spec and correct. [0:29:31] GV: I'm not sure, completely understanding if you're not familiar with this, but MongoDB, they released queryable encryption. That feels like they're almost trying to get into this space, but maybe from a different angle, where it's not as much, because the AWS enclaves sounds - it's quite a hardware-heavy hurdle to get over it for someone else to come into that space. Yeah, I don't know if you are familiar with any comparisons you could, or differences you could make there. Yeah. [0:30:00] AG: Yeah. I'm not familiar with the fundamentals of it. I read a little bit about it. I think the major questions I would have if I were to go dig into this and compare it, is how those keys are managed. How it actually does the encryption. Basically, there's two important things to consider. When you're writing data, what does that process look like? How are you encrypting it in a way that it can be queryably decrypted later? Then, of course, how those underlying keys are stored. Because one of the nice things about Nitro Enclaves is that you get these hardware security guarantees of isolation that says that this key, this master private key for that user vault cannot be decrypted outside of Footprint-signed enclave code running on legitimate enclave hardware. Potentially, you could even write maybe an adapter in MongoDB that talks to a Nitro Enclave in real time, or something. You might be able to do that as well. There's a really good, and this is a pretty old paper that came out at MIT and I read it when I was there called CryptDB, which actually tries to do a lot of these fully homomorphic encryption. If you're going really far into the theory field, and there are companies that are actually trying to build this in practice, it's pretty slow. This is the generalizable way of computing on encrypted data. There's two interesting things about that. The first is that it's pretty slow, but there's a lot of research happening to optimize it. The CryptDB paper is a way of saying, okay, let's take a bunch of different partially homomorphic cryptographic algorithms and encrypt it in some special way, so that we can still do a bunch of queries without fully decrypting all of that data. I think the problem in general, there's two problems. One, it's fairly complicated for most developers to interact directly with these systems, because it requires a deeper level of understanding about things like, homomorphic functions, like how to actually encrypt data in a way that you can query what you want later. Most companies, as they're building products, they actually don't necessarily know all the queries that they're going to want to run eventually. Footprint took the more opinionated approach of, you rarely will ever need to query SSNs. We know what PII data looks like, we know what identity data looks like, so we can figure print things and make things searchable in a way that you're using us as your identity source, secure identity source. We already know all the kinds of queries you're going to want to run on searching for identity information. We're going to make that secure. Versus a more generic approach, which then punts that decision and architecture to the developers. The second thing, which is also pretty important, is how are the keys managed, right? This is something that Footprint solves with Nitro Enclaves. At the end of the day, cryptography doesn't really solve any problems. It just boils it down to the length of the key. Those keys are pretty short. But you still have to store them somewhere. Even in the world of fully homomorphic encryption, even if we had it, even if it was efficient, you still need a secure place to do those computations. Fully homomorphic encryption becomes super performant tomorrow. I think our nitro enclaves are the best place to do them, and we would essentially be able to roll out a bunch of new abilities for doing more computations efficiently in a way that secures the key outside of the rest of the application service area. [0:32:59] GV: Yeah. That's a very good point to make just about working with encrypted data, which is, yeah, the speed factor. I think it's a great point to make about, it is okay, actually, in cases such as this, to have opinions about the kind of data that is going to need to be worked with often, and then the kind that isn't. Developers should maybe try and think a little bit more ahead on these ones where they can. I say this more from the, I guess, the perspective of developers should start getting really used to having to work with encrypted data, because to this point in time, probably, I'm just going to hazard a guess that at least 50% out there listening have not ever. Their databases that they work with are just full of - they can see all the data and they know exactly what's going on, or they can see it. Fast forward two years, I hope it's only as long as two years that most databases, if you're a developer, you look at it, you have no idea what's going on. You're maybe working with some fake data, which we've fake test data, which we've got a couple of episodes coming up on, or maybe have already been out. Generally speaking, so the age of this database that everyone can just see and work with really fast, no, it's going to have to change. It sounds like, Nitro Enclaves are the absolute hard inversion of that, which is obviously needed for such a platform that is a vaulting platform. There are other step measures that developers can take that maybe isn't quite as far as Nitro Enclaves, but yeah, it's good to be aware of all the different approaches. Yeah. [0:34:29] AG: Yeah, absolutely. We've seen already that a lot of our customers and companies we talk to, they don't even want to store SSNs. You wouldn't believe the amount of architecture hoops that people jump through, so that they don't need to store things like SSNs. Because they don't have to worry about encrypting them beyond it and before it later, so they sometimes require users to retype their SSN multiple times in order to then send it in memory, without actually restoring it down. I actually applaud those approaches. I mean, they're thinking about it the right way. We're just trying to make that developer experience much easier. Tons of businesses actually do need to store this data for audit purposes, so that we need to solve it for them. [0:35:08] GV: Absolutely. Moving forward to how Footprint is a platform that a consumer, or user is going to be aware of and interact with, as well as the provider, the one that needs all this technology so that they can verify. It's a double-sided problem, at least that's how I looked at it, that you have to get both sides in agreement that they're going to use this thing. I guess, the user consumer maybe has way less choice. If they're coming onto a platform that uses Footprint, well, that's what they need to use. Yeah, how are you approaching this of other services using Footprint and are there any - what hurdles are you facing there, if any? [0:35:49] AG: Yeah. I think you said it right, which is users, they don't really care, I think. We'd like to think that most people love to perfectly architect their entire world of privacy and security. Most don't understand it, and they shouldn't really understand it. I've always been believer that security without user experience is pointless. It's not easy to use, no one's going to use it, so it doesn't matter how secure it is. Part of the overall ethos of Footprint is actually, be very design and consumer focused, even though we're selling to enterprises, to businesses. Part of that is because the end-user interacts with these embedded onboarding modules that we built. From the user's point of view, they think that the first time they're onboarding onto Footprint via a product, they're not really thinking about Footprint. They're not really seeing it. We do a couple of things to help the user understand if they're curious, because even though a lot of users might not care so much about their privacy and security, any time you ask them for very sensitive information, they always pause, right? That's the worst thing. You're trying to convert a user to buy some stock in your investing app, and they don't want to give you the core information you need to open and account for them. That's tough. The drop-off rate is huge. One of our missions is actually, just to lower the friction. Make it easier for people to use trusted applications on the Internet. To do that, we actually automatically generate certain privacy pages, and we explain to users how their data is stored and secured. It's akin to the very old days of your credit card, the badges on the websites of your credit card information stored securely, but I think on steroids, and where we actually explain to users much better. From the user's perspective, they're - the customers, businesses, the products that they're onboarding to have already made a decision to use Footprint, and so they go along with the flow. The one crucial step that we do to that onboarding is we have the user set up their passkey, we verify their phone number. We do a couple of credentialing steps. When the user comes back, it is a magical experience, where they do a face ID, or they do a touch ID, they basically use their past key, which from the user's perspective is just a biometric. As we understand it, the biometric is really a safeguard to the cryptographic key that's stored on that device, or synced across all their devices. From the user's perspective, they do this very secure operation, and all their data is auto-filled, right? That actually is a much better feeling than if, for instance some competing technologies, like, I think you entered the last four of your SSN and then verify an OTP, and then it fills in your information. That to users, I think, feels a little bit more sketchy of like, "How do you get all my information? Maybe I'll drop off. Maybe I'll convert." It's a little bit less clear, but also less secure, because SIM swaps are happening all the time. Men in the middle of fishing happens all the time with OTP codes. Passkeys really let us, when the user onboards for the first time, we create that passkey for them that lets us not only secure that account, but also slowly start onboarding them into this idea of Footprint in this portable identity across the Internet. For businesses, on the other side, they also don't actually necessarily care about the portable identity, especially when we were just starting out and we had zero portable identities, right? Why would they care, right? It's a chicken, or the egg network bootstrapping problem. We actually knew that that was part of our design from day zero. We knew that companies would not care about that. The reality is we actually set out to build the best onboarding platform, regardless of the portable identity, right? Even if portable identity never existed, companies should still choose Footprint, because it's simplified developer experience. It's much more accurate. It has security baked in and solves all these compliance regulatory problems as well. That's how we convince businesses to use Footprint is just giving them a much more superior product. Then eventually, the portable identities start rolling in and then it actually creates an even higher value prop, because not only can you securely onboard your users, you can also onboard them with less friction and means higher conversion rate, better user experience. For businesses, things like the passkeys, the credentialing actually end up playing a pretty positive role, too. That was something that wasn't necessarily obvious to us when we first set out to build Footprint. This is part of the security pillar as well, which is every platform that we talked about early on, they need to have the user log back in. It turns out that account takeover has detrimental effect, of course, to the end user, but also in the business, who sometimes is responsible for remediating the effects of that account takeover. Take, for example, a gambling app, right? Gambling regulations are really strict. If you break them, you can lose your gambling license, you can totally shut the business down. Imagine a case where a parent creates an account and they're doing everything legally. They KYC themselves. Kid picks up their phone, does the OTP challenge, because they picked up the phone, and then logs back in. Now places a bet. Now that you have an underage person doing gambling, the parent complains that they lost a bunch of money and it wasn't them. It's this gray area situation. Things that strong authentication that proves that the person who verified their identity initially is the same person unlocking that device, all of a sudden, becomes very important. That's true not only for - this is more of a friendly fraud scenario where like, if someone, somebody you know takes your phone, maybe they don't even know any better. This is true as well if somebody breaks into your account, who somebody, like an actual fraudster, hacker, or whoever it might be. Really having that strong identity and authentication tied to the identity that created that account becomes really important. Things for account recovery. If you lose access to your device, how you prove who you are? Again, Footprint can do that. We know how to verify someone's identity. You have a bunch of authentication mechanisms that are beyond just username and password, which you might forget, or lose access to. These properties that make portal identity possible also have become pretty valuable to companies that aren't even thinking about the portable identity aspect, but just the core onboarding things that they have to solve. [0:41:33] GV: Yeah. I really like how you guys have thought about this, which is, yeah, the portable identity, yeah, that would be great once hundreds, thousands are using. But if you focus on that on day one, and that's how you try and sell it, of course. Unless the product is just a superior product, then yeah, chicken and egg. Really like that. Passkeys, I'm really interested on this one. Some listeners will probably know me by now that I love passkeys. I love talking about them, because I think it's just so many bits to them and nuances of the experience, especially. It's really interesting, you said that actually, passkeys has really helped here and sped up some of the parts of the process. I'm making a guess here that actually, when we're talking about identity and documents, then when we're then asking people to do an extra step of authentication, they're quite - perhaps, they're quite happy to do that. I'm coming from a different side, which is a platform that is actually currently building a platform that is passkey only. Actually, it's become our bit of a hindrance for us, where users are like, "What is this thing? What is this passkey?" It's because we're one of the first times they've ever seen a passkey, or for most cases. Do you find that your users, have they seen passkeys before? Is it something to do with, yeah, the biometric, or however they do it, it could be via, even their password vault? Do they just match it up and say, "Yeah, well, if this all makes sense," or have there still been some UX hurdles to get over there? [0:43:01] AG: Yeah. I mean, and I think this is totally hit the nail in the head. The user experience part here is really the hard problem. I mean, we've passed a lot of the other hurdles, the technology problems, the cryptographic keys, the hardware devices, storing them. This is the really difficult one. There are a couple of things that we've done that actually make passkeys a little bit easier for our users to adopt. One of the cool things, part of the onboarding process in Footprint sometimes includes document verification. When you're scanning a document and then doing a selfie scan, I mean, users are fairly familiar with this process, just because tons of platforms like a Coinbase requires it regularly, right? One thing that we do when you're onboard on let's say, on desktop or web, we show QR code to that user and they scan it with their phone, the camera on their phone, and that actually opens up a native experience on their device. We're leveraging this new technology called InSnaps on Android and App Clips on iOS. You might have seen this if you went to a restaurant and you got a QR code on a bill and you scan that QR code and brought up this native toast app, or this native app to pay. We're actually using that exact same tech. When you scan that QR code, we're loading an app just in time. This is a really small application that really gives us the business and the user a bunch of different advantages. First of all, it's much more native user experience, much more trusted, user feels that they're doing something that is okay, versus pulling up a sketchy, we've all done those like, checked into a hotel recently and they made me go to this random URL and upload a picture of my driver's license. This feels like a really native experience. It's branded to the product that they're onboarding to. They'll see Coinbase, or they'll see Flexcar there. The idea is we do the document scanning. We do the selfie scanning. By the way, it's much more accurate, because we can use rectangular detection, use all the native ML capabilities on the device to have much better scanning than you would get through a webcam. We do the space detection, selfie detection. We can scan the barcodes and the different attributes, vaulted directly, right? All of that good stuff. The other benefit is that we can tap into the native passkey biometric API, so we can, as part of the liveness check, right? The user does not necessarily even know that they're registering a passkey. From their perspective, it seems like, they're setting up Face ID for this product. It actually feels a lot more native. Because you're in a native app, there is a lot fewer screens to go through. You're already giving some information, so maybe emotionally, it's easier to also do a Face ID, or because that's actually much faster than scanning a document and whatever else. We couple that piece with the identity verification piece for documents. Then it works standalone, too. If you're not scanning a document, you could just scan that QR code to use your phone to set up that passkey. One of the things that we do is when we onboard a passkey, we always do it with a phone. Our reason for that is that maximizes the chance that the user will go through that flow successfully, but also that that passkey will then be synced across all their devices, right? Who knows where they're onboarding, desktop or web? It's like, sometime if you're renting an apartment, let's say, you rent an apartment in person, you use the realtor's laptop or whatever, right? At least you're using your own phone. We try to make sure you use your own device every single time to do these really sensitive things, like setting a passkey, scanning a document. That's just part of the regular flow. We've seen pretty good success with that. I think, different platforms when they introduce passkeys, they try to explain a passkey to a user. I'm not sure exactly. I think different users maybe react differently to those kinds of things. [0:46:30] GV: I just want to call out to the listeners. I think that's one of the most interesting and fantastic ways to use passkey is the way that just been explained there. I was going to ask anyway, yeah, how maybe more devices, or has that come into it? This is it. I think that passkeys on desktop currently are the big fall down, for all the reasons you've just mentioned. You could be on someone else's laptop much more likely than a phone, for example. Also, just the general experience across OSs, across browsers, very disjointed right now. I really love the way that you've explained how you've approached it. Yeah, that's fantastic. Just starting to wrap up a bit. I mean, we're recording this probably around a month before listeners will be hearing it. You mentioned one product development towards the start of this episode. What else can you share across, say, the next six to 12 months? What can people potentially expect from Footprint? [0:47:24] AG: Yeah. First of all, thank you. Appreciate the kind words there. Yeah, we're pretty excited about it. Yeah, there's two real updates coming pretty soon. Probably sooner, probably the next six months or so. In addition to this compliance product, we've been working really hard to integrate a bunch of new fraud tools. One of the really cool things about using Footprint on the frontend is that because we can do a bunch of behavioral analysis of the user, we can actually bake that into our rules engine. Bake that into different step ups. What you'll see with Footprint is that we're now starting to integrate and provide a lot of risk signals around fraudulent behavior. Think of like, user is typing their SSN very hesitantly, or they're typing in two digits and then they're pausing and then typing in more, to suggest that maybe they're copying it from somewhere. Usually, people know those by heart. Taking a bunch of different variables and user behaviors and how they interact with different inputs, maybe they're fingerprinting their mobile web-based session, all the frontend bells and whistles you can imagine that can tie into the KYC onboarding experience and exposing those as progress signals. We're also integrating third-party tools. I think, it's unlike KYC which is commoditized and largely can be solved for any business with the simple set of rules, I think fraud is much more complicated, because different businesses experience really different types of fraud, payments fraud, like crypto for instance, experience this horribly different fraud. The idea of being able to, without having to a new fraud attack pops up, put three engineers on it, spend a month building integration. By that time, a new fraud attack hits your company. The idea with Footprint is because we own that onboarding flow for you, you can just turn on different tools and make it really easy to deploy anti-fraud techniques, without writing a single line of code and respond to it in real-time. We can even tell you that these things are happening before you even realize they're happening. This is something that we've seen be really effective to a lot of customers that we're talking to and our existing customers. That's one. Related to that, we've talked about this and I've spoken maybe for granted a little bit about how companies just use our onboarding experience. That actually, if you're head of product at a company that onboarding is part of your domain, you're probably a little bit hesitant when you hear that. You say, okay, we spent three months building a perfect onboarding flow that explains the product and then bounces into collecting some information. Something very intricate. How can we just replace all of that with an embedded credit card form, like Stripe would do, but for identity? We've built from the ground up a very customizable onboarding form that makes it so that it looks and matches your - the look and feel of your product. We've even hit the upper bound limits of that as well. One of the things that we're rolling out really soon is we've taken everything that we've done in our embedded onboarding experience and we're breaking that out into components. Effectively, if you want to adopt Footprint, instead of having to rebuild your onboarding flow, or delete the thing that you've already built and replace it with Footprint, what you can really do is go to all your different PII inputs and just replace them with the Footprint components. We'll magically take care of the rest. That includes all the validation, errors, like the PO box example I gave, or the fat fingering the date of birth, all the way to all the fraud, behavioral capturing that we do because those are - you're now using our inputs, and all the one-click ability. If we detect that we already know who that user is, we can just pop a modal up and say, "Hey, authenticate with your passkey," and then auto fill the rest of those form fields. Have the user confirm that information and skip past the next step. We've effectively taken our embedded onboarding experience and broken it out into components. We're calling it onboarding components. Like what you would imagine an SDK, right? Instead of, if you're a new company and you're building your onboarding flow, you can still build it. Just use the components from Footprint. You can customize them however you'd like, but you get the superpowers right from day one. Those are the two things that we're excited and most about probably the next few months. Yeah, a lot more coming later, but I don't know if I can share that just yet. [0:51:19] GV: Yeah. I like where I think I hear that's going, almost SSO, but in a nice way, where the user hasn't quite realized that there is the experience that's driven and it's not maybe quite so much a brand, but they realize this experience of onboarding. They're used to it. Then, yeah, the magic bit there. "Oh, I just used my passkey," and boom, all these details. Obviously, if they slow things, they know why they came up and where they've come from, but yeah, I use my passkey. "Oh, wow. They already know about me in a good way. Fantastic. I could just move through this process very fast." Yeah, I like the sound of that. [0:51:54] AG: Yeah. Our goal isn't to teach the user about Footprint when they're filling out that onboarding flow for the first time, but rather, to teach about it when they - so they understand why it's being auto-filled the next time, or the third time, and fourth time. That's really where I think people will start seeing Footprint directly. But right now, we're focused on doing that initial onboarding experience and making that the best. [0:52:13] GV: Yeah. The example of that, I guess, I've seen more closely, but it's on the end of an experience is the Shop Pay model, where, yeah, users weren't really aware they were using Shopify across all these different sites, but they were aware that this payment method, which was just, I believe the first iteration was just put in your phone number and we've got the rest, basically. That, yeah, people started it and clocked, oh, this means it's Shopify. But the experience was so great, they didn't really care to begin with. Then now Shop Pay has been rolled outside of Shopify, which is super interesting. Yeah, sounds like a same approach, very different place to position it for the user, but yeah. [0:52:56] AG: Yeah. Shop Pay is incredible. I mean, I think they're also rolling out passkey as well now, I believe. Yeah, I think it's a very similar model. I think they're probably in a bit like, maybe them and Stripe link, I think, is trying to do something similar as well with the payments provider. But yeah, we definitely have a lot of respect for those giants that do an awesome work. [0:53:15] GV: Yeah, yeah. Likewise. Alex, it has been great to have you on. It has been just so many interesting things here. I'm sure a lot of inspiration for developers out there as well, especially around the vaulting side, as well as all this stuff towards the end of about passkeys and how to implement them in a nice way. Yeah, I just want to say thank you so much for coming on. Really appreciate the time. [0:53:40] AG: Thanks, Gregor. This has been super fun. Really glad to do it. Thank you. [END]