Web3 UI/UX in 2024: Passkeys, Account Abstraction, MPC and the Industry State | Zhen Yu Yong

[Music] hi everyone welcome to the Trident stage and welcome to eth Denver 2024 our next speaker is Zen CEO of web 3 o thank you hey guys hi Denver how's everybody doing is it a fresh morning it's uh I'm feeling a little bit jet lag to be honest but glad to be here for sure the sport whales are a lot cuter this year um I was checking one out um I'm Zen I'm one of the co-founders of web3 off we are the leading W as a service uh company that provides social logins to wallets and uh via account action MPC and more we power no safe animoca Brands and a lot of other uh both web 2 and web 3 brands that you guys might know know and have heard of um today I'm going to be talking a little bit more about let me just get this out it's a bit weird okay today I'm going to be talking a little bit more about uh something a little bit more technical um I'm going to talk about pass keys and basically enabling face/ Touch ID uh on wallets um and on your applications so that you guys can go off and try it out and kind of like play around with it yourselves so um before that just want to do a quick lay of the land right um who here knows what pass keys are even in the first place okay most of y'all and who here also know what account abstraction is okay also everybody and also um like uh fantastic that that that's just perfect who who knows about webo then okay I'm surprised okay yeah that's great okay so most of you kind of know uh what pass Keys as a a construct R um P keys are an implementation of web ofen which basically is a a a interface on your browser or also on some native devices that allow you to use your Hardware Enclave key pair to sign and authenticate to web two applications now although pass Keys um and the user experience is really nice and seamless it actually looks a little bit like this um you this is me doing it my Mac I was just doing it last night um but basically you can see that I I just use my Touch ID on my Mac and I'm basically into the application or into whatever I want to do right um so bis is also a trend that has been pushed out by large industry Giants including Apple Microsoft and you all know that already because most of you all know what pasis are um some of you might have felt the experience on applications that you guys already know and love coinbase in particular just launched it I think like couple days ago or last night um binance has it GitHub you know all all all of these nice applications have passies and now today we're going to learn a little bit more about how these are implemented and how also y'all can uh do that in your application yourselves as well so um first steps the first thing is right uh uh digesting kind of like the flow and authentication flow of p keys themselves and uh how how how how how that works so this is just ripped off from the website directly itself you'll you'll see that um there are two main parties over here the first party is the relaying party server and this is the server that's looking to authenticate the user looking to uh digest and understand and make sure that the user is who they say they are and the second one is the authenticator the authenticator and as well as like you know this browser and all that lives on the user's device um and that's the second stakeholder here now the flow of authenticating a pass key is uh simply the relaying party server issues a challenge this is not too different from what you think a OTP is or an email you know a passwordless email OTP might be um it typically is a string you can configure it as the relaying party server and you issue that challenge to uh users front end then um it's ingested by uh the JavaScript on a user's website or users um on on the website that your user has loaded up uh that the web auen API is then called it hits the browser and then it hits the authenticator now authenticators are actually generalizable there are lots of different authenticators out there um pass Keys is a form of a authenticator uh in particular that like Google and like apple have implemented on their phones but um I'm not sure do you guys know like Ubbi keys or like uh or like uh um uh let's see UB Keys uh authenticator app is different but you know UB keys and all of these different Hardware keys that you might have played around with before that's also forms of web auth authenticators as well um but today we're specifically talking about past keys and uh so the authenticator will basically sign on the challenge that's been issued this challenge is then uh propagated upwards um generally a new public private keypad is generated for each credential that we're talking about signing on and uh that's also relayed upwards in Step number four and finally last but not least it's relayed through the browser and pass back to the relaying party server where we see server s side validation so how do we add um how do we add uh how do we add crypto into this how do we add a connection to the blockchain into this right um so the way we do it is and this is the first way to kind of uh a way to kind of naively uh implement this would be steps one to five are basically exactly the same right but afterwards the public key as well as the credential is relayed via you know like infer what whatsoever um on chain in particular into on on on either a uh smart contract wallet or a account abstracted setup right um uh on chain and and and and just used the the the transa the the signed object which was received back from the relaying party server it's used as verification and it's used as an intention for a user interaction um so we would basically choose to Adit the challenge right in Step number one we would instead of just issuing a random nons or random like uh uh a random uh like challenge to the front end we'd actually issue maybe um a set of commands something like transfer 20 usdc um we then sign uh we then go through the same process sign relay that object through the gas relay and step six and then it goes on chain and verified on the contract the the um the signature itself is verified on the contract itself now this is a naive implementation right a naive architecture of how this would be done can anybody kind of spot what's wrong with this implementation just outright if we were just to do this if we were just to take a web signature or a pass key signature and put it on chain can everybody spot something that's wrong I don't know if we have a Q&A and mic but you guys can shout anybody what wrong curve wrong curve um yes it's uh web then is a wrong curve but that's why we actually doing the signature validation on chain on in Step eight relative to it um so uh that so like um he mentioned wrong curve and that's absolutely correct wellan signatures do not comply with ecdsa or sccp 256 K1 signatures um and therefore we need to validate web authen signatures specifically on chain um and while that's correct and accurate that wasn't the uh problem that I was trying to point out here can anybody else see potentially what what's wrong in this naive setup again we're just taking a signature and we're relaying it on chain and intending that that is a uh interaction that the user wants to do for example in step one we're saying hey you want to send 20 usdc and we're just relaying that onchain and that acts as verification for you know the contractor wallet to then move forward anybody okay so the problem is actually replay attacks um in particular oh this is yeah so in particular it's replay attacks um the the main issue here is that if I choose to try to send 10 usdc outwards right and a signature from webn describes my intent to do so somebody once I relay that transaction on chain this transaction is public people can see it people can basically take the same web aend signature the same uh the same uh intent right and replay it so for example if I I Zen were to send Bob $10 and I actually had $100 in my wallet Bob could take that same signature and Replay that 10 times right because it's the web offend signature that we're verifying on chain because the Curve is not compatible that describes my intent to send money how will we fix that does anybody have a does anybody have uh fix to this now that now that uh We've outlined the issue what' you say yes that's right use a nons he said use a nons so basically we just have to add an not on chain that is that describes part of the intent it's not unsimilar to the transaction nons that you might typically Implement um so you just add a nons and this nons will increment it can start at zero and that means that every signature that you sign on is unique because of that nons um and if it's not signed on a incrementally you know increasing nons it's just not a valid signature um yeah and that basically is more or less a basic a very high level interpretation of uh of uh of how one can um uh Implement pasis into an account structed setup um so us at web through off we've had we we've done this with a couple of clients and a couple of companies and um I and we've made a lot of mistakes along the way past Keys is a relatively New Concept it's a relatively new thing for users to be adopting um and as such in production you actually face quite a few uh issues here and there the experience is great in general but definitely one of the biggest problems is that pass Keys themselves or webn uh Works super well in apple and some of the latest Apple versions but on other devices on like Windows on like Androids they don't work so well there's a lot of different versions of Android there's a lot of different versions of um uh of window Windows a lot of different manufacturers and there issues with Pass key implementations uh across them right um another thing is definitely there's extra cost for the verification in particular because the chains are not compatible you are paying an additional component for Pass Key verification on which is on chain verification which can be costly and then last but not least I so it's about like the last I checked is about 15 to 20 cents on polygon and quite a bit more expensive on on mayet um and then last but not least there's actually a centralization risk with the relaying party server so pass Keys as well as webathon in general are application scoped meaning that there has to be a relaying server party issuing The Challenge and receiving the challenge as well in particular this is required by the domain specification and it's enforced by domain um by domain ownership uh and like DNS ownership right so um if somebody basically you are dependent your pass key is dependent on that specific domain to be used and if this domain goes down they can't steal your money but they definitely can um they definitely you you basically can't use your P key anymore um so some implementation recommendations so that you guys don't commit the same mistakes that we do and some of our early customers did um are definitely with with pass Keys what you want to do is you definitely don't want to use pass keys in a silo at this point in time what I mean by this is you want you don't want to use pass Keys as the only signer to your account contracted wallet or the only signer to your um uh to to to to your account essentially uh why this is the re why why why this is the case is because um pasis are well uh not exactly as robust there are edge cases people do lose them and you don't want people losing accounts on your different implementations um no web to implementation that exists today includes just a pass key login into a user account because recovery is an issue um the second thing is you definitely so the second thing is just to add on that you definitely uh you can use it as the the a alternative login as the FSE Factor but you can also use it as a second Factor like a 2fa um as per normal um like uh as per normal uh last but not least you want to restrict uh you want to restrict your implementation to compatible browser and Os setups so uh for example Chrome and um iOS just don't work with pys uh you won't be able to access your Hardware Enclave via Chrome Pas Keys is a very specifically Safari integration so on iOS you only want to allow Safari and if the user is not on Safari you don't want to enable this feature because it just uh runs into RIT routes and it is the same on Chrome Android you only want to allow Chrome Android or Chrome um and uh Windows edge/ Chrome as well in particular yeah I mean that's about it um and uh I hope you guys uh enjoyed this little snippet and uh if I mean I can take some questions actually if there's any time for Q&A in particular anybody has any questions or anything they want to double click on here yes sir so the coinbase implementation is a very interesting and novel implementation um for for those of you who don't know the coinbase implementation is a uh they have your main key right your main smart wallet that is on coinbase wallet itself and then they basically use pass Keys as session keys for adaps and applications to use and sign without having to go back into the um coinbase wallet to confirm every each and every transaction so the optimiz so what they're using pass Keys as is essentially they're using pass Keys as session keys for dabs um I think it's a good implementation because even though you lose your pass key you never lose your original account with coinbase you just lose your session key and your session on that application you can rehydrate it and you can um you can create a new Pass key for that dap so there's no concerns of loss uh I think it's quite an Innovative and novel approach of using pasis and I think it's uh really cool any other questions all right okay um yeah you can find us here if you guys want to use social logins in your applications do hit up web three off um we also have recently released our pasy SDK as well as our foraster login SDK so if you want to do log in with farcaster into your application do check us out as well unfortunately we aren't sponsoring Eve Denver this year so we have no prizes to offer but you know um you know to that's it thank you guys thank you so much Zen uh stay tuned our next talk is at 11