gakonst on Warpcast

Tony D’Addeo pfp

7702 - EOA key still needs to be stored - passkey signing is blind and confusing since the system UIs can’t be changed and refer to signing in - passkey sync has holes (x platform) - session keys UX unclear: how are keys requested? what’s the trade off between exposing complexity to users around restrictions vs making it magic but users don’t know what they’re approving?

7 replies

5 recasts

50 reactions

Tony D’Addeo pfp

recovery - is zk email production ready? - WaaS provided solutions (oauth, email, hosted social) will be great UX but require more trust - onchain social is exciting but setting up and managing keys seems is a challenge what’s going to be best patterns for recovery? something with a time lock? if so will require good service provider to help you monitor

1 reply

0 recast

10 reactions

gakonst pfp

- not necessarily, you can forget the key and just replay the auth sig across chains, delegate to proxy and use the contract to handle upgrades. alternatively can store the privkey in cloud etc encrypted w enclave, nbd imho. - unclear it matters, the ui will give you a preview over x-origin iframe, and your contract will have enough safety checks to ensure you don't get rugged. check secure payment confirmation web api if you really care about doing it non blind. - granted but not deal breaker, your contract can have multiple signers, need to be thoughtful about it but navigable, plus passkeys being pushed top down. - session keys app/account interface is important to get right, see our work in porto for more: https://www.ithaca.xyz/updates/porto, and our WIP session key api which is still evolving: https://github.com/ithacaxyz/porto/tree/next?tab=readme-ov-file#keys

3 replies

1 recast

9 reactions

gakonst pfp

- zkemail is fantastic imo and totally underutilized. next up figuring out how to get google's certs reliably on chain as a public good, so we can do jwt verification for oauth. - timelock or otherwise optional. can easily make your account say "if an operation tries to transfer more than X value of such asset, request more auth keys (mfa) and also queue it up for 1mo in the future to ensure user can abort op if hacked from master key" we have put multiple examples on how to use 7702 and have deployed it on Odyssey, our devnet with Pectra + EOF, see below: https://github.com/ithacaxyz/odyssey-examples There's also many examples / demos across Twitter if you search "7702", see eg this one using "anvil --odyssey" which enables the same features Odyssey has but on Anvil (soon Anvil will be running same code as Reth via Reth SDK!) https://x.com/thegaram33/status/1877410275814445170

1 reply

1 recast

5 reactions

jxom pfp

Elaborating on point 3: you can also configure the root admin signer to be of something different to a passkey.

1 reply

1 recast

3 reactions

Tony D’Addeo pfp

for throwing away the EOA, the wallet needs to be deployed w sufficient recovery mechanisms or when adding/updating recovery mechanisms are you generating a new auth sig that can be replayed?

0 reply

0 recast

0 reaction