This is an extension proposal to EIP-1271, it addresses the issue of smart contract wallet signatures becoming invalidated and breaking certain dapps.
For example:
Assume a multisig smart contract wallet with signers X and Y, you use signer X to list some assets on opensea, 2 weeks later you replace signer X for a new signer, Z. Without any additional measures, the listing becomes invalidated.
Using this EIP the wallet can use signer Z to re-sign the message, and the dapp can non-interactively fetch the signature as a replacement.
It would be helpful if the rationale section included why a fully on-chain solution was not chosen. Itâs stated that URI can be used with both centralized and decentralized systems, but not why URI is a better choice over a fully on-chain system.
This solution wonât work for contracts that forward the signature. For example, you could have an approve-transfer batch contract (using something like Daiâs permit.) The off-chain application might have no idea a signature is being used in a subcall, and so wonât know that it needs to retry.
The top-level caller should still be able to detect the signature is stale and do the replacing. Maybe the EIP should specify that all signatures should first be validated using EIP-1271 (and replacing if needed), even if that signature is going to be used for something other than direct validation.
Is this a common thing? if a signature is used internally then itâs most likely an input of the top-level caller, a contract that stores signatures could lead to the scenario, but I havenât seen that pattern out there.
This scenario is hard to cover because the smart contract wallet doesnât have that information on-chain (otherwise it could just accept the digest and ignore the signature), but at least the edge case reverts back to the status-quo (the stale signature fails).
I just noticed that you donât define which algorithm to use for _digest. Probably should do that.
Have you considered using an EIP-1155 style URI format, where the client is expected to substitute {digest} in the returned string with the digest value? If thereâs some technical reason why that wouldnât work, might be good content for the Rationale section.
My bad, digest is meant to be the hash as defined by EIP-1271. That can be a little bit confusing, I will update the EIP so it uses the same nomenclature.
This is an interesting idea, the biggest benefit is that a client wouldnât need to call the contract to fetch every replacement URL. I think this makes more sense on metadata (because you usually need to fetch N tokens), Signature replacement is only triggered when a signature is found to be invalid, so a 1 by 1 basis.
Weâre trying a new process where we get a volunteer peer reviewer to read through your proposal and post any feedback here. Your peer reviewer is @abhinavmir!
If any of this EIPâs authors would like to participate in the volunteer peer review process, shoot me a message!
@abhinavmir please take a look through EIP-5719 and comment here with any feedback or questions. Thanks!