A place for talking about the Ethereum Virtual Machine on Farcaster.

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.

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

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)

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

Working on building zkTLS infra/products. A ruthless empiricist and meme connoisseur.

http://opacity.network

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

Making investing together better https://onit.chat | Variant Founder Fellow | Cambridge Alum | Formerly Ireland's #3 powerlifter (74kg)

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?

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.