ZK Podcast: ZK for authentication with Nolan and Locke from NuID

Transcript

[Music] welcome to xero knowledge a podcast where we talk about the latest in zero knowledge research and the decentralized web the show is hosted by me anna and me frederick in this week's episode i speak with the co-founders of new id a zero knowledge authentication solution we explore the use case of password management using zkp's and how this relates to identity but before we start in i want to say thank you to this week's sponsor

elio elio is 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 elio developers can write private applications without a background in blockchains or any expertise in cryptography the world-class team of cryptographers engineers and designers at elio have released developer preview 1 an early peak at 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 a new development environment or ide called aeliostudio we recently had howard wu the co-founder

of elio 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 elio and start contributing today so thank you again elio now here is my interview with the guys from new id [Music] so this week i'm chatting with nolan and locke both co-founders at new id new id is a zero knowledge authentication solution think zkp's for password management welcome to the show lock and nolan thanks hannah yeah it's great to be here excited to talk about zkp's and some of the exciting applications that

you know we're we're working on yeah thanks thanks for having us 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 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 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 times spent in a in a basement having fun with some white boards what were you working on before i worked for the investment office of bill gates uh bgi and nolan was working at microsoft seattle makes sense yeah in seattle yeah right yeah right um and and i had actually been following and involved in the crypto currency space for a while so you know was very familiar with certain applications there and kind of blockchain entered the space stumbled across your knowledge proofs and i think i don't know it just kind of all happened

in a bit of a whirlwind of a year of hanging out outside of work cool would you say that's fair oh yeah no yeah that's that's that's about it for sure nolan what were you so you were working at microsoft before what kind of stuff were you were you working on there 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 for that stuff and so i was doing sort of data intensive things i guess is is what they described it as cool so so you left microsoft and lock

you left what you were doing at that moment and you jumped into founding this project or starting this project how did that start i'd say that the straw that kind of broke campbell's back in terms of us going all in was probably a conversation that we had with professor matthew franklin uh he's a professor of cryptography at uc davis and we kind of randomly got plugged in with him and it wasn't but 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 uh in 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 cool and you you said you were sort of interested in blockchain stuff at the time but like what i mean what year is it are we talking 2017 2016 it was it was uh certainly along with we kind of like rode the whole new id and cave phase right into like the center the heart of the hype you know wave and that it was it was kind of a funny thing to to enter almost immediately right after doing this so going into zero knowledge and and uh web three and

identity you know this whole push so uh yeah did new id at the time did you end up doing a token sale or anything like that or was it because like that would have been the time when you would have been tempted to do so i imagine oh absolutely yes and and we we designed one out and we it was definitely a big uh possibility for us at the time but ultimately uh it was also kind of what i'd call a peak of the hype wave and you know there was no precedent set in you know by authorities and regulatory bodies and yeah so we ultimately decided to go with kind of more traditional angel 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 a safer play to kind of go the private route than to do a token sale but we definitely have been i'd say uh following that space and and involved in it got it yeah that would say that's locked that would that is definitely locks insert i think that that 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 detectably 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 and a better you know better foundation for that to actually go through yeah when there's a framework for actually you know equity tokens right where you basically have a token or 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 equities need to be associated with an individual's identity they can't be associated with just a public private key pair on a

you know computer that like a token would that could just disappear if you know 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 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 yeah yeah 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 yeah so let's let's find out a little bit more about this project new id 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 what does it do so new id basically is an authentication solution uh we sell to organizations enterprises developers uh super simple to use and implement zero knowledge we call it trustless authentication meaning we actually use 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 hashed or any form of password on a local database

so it effectively returns the ownership of the authentication credential to the individual because they're not entrusting it to any other party including that who they're authenticating themselves to i'd like to hear a little bit about how authentication works now so that we can see what the difference is here so in the case of a password as you described how how is that currently being transferred like where does it live how 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 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 uh and authentication secrets

the way that they're stored and and the heterogeneity in that environment creates externalities for the 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 stored 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 is certainly one way to do it it has worked for us right we we do have all these services and solutions new services come up every day and all of them you know if you're 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 these different development solutions for providing a web service instantly pipe a new password into a new database right and so so we've got this viral outbreak of the way that this stuff is stored and managed and 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 this technology into our like daily lives uh 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 uh and and so that's one of the sort of cores of of why new id is interesting to work on because it does hand over 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 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 no that is 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 web page and you type in you know usually it's an email

and a password sometimes it's a username these days still but what that does is the email is just a convenient way for the receiving service to deduplicate or make sure that that usernames are unique right that's a that's a enforced by smtp for them then 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 and uh you know that pair goes across the internet and hopefully over https right and typically in plain text right typically there is no client side hashing done on that password sometimes that

there might be you know nuance there i but but typically what you see is that when a service is using https they're happy to send that tuple the the email address and the password across the internet the web server has some handler for uh you know they're hitting some endpoint 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 will pull the password along with that you know that we had previously stored when this person registered and then we're gonna compare for equality for symmetric equality the plain text password and and what we

have stored uh or or or some hashed version of that sometimes this is this is when somebody's actually submitted their password to log into the thing yes that's what you just described yeah like that first the first step of this you create your password the registration yeah so where does that live usually that's 100 just living sitting there in the services database from when you register right it's it's 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 but is sitting in that services database

and every service you visit and sign up for that is the case 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 and authentication identity experience uh where you know centralized in that there is a central database storing all the users authentication credentials login information and it's fragmented because that happens at every single service and and one other thing i'll say too is that to the registration process and and login process that nolan just described you know a lot of what we've seen in the last couple years is that even companies that may be hashing passwords and storing the hash which you know does have its 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 and breaches in the recent history and not just small companies either we've seen that we've heard about some of those yeah yes yes but i'm wondering like on the side like it's like on this on the side of this database like do they also encrypt that like they must put up protections sometimes sometimes yes hopefully yeah it's shocking how well a lot of there's not really a a no a well adopted just simple solute standard or solution that people use there's 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 and methods that people try to you know employ to stay ahead of potential breaches and and whatnot 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 right by protection by tremendous effort yeah but 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 centralized and 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 of 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 yep you know an individual is 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 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 does system look like instead with new id so i think that the simplest way over the course of of new id's 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 non-sensitive piece of information that they can verify a one-time time-bound sort of zero-knowledge proof against rather than symmetric equality when you say asymmetric like here you're saying that the server the server side like the right company side that would hold these passwords it doesn't have the information but you yourself do right you have the keys to like prove something on your side i guess the server doesn't have the private sensitive piece at all right exactly so exactly 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 you know prove that you're providing the same one with the new id solution we're using zero knowledge proofs on the client-side 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 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 know like we've we've covered it many many times on the show but now i'm trying to figure out which part is where right 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 something 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 yeah the prover yourself the proverb 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 the correct secret information right correct 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 uh root or the you know foundation or the anchor of that credential or that authentication see that asymmetric authentication secret is authentic and has integrity as data and that's why we use a ledger or a blockchain or anything like that is so that those public parameters that the verifier reference to references to make sure that the the prover has proven the right knowledge or you know provided the correct secret you know that needs to be public and correct correct public yes exactly public and high integrity you know high degree of integrity with it

and a further benefit of having it 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 i want to understand a little bit how like you say you know you've said at the beginning that you work mostly with the 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 a schema are they using a piece of software how does this work yeah 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 deal with interfacing with you know any of these ledger networks uh i see so that's an app so that's something you're doing on your side basically the writing to absolutely some public blockchain yes writing and reading and now of course should some company want to and this is very important uh i think as a general property of the system is that should

any of these enterprises businesses anyone we work with decide to basically eject new id 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 this lot uh ledger right they can still provide access to those identities completely independently of new id in perpetuity for as long as that network is running so are you part of then 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 because 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 so this is big yeah so so the full set of endpoints right now that 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 endpoints for challenging a credential and then verifying the proof right and so that's the big big thing right so those last two those ladder to 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 and so that requires that the client can do the proof generation and all of that stuff is provided through open source libraries through new id so proof generation and verification uh are kind of packaged up in in nice like little javascript libraries and and we're trying to uh 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 for 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 new idea at all they could very much implement the protocol and everything and and just continuously support those same identities across time without needing you know being bound to new id in any way we're making it such that companies don't ever have to worry about their authentication process or workflow and never have to worry about you know having compromise their users 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

takes care of the entire process cool 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 oh yeah company season i mean a lot of companies what 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 it 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 yeah you know whatever that is but 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 uh 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 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 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 idea that you you own something that's yours it's bigger than just a password maybe like what is your thinking around that there are a number of a number of branches there and kind of the next piece i guess would be a you know

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 a user owned 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 prover right and as part of that like imagine where you know a service a company that's using new id for authentication could you know verify through today's kind of standard channels and individuals 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 then

not only are there authentication credentials portable but you can build a record of you know history of any well any sort of data but particularly a verification that that person you know is who they claim to be and and all these um kind of appended 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 having to do so uh one can do it you know give you this attestation you go you know authenticate yourself at another service they could request and you could authenticate them access to see that identity verification so like a portable kyc

really that's 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 so there's a number of ways this can 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 or provide you know 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 zero knowledge proof yeah just to kind of expound 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 like 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 uh absolutely some schemes and and jan uh i think his name is is jan kamench does a lot of work on proving the attributes in zero knowledge as well so actually embedding that information into azure knowledge proof as well can be done for sure interesting this is a like so we've had so many

we've you know talked to lots of zero knowledge projects and companies but i like that this is a very like i have not heard id plus zkp's actually like combined into a full a full thought yet um this is cool very nice 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 right 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 that history you describe you 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 well there's ways where that actual data could be encrypted right 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 new id 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 our we were thinking about digital identity but ultimately you have to have a rock solid foundation for authentication to ever even have a you know user-owned 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 definitely in its infancy i'd say you know you've got distributed identifiers verifiable claims people working on these kind 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 owned and decentralized you sort of you you hinted at this earlier when you talked about like the zkp's i want to kind of go back for a second because i really 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 around like every time you submitted it or something what i've i missed this part of it sorry sure sure and 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 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 the password you're you're actually sending something fundamentally different and completely independent right completely separated completely uh isolate not correlated at all from what you sent before it from the previous attempt yeah so right now as i understand it you actually are like this the ledger that you've decided to use you use the ethereum uh 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 off chain thing so we actually so right now uh during

the preview for our developer portal uh we've actually been submitting them to the rink b test number one could be um but it would be sort of a trivial sort of parameter switch to to switch to the main chain and the other thing that we've really considered doing is using sort of whether it's in fiera or cloudflare's gateway to ipfs that could also be a really uh robust uh backend for for these kind of persistent credentials the ideal scenario would be something like a file coin 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 observe that and stop paying for its hosting and stop

so that would be a really cool thing it's kind of a bittorrent plus payment right so the more a credential was used the more places it would be sort of seated 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 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 them the gas prices so you only have to write to change during registration okay so when a credential is being registered uh in subsequent authentication verifications you're not writing from the chain at any point you're just registered checking it again yeah and it's also yeah the size of the data that's

actually being you know written to the chain during a registration is super small so the actual uh you know dollar value equivalent of the gas cost of writing is is very low would that gas cost fall on the side of the client or the the server in this case so we as per by providing the api bear that cost and pay that and that's yeah and so our api our kind of sas model is such that you're effectively paying per monthly active user so or at least within a certain tier of number of monthly active users so uh effectively it's being passed on to the organization that's implementing new id uh via the you know api access

and i guess with like password registration it doesn't have to be done immediately like it's okay if it's a minute right i think well it gets cached as well so it can be used immediately even before it's confirmed uh within a block on on the blockchain okay so and again that's sort of part of the service right if it uh you know we do uh shield that finalization that you know waiting for it to finalize on the chain is something that or on the ledger or you know whatever the back end is is something that we kind of shield our consumers from which is you know immediately once something's registered with new id it's available okay uh to be but you know if there was an independent service right that that you know say service a registered through new id

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 the blockchain unless they were like looking at the mining the pool right the the transaction pool you know yeah the mempool doing if they were kind of you know analyzing the mempool then maybe uh something but you know there's what is the what is the zkp built out of what like what kind of zero knowledge proof are you talking about because i'm guessing it's pretty it's probably pretty small right it's small and it's simple and it's my favorite it's just schnoor okay right it's it's uh schnoor's uh non-interactive zero knowledge proof and the reason that we chose it

so the other kind of thing that is 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 uh zero knowledge protocol implementation or scheme 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 yeah it's very much just pure data you know anything it's binary it's just whatever it is it's pretty small you're not running the verifier in a smart contract no no and that's that's we're not making use of smart contracts that's a very common thing yeah it's a very common thing all we're using is is basic transaction mechanism uh and so

basic storage uh again bitcoin could be used for this it doesn't have to be absolutely smart contract based chain it's truly we're we're only using the this distributed ledger for persistence storing yeah the immutable persistence and redundancy of the actual public pieces that's right zero knowledge got it have you thought about actually like building more on the ledger side like having a verifier on chain definitely definitely i think that once 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 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 and 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 their ability to be implemented correctly and securely especially doing something uh like zero knowledge verification and and 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 a less lesser concern uh i think but i would like to see a a

smart contract verifier would be would be cool you just used the term dark forest this is the third way that we've heard it used yeah so it's been you it's refers to the game the zk game okay it refers to the mempool and you've just used it to refer to smart contract development which is fair right right right it's very much a useful term and this yeah it's a very useful term in this space i think you're now you work with businesses so this is like yours your sas business working b2b are you like what is 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 yeah it really varies i'd say yeah so we we launched

our self-service our developer portal just earlier this year and we've seen a lot of uptake and people um trying that out and gotten some really great feedback from folks so there's like a free tier right premium 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 than the kind of value prop and then other folks you know become interested because of the actual technology they're in maybe the crypto space and then they want to talk about you know it all the way down to every last detail so there's a bit of variance there for sure it varies broadly and that has been

probably my greatest like 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 yeah i mean trying to bring i mean 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 um 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 waldorf waldo case sure 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 who 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 right clearly there's no question about that and that's actually one of the reasons that schnoor was uh i 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 schnoor's non-interactive zero-knowledge proof and actually come away with meaning whereas sometimes you see this notation in these white papers or academic papers yeah academic papers you see see or if you go look at like dan bernstein's like code for you know curve 255 one night it's like you're not going to be able to fig you know figure that out but in a higher level language i think schnoor is very accessible and i think that's one of the 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 so yeah

and to add to that a bit too you know it's not like we're walking out in the street and and telling everyone like hey we've got this great new authentication solution uh and they're like cool like how can i use it and it's like well you can't because no one's like taking it right so right 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 new id 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 into having new id credentials inherently but they don't need to take the time to go understand it if you know unless they'd like to i actually i just

i just thought of something what happens if they lose the password though if it's a ckp are they more screwed or what they can respond so this is the big thing about keeping the rough you know for the data piece right the 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 as part of kind of rectifying this is just like they do now they register a

new credential right they just uh a new credential appears on the chain or on the back end or 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 that you know the user will not see anything uh as a change there this is where i

actually expect a lot of zero-knowledge proof systems to live i think this is how i expected yeah yeah they're in something and nobody really knows that they're in there but they're doing something that's very efficient yeah and potentially you know taking away some of the risk of these third parties holding data absolutely in all sorts of levels yeah all sorts of ways 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 uh private key pair and and because of that i think you're right that like

most of these zero knowledge proof systems and and the ways that zero knowledge proofs will uh get applied in practice is gonna be at least at first these sort of back end kind of invisible type applications i 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 could be a really cool thing you know if users are able to to apply cryptography themselves in a sane way then we could have more surface level 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 back end 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 kept sort of for both for for a new idea 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 i'll share one that kind of actually sits in i guess in the intersection of of those two 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 you know 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 is quite exciting um and 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 you know methods where potentially you

have an ordered you know output from a a credential that can be you know rep repeatedly generated when successfully authenticated so so that's that's one area i'm sure nolan has a other yeah yeah i mean the the zero knowledge biometric is still you know sort of weary about but there is people you know people are definitely uh looking into using range proofs to like derive a zero like a template that you can then you know in zero knowledge prove the kind of feature set against which would be really cool if we can do that you know securely and well i guess another uh like lock was saying that the 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 and data in the sense of attributes or usage data of a platform or you know likes and 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 it tends to be going that way where people are wanting more of their data want to monetize their data you know want to do all sorts of interesting things with their data and so i know it's not very it's not zero knowledge proof specific or even new id specific but i i could definitely see

um it would be really cool if applications started giving you a more direct interface to their machine learning and out like ai about you 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 proof specific but i think that this the sim becomes sentient yes yeah very for it's breaking down the fifth the fifth one what that is 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 to 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 in the future so i want to say thank you to both of you for coming on the show sharing a little bit about new idea and having this conversation about kind of zero knowledge for authentication and zero knowledge for identity absolutely thanks thanks for having us can't we an hour just food sorry about the jackhammer uh great timing in the background yeah now it's gone right it actually has yes stopped we'll see if it comes back

too funny anyway well thanks um this is great looking forward to it yeah thank you so much it's been awesome thanks again yeah and to our listeners thanks for [Music] listening