Authentication Methods with Lit Protocol

All right, we're live. GM, GA, GE everybody. Welcome to what's going to be another great DevNTell. So if you didn't know, DevNTell is a 30-minute window for builders to showcase something they are passionate about or have been working on in Web3. This could be an awesome project you've been working on, demonstrating unit testing best practices, automation goodies, smart contracts, how to structure a project, etc.

Basically, if you've got a passion for something, this is your opportunity to share with the community. And today I'm ecstatic to have Josh from Lit Protocol on to give us an overview of authentication with Lit Protocol. Welcome, Josh.

Hey, happy to be here.

Yeah, so maybe you can start with a brief introduction about yourself, what you do at Lit, how you got into Web3, and maybe even how you got into Developer DAO.

Sure. So, been like a software developer for about five years now. Went to college for it, was pretty passionate about different open-source technology as well as when I was in college. So, right out of college, I went to work for a larger like enterprise IoT company, spent about three years there, and then started kind of hearing more about different kinds of cool technology in the Web3 space and had an opportunity to kind of transition over. So I was working for a couple startups in the space, having just a fun time kind of playing around with different like on-chain and off-chain storage mechanisms.

And then had a wonderful opportunity to join Lit Protocol, where I've been working primarily on different authentication methods. And that's actually what our talk is going to be on today, is how you are able to authenticate and use resources on Lit Protocol. So yeah, really happy to be here. And actually I joined Developer DAO when I joined my first like Web3 startup, heard about you guys and got my Developer DAO NFT. So really happy to be here and to kind of share what myself and the rest of the team has been working on.

Excellent. Love it, man. And yeah, thank you so much for coming on to share with us. So yeah, if you want, you can start your screen share and we can get on going.

Fantastic. All right, let's kick it off. Get these slides open. All right, so as I said, my name is Josh and this talk will kind of be starting with a high-level overview of what Lit Protocol is. And then we're going to go through some different feature sets of the network and then we're going to kind of jump into different authentications. So for those of you who are not familiar, Lit Protocol primarily deals with protecting encryption resources via threshold cryptography.

So what that basically means is that on our network, keys are not kept in like a static database or a central like one central point that can be breached where all your keys are kind of exposed during some sort of singular resource breach. Our keys are actually kept on a series of nodes that comprise our network, where when a resource is requested in order to perform a decryption or a signing operation with one of the keys that are preserved for you as a user, they have to go through a round of MPC, which is multi-party computation, and a network threshold must be reached in order to perform the operation. So a certain number of nodes must reach consensus in order to actually perform the operation you're requesting with a key. And then once consensus, once threshold is reached, each individual node will either perform an act of encryption or an act of signing, at which point signatures or encryption shares will be recombined on the client and your particular request will be fulfilled.

So there are two relatively interesting things about this. One being the network threshold and two being that all operations are recombined on the client. So when you make a request to the network, it's only recombined on the user's machine. So the client is kind of used as the one trusted actor, and the nodes are merely are not fully trusted by the network. So all signatures must be recombined client-side such that we're confident that nothing sort of collusion or any sort of malpractice was happening network-side. So on that topic, there are two main types of feature sets of the Lit network, which will be encryption and signing. So you are able to encrypt specific resources, store those encryption shares on the network, and then request those encryption shares via a multitude of different kind of conditions, which we'll talk about.

And you're also able to perform signing operations with keys such that you're able to facilitate different kinds of like on-chain credential conditions. So you can do things like request that something can be decrypted when someone holds like a particular NFT inside of a given wallet, holds a specific balance of a specified token, and other type of like on-chain conditions that you can insert on via like smart contracts. So this is supported for EVM chains. So we support most kind of style EVM chains, which you can check up on our docs. And we also support Cosmos chains and Solana with these kind of like different conditions. So yeah. And then a big other part of this is kind of programmatic signing. So just like we have like control conditions for encryption resources, you can also set up different conditions for signing.

So programmatic signing really unlocks a lot of different opportunities network-side. So not only can you do things in like the DeFi space where conditional transactions, things like reoccurring payments with a specific entity, you can also do like kind of different chain storage with these kind of mechanisms. You can do like kind of abstracted wallets with these mechanisms. And this is all through what we call Lit Actions. So not only does our network allow you to persist keys and persist like encryption keys and signing keys for later uses, but you're also able to execute code network-side, kind of similar to like serverless functions. So this is kind of like another form of serverless function, but there's like one kind of key difference to this, which is that on Lit network you're able to associate what is what we're calling a Programmable Key Pair with a specific condition. So you can have code that essentially will say, check these series of conditions and then if these are true, sign with this particular resource and that resource is the Programmable Key Pair or PKP.

So this sets up a really kind of interesting dichotomy where you're able to have this execution context on our network where you're not having to manage like resources for this, but you're also able to associate a public-private key pair with that particular execution and perform different kinds of conditional signing. So this is a pretty powerful new concept of the network and it makes it a pretty interesting way of facilitating different kinds of signature conditions where you might in the previous systems you would have to like connect a wallet and have a user go and accept a transaction and have to tie that all in. But in this particular environment you're now able to do this all network-side. So you can simply send a request to Lit network saying that you want to execute this particular piece of code and you want to do it with these series of parameters and then if conditions that you implement inside the action are true, it will then produce that signature which, as like said before, it will then recombine client-side and give you this fully constructed signature that you're able to then use.

So which really... Oh and one other thing that's kind of interesting about this is because all these keys are kept network-side, you're not able to kind of just access this private key of the PKP but by using Lit Actions to sign you are able to reconstruct signatures that are produced from the private key pair. So the network when like when you are requesting to do a signature, when you're requesting to create a signature, the network will reach that beforementioned consensus threshold, produce each one will create an individual signature share that will recombine client-side and then you're able to use that in whatever kind of operation you wish to use. So whether you're signing a transaction, you can then send that transaction with the signature produced from the PKP, but you can sign other types of resources as well, transactions just being kind of one example for that.

Actions also work pretty well in type of in kind of an Oracle model where you can we support the fetch API inside of Actions. So you're able to fetch like arbitrary data over HTTP. You can then assert on that payload that you retrieve and then sign based off of some sort of state that you're able to discern on. So you can kind of reimplement a lot of different pieces of things that would be more traditionally implemented in smart contracts, but you can actually reimplement those things using Lit Actions and PKPs. And I guess like one other thing about Actions is that you don't technically need to bring a PKP with you to execute. So if you don't want to create PKPs, you can still execute code on the Lit network.

But there's so much kind of added to the functionality of Lit Actions with PKPs that really like kind of power that particular part of the network, but you're perfectly able to execute just execute code that doesn't utilize that functionality. But that is kind of the big piece of Lit Actions is the access to PKPs inside of that execution context. So whether you're kind of encrypting like wanting to encrypt data and store that store that encryption keys with Lit or you want to or you want to execute use PKPs and execute Actions, this like to do any of these operations on the network is going to require a either authentication signature or an auth signature. So the first one we'll kind of talk about is an auth signature. So auth signatures are more or less just the sign-in with Ethereum model. So kind of just take a look at an example of this is that you have like a signature derived via a signed piece of signed message and then the public address of that.

So with like sign-in with Ethereum you are able to specify specific resources within the message body that then you can assert on when you're validating the signature. But it's relatively limited in what you can actually do with it because it always has to be signed with a with like standard Ethereum wallet. So what we've also added to the network is the we've added this concept that we call session signatures. So session signatures are interesting because they allow for a variety of different authentication methods with them and they also allow for explicit capability delegation. So you can say with a session signature that you only want to permit access to explicit resources such that if something else is being requested to execute or to use a resource that wasn't explicitly expressed in the capabilities of the session signature, you then will not be able that operation won't be able to be completed.

So these capability delegations allow for very explicit access rights and that's really interesting when you think about like all the different capabilities that might be like tied to a specific resource, but you only want to permit like a very specific range of them. This is really helpful for that kind of thing. So it's kind of like the having the lowest level of permissions possible for a specific request. And what's very powerful about session signatures is that it doesn't necessarily need to be signed by a wallet. You can use various different forms of authentication with this.

So here we have a example of a session signature. So as you can see that the signed message is much larger here. And what we have inside of this what we have inside of this is it will look very similar to a authentication signature because this is still kind of built on top of sign-in with Ethereum. So we have our resource you'll see that we have our resourceability request where we specify the specific resource that an action that we want to do. So in this case we're specifying that we want to sign with a PKP. And then here we have the specific capabilities that we're providing. This is the origin that it is coming from. And then here we still have an Ethereum account where this key is actually this key here is this address is derived from this public address down here.

And here we'll see that we have a specific session ID that's generated client-side. And we also have here in the recap a CID from IPFS that is specific to the like the Lit Action that was going to be executed with this particular session sig, and then the same address again. And then we have some issued-at expiration times. So oh and another really cool thing here is that the derived-via here is not like a personal like personal signage. This is a signing key that is kept locally in a like in the browser. And when it's time to sign a session signature that key is requested and then the private portion signs the key, and the public portion is put inside the session signature for validation. And this can be either a this can be one of the like NACL key, it can be a wallet.

So you can either bring a wallet or if you don't want to use a wallet, it will sign with this locally stored key. So this means that you don't necessarily like an end user doesn't necessarily need a wallet. We can generate a key in the browser and use that to sign along with a authentication method and then if that authentication method is deemed valid then it will sign the session signature. So the flow kind of like the flow essentially if we go back up a slide is you generate this session signature to be signed locally, it contains an authentication method which will either be like right now we're supporting Google OAuth, Discord OAuth, email, SMS, and you can also sign with sign-in with Ethereum so you can sign with a wallet.

So any of those can be an authentication method. So you provide that in your request to sign a session signature to the network. The network will validate that authentication method. If it's valid, the session signature gets signed. So then the signed session signature is what's returned and that's what this is representing. So this is like a signed session signature. So then once you have a signed session signature as long as it's not expired you can keep using it. So the flow kind of be for like if implementing with session signatures, the only time you have to regenerate is if it expires. So then it would be time to like remove it from storage cache and have the user reauthenticate and then it will be valid for as long as the expiration. And that expiration is configurable.

So as kind of said before, this the session signature model was built on top of sign-in with Ethereum Recap, which is EIP-5573. So if interested, can drop a link in the chat to that specific specification. But basically what it adds on top of sign-in with Ethereum is like a capability delegation model. So that's what we're using with our session sigs. And then the actual part of like authentication is done by our nodes. So whatever authentication method you put inside of the session signature when requesting a signature will be validated by the nodes. So if it's an invalid if it's deemed to be like an invalid token or it's something kind of goes wrong with the authentication, we won't sign the session signatures.

So that's kind of the part that's like kind of obscure in this EIP and because it's like it's not part of the actual specification. So that's how we're doing the authentication part is our nodes will authorize based on the authentication methods and then produce a signed session signature with those explicit capability delegations. So that's about all the slides I have. So now I think we can kind of hop into a demo. So pull up one of our authentication method demos. So this is our email/SMS auth method. So... Oh it's still sorry Josh it's still showing your PowerPoint slides. Ah that's yes, sorry about that. Let me switch.

All righty, I think it's sharing. Perfect. All right, so what I'm going to do is I'm going to register myself with a I'm going to register my auth method. So what this is going to do for me is it's going I'm going to type in my email address, and then once I do it's going to send me a code to my email and then from that code I'm going to be able to authorize myself to generate an auth method, which will be a like what that particular auth method is is a JSON Web Token that will be produced and then I can present that to the nodes in order to get my session signature signed. But first we're going to register which will put which will put my email address as essentially like a user ID for this PKP resource that we're going to be creating.

And then that will set it up so that when I go to log in, it can query that and then assert on the authorization method that is presented. So let's first go and register. Grabbing that code. All right, code was presented to my email. That's my one-time password. So what it's doing now is setting up my PKP resource. So I already had a PKP resource associated with this user ID, my email, so now I have two. So I'm going to select the top one and we're going to log in.

So now that it was able to take that authentication method that was generated when I entered the one-time code, it was took that token, it validated that token network-side, and what we have here is a created session signature. So very similar to what was in the slides and we can see down here that this is the requested resource. So what this is specifically is a hashed version of a very basic signature generation action. And that's this is the CID representation of that. And then up here we have that we are requesting it for PKP signing. So if we type in a message to sign, we'll sign Hello Developer DAO.

And in a second, yep here we go we have our signature. And one thing that's interesting about our signatures network-side is that they're non-deterministic. So meaning that if you enter the same like if you enter the same body of content to sign, you will get different signatures at this time. So they are not deterministic signatures just kind of good thing to note. But yeah, so that's that's kind of the flow for authorizing with session signatures. So now you don't really need to bring a wallet or have a you don't really need to bring with you a particular wallet where in other kind of system flows like this you would need to have a browser extension, communicate with a browser extension, and explicitly grant grant permission to sign.

Now this is all done on the Lit network and if I wanted to take this and put it into like put it into Safari or like a mobile site or use it on mobile, it's much easier because you don't have to go back and forth and do a bunch of communication to a bunch of different applications. And because you're able to now sign up with like Google OAuth or email/SMS, it's much more typical kind of like user registration or user sign-up flow that people are used to. So yeah, that kind of brings us to the end of the presentation but if anyone has any questions or anything...

Yeah, K has a question. So is the email/phone auth handled by Lit-owned servers or who is responsible for that?

Right, yeah. So we have what we're calling a verification API or Auth API, and that's what's handling like handling sending and confirming these one-time password codes. And that's actually what's generating the token. So like when it's authorizing when it's authorizing on the nodes, it's checking to see it's not only checking to see if the signature is valid but it's checking to make sure that the public key that's that's retrieved from it is actually from that server as well.

Awesome. Great question, K. And when you first in your demo when you first entered your email, it showed that you had it looked like two accounts. So I guess what happens when you enter your email for the first time? Is a brand new account created for you on the Lit Protocol side?

Yes, so the only reason there was two was because I've already done it with that particular email, so the first time you register you will just have one. But you can register what's what's cool is that you actually can register the same user ID to multiple so you can have many PKPs to one like email or phone number.

I see. And then how do you so say for example I just want to have the one associated with my email. Is there a way to not generate a PKP every time you do the authentication or...?

Oh yeah, absolutely. So when you log in, you're not going to be generating it. You'll just be able to pick one. But since I registered, it generated a new one and then I logged in with it.

Got it. Gotcha, gotcha. And regarding the threshold on the network side of things, what is said threshold that the nodes have to come to consensus to be able to complete a request?

Two-thirds consensus. So as long as two-thirds of the network come to agreement, it will you will be able to complete your request.

Gotcha, gotcha. And one off like one also interesting sorry but interesting thing about the network as well is that these are all named actors on our network. So when you sign up to like if you sign up to be a node operator, your name and very like it's publicly known that you're operating this node. So this is not something that like anyone can come and just start operating as like an unnamed actor. You are like a known network participant.

Cool. Any like reasoning behind that? Like why you guys chose to do super transparent on that?

Just so that everyone who's involved in the key sharing and holding like key shards is named and available so that no one's just kind of operating where they don't have to discern information about themselves since they are holding pieces of private keys. So we feel it's better that everyone's kind of like a named actor in this part of in the network.

Cool. Makes sense. Gilad has a question here. What are the use cases you're most excited about for the PKPs and auth?

Right. I really like account abstraction personally. I think it really unlocks a lot of it really kind of lowers the bar to Web3 sign-up in ways that I think are much more accessible to wider audiences. And like other there's a lot of different specifications around like and ideas around account abstraction that are really awesome. But I think PKPs kind of solve it in a way that's relatively elegant since that no key shares have to be kept on like users' devices, they don't have to like remember some seed phrase and then connect their wallet through either like a QR code or browser extension. This is all built into the actual client side of the application or communication with its built into client side of the application and you don't have you can bring it to a much wider array of browsers. So it works particularly well on mobile and you can have more traditional sign-up flows that don't require you to kind of bounce between a bunch of different applications. It's just stay in your app, register, and get the benefits of being able to sign and request resource and hold tokens. So it's pretty awesome.

Great answer and great question. Thanks Gilad. And I guess since we're coming up on time here, what's the best way for folks to keep up with all things Lit Protocol, yourself, and how can people get started?

Yeah, that's a great question. So in terms of keeping up with us, we're relatively active on Twitter. So you'll that's definitely a good place to kind of check up on our announcements and stuff. We have a great Spark page as well where we've been posting a lot of articles which I'll definitely grab a link for. You can always join our Discord as well if you're interested in developing with Lit. Definitely join our Discord. We have a lot of discussion threads there and a lot of good resources for devs. Yeah, I think that's I think that's kind of yeah definitely Discord, Twitter, and Spark are great places to to kind of see what we're up to and I'll grab some links to those.

For sure. And in terms of getting started, people can just read up on the documentation of Lit Protocol and be up on their way?

Yeah, join our so if you're interested, join our Discord and start reading our documentation and we have a nice developer SDK. It's written it's all in TypeScript. So like we have one officially supported SDK that's in TypeScript. So yeah start playing with the SDK, look at our examples on our docs, and join the Discord.

Excellent. You hear it here gang. Get on that Discord, get lit with Lit Protocol. Yes indeed. Yes indeed. All right, unfortunately that brings us to time. Thank you so much Josh for coming on and giving us that great overview. Certainly piqued my interest and we'll be looking to dabble with Lit Protocol sometime soon. And just wanted to wish everybody a very happy weekend, happy Friday, and that we'll see you all here back next week.

And before we all leave, I want to share with everybody this QR code that you can scan with your regular QR code scanner to mint your mint Kudos for being an attendee here today. So again, what you'll want to do is pull up your regular QR code scanner, scan this code, and you'll have one hour from now to claim your mint Kudos. So go for it. And yeah, like I said, happy Friday, happy weekend, and thank you again Josh for coming on and we will see you all here next week again. All right, thanks for having me. Happy hacking everybody. Happy hacking. All right, cheers gang. Bye everybody.