Additional security features.

[evmKnows]

In principle the specification is a great move for better enduser protection.

Some purists would refer to the sufficiency of existing signature encoding standards but the reality is that many, if not, almost all wallet developers are brewing their own Blind <> Clear signing schemes / security engines. So having some form of standardization that unites dApp devs, hardware, software wallet devs & integrators is net-positive for everyone involved, including the users.

Why I am mentioning this. I think the spec can go a bit further, albeit at the cost of increased concerns of censorship (or "close to censorship"). Ultimately the user(s) always have the choice to perform "untrusted" actions, so as long its not bloated with too many speedbumps / warnings, the elevated security measures should be fine.

The issue currently goes the other way round, but for newer dApp devs / entrants >> having to "register" with wallet providers to get their contracts, dApp, URLs whitelisted / vetted.

Since the 7730 spec is already enriched with metadata, there is room for more features, or optional extensions touching security aspects in particular, potentially strengthening the case for a wallet / extension integration.

E.g.

(Ordered by high relevancy, high impact, at the top, less so at the bottom)

Binding Contracts, function calls or signature payloads to:

• One or more URLs / domains / subdomains, or a list of other integrating protocols (Gnosis Safe e.g.)

Threat Model: Phishing sites, impersonating the dApp

• Whitelisting interactions with external contracts at those URLs. (e.g. Permit2 only possible with schema x, entries y, dApp related contracts z with all of the options variably combinable)

Threat Model: Phishing sites, impersonating the dApp, injected malware.

• Pre-fills for critical entries (e.g. spender: address, should always be the contract, or recipient the user/signer itself)

Threat Model: Injected malware through different vectors, malicious extensions, supply-chain attacks in frontend dependencies, XSS.

Additional Note: The input validation for the user / signer address spec has to support Smart Contract Accounts (same EOA owning multiple SCAs)

• Bytecode hash for proxy / upgradability / factory patterns

Threat Model: Unauthorized / malicious upgrades of smart contracts.

• DNSSEC records for URLs

Threat Model: DNS Hijacking

• Signature schemes & pubkey. The payload has to be signed by the dApp backend, with the same key as specified in the files.

Threat Model: "Catch-all" of the above. BGP Hijacking.

• Cipher schemes (e.g. ECDHE)

Threat Model: "Catch-all" of the above. In particular, supply chain & side channel attack vectors, DEX apps receiving signatures to execute trades >> wallet integrators / analytics plugins / stealth malware silently intercepting and front-running orders.

The first 3 would help immensely wrt the high adversity of the space. As for all of the above, there is surely more aspects that could be covered. Except for No. 3 and 4, maybe a different EIP is needed, which if ever pursued should def. be drafted on top of 7730.