Content
@
0 reply
0 recast
2 reactions
Varun Srinivasan
@v
EIP to validate passkeys on-chain with a precompile: https://eips.ethereum.org/EIPS/eip-7212#motivation This would be huge for AA wallets. I'm curious if anyone has a pulse on how likely this is to pass, seems like there's usually a lot of contention around adding precompiles.
10 replies
8 recasts
50 reactions
EulerLagrange.eth
@eulerlagrange.eth
With largeBlob storage it’ll be possible to store any key type along with a passkey, but it can be read by the app loading it. Not as secure as the enclave, but you don’t have to precompile the P256 curve. You can use secpk1 (as some demo wallets have done)
1 reply
0 recast
0 reaction
Peter Ferguson
@peterferguson.eth
The webauthn spec doesn't specify a curve ... so if providers like browsers, apple and google build other curves into their passkey spec you don't need the large blob https://www.w3.org/TR/webauthn-2/#sctn-alg-identifier
1 reply
0 recast
0 reaction
EulerLagrange.eth
@eulerlagrange.eth
Using the passkey in the enclave requires a faceId for every interaction. If you’re sending a tx then it’s fine. For farcaster, if you use the delegated signer in this way you’d have to do a face id check for each like, recast etc.
1 reply
0 recast
1 reaction
Peter Ferguson
@peterferguson.eth
Seems like a draw back of the delegated signer rather than the passkey With the current crdt model that is not the case but I haven’t looked into the delegated signers spec Maybe something to think about more abstracted accounts come onchain Maybe @v can shed some light?
2 replies
0 recast
0 reaction