Hey @sscovil, thanks for bringing this up and reviving this thread. I am happy to help move that forward too.
As discussed earlier in this thread there are 2 non-mutually exclusive proposals that we could push forward
A) EIP-1102 backward compatible extension (adding a challenge string to eth_requestAccounts)
B) Generic Automatic Signatures (PR-2224)
A) is simple and backward compatible. should be easier to get accepted. It does not offer the full feature set of B) but for authentication might be enough. Interested to know what you think here.
B) is more powerful and actually with B you don’t need A) anymore, but there are still open questions that I mentioned in the PR
- Is it secure to let applications sign at will (even if the message is prepended by “Automatic Signature”) ?
- Or should we do such signing using a non-hardened derived key ?
- If so could EIP-1102’s eth_requestAccounts be used to provide the parameter to derive from (could be one based on the origin of the document) ?
- Should we rate-limit the requests ?
Also if we explore B) we could also explore further proposals that I discussed in the past.
1 Like
@wighawag please see my comment on your PR, which includes a proposal for a revised version of the draft. For some reason, I can’t include a link in my post, but it’s https://github.com/ethereum/EIPs/pull/2224#issuecomment-2884118048
1 Like
Thanks, as I replied on the PR comment, we should discuss here further before moving with a fully fledged PR.
In particular I would like to know the rationale for generic automatic-signatures compared to having it as part of eth_requestAccounts
The important one I see is that eth_requestAccounts is supposed to be invoked once and asking for authentication signature might require further request.
While eth_requestAccounts can be invoked multiple time, I am not sure of the current behavior across wallet, do they show popup even if the user already accepted the request ?
if so it would make automatic signature more compelling.
Another thing I would like to hear is about potential use case of Automatic signature that would not be fulfilled by an extended eth_requestAccounts
1 Like
It’s a great question. At first, I felt the idea of having automatic authentication built right into eth_requestAccounts made a lot of sense. However, I’m not sure what that would look like for an app developer, in practice.
For example, let’s say you visti my site for the first time and click a ‘Connect Wallet’ button. Upon clicking it, my client application code calls eth_requestAccounts, and the account is connected successfully.
In this scenario, how can I as the app developer be sure that the wallet performed any sort of authentication at all? What if the wallet doesn’t support automatic authentication, but does support the current implementation of eth_requestAccounts? Would the return value of eth_requestAccounts need to change?
Changing the behavior of eth_requestAccounts creates versioning and backward compatibility concerns that could be avoided altogether by introducing a new method instead.
A new method could reasonably be expected to return a signed authentication message that the application can verify. I’m not sure it would work if we just modified the behavior of eth_requestAccounts…
We should be able to keep backward compatibility with eth_requestAccounts and ensure apps can identify if eth_requestAccounts with authentication is supported by having a different request and response type.
But even if we could not or if we did not want to overload it, we could simply add a new request like eth_requestAuthenticatedAccounts that keep the old behavior of associating domain with accounts but also return signature for authentication.
(EDIT: and after reflection this seems indeed a better approach: having a new method for clarity)
So I would not worry too much at this point about the api itself
In other word, the choice is between
A) having authentication as part of the connection flow
or B) having a method to auto-sign independently
The advantage of having the connection flow return signature of connected accounts, is that we reuse the exisitng user approval and it means it works with hardware wallet or other wallet that cannot support automatic signature without assuming they are connected all the time.
Having authentication as part of the connection flow makes sense, as long as it’s verifiable by the application requesting authentication. The server cannot just trust the wallet.
Yes of course, that’s why the challenge string is added
And the response type could be something like
{address: '0x${string}', signature: '0x${string}'}[]
(I kept the array type to match eth_requestAccounts but having a single {address: '0x${string}', signature: '0x${string}'} might be preferable and we could then remove the plural form. A strong reason here to have a different method name like you suggested.
And as mentioned in this thread above we can use the same prefix scheme : Automatic Signature: <challenge> for the signed message to be verified
But I still wonder what should the behaviour of wallets be when calling wallet_requestAuthenticatedAccount multiple times
(I used the wallet_` prefix here as it is a namespace we should move to for wallet specific RPC methods)
Currently eth_requestAccounts needs to be called when the wallet was never connected or is locked. Is that sufficient?
What if the backend require the authentication to be short lived and require a new authentication signature even though the wallet is neither locked not disconnected.
Should eth_requestAuthenticatedAccount accept being called multiple time and only show a popup if the rate limit is reached or if the actual private key / signing capability is not available instantly (hardware wallet…)
I guess that works. In some ways it become very similar to wallet_autoSign except that the connection flow is included, solving the case for hardware wallet too and allowing the wallet to continue using eth_requestAccounts-like behaviour to show a confirmation popup if needed (rate limit, locked, etc…)
I think the act of a server requesting access to an account from a wallet is distinct enough from the act of a server asking a wallet to verify ownership of an account by signing a challenge message, that it warrants two separate methods.
The first method already exists. The second method is what we believe is essential. If we want to separately propose a third method that combines the two, I would be supportive of that…but for now, I think we should just focus on the path of least resistance.
If an application has to make a call once to gain access to an account, and then once per session to authenticate, that is perfectly acceptable and should raise no concerns.
If, on the other hand, an application makes a since call once to gain access to an account and authenticate, then the application needs to be confident that, once a wallet has granted it access to a an account, it can be sure that wallet owns that account in perpetuity. This assumption is what makes my security senses tingle. It seems like an attack vector that could be exploited.