Tony D’Addeo
@deodad
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
Mikko
@moo
Most Ethereum signing, outside very basic transactions, is basically blind because Ethereum does not have human-readable transactions. It's not just 7702 or something it could fix. Or anyone could fix.
1 reply
0 recast
4 reactions
Tony D’Addeo
@deodad
good point but it’s even slightly worse here in that you don’t even know you’re doing a crypto tx
3 replies
0 recast
3 reactions
jxom
@jxom
Secp256k1 is even worse, there's no "prompt" at all. ;) We have normalized the pattern of Wallets interfacing over Secp256k1 signing (ie. browser extensions, WalletConnect, etc), so same goes for Passkey signing.
3 replies
0 recast
3 reactions
Tony D’Addeo
@deodad
i’ve found it hard to reason about client security presumably wallets securing larges amounts of money are being very cautious what precautions should apps that have passkeys signers be taking?
1 reply
0 recast
0 reaction
jxom
@jxom
Usually the app would be communicating via JSON-RPC to a secure wallet environment that holds the passkey (e.g. x-origin sandbox iframe, external popup, browser extension).
1 reply
0 recast
1 reaction
Tony D’Addeo
@deodad
makes sense thinking about it for a warpcast embedded sandboxes iframe seems like the best option do you know of any reference implementations
1 reply
0 recast
0 reaction
jxom
@jxom
we are making one now :D
1 reply
0 recast
1 reaction
