DAPPCON 2024: Session Authentication For Smart Accounts - Pedro Gomes

Transcript

my name is Pedro Gomez and I'm the founder of Walla connect and I'll be talking about session authentication for smart accounts and in order to do that I think we need to kind of break down the lingo because in web 3 we talk about a lot of like new terminology but if you think about it a lot of the terms are familiar or at least the experience is familiar with what is the internet today and when you think about connecting the wallet we're basically just moving away from like this login experience to a connect experience but is it really that different like even if you consider all of the actual terms that we talk about from signing and accounts and keys and connections but realistically we're doing authentication which is a very

well-known uh term and at the end of the day you just need to verify you are who you are and if you're a user and you want to use an application authentication isn't necessarily the most fun part because at the end of the day as a user just thinking let me in like I just want to get in like I don't want to get like like with more steps so I think it's important for us to define the mission that in order to have a good experience less clicks is more and that's essentially what we're going to try to achieve with smart accounts but at the same time we to address why web Tre is different and by understanding the concept of how the previous internet to some extent or the internet that the

majority of the world uses sometimes called Web 2 you have this concept of a server and an application and while the server has a lot of components one of the most important components is the authentication part and you can see in this diagram a very simplified version we have internally of the server a small service or component called off and in a blockchain or web Tree World we basically move that into the user device because we wanted to empower the user to actually have control over his data and assets and we called it the wallet and the wallet essentially is the module that actually allows you to authenticate into the blockchain and the app is essentially waiting for the user to

actually give permissions so if you think about this like maybe we should break down what the wallet actually is uh because obviously it was different than what we had before and we can think of it as almost three separate Concepts where you have a set of credentials that allows you to actually get access to the wallet which might vary from like passwords and PIN codes or email depending on which wallet design you're actually using and then there's like some form of signing whether that's local software or Hardware or even like remotely in a node but at the end of the day they all have this idea of an external account and we want to evolve this into a smart account world so we kind of have to like explore how we actually use wallets today and how we

can get to a much better experience the way we actually log in or connect our W today is that we actually establish a connection between the dab and the wallet as you guys saw in the diagram before but we then need to actually prove that you are who you are and in order to do that the standard signed withum was created to verify with a single message signature that you actually own the wallet that you're claiming to own and this actually looks like this which isn't like horrendous but it's still a Improvement to to what we had before because before some people were just like signing random hashes or arbitrary messages that every D did differently so with sign withum we created a standard to actually format

and have a more consistent experience that actually feels somewhat familiar to the existing Google login or Facebook login and you can see that essentially have a concept of some website or application wants to access your account and there's some terms of services associated with it and certain conditions around which chain which timestamp or when it expires and we even have this concept of resources which will eventually be useful for us to actually build a better connection experience which we'll then get into that at wall conect we decided that this idea of connecting and then signing a message with ethereum it kind of becomes a little bit of a nuisance and we

actually should reduce the steps at the end of the day less clicks is more so having two steps already just to get into an application feels like a big hurdle that we should solve so why don't we just like scrap the connection part and skip it to the session so with CIP 222 which is a chain agnostic standard so it would work for all the evm chains and outside of it we would have a single step where we can sign in right away without actual having a connection but you're still able to establish a session with the application but prove at the same time that you won't that wallet so that was already a big step but is that enough because realistically you also want to sign transactions that's why we

actually built this ecosystem around blockchains uh you want to actually create some assets and data and actually change how the blockchain works and signing transaction is the end goal so most people might think just close your eyes and approve like you know whatever like the pop-up shows up like I'm so tired I just wanted to get it done with and and that kind of like breaks the security and it's quite a challenge right to build a good wallet experience you always have to like balance convenience and security and in order to do that it's quite of an art uh because the user at the end of the day wants less clicks is more like this is why we're here right we want to have the best user experience the user just wants

to get it done with so we need to kind of understand why wallets work the way they work right we already have the concept of a wallet an application and the blockchain but why is the wallet so important in this component it's because P public key cryptography consists of two keys the private key which is the one that's secret to you as a user and then the public key which actually is available to everyone to verify that you own the private key so these two are connected to each other but only one of them is actually uh available to you and what happens is that you actually have some message and when I say message here it could be anything it could be a transaction or just a simple plain text message and once you actually pass this

message through like a cryptographic curve with your private key you actually output a signature and this signature is quite powerful because it validates not only that this message um has been validated by you but then they can actually compare it against the public key which is publicly available as it says in the name and then verify that you actually intended to do something but in blockchain like obviously it's not as simple as that simple diagram uh you actually have some formal transaction that passes the message through the private key outputs a signature and then you have a public key that actually matches an account because it's also important to note that your zerx address that you see on the blockchain is not the actual public key but it does match an account so actually

what we can do is break down this concept that the public key always matches to an account and build a much better experience and this is what smart accounts is all about or more technically known as externally owned on accounts EAS converting into a smart contract account or scas or let's just call it external accountant smart account like I I want to keep it simple so that we have this experience we want to move into smart accounts and we're going to understand how we're going to get there and a smart account is deployed by a smart contract so if you have a smart contract how can you actually sign because we just said that a wallet is essentially a private key if you have no key then you have no

signature so it's important that we actually create a standard for this and fortunately someone has already thought about that and signature validation for contracts already exists uh with 1271 which allows you to actually sign with a key that has ownership over a smart contract and essentially sign on that behalf and the contract will validate yes this key can sign on the behalf of this account so we essentially decoupled the signing uh into having multiple signers to then own a smart account and this comes with a very simple spec if you actually look at it it's just a single method that literally calls is valid signature that was simple enough to actually solve a lot of problems but

we also have to kind of go a little bit deeper into what an account means we broke down what a wallet is but what is an account and an account you can think of it as a signer a payer and some cryptography the signer that we just saw was solved with the 1271 because now you actually have multiple signers on owning the account which is validated through that method and what we don't have is the payer and this is what something that the smart accounts can actually introduce where the signer always pays for the transaction in an external account with that smart account we can break that relationship and have someone else pay for that and an advantage or almost as a sign effect for this is that because we decoupled the signer from the

payer we also can use different cryptographic curves so we're not like tied to the blockchain limitation of using this specific curve we can actually use something that's more widely available in your phones in your computers or tablets so now that we actually have this world where like we can have like multiple signers and wallets and applications uh we also have the opportunity to kind of simplify it and just have for all users or all profiles a single smart account everywhere and kind of make a better experience so what it actually means to be connected when you actually connect to exposing accounts you read some blockchain data because you're given an address and we can actually check the state we create a session for you which

we validate with sign of etherum and then we request user approval to submit transactions so if you now have these multiple signers and you have payers now we kind of need to standardize how these smart accounts work and this is where account abstraction kind of took off uh 437 was a pivotal moment for smart accounts because it standardizes this concept of multiple signers and pay layers and it almost can be described with a simple diagram which if you remember the triangle that we had before of app and wallet and blockchain now it's a little bit more complex but it actually can be simplified as a wallet requests a pay Master to actually pay for its gas and then the signer would

actually sign the operation and then the wallet submits all of that to a bundler and in 437 we introduced A New Concept of a user operation so remember how we actually signed with your private key a message before that message was a transaction now we shift it into a user operation so now the wallet is delegating the payment to the pay Master delegating the signer to a signer and then we actually send all of these user operations to a bundler and the reason it's called a bundler is because it takes a bunch of user operations and constructs a single transaction as a single bundle and submits the blockchain and now we have abstracted a lot of complexity but we also introduced fragmentation because every wallet and pay master and bundler will do something

a little different and we want to make sure that we still have the same inability that we had with external accounts so the first problem that we have is how do you discover if a wallet supports smart accounts fortunately we have 5792 wallet called API methods which introduce four new methods and in these four methods we have a much better experience to interface with wallets but most importantly I would like us to focus on get capabilities because this one is actually the one that gives a little bit B more visibility from adap to say this is a smart account and something that we can do is actually you know this is purely illustrative but you could say this supports session keys or pay Master service and essentially gives the scope of the dep what I can do with

this wallets it's much more than you could do with an external account but then even if you found that you still have to understand like does this wallet support pay Master which support which pay Master does it support and how can you interface with these pay masters so yet again we created a new standard for that a pay Master web service capability which actually describes let's not get into what it actually describes but the most important thing is that all pay masters will follow the same API and this again creates a more competitive and fair market for pay masters because you don't have vendor lock in around specific pay masters and instead you actually have all pay masters using the exact same API and even if you do have that remember how we actually introduced

the concept of user operations those are different from transactions and one of the difference is that the smart contract wallets will then actually do user operations very differently so actually for someone else to actually construct the user operation will be very hard so with 7679 we have this contable of a user operation Builder where we can delegate to the wallet and say I want to do this transaction but I don't know how to construct the US operation so you tell me how to format correctly and this a lot of code I know but like if you look at it it basically gives you like The Primitives to actually construct a user operation so now that we actually standardize how smart contracts can actually interface with user operation

and pay masters we have standardized a lot of things but still if you think about like smart contracts today they're more complex than just like paying and submitting transactions they also have concept of modules if you think about safe modules like they have their own ecosystem but then how can we standardize across the whole etherum ecosystem that's all modules work the same 7579 introduces a solution to that which essentially brings a even more generalized solution that everyone can comply and we can think of modules for many different use cases around Guardians and around key management but I like to think even something as simple as recovery can be designed as a more competitive market with this standard now you you kind of think that

we did a lot of work into breaking down the wallet in multiple component on we could almost embed the experience in a dab so why don't we just like take the pay masters and signers and we bring it all to the dab and we start signing oper user operations in the dab if we do this we would be introducing the concept of session keys and personally I think this might be the most pivotal moment for the experience of ethereum because if you do have session Keys you can almost think of the wallet as its own purpose is to approve an interaction with a dab and do a single uh click to sign with ethereum and yet again we completed our mission to do less clicks is more not only we

remove the connection part we go straight to sign with ethereum but we can now actually improve it by not even having to go to the wallet to submit transactions so to do this we're currently working on an ERC that is pending having its own number because we're still working on it but hopefully within the next days we will start seeing how we can actually find permissions for sessions and this will look very simply where you can actually request permissions from a wallet and the wallet will ask the user do you want to approve these permissions and then once approved it will allow the dab to actually have this permissions object and then it can use like um the permissions to send it directly to the bundler so now if the dab can actually

do everything by itself the only thing you actually need from the wallet is the permissions and if you remember when I showed that signning withum look very similar to Google login in Google login you also have a list of permissions that the DAP or the app asks from Google we can have the exact same experience for ethereum apps so if we're going to give keys to the dab um how can we secure these session Keys better because you know we did create a good process of standardizing everything but we didn't actually protect the key itself fortunately there's a standard today that's widely available in the internet which is called called pass keys and in order to do that we have to upgrade the pass Keys into using this new standard

that's called um 7212 and 7212 introduces a a new standard that if you look at Pas Keys you have this experience that is very widely known and even whether it's like on Android or iOS what it uses is that the key doesn't actually exist in the website instead it exists in the secure Enclave in your device and and if ethereum supports the 7212 this means that now we can actually verify the same curve that it's being used for Google pay or for Apple wallets and now the secure the session keys are as secure as your credit cards and this is currently being considered for inclusion in the next hard Fork so in

the next etherum upgrade we might have compatibility with pasis at the ethereum level which is really powerful so now you might think is this the end game for wallets I hope so because we went from this path where the authentication lived in the server and now if the app can act as a wallet following all of the standards around pay masters and user operations and session key permissions we can essentially put the wallet in the app in the user's device without having the constraint of having to go to the wallet to click and approve and constantly redirect themselves into the wallet I think that this kind of redefines what's actually being connected because in the past wallet connect acted as a protocol between daps

and wallets to interface with each other but now the definition of a Dap wallet connection is more complicated and essentially what you're actually connecting is a bunch of infrastructure that's enabling you to have a much better experience such that you can have less clicks and you have a more redefined wallet experience which I believe has always been the mission of wallet connect and hopefully we can they say less clicks is more and we have achieved the final end goal of wall conect any questions yep uh we still have some time for questions so if

anyone has any questions please raise your hands yes gentlemen over there hello um thanks for the presentation uh not exactly a question I'm just trying to see if I followed this correctly so with this session Keys thing it means that me as a user I'll go to the dab uh I'm sort of already connected and then from there I'll give permissions on and then it uses the session keys to do actions from that moment onwards until I um finish those session keys so I never

leave that up in the end is is that right that's correct so if you think about the current experience uh going from you go to an app you see that connect button you press on it you go to your wallet and it says this app wants to connect to you but then the app wants to actually verify that you own that account so they ask you to sign with ethereum you sign another message you go back to daab but then even after that once you go through those two steps you actually still have to go back to the wallet to approve a transaction and it might be multiple transactions so you have this constant like going back and forth between two applications to interface which you know doesn't feel great so in the beginning you saw that

we actually reduced already today with wconnect the connection and the signing with ethereum into a single step which was a great Improvement but that didn't stop the wallet from actually having to be redirected every time you need to approve a transaction so if we want to have a single click experience for ethereum then we need to sign in with ethereum and in that message we need to encode as many information as possible that will delegate responsibility to the dab to interface so in these permissions one of the things that we are working on is that you give a scope of how much the session key can do so you're not just signing with theum and verifying your ownership you also giving an

authorization to app to interface for example I want to interface with this smart contract and it's able to use this amount of assets and it can call these transactions and maybe do something else you know so this session key now not only has an expiry it could be an hour it could be a day depending on how the standards evolve as we build these applications but in this more mod modern experience for ethereum you basically won't see the approvals anymore because this key was already constrained to do only a very specific set of methods and it only has access to a certain assets and basically they will only use it for their specific application so now the

reason we always redirected users to wallets is because we wanted that consent but the consent was given up front as to how much scope are you giving this application cool cool thank you hopefully that is the end game indeed uh anyone have any other questions for Pedro yes you sir gentleman at the front oh back there okay um a bit of front running so um are you thinking of uh how to visualize the permission that the user is going to give to the uh to the wallet uh and uh is it part of this permission standard how to like explain to the user what the exact permissions

are and how to translate basically the yeah the sis key into human readable format no so in the permission standard the only thing that being defined is the actual conditions so this will be very machine readable very like computer focused but then what we actually need to create is some standardization around the most common permissions like similarly to how many transactions today like if you're going to approve it in a wallet some of them literally just say sign contract and that's all it says but some more common patterns like approving a token balance uh transferring a token like doing a swap these have become some common that created dedicated user

experiences where you actually have a little bit more context about what's happening so in the permissions we will eventually have a common like allow this many tokens to be spent uh allowed these many swaps to be done you know so you can have like very clear scopes around the most common patterns I guess the open question today is what about the least common patterns do we just like straight reject them and don't allow session keys to do this or do we allow the user to you know kind of explore applications with session keys and then do their own research you know at least I think that simple things like swapping and allowing token balances and maybe like some Dow voting could already be

like scoped because these have been like very common patterns that we can stand standardized UI for but it's a it's an open work I think we can squeeze one more yes so uh great talk and it's very consistent with the one at safe con no I didn't have time to ask at there and U I want to ask just to clarify a bit so uh the session key you mentioning is mostly for simplifying the usage on DS but it won't eliminate the walls self right cuz people still need a place to store their digital assets instead of putting them all on each daab so it's mostly for tabs the big difference you might see is that

at the end of the day you have I guess you could call it the signer keys and the session keys but they're all signers right but I guess you could say it like there's a primary signer and a app signer and the difference between the session key is that has a very narrow scope there's still a lot of things that you have to do and you have to consider like the security implications of having a key that can do everything and this key that can do everything could be adding new signers approving new apps uh changing recovery options uh allowing you to top up the balance you know you can't just give all the power to these session Keys you still have to have a primary key that has more power over managing your wallet and another thing

that it could also do is potentially even revoke like uh capability is from an existing if for example a session key were to be malicious you can actually have the primary key go revoke that capability and now all the system will now see wait a second you do have this permissions object but I can see that the primary key has revoked it so now you can stop that session key from going malicious so the wallet will still manage your accounts uh as your primary key and the session key is just abstracting a set of methods that you can do within this appli specifically okay awesome thanks everyone thank you so much pjo everyone give a big round of applause to pjo

again