Anna (00:07):
Welcome to zero knowledge. A podcast where we talk about the latest in zero knowledge research and the decentralized web. The show is hosted by me, Anna.

Fredrik (00:18):
and me, Fredrik.

Anna (00:18):
In this week's episode, I speak with the co-founders of NuID, a zero knowledge authentication solution. We explore the use case of password management using ZKPs and how this relates to identity. But before we start in, I want to say, thank you to this week's sponsor Aleo. Aleo was the first platform for fully private applications. It uses blockchain and zero knowledge cryptography to deliver a web experience that is both personal and private. With Aleo developers can write private applications without a background in blockchains or any expertise in cryptography. The world-class team of cryptographers, engineers and designers that Aleo have released developer preview one. An early peak of what the future of the web can look like. The release introduces a new programming language called Leo a new community-driven package manager for Leo and new development environment or IDE called Aleo studio. We recently had Howard Wu, the co-founder of Aleo on the show for an interview. If you haven't yet checked it out, I highly recommend giving it a listen. I'll provide a link to the podcast and the developer preview in the show notes. So you can learn more about Aleo and start contributing today. So thank you again, Aleo. Now here is my interview with the guys from NuID.

Anna (01:47):
So this week I'm chatting with Nolan and Locke, both co-founders that NuID. NuID is a zero knowledge authentication solution, ZKPs for password management. Welcome to the show Locke and Nolan.

Locke (02:01):
Thanks, Anna. Yeah, it's great to be here. Uh, excited to talk about ZKPs and some of the exciting applications that you know, we're working on.

Nolan (02:10):
Yeah. Thanks. Thanks for having us.

Anna (02:12):
Let's find out a little bit about the two of you. How did you get started and why the authentication space, if you can describe what kind of got you curious about this? I think it would be interesting.

Locke (02:23):
Yeah, I'm sure that we both have maybe slightly different perspectives, but long story short, we were both working in Seattle, uh, four years ago or so, and happened to meet serendipitously through a mutual friend one day and kind of hit it off. And then, one thing led to another, I guess, and we just kind of went down the rabbit hole, thinking about all sorts of things, I guess, online, but a lot of things came back to identity and digital identity, and then we realized that authentication was really the foundation for digital identity. So a lot of time spent in a basement I'm fun with some whiteboards.

Anna (03:01):
What were you working on before?

Locke (03:02):
I worked for the investment office of Bill Gates, BGI, and Nolan was working at Microsoft.

Anna (03:11):
In Seattle.

Nolan (03:13):
Right.

Locke (03:14):
And I had actually been following and involved in the crypto currency space for awhile. So, you know, I was very familiar with certain applications there and kind of blockchain entered the space. Stumbled across zero knowledge proofs. And I think, I don't know, it just kind of all happened in a bit of a whirlwind of a year, hanging out, outside of work. Cool. Would you say that's fair?

Nolan (03:38):
Oh yeah, no. Yeah. That's that's, that's about it. For sure.

Anna (03:41):
Nolan, what were you, so you were working at Microsoft before, what kind of stuff were you working on there?

Nolan (03:47):
Uh, I had joined the sort of newly formed hub for their data science, um, like operations. And so they had just recently sort of centralized their like data science efforts. And I joined that kind of push, uh, for that seven. So I was doing sort of data intensive things, I guess, is what they described it as.

Anna (04:11):
Cool. So you, so you left Microsoft and Locke you left what you were doing at that moment and you jumped into founding this project or starting this project. How did that start?

Locke (04:22):
I'd say that the straw that kind of broke camel's back in terms of us going all in was probably a conversation that we had with professor Matthew Franklin. He's a professor of cryptography at UC Davis and we kind of randomly got plugged in with him. And it wasn't about maybe a week or two following that, that it was like, I don´t know, late Sunday night, we were in what we called the cave, which was basically the basement and the house I was living in. And it was like, we need to go all in on this. So that was kind of the moment that it really made a lot of sense. And then, uh, within the next few weeks we had kind of jumped ship to, uh, do this full-time.

Anna (04:59):
Cool. And you, you said you were sort of interested in blockchain stuff at the time, but like what, I mean, what years are we talking? 2017. Hype extraordinaire.

Nolan (05:09):
Yeah, it's a little before I think is really it was certainly along with. We kind of like rode the whole NuID in cave phase, right into like the center, the heart of the hype, you know, wave. Uh, and that was a, it was kind of a funny thing to enter almost immediately right after doing this. So, you know, going into zero knowledge and, uh, web three and identity, you know, this whole push. So, uh, yeah.

Anna (05:43):
Did NuID at the time, did you end up doing a token sale or anything like that or was it a cause because that would have been the time where you would have been tempted to do so? I imagine

Locke (05:54):
Absolutely. Yes. And we, we designed out and it was definitely a big, possibility for us at the time, but ultimately, uh, it was also kind of what I'd call it peak of the hype wave and, you know, there was no precedent set in, you know, by authorities and regulate jury bodies and yeah, so we ultimately decided to go with kind of more traditional annual institutional private capital and the possibility of doing that, uh, is not completely off the table at some point. Right. But there's, it's still kind of in its infancy. There's been a lot of development in the space. I know some European countries are probably further ahead than the US but ultimately I think it was safer play to kind of go the private route then and do a token sale. But we definitely have been, I'd say, uh, following that space and, and involved in it. Got it. Yeah.

Nolan (06:45):
That would say that's Locke. That is definitely Locke´s answered. I think that rough roughly reflects how I would be thinking about it too. But I think that, uh, especially in the 2017 and the hype wave, it was so detectibly a can of worms from so far away that I'm surprised that as many people did it as they did, uh, frankly. But yeah, I agree that like over time, you know, I think there will be more precedent set in a better, you know, a better foundation for that to actually go through it. Yeah.

Locke (07:16):
Yeah. When there's a framework for actually equity tokens, right. Where you basically have a token or a smart contract that effectively represents, you know, equity and cash flows in a company, and there's a legal framework for that, then it, that's going to be an awesome shift, I think from, you know, the way that that's all managed and handled today. And ultimately I think that identity, you know, does sit at the basis of that because equity need to be associated with an individual's identity. They can't be associated with just a public private key pair on a computer that like a token would, that could just disappear if you lost your private key or blew up your computer because like the framework for equity or ownership in a company like they don't match really.

Anna (08:00):
Yeah. I know that there's projects trying to work on that in different regions, but I, I don't think that there's like a standard set that is kind of accepted everywhere and yeah, I guess that's sort of coming. Maybe .

Locke (08:14):
There's definitely people working on it and working with regulators to try and, you know, create a framework for that. Um, but it's not quite there yet.

Anna (08:24):
Yeah. So let's, let's find out a little bit more about this project, NuID I gave a one-liner at the beginning of the show, but I think you can probably explain this a lot better than I can. What is this company project? What does it do?

Locke (08:39):
And what does it do? So NuID basically is an authentication solution. We sell to organizations, enterprises, developers, super simple to use and implement zero knowledge. We call it trustless authentication, meaning we actually zero knowledge proofs on the end user device to make it where the individual never actually has to share their secrets such as a password, for instance, with any other party, including us. So it eliminates the need for anyone to store that hashed any form of password on a local database. Um, so effectively returns the ownership of the authentication credential to the individual. Cause they're not entrusting it to any other party, including that who they're authenticating themselves too.

Anna (09:27):
I'd like to hear a little bit about how authentication works now, so that we can see what the differences here. So in the case of a password, as you described, how is that currently being transferred? Like where does it live? How would somebody use it? I mean, we've all used passwords, but I think it might be good to explain what's actually happening.

Nolan (09:47):
Absolutely. So that's the, that's kind of the thing. And that's really, that's one of the kind of design goals or hopes of new ideas that passwords and authentication secrets, the way that they're stored and the heterogeneity in that environment creates externalities for the ones that are stored extremely well. Uh, if there's correlation between the ones that are stored really well and the ones that are sort of very poorly, then it kind of brings the overall security bar down. So that, you know, casting ourselves all over the place, all over the internet, like that is certainly one way to do it. And it has worked for us, right. We do have all these services and solutions, new services come up every day and all of them, you know, if you're using an existing development framework or an existing Firebase or, you know, so on and so forth, uh, all express or whatever, you know, all of these different development solutions for providing a web service, instantly pipe, a new password into a new database.

Nolan (10:51):
Right. And so, so we've got this viral outbreak of the way that this stuff is stored and managed, and stuff like that. And I think that, you know, in general, that is fine. Uh, if your users don't care when we went from no internet to internet, uh, I think that just having the service was enough of a benefit that, that things like password storage, uh, kind of fell by the wayside in terms of user expectation and user experience. But I think that as we kind of really integrate this technology into our daily lives, uh, and it's kind of a cliche thing to say at this point, but, but as this gets bigger for us, things like that, the subtleties and the nuance in how our passwords are stored and how we represent ourselves and just a generalized, like management of our representation on, on the internet is something that comes into view, right? It's something that you want to have. And so that's one of the sort of cores of, of why NuID is interesting to work on because it does handover one of those kind of key parts of any web service to the user that's going to be using that web service. Uh, that's vastly more preferable for me, in my case, at least. Uh, and so that, I think would be my answer with that.

Anna (12:19):
I still want to understand a little bit more clearly though, like, what is the journey of the password and where does it live? Like step-by-step, but I don't even know if it's technical like architectural way.

Nolan (12:32):
Oh, that is exactly architectural is a perfect way of, of understanding it because that's what we're changing. Right. That is more, that's what we're changing more than, more than anything else I would say. So architecturally, right? You, you land on a webpage and you type in, you know, usually it's an email and a password. Sometimes it's a username these days still, but, uh, what that does, the email is just a convenient way for the receiving service to deduplicate or, or make sure that that usernames are unique, right? That's, uh, that's, enforced by SMTP for them then, uh, rather than them having to do it themselves. So they take the email address and you type that in that's a unique, you know, key for you, and then you type in your password, and, uh, you know, that payer goes across the internet and hopefully over HTTPS, right.

Nolan (13:23):
And typically in plain text, right? Typically there is no client side hashing done on that password. And sometimes that there might be, you know, nuance there. But typically what you see is that when a service is using HTTPS, they're happy to send that the email address and the password across the internet, the web server has some handler for, uh, you know, they're hitting some end point with that tuple and what the, you know, there's usually some sort of middleware that says, "Hey, is this password?" So we'll, we'll look up this record by its email address. We'll pull the password along with that, you know, that we had previously stored when this person registered. And then we're going to compare for equality for symmetric equality, the plain text password, and what we have stored, or some hashed version of that sometimes.

Anna (14:18):
So this is, when somebody actually submitted their password to log into the thing. That's what you just described. But like that first, the first step of this, you create your password registration. Yeah. So where does that live? Usually.

Nolan (14:32):
That´s 100% just living, sitting there in the services database from when you register, right? It's it's you, you sign up usually maybe you have to verify your email, you click the link, whatever. And once that process is complete, once you sign up for a service, your password is just planted. And again, sometimes hash, sometimes not, all sorts of different nuance there, but it's sitting in that services database, and every service you visit and sign up for that is the case.

Locke (15:00):
I was just going to jump in and say that that leads to what we have today, which is kind of a centralized and fragmented password authentication identity experience, uh, where, you know, centralized in that there is a central database storing all the user's authentication credentials, logging information, and it's fragmented because that happens every single service. And one other thing I'll say too, is that the registration process, and login process, and no one just described, you know, a lot of what we've seen in the last couple of years is that even companies that may be hashing passwords and storing the hash, which, you know, does have it security benefits compared to the plain text. But we've seen like where log files have the plain text passwords stored. You know, we've seen that with a number of companies & breaches in the recent history,

Nolan (15:50):
Not just small companies either, we've seen that.

Anna (15:53):
We've heard about some of those. Yes. Yes. But I'm wondering, like on the side, it was like on this, on the side of this database, like, do they also encrypt that, like they must put up protections. Hopefully...

Locke (16:07):
No. I mean, it's shocking. No, yeah. It's shocking. How well, a lot of, there's not really, you know, a well adopted, just simple standard or solution that people use is, are all, there's all sorts of workflows set up and it's kind of scary to see actually how many of them aren't secure, but yeah, there's definitely all sorts of, you know, firewalls and, and database hardening methods that people try to employ to stay ahead of potential breaches and, and whatnot.

Anna (16:36):
Hmm. So I think I follow what you've just set up. So you're sending password email across hopefully secure network. It arrives, it's placed in a database, potentially made secure by some sort of like further protection, but yeah, but then we've heard about so many of these breaches and then, uh, Nolan, you were describing that second step, which is like to unlock that to basically log into the service, you again, send the same thing and it gets matched and checked. So that's how it works today for the most part. And I also, I think everyone can appreciate this idea of like fragmented. How did you say it? It was like a fragmented, it's centralized and fragmented. I think that's a really well, that's a good way to put it where we have tons of these passwords. We change them. We, you know, we all have this and yet we don't know exactly how it's being managed. They might be being managed differently, but always by these centralized bodies.

Locke (17:34):
Yeah. You know, an individual's putting their trust also in each of these services they interact with, to you know, store and secure that, that data. And it's a constant process to secure it. Right. I mean, it's staying up to date, maintaining your systems and staying a step ahead, I guess, of, you know, an attacker.

Anna (17:52):
Now, what is the idea that you bring to the table? Like you described it before, but like in this context where usually you'd be sending these pairs over, right. What a system look like instead with NuID.

Nolan (18:04):
So I think that the simplest way over the course of, of NuID history, I think that I've come to think that the most succinct way of describing the fundamental difference that we're kind of bringing to the table here is making every single authentication, modality, asymmetric. And so, you know, we were talking about passwords, right? And that, and regardless of whether they're hashing or not, the server, the authenticating server is testing two pieces of data for symmetric and quality are these the exact same thing. And that is what we've changed. That's the only thing. And, and using zero knowledge proofs, kind of a direct application of zero knowledge proofs to make even the process of proving knowledge of a password, making that process asymmetric as well. Right. And so there's a bunch of other kind of nice niceties of the, you know, various zero-knowledge protocols. But the fundamental difference is really that we've made any way you've chosen to authenticate yourself asymmetric, such that the authenticating server has some public nonsensitive piece of information that they can verify a one-time time-bound sort of a zero knowledge proof against, rather than symmetric equality. Uh.

Anna (19:25):
So when you say asymmetric, like here, you're saying that the server, the server side, like the company side that hold these passwords, it doesn't have the information, but you yourself, do. You have the keys to like, prove something on your side? I guess

Nolan (19:43):
The server doesn't have the private sensitive piece at all. Right. Exactly. So exactly.

Locke (19:48):
And, and the idea too, is you can think about it, that today's paradigm is what we call the shared secret paradigm, where it's a contradiction in terms, because you're sharing your secret when you're registering an account somewhere, right. Because you're giving them that password to store so that in the future, they can use it to prove that you're providing the same one. With the NuID solution, we're using zero knowledge proofs on the clients, that device to make it where the individual never has to actually share that secret with anyone. And it allows them to essentially prove knowledge of something in this case, a secret or an authentication factor without ever actually sharing that underlying knowledge with the party. That's verifying it.

Anna (20:30):
I now want to hear like the zero-knowledge proof itself, where does the pieces of the ZKP live? So we know that there's a proven verifier. We net like we've, we've covered it many, many times on this show, but now I'm trying to figure out which part is where, right.

Nolan (20:46):
So I'll Talk about it in terms of prover and verifier. Uh, because I think that that is a really clear kind of framing of it and will be common across any zero knowledge proof. And so in our case, uh, the prover is obviously the person logging in, right, the person providing the password or whatever, authenticating themselves to do some thing. Um, the verifier is always going to be the authenticating server. So in this, you know, the service, whether it's, you know, uh, whatever company, the company side, like you said.

Anna (21:18):
Yeah. The prover yourself, the prover is like, you're going to first create that thing. And then the verifier needs to make sure that when you try to log on, right, that you're using the correct information.

Nolan (21:30):
Right. Um, and then there's a third kind of one easy way of thinking about it is that there's a third body in this setup. That is the ledger, right? And the user can transact, both can independently transact with, you know, impunity on this ledger, within the scope of that network. And so that's a really important part because that is where the public reference is stored. And so both the prover and the verifier use that third body, which is the ledger to kind of make sure that the root or the, you know, foundation or the anchor of that credential of that authentication. So you, that asymmetric authentication secret is authentic and has integrity as data. And that's why we use a ledger or blockchain or, or anything like that is so that those public parameters that the verifier reference to, references to make sure that the prover has proven the right knowledge or, you know, provided the correct secret, you know, that needs to be robust and correct, correct public. Yes, exactly. Public and, and high integrity, high degree of integrity with it.

Locke (22:42):
And further benefit of having a stored on a distributed ledger like that as well is that there's no central authority, right. That actually has control over the persistence of that, that reference. So it's not like we could just delete that individual's authentication credential.

Anna (22:59):
I want to understand a little bit how, like you said, you know, you've said at the beginning that you work mostly with businesses who would be providing some service and they need a password management system and they could potentially use this, but like, how do they do this? Do they like, what is it exactly? Are they, are they implementing the schema? Are they using a piece of software? How does this work?

Nolan (23:22):
Currently? It is, it's provided through an API, it's an API available, you know, anywhere you've got an HTTP client. Right. Um, and so you just interact with this API and basically there's end points for registering a new credential. And so that sort of abstracts the idea of transacting with the ledger so that the business doesn't have to with interfacing with, you know, any of these ledger networks.

Anna (23:50):
So that's something you're doing on your side: basically the writing to some public blockchain...

Nolan (23:56):
Yes. Writing and reading. And now of course, should some company wants to, and this is very important uh, I think as a general property of the system is that: should any of these enterprises business, anyone we work with decide to basically eject NuID, right? I'm out, I don't want this. You guys are terrible. They can continue to, they can continue to support the same identities with no interruption because they're all public on the slot, uh, ledger. Right. They can still provide access to those identities completely independently of NuID in perpetuity for as long as that network is running.

Anna (24:35):
So, are you, part of them, is it, is the side that you do more of the proving part, the writing to the ledger? And then they always have access to the verification. Cause I'm just picturing if they stopped using the API at some point, like how they can't necessarily interact solely with public data on a ledger.

Nolan (24:51):
So this is big. Yeah. So, so the full set of end points right now that are like relevant to us is the creation of new credentials and the retrieval of those credentials. So that's a big part. And then there's also stateless end points for challenging a credential and then verifying the proof. Right. And so that's the big, big thing, right? So those last two, those latter two end points allow you from anywhere that you have an HTTP connection to basically challenge a credential and, you know, issue that challenge to some person that's trying to log in and then verify whatever they come back with. Uh, and so that requires that the client can do the proof generation and all of that stuff is provided through open source libraries through NuID. So proof, generation and verification, uh, are kind of packaged up in and nice like little JavaScript libraries.

Nolan (25:48):
And we're trying to, you know, we're continuously increasing support for various languages and whatnot, but basically there's JavaScript libraries for proof generation verification, but the API will do any component of that before you remotely. So it's largely about how a business wants to use it. There's sort of a, a full remote case where they're just using the API and very, very thin kind of integration in terms of they aren't doing any of the proving and verifying themselves. But if they wanted to do that, right, and especially if they didn't want to deal with NuID at all, they could very much implement the protocol in everything and just continuously support those same identities across time, without needing, you know, being bound to NuID in any way.

Locke (26:37):
We're making it such that companies don't ever have to worry about their authentication process workflow and never have to worry about, you know, having compromise their user's authentication, credentials and data. Because they don't have to store it. They don't ever have to worry about it. Our API is super simple and you know, it takes care of the entire process.

Anna (26:58):
I think I'm following a little bit, like I understand the business model around this where it's like, it's, it's basically, you've created the, the libraries and one could actually do it themselves. Like a company could run this themselves, but you do kind of the managed service, which will be a lot easier for a lot of companies. I mean, a lot of companies, what do they usually do? They just sort of like have there's some generic password system that they inject and now you have a new system for that.

Nolan (27:23):
You kind of zoned right in on it. It's like, basically what you're doing currently is either rolling it yourself, completely from scratch, you know, whatever that is. But then there's also, you know, a lot of these frameworks and this is the much more common path that developers follow this these days is you're either using Firebase or, or some, you know, the express middleware that is specifically for, exactly like you said, sort of inject this little password tool into your basic, uh, that really is, you know, it seems so inconspicuous when you're doing it, right. It's innocuous in that, in that, Hey, this is what everyone's doing. This is exactly what's supported. This is perfect. I love this, but, but there are all sorts of externalities that we're creating there and there are downsides to that model. And so yeah, that's, what's happening these days is. And so what we're trying to do is make it as easy or easier as the default to just use this zero knowledge thing, this asymmetric thing, and really have that be sort of the fallback rather than the current fallback.

Anna (28:27):
That's really cool. I want to go a little bit like we we've just zeroed in on the password example, which I think is really useful for people to understand kind of like a one-to-one comparison of what you're doing, but you've sort of mentioned that it's more like this ID, there's this like larger version, this, this idea that you, you own something that's yours, it's bigger than just a password. Maybe like, what is your thinking around that?

Locke (28:52):
There, there are a number of a number of branches there and kind of the next piece, I guess, would be a verified identity. So the idea of digital identity online, and, you know, the concept of kind of bring your own identity is where we're headed. That's also self-sovereign. So basically they use our own identity that they can access and authenticate, you know, their ownership of from any device, you know, that's internet connected as kind of the, the prover, right? And as part of that, like imagine where, you know, a service, a company that's using NuID for authentication could, you know, verify through is kind of standard channels and individual's identity. They could then create like a, this verified credential or attestation that is associated with that user's credentials, your ID credentials, right? So that not only are their authentication credentials portable, but you can build a record of, you know, a history of any, well, any sort of data, but particularly like a verification that that person, you know, is who they claim to be. And all of these, um, kind of upended pieces of data that then they can actually allow, you know, another party, an organization to reference. So, you know, imagine where instead of every company that wants to verify your identity, you're having to do so, uh, one can do it, you know, give you this attestation, you go, you know, authenticate yourself at another, uh, service. They could request them, you could authenticate them access to see that identity verification. So like a portable KYC really.

Anna (30:23):
Super cool is in this case, is the verification like in a proof, is it inside? Like, do you just submit the proof that it exists? And it still stays like...

Locke (30:33):
Uh, there's a number of ways it's going to be accomplished really we're using zero knowledge proofs specifically for the authentication credentials, right. And data, and then those can be used effectively to decrypt or provide access, authenticate someone to another piece of data that could be, you know, actually stored on any kind of storage backend, but not, you know, that data itself necessarily being in a, in a zero knowledge proof.

Nolan (31:02):
Yeah. Just to kind of expand on that a little bit. There's a, there's a number of architectures that you could go for all the way from, from centralized, like truly, uh, and, and, and a lot of them at least early on will likely be very trust centric. Right. That does specific institution granted me, uh, you know, some thing, right. And that's, that's just inherently sort of trusted, but there are absolutely some schemes and, and Jan, uh, I think his name is Jan Camenisch does a lot of work on proving the attributes in zero knowledge as well. So actually embedding that information into zero knowledge proof as well. Uh, it can be done. For sure.

Anna (31:44):
Interesting. This is a like, so we've had so many, we've talked to lots of zero knowledge projects and companies, but I like that this is a very, like, I have not heard ID plus ZKPs actually like combined into a full, a full thought yet. Um, this is cool. Yeah. I mean, there's definitely like inklings people kind of going in that direction. And I heard a lot about identity in general, like identity, identity on the blockchain, but I mean, one of the challenges in identity in general is some of it should also be private potentially, but right now it sounds like you're, you're using the ZKP more as like proof by holding certain things. But like, I guess you could also like the history you described. You'd need to have that within the ZKP itself, if you're going to also keep that private. But right now it sounds like you still want to have it a little bit outside because of kind of where we're at...

Locke (32:35):
Well there's ways where the actual data could be encrypted, right. Or, or fragmented and stored in any number of ways where it's private unless shared, right. And then the decryption keys could be actually your NuID credentials, that authentication data. But, you know, we are kind of at this point now where we've built the authentication solution originally, you know, are we were thinking about digital identity, but ultimately you have to have a rock solid foundation for authentication to ever even have a user own trusted digital identity, because if you can authenticate yourself as me, how can anyone ever trust that, you know, identity representation? And so we're kind of moving to the point of figuring out how to do these, you know, data storage and attribute storage type mechanisms on top of, you know, our authentication solution. So it's, it's something that's, you know, I definitely in its infancy, I'd say, you know, you've got distributed identifiers, verifiable claims people working on these kinds of things, but ultimately we think that user owned authentication credentials need to be the basis for that. If you're going to actually have it be ever truly user on decentralized

Anna (33:45):
You sort of, you, you hinted at this earlier when you talked about like the ZKPs, um, I want to kind of go back for a second. Cause I realized that we didn't really cover it sort of said that like with the public data in, on the public ledger, you mentioned that like, it would change round. Like every time you submitted it or something, what, I missed this part of it, sorry...

Nolan (34:02):
Sure. And we can definitely get into the protocol more specifically, but the part that's on the ledger is persistent and that's, it's very much, you know, persistent unchanging it's the, it is the kind of initial parameters of the proof, what changes and what is used one time, it can be sort of time-bound or at least contextually bound is each individual proof against that public reference. And so every time I log in, I'm going to be using a different, like piece of data that is completely indistinguishable from the last time that I did this. Um, and so, you know, that's, that's a big, big part of this is that like, instead of sending that same thing over and over every single time as is the case with a password you're, you're actually sending something fundamentally different and completely independent, right. Like completely separated, completely, isolate, not correlated at all from what you sent before from the previous attempt. Yeah.

Anna (35:03):
So right now, as I understand it, you actually are like this, the ledger that you've decided to use, you use Ethereum blockchain as your ledger, I guess, are you using like the main chain? You don't have like a side chain or any sort of offchain things.

Nolan (35:17):
So we actually, so right now, uh, during the preview for our developer portal, uh, we've actually been submitting them to the Rinkeby Testnet. Um, and, but it would be sort of a trivial sort of parameter switch to switch to the main chain. And the other thing that we've really considered doing is using sort of whether it's Infura or Cloudflare's gateway to IPFS, that could also be a really, uh, robust backend for, for these kind of persistent credentials. The ideal scenario would be something like a Filecoin where, where users are actually hosting also their public credentials and can then say, you know, Oh, this I'm not using this credential anymore. I can obsolesce that and stop paying for its hosting and stop. So that would be a really cool thing. It's kind of a bit torrent plus payment, right? So the more a credential was used, the more places it would be sort of seeded from, and that would be really efficient, right? That'd be a really efficient way of storing these things, but for now, you know, we just use Ethereum for that persistence layer.

Anna (36:21):
Right now you're on Rinkeby, but if you move to mainnet, I mean, how many times do you have to write to chain? I'm just trying to picture it, just give me gas prices,

Locke (36:30):
So you only have to right to change

Anna (36:57):
Would that gas cost fall on the side of the client or the server in this case?

Locke (37:02):
We, by providing the API bear that cost and pay that. And that's yeah. And so our API, our kind of SaaS model is such that you're effectively paying per monthly active users. So, or at least within a certain tier of number of monthly active users. So effectively it's being passed on to the organization, that's implementing NuID via the API access.

Anna (37:28):
And I guess with like password registration, it doesn't have to be done immediately. Like it's okay if it's a minute.

Locke (37:34):
Right, it gets cashed as well. So it can be used immediately, even before it's confirmed, uh, within a block on the blockchain. Right.

Nolan (37:41):
It's and again, that's sort of part of the service, right? If it, you know, we do, uh, shield that finalization, but, you know, waiting for it to finalize on the chain is something that are on the ledger or, you know, whatever the backend is, is something that we kind of shield our consumers from, which is, you know, immediately when something's registered with NuID, it's available, to be. But, you know, if there was an independent service, right, that, that, you know, say service A registered through NuID service B could also authenticate that same user by their same credential, but they would have to wait for, you know, the finality on the blockchain, unless they were like looking at the mining, the pool, right. The, the transaction pool, you know, if they want to pull the Mempool doing it, they were kind of, you know, analyzing the men pool, then maybe, uh, something, but, you know,

Anna (38:32):
What is the, what is the ZKP built out of? What, like what kind of zero knowledge proofs talking about? Cause I'm guessing it's pretty, it's probably pretty small, right?

Nolan (38:41):
Well, and it's simple and it's my favorite. It's just, Schnorr right. It's, it's a, Schnorr's non-interactive zero knowledge proof and the reason that we chose it. So the other kind of thing that is super important here is because of the way that we encode and store this information, we're actually not bound to any single zero knowledge and a zero knowledge protocol implementation or scheme.

Anna (39:07):
And it sounds like you're not, you're not bound to whatever the blockchain can allow because you're just storing the public key.

Nolan (39:13):
Yeah. It's very much just pure data, you know, any it's binary, it just, whatever it is, pretty small,

Anna (39:20):
You're not running the verifier in a smart contract, in this case.

Nolan (39:23):
No. And that's a common use of smart contracts. That's a fairly common thing. Yeah. It's a very common thing. All we're using is, is basic transaction mechanism. Uh, and so basic storage against.

Locke (39:34):
Bitcoin could be used for this. It doesn't have to be a smart-contract-based chain. It's truly, we're, we're only using the distributed ledger for assistance, storing the immutable persistence and redundancy of the actual public piece of zero knowledge credential.

Anna (39:50):
Got it. Have you thought about actually like building more on the ledger side, like having a verifier on chain?

Nolan (39:57):
Definitely. Definitely. I think that once I said for me, I know that the big thing there is that kind of smart contract verification and the actual implementation of, you know, implementing these things securely and, and without the ability to kind of like bleed it of all of its money, you know, it's like, I, I, I think that for me, uh, up until at least very recently, and only recently, has it gotten a little bit more comfortable, uh, smart contracts are sort of a, a dark forest in terms of, of, you know, their ability to be implemented correctly and securely, especially doing something, uh, like zero knowledge verification and stuff like that. And I know that that's largely what they're, what they're meant for, but we've avoided it to this point in favor of, of sort of, because the, the zero-knowledge proof itself is, is sort of a trustless thing who is doing it is ultimately a lesser concern. Uh, I think, but I would like to see a smart contract verifier would be, would be, uh,

Anna (41:02):
Cool. You just use the term dark forest. This is the third way that we've heard used. It's refers to the game, the ZK game, it refers to the Mempool, and you've just used it to refer to smart contract development, which is fair.

Nolan (41:18):
Right, right. It's very much a term and this, yeah, it's a very useful term in this space. I think.

Anna (41:25):
You're now you work with businesses. So this is like your SaaS business working B2B. Are you like, what does it like explaining this to businesses? Like, do you go into the zero-knowledge proof stuff or do you just kind of go like more private or something?

Locke (41:39):
Yeah, it really varies. I'd say, you know, so we, we launched our self-service our developer portal just earlier this year, and we've seen a lot of uptake in people, um, trying that out and gotten some really great feedback from folks. Uh, so there's like a free tier right freemium model, where, um, we've been able to get it out there. And then on the kind of more enterprise, like top down selling side, it really kind of varies. I think some people tune in very much more to the vision and what it accomplishes the kind of value prop, and then other folks, you know, become interested because of the actual technology there in maybe the crypto space. And then they want to talk about, you know, that all the way down to every last detail. So there's a bit of variance there for sure.

Nolan (42:22):
It varies broadly. And that has been probably my greatest challenge in terms of like meeting everyone where they're at with it and, and really trying to land why they would do this and why we would spend time working on this and stuff like that. Sometimes that can be more difficult than it should be.

Anna (42:40):
Yeah. I mean, trying to bring this podcast has existed for like the last three years. Wow. I guess. Yeah. And I think right around now, we're hitting three years and I'm like trying to explain zero knowledge proofs. We have an episode where we did like intro to zero knowledge proofs back in the day with the Waldo, Waldo case. But in your case, I think it's the architecture. That's like, that's also the most exciting thing for the end user, like for them to understand where things live. But I guess there is, there is this sort of sense, like, because it's really hard for the average person to do the math, to really verify it themselves. They have to rely on like other smart people could do the math who say, yes, it's really that way. And it really does work this way. And I think that's the, like, that's the unfortunate thing where it is mathematically sound, but the average person will not be able to look at the math and be like, Oh yeah.

Nolan (43:29):
Right, right. There's no question about that. And that's actually one of the reasons that Schnorr was, uh, I actually do think that Schnorr in particular is very well within range of if not all users, certainly all developers. If you, you know, all, I think developers can look at the implementation of Schnorrs, non-interactive zero-knowledge proof and actually come away with meaning. Whereas sometimes you see this notation in these white papers or, uh, you see academic papers or if you go look at like Dan Bernstein's like code for, you know, Curve25519, when I was like, you're not going to be able to fit, you know, figure that out. But in a higher level language, I think Schnorr is very accessible. And I think that's one of the main reasons, uh, that it was another, one of the main reasons I guess, that it was chosen is that, I think a developer could go look and be like, huh? I mean, that at least seems right. And then someone that's more involved could actually really truly audit it and get something out of it.

Locke (44:32):
And to add to that a bit too, you know, it's not like we're walking out in the street and telling everyone like, Hey, we've got this great new authentication solution. And they're like, cool. Like how can I use it? And I was like, well, you can't because no one is like taking it. Right. So, you know, the nice thing about being a B2B company with the authentication solution is that the end user doesn't actually their experience logging in and authenticating with the service that uses NuID. Doesn't have to be any different than the experience they have today. And it's really just, the company needs to be comfortable understanding that. And then we adopt, you know, the end-users and to having NuID credentials inherently, but they don't need to take the time to go understand it.

Anna (45:12):
I actually, I, I just thought of something, what happens if they lose the password, though, if it's a ZKP, are they more screwed or what?

Nolan (45:22):
They can reset. So this is the big thing about keeping the rough, you know, for the data piece, right. But for the, for the attributes or the data that you're acquiring or amassing at these services, the important thing early on is to keep that such that the service can rotate against the credential. Right? So, so in the case where I lose it is a different kind of flow, but in the case where I lose or forget a password or whatnot, what a user ends up needing to do in order to, or, you know, ends up doing it as part of kind of rectifying this, is just like they do. Now, they register a new credential, right? They just, a new credential appears on the chain or on the backend, or what have you. And then the service basically rotates just as they would a password field in their database. They rotate the reference of, to that public data in their database. Uh, and in that way, user experience wise, it's, it can be made to look absolutely identical to, to what, you know, a forgot password flow today. Now the semantics are a little different behind the scenes, you know, behind the login box, but in terms of the implementing service, they, you know, the user will not see anything, uh, as a change there.

Anna (46:38):
This is where I actually expect a lot of zero-knowledge proof systems to live. I think this is how I expect them. Yeah. Yeah. They're in something and nobody knows that they're in there, but they're doing something that's very efficient and potentially taking away some of the risk of these third parties, holding data in all sorts of levels, all sorts of ways.

Nolan (46:55):
I think you're right. I would agree with that entirely, especially early on, because right now we do not live in a time where everyone is key enabled, right. Not everyone is like, you know, has a key in their hand that they can go and use at any of these services, you know, a private key or a public private key pair. And, and because of that, I think you're right, that like most of these pero knowledge proof systems and the ways that zero-knowledge proofs will, uh, get applied in practice is going to be at least at these sort of backend kind of invisible type applications. I totally agree. But, but it would be awesome if in the future as users gain a more direct interface to cryptography. Right. I think that that could be a really cool thing. You know, if, if users are able to, to apply cryptography themselves in a sane way, then we could have more surface levels, zero-knowledge proof systems and applications. Uh, but I, I agree in general that, that until, until everyone's holding a key, then, uh, it'll be mostly on the backend.

Anna (48:05):
So what do you see as sort of like next steps for this just zero knowledge proof space, like you kind of mentioned this idea of like maybe having a single zero knowledge proof, guaranteed password verified. I know I just said that completely wrong, but like, I guess actually the question is sort of two for both, for NuID, but also for zero knowledge proofs in general, like in their use, what do you see kind of coming up or what's exciting to you?

Locke (48:29):
I'll share one that kind of actually sits in, I guess, in the intersection of those two kind of sides that you just said, and that's, you know, the exploration of using zero-knowledge proofs for other, uh, authentication factors and modalities other than passwords, right? So for instance, a zero knowledge or fingerprint or face scan type authentication factor where you're actually on today's flow, you would basically use, you know, fingerprint or face scan on a local device that unlocks the private key. And then that private key could be used for, you know, to generate a zero-knowledge proof authentication factor, but actually creating a zero knowledge proof, you know, biometric credential is something that I think is quite exciting. Um, and people are looking into, uh, so that's, that's one area. The thing is you need, and maybe not, you can have there's range proofs that are looking to maybe accomplish this, but other methods where potentially you have an ordered output from a credential that can be repeatedly generated when successfully authenticated. So, so that's, that's one area I'm sure Nolan has other, yeah.

Nolan (49:39):
Yeah. I mean, I, the zero knowledge biometric is still, you know, sort of weary about it, but there is people, you know, people are definitely looking into using range proofs to like derive a zero, like a template that you can then, you know, in zero knowledge proof the kind of feature set against, which would be really cool if we can do that, you know, securely and, well, I guess another, like Locke was saying that the whole idea of data management is interesting. I mean, there's, I don't know if you're familiar with like Twitch and like there's all these sort of different, uh, pushes for applications that give the user more control of their data or more ownership of their data, and data in the sense of attributes or usage data of a platform, or, you know, likes stuff like that. I, you know, I think that whether or not, I think it's a good idea or what, I think a lot the space is tends to be going that way, where people are wanting more of their data and want to monetize their data when you want to do all sorts of interesting things with their data.

Nolan (50:43):
And so I know it's not very, it's not zero knowledge proof specific, or even NuID specific, but I could definitely see, um, it would be really cool if applications started giving you a more direct interface to their machine learning and like, AI is about you, right? And so like if I could go into Spotify and sort of work with the recommendation algorithm, right. That is something that I think would be really cool. I know it's not zero knowledge proofs specific. But I think that...

Anna (51:12):
That the sim becomes sentient. Yes. It's breaking down the fifth wall.

Nolan (51:19):
Yeah. You're dealing with, yes. You're dealing with the model right directly and you can kind of update the services model. And I do think that over time in order to do that in order to like have the kind of data sharing mechanisms in place too, to really get where we're going, there will be sort of zero-knowledge proof systems, uh, kind of like you were just saying in the back end, supporting sharing and manipulation of data over networks in the future.

Anna (51:49):
So I want to say thank you to both of you for coming on the show, sharing a little bit about NuID and having this conversation about kind of zero knowledge for authentication and zero knowledge for identity.

Nolan (52:00):
Absolutely. Thanks for having us. Can't believe an hour just flew by, sorry about the jackhammer! Had a great time. Right. In the background now it's gone actually has just stopped. We'll see if it comes back. Too funny. Well, thanks. This was great. Looking forward too, yeah.

Locke (52:19):
Thank you so much. It's been awesome.

Anna (52:21):
Thanks again. Yeah. And to our listeners. Thanks for listening.