Add session-key scoping integration tests#23
Open
willemneal wants to merge 3 commits into
Open
Conversation
Deliverable 1 lists session key scoping as required test coverage, but the existing suite only verified that the default context rule exists. These tests exercise the context-rule machinery the migration flow relies on for delegated, limited-scope keys: - add_scoped_context_rule: a CallContract-scoped rule registers with the expected type, valid_until, and signer, and bumps the rule count - session_key_authorizes_within_scope: a scoped session key authorizes the contract it is scoped to - session_key_rejected_outside_scope: the same key is rejected for other contracts (only the default passkey rule applies there) - expired_session_key_rejected: scoped rule honors valid_until once the ledger advances past expiry - removed_session_key_rejected: remove_context_rule revokes the key Extends the test-only SmartAccountClient with add/get/update/remove context-rule methods to drive these through the contract. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Preview deployed! Account URLs: |
The committed test snapshots referenced an outdated WebAuthn verifier wasm hash (c6fa2216...) from an earlier build. The current optimized build produces bb43ad35..., already reflected in the new scoping snapshots. Update both the contract-instance executable and wasm code-entry references in the pre-existing snapshots to the current verifier hash. Done as a targeted hash swap rather than a full regenerate: the suite uses random P-256 keys, so regenerating would churn non-deterministic key material on every run. Only the deterministic verifier wasm hash changes here. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The suite generated P-256 keys with SigningKey::random(OsRng), so every test run rewrote the recorded test_snapshots/ with fresh key material — making the committed snapshots perpetually stale and their diffs pure noise. Add a deterministic test_key(seed) helper (SHA-256 of the seed -> P-256 scalar; no new deps, sha2 is already pulled in). Because p256 ECDSA signing is deterministic (RFC 6979), a fixed key yields fixed signatures, so the snapshots are now byte-identical across runs (verified by running the suite twice). Each call site gets a distinct seed where it needs a distinct key (deployed passkey = 1, session key = 2, wrong-key = 99, verifier tests 10-13). This regenerates every snapshot once with stable values (and supersedes the prior targeted verifier-hash swap, since the current hash is now recorded naturally). SigningKey::random stays available for future property/fuzz tests that assert invariants rather than record ledger state. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Deliverable 1 (Smart Contracts — Feature Complete) lists session key scoping as required test coverage. The contract already implements it via OpenZeppelin's context rules, but the existing suite only verified that the default context rule exists — it never exercised scoped keys, expiry, or revocation. This PR closes that gap.
What
Adds
crates/integration-tests/tests/it/smart_account_scoping.rs(5 tests). A "session key" is modeled as a second P-256 passkey added under aCallContract-scoped context rule:add_scoped_context_rule— aCallContract-scoped rule registers with the expected type,valid_until, and signer, and bumps the rule count from 1 → 2.session_key_authorizes_within_scope— a scoped session key (not part of the default rule) authorizes calls to the contract it is scoped to.session_key_rejected_outside_scope— the same session-key-only signature is rejected for a different contract, where only the default passkey rule applies.expired_session_key_rejected— the scoped rule authorizes beforevalid_until, then is rejected once the ledger advances past expiry.removed_session_key_rejected—remove_context_rulerevokes the key; a previously valid signature is rejected afterward.Also extends the test-only
SmartAccountClient(src/lib.rs) withadd_context_rule/get_context_rules/update_context_rule_valid_until/remove_context_ruleso the tests drive scoping through the contract'srequire_auth-guarded entry points.Testing
cargo test --workspace— integration tests go from 11 → 16, all green. No production contract code changed.🤖 Generated with Claude Code