You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -238,11 +254,24 @@ Surfacing the prepared calls should be relatively simple for wallets, who alread
238
254
239
255
## Backwards Compatibility
240
256
241
-
TBD <!-- TODO -->
257
+
This specification is currently compatible with EIP-5792 and does not introduce breaking changes to existing `wallet_sendCalls` flows.
258
+
259
+
- It does not modify or deprecate `wallet_sendCalls`; wallets compliant with EIP-5792 continue to work unchanged.
260
+
-`wallet_prepareCalls` mirrors the `wallet_sendCalls` request shape and returns values intended to be forwarded to `wallet_sendPreparedCalls`, preserving field formats such as `capabilities`, `chainId`, `context`, and `version`.
261
+
-`wallet_sendPreparedCalls` consumes the same data the wallet would otherwise construct internally for EIP-5792, with the addition of an externally produced `signature`.
262
+
- Any additional key types or hints (e.g., WebCrypto/WebAuthn variants) are optional and do not affect EIP-5792 behavior.
242
263
243
264
## Security Considerations
244
265
245
-
Needs discussion. <!-- TODO -->
266
+
- Key authorization and scope: Wallets MUST verify that the provided `key.publicKey` is authorized for the account and that the requested `capabilities` are within that key’s permissions (scopes, limits, validity windows).
267
+
268
+
- Prehashing consistency: Honor `key.prehash` consistently. A mismatch between signer and verifier (e.g., double-hashing vs prehashed input) can cause verification failures. Wallets SHOULD fix the hash function per key type.
269
+
270
+
- Preparation-to-execution linkage: Wallets SHOULD ensure `wallet_sendPreparedCalls` corresponds to a `digest` they could have produced (e.g., by recomputing it) and MAY track a preparation identifier and/or validity window to mitigate long-lived replay.
271
+
272
+
- WebAuthn/origin considerations: For `webauthn-p256`, prefer user-verification and origin-bound credentials. Applications SHOULD keep session keys non-extractable and hardware-backed where available, and avoid presenting opaque digests for end-user approval.
273
+
274
+
- Resource usage and DoS: Wallets MAY rate-limit `wallet_prepareCalls`, cap bundle sizes, and validate inputs early to avoid expensive context generation for malformed or adversarial requests.
0 commit comments