Greg pfp
Greg
@greg
Passkey-based wallets are cool but I feel like people are skipping over the part where passkeys are scoped to domains, which means the provider could effectively brick your wallet at any time (I think, please tell me if I'm wrong) Sounds like backup signers are in the roadmap but feels like an important caveat
20 replies
24 recasts
178 reactions

Adam Hodges 🔵-' pfp
Adam Hodges 🔵-'
@hodges.eth
Correct! Adding a non-passkey recovery key is our top priority at the moment.
1 reply
0 recast
12 reactions

greg pfp
greg
@gregfromstl
I’m not sure if Coinbase Smart Wallet allows this but in theory you could just add another signer to the smart wallet, right?
1 reply
0 recast
0 reaction

cryptocellaris.eth  🎩 pfp
cryptocellaris.eth 🎩
@cryptocellaris
savye problem with visa or your bank account the masses don't care as long as it works most of the time and is easy
1 reply
0 recast
1 reaction

df pfp
df
@df
are all passkeys like this?
1 reply
0 recast
0 reaction

itai (building dynamic.xyz) pfp
itai (building dynamic.xyz)
@itai
You're right - passkeys are domain bound and so technically if you can't access that domain you'll have an issue. A solution around this is adding more signer options etc that let you access the smart contract account in other ways.
1 reply
1 recast
13 reactions

zack pfp
zack
@labadie.eth
Completely agree. Passkeys need to be more easily exportable + easily duplicated across different devices and ecosystems. Until then: https://warpcast.com/labadie.eth/0x452c0eac
0 reply
1 recast
1 reaction

Harpalsinh Jadeja pfp
Harpalsinh Jadeja
@harpaljadeja
this?
0 reply
1 recast
1 reaction

vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
I don't trust passkeys because I don't know how they work. Probably my fault. But I get the feeling that under the magical-one-touch-login there's a compromise and they've tried so much to make it "user friendly" I can't tell what it is.
0 reply
0 recast
1 reaction

Tim Mustafin pfp
Tim Mustafin
@mustafin.eth
I never looked into specs of passkeys, thanks for the highlight! I genuinely thought it's just a keypair like any other public key cryptography. Since self-hosted bitwarden can be used as passkey storage, the problem of untrusted provider can be avoided, right? (for geeks who self-host)
0 reply
1 recast
1 reaction

Nitya pfp
Nitya
@nitya
Great post! I agree this isn't talked about as much- the ease of any 1-factor setup path (whether its passkeys-only or social-only) will be inherently brittle
0 reply
1 recast
1 reaction

matt  ↑ ᖽ pfp
matt ↑ ᖽ
@blueish
🧡 CB wallet and the new Smart Wallet but feel social recovery / forgot password would’ve been killer feature for onboarding. Marginally easier to custody a passkey then seed phrase but fact remains there’s a single point of failure and you’re rekt. any plans for soc recovery @wilsoncusack ?
1 reply
1 recast
1 reaction

↑langchain 🎩  pfp
↑langchain 🎩
@langchain
Ah I hadn’t thought about this deeply when I was creating it. This makes sense. Why not host these things on IPFS/Arweave? Is it not that simple?
1 reply
1 recast
1 reaction

Myk.eth pfp
Myk.eth
@myk
TIL you can have multiple passkeys control the same wallet. Could be a useful mitigation to this.
0 reply
0 recast
2 reactions

Nick pfp
Nick
@nickdodson
They should only be considered a signing factor not your only signing factor for exactly this reason.
0 reply
0 recast
0 reaction

Luke Puplett pfp
Luke Puplett
@lukep
Implementers and builders should also consider ways for things in wallets to be cancelled and reissued, or even continual renewals, where that makes sense. Thinking more of attestations and the like.
0 reply
0 recast
0 reaction

timdaub pfp
timdaub
@timdaub.eth
Is this even true if e.g. set my host file to 127.0.0.1 wallet dot coinbase dot com? Like are the passkeys 100% inaccessible?
0 reply
0 recast
0 reaction

TomCruice007 pfp
TomCruice007
@tomcruise007
yes backup signers are the road map
0 reply
0 recast
0 reaction

Manarkamel pfp
Manarkamel
@azlan07
Just learned about
0 reply
0 recast
0 reaction

Manarkamel pfp
Manarkamel
@azlan07
Wow wonderful
0 reply
0 recast
0 reaction