1/ 🚀 By popular demand, here's the getting started guide on passkeys! Learn what they are, their benefits, and usage—including their relation to web3 and embedded wallets. 🧵👇

2/ 🤔 "Passwords are terrible. They might just be the worst invention since unsliced bread." - ancient greek proverb

Enter passkeys: long, invisible, site-specific super-passwords.

When you login to a website, instead of creating a password, you generate a private/public key pair using your device biometrics.

Building dynamic.xyz | @dynamic | Craft magical onchain sign up experiences  - embedded wallets, login, user mgnt, authz and more | Demo: demo.dynamic.xyz

3/ 🛡️ Passkeys take out the weakest link of security - YOU (yes you heard me, don’t @ me).

They are essentially invisible, hence, there is nothing for you to easily send to someone else (you can’t be phished).

Because they are unique to a site, if site A gets hacked, it’s no longer a problem for site B.

4/ Backup and recovery
📱🖥️ To use a passkey on your iPhone, Apple will force you to set up iCloud and 2fa.

This is the magical part - the average user is forced to use a password manager. So when they inevitably switch phones, they still have access to everything (in an end to end encrypted fashion).

5/ 🚧 There are some challenges with passkeys:
1. They are not yet fully supported on Firefox
2. They are bound to a domain; exampleA.com and exampleB.com will need 2 different passkeys (subdomains work)
3. Desktop to mobile needs more love. It uses QR codes. Seems like Chrome is improving this interface weekly btw.

6/ Why am I talking about this, you ask? Glad you did! 

If a hacker takes your password and breaks into a site, they usually steal your data (bad). If they break into your wallet, they steal your money (really really bad). In other words, you kinda want killer security for your wallet, even from yourself.

7/ Passkeys in web3 (1/2):
1. Use it as an API key to access your private key in a Trusted Execution Environment such as AWS Nitro Enclave (this is how @dynamic uses it).
2. Store a seed phrase for backup in a passkey largeBlob (this is what Warpcast does)

8/ Passkeys in web3 (2/2):
3. Use it for local share/shard backup when leveraging Threshold Signature Schemes (TSS-MPC) or Shamir Secret Shares (SSS-MPC).
4. Do clever things with EIP-7212 (beyond the scope of this post)

9/ 🎉 That wraps up our journey for now.

This is the biggest auth revolution in many years (and is years in the making), and has profound implications for web3 security. Think about this as everyone in the world being forced to use 1password/dashlane.

10/ Notes and random thoughts: 
- unlike a password which has a 1:1 relationship to a user, in the world of passkeys, think about them as authenticators. Meaning a user might have several passkeys.
- My observation is that we’ll all default to passkeys in 12-18 months

with our sdk at Lighthouse, users can store encrypted data on IPFS, Filecoin with Passkey support. Read more her

Working on @lighthouse-web3

Telegram - t.me/nanditmehra

with our sdk at Lighthouse, users can store encrypted data on IPFS, Filecoin with Passkey support. Read more her

https://docs.lighthouse.storage/lighthouse-1/how-to/upload-encrypted-data/kavach-encryption-authentication/method-3-passkey

Unlock Protocol founder.
Previously founder at Superfeedr (RSS push API) acquired by Medium!

https://ouvre-boite.com

Yes. Essentially any password manager - 1Password, dashlane etc works across the ecosystems.

So you can do this without iCloud or Google password manager

Thank you for this really good thread!
Do they tie users to the apple or Google ecosystem? Is there a way to backup outside of these 2?

founder @explorelabs

don't take my casts seriously please (most of them at least)

building far.quest & @wieldlabs.eth. cofounder at miy.com ventures. FID #274. Previously Square/Cash App. https://hiimnico.xyz/

True, but I would argue that is true for pretty much any embedded wallet approach. That is, in a 2:2 MPC approach (Fireblocks, Coinbase WaaS etc) a share is held on a server, and technically the server can "deny" access to the share, and hence signing.

Good stuff! One part that’s worth mentioning is that wallets that rely in the API/Server model to authenticate wallets via Passkeys might be at risk of being “denied” access, even if only them can access the wallet.

EIP-7212 is promising but there are already implementations that could use it, just not with AA

This might also be helpful for same topic (this is from my previous talk I gave 2 days ago)

This might also be helpful for same topic (this is from my previous talk I gave 2 days ago)
https://docs.google.com/presentation/d/1bknsMvM0YP0grDVVitKZmi6KjApXvdnrg5Qrj3kyGKQ/edit