Thanks for flagging this!
First things first. FedCM looks reaaaally good, and should be discussed in a wider context! Happy to facilitate!
I want to make sure we’re using the same definitions, so let me articulate how I’ve described things, hopefully I haven’t missed something
Webauthn (you call it passkey)
Webauthn is specification for a browser based API for public key crpyto. You can almost related it to EIP-1193, in the same sense how does a browser communicate with a wallet. To be even more concrete, an iOS app deployed through the native app store does not use webauthn when using passkeys, it will instead use the native
ASAuthorization APIs. When I say passkey, I’m referring to the curve p256.
The main reason I’m explicit about that differentiation is because this EIP in my opinion shouldn’t care how a key is generated, nor what type it is (theoretically you could be generating BLS keys for a user).
convince us to let centralized providers like walletconnect bring SSO
So I actually would prefer people not use them! Let me articulate how. The provider side logic needed to discover and respond back to an application should be stateless. Meaning you shouldn’t need an centralized server what so ever to do anything for you, a website with an IPFS hash is sufficient.
(fwii @ ChainSafe we’re working on this demo should have it at somepoint early next week)
Let’s imagine web3modal, it now hows a text box that says “enter url”, that url can be anything, native ios/android app deep linking, a website, localhost, it doesn’t matter. In this case, I will say its sso.gregthegreek.com (doesn’t exist), my personal website. On this website, I have implemented:
- Passkey (via Webauthn)
- Web3modal (for injected browser wallets, like metamask)
- Native Ledger support
On this website, I can select any of the above options to determine a public address that I want to use for the app I was previously on. Once I’ve selected a “login” option, the website automatically knows how to “discover” if that public key has an associated smart contract wallet, perhaps via
create2. Per ERC-7555 I would respond with all that information.
As you can see, this ERC allows support of any signing algo. It also isn’t opinionated on what tech to use. The redirect in my example above using web3modal (walletconnect) you can completely skip that! You can just have a list of url’s and call
window.location.redirect(url) and never even show any third parties!
This ERC extends the possibility of decentralizing 4337 wallet creation, and utilization which is currently heavily gated by APIs. The same way running a dappnode at home, and setting that as a custom RPC decentralizes you away from centralized RPC providers.
I hope that helps explain things a bit better, I love criticism, so lets keep finding holes.
I think using FedCM would probably need to be an effort discussed within the 4337 community more widely.