ERC-7555: Single Sign-on for Account Discovery

This proposal establishes a standardized interface and functionality for applications to discover user addresses that may not be readily available from an EOA. Specifically discovering addresses and smart accounts that may have been deployed or configured using a signing key that is not the standard Ethereum secp256k1 curve. The objective is to ensure uniformity of address retrieval across applications, and domains.

Note: This EIP has an accompanying EIP Embedded Accounts as Smart Modules, that extends the functionality of this one.


Webauthn (you call it passkey) does not force you to create anything – creating a public keypair (per origin) is just the tip of the iceberg, it can do so much more (prf, largeBlob, payment).

If you’re going to try to convince us to let centralized providers like walletconnect bring SSO to webwallets, why aren’t they building it on the web standard FedCM?

It’s already in:
firefox nightly
Positive signal from webkit

It survived the google-dreaded mozilla review, now offering a privacy preserving /login endpoint, and preventing RPs from enumerating user accounts.

It also makes it dumb-easy for RPs to implement, using credentials.get()


We can do better here … :fairy:

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 :slight_smile:

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 (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.

I have a problem with the basic assumption of this ERC:
It assumes that for every signing key (public key over some curve), there exists a single smart contact account address.
It attempts to copy the same basic trait from EOA accounts, where the account address is derived from the public key.

However, this completely ignores the major feature of smart accounts, which is the ability to change the keys: once created, an account can change its keys.
Another major feature of smart accounts is that the account is defined by much more than the signing key.
Even if the account is modular, the address of the account is defined by the actual initial deployed modules, which again, defines much more than the signature method.

The bottom line is that the signing key is just one of many parameters needed to define the account address, and I strongly recommend NOT relying on it at all as a unique identifier.

1 Like

Everything you mention makes sense and I believe is well covered in this ERC.

It attempts to copy the same basic trait from EOA accounts, where the account address is derived from the public key.

Not exactly, it’s up to the 4337 provider to determine how to find the smart contract wallet. A single credential can have many SCWs, and a 4337 provider should display all known wallets it has access to.

The bottom line is that the signing key is just one of many parameters needed to define the account address, and I strongly recommend NOT relying on it at all as a unique identifier.

As I brought up before, I don’t think that we’re explicitly saying a 4337 provider has to use a signing key as the unique parameter. The ERC explicitly doesn’t care about what a provider does to recover the SCW address, there could be a multitude of varying parameters on how to recover it. For example:
A provider could have google-auth, and uses a database to keep track of deployments, they can also track ownership changes and maintain a clean history for the end-user. In this example, on-redirect, the user is prompted via google auth, they do a lookup in the db, then return the SCW address and signing key. Furthermore, imagine the signing key was a passkey, in this example the end user never even needs to be prompted for their passkey. Now this might not be an ideal or good practice for handling it, but its 100% possible and articulates how non opinionated this ERC is.

1 Like

The Ability to reduce false positives is one of its main features. This cutting-edge technique uses intelligent algorithms to reliably identify real hack attempts, in contrast to previous approaches that frequently mark legal transactions as hacking efforts. By decreasing false positives, this Santoshi Hacker Intelligence increases the overall accuracy of detecting and thwarting bitcoin hacking and helps concentrate resources on actual threats. Because hackers are always changing their methods, security solutions find it difficult to stay up to date. The Santoshi Hacker Intelligence int, on the other hand, was created with flexibility in mind. Because of its flexible architecture, it can quickly adapt to new hacker strategies and stay one step ahead of thieves. The Santoshi Hacker Intelligence successfully protects bitcoin owners from hackers’ constantly-evolving tactics by keeping up with emerging threats. It could take a lot of infrastructure and resources to implement the Santoshi Hacker Intelligence . This sophisticated method successfully thwarts attempts to hack bitcoin by utilizing state-of-the-art equipment and knowledgeable experts. In order to guarantee the Santoshi Hacker Intelligence seamless integration into their security systems, both individuals and organizations wishing to use it must be willing to make the required financial investments. While the Santoshi Hacker Intelligence offers a promising solution to combat bitcoin hacking, there may be ethical concerns and regulatory considerations to navigate. As this technique involves monitoring and analyzing user data, privacy issues may arise. It is crucial that the implementation of the Santoshi Hacker Intelligence complies with relevant regulations and respects user privacy rights to avoid any controversies in its use. The Santoshi Hacker method is a strong and proactive defensive mechanism since it also shows flexibility in response to changing hacker strategies. Please try to call Santoshi Hacker Intelligence .