feat: reject update calls when sender_info restricts permissions to queries

[aterga]

Queries-only permission for sender_info — combined read-only-session design

Stacked on #10452 (delegations can require a signed sender_info): this PR is now rebased on top of that branch, and together they form the complete, protocol-enforced read-only-session design. The base of this PR is set to the #10452 branch so the diff shows only the attribute-checking part; GitHub will retarget it to master automatically when #10452 merges.

The combined design

1. feat: delegations can require calls to carry a signed sender_info #10452 — the delegation bit: the issuer (Internet Identity) signs the session delegation with sender_info_required = true. The field is covered by the delegation signature, so the dapp holding the session key cannot strip it; update calls without a sender_info are rejected (SenderInfoRequiredByDelegation).
2. This PR — the attribute semantics: when an update call carries a sender_info whose info blob is a Candid-encoded ICRC-3 map (the format II certifies under the ic-sender-info domain separator) with the attribute implicit:permissions = "queries", the call is rejected (UpdateCallNotPermittedBySenderInfo). Query calls are unaffected.

Together: a read-only session must present its certified attributes on every update call (1), and those attributes forbid update calls (2) — so the restriction holds regardless of client cooperation, while all permission semantics stay in the extensible attribute map rather than the delegation format. The new read_only_sessions e2e test module in rs/validator/ingress_message/tests/validate_request.rs demonstrates the full story: update with queries-only attributes → rejected; update omitting attributes → rejected; queries → permitted; update with "updates" attributes → permitted.

Design notes (attribute checking, this PR)

• Enforcement point: HttpRequestVerifier<SignedIngressContent>::validate_request — the same layer that enforces delegation targets; the ingress manager uses the same verifier for payload validation, so the restriction also holds during block validation.
• Attribute key: implicit:permissions (single colon), following II's existing implicit:nonce / implicit:origin convention. The attribute parsing only runs after the canister-signature verification of the blob succeeded, with bounded Candid decoding quotas.
• Fail-open for unknown values (legacy-blob compatibility): only the exact value "queries" restricts. Note the presence requirement of feat: delegations can require calls to carry a signed sender_info #10452 and the delegation field itself are fail-closed.
• Update-call path, not update methods: replicated queries via /call are also rejected (the validator cannot know method kinds); restricted callers use the query path.
• The ICRC-3 Value type is mirrored minimally inside ic-validator to avoid pulling ledger packages into the consensus-critical validator.

Tests

• Unit tests for permission extraction/decision logic.
• End-to-end tests with validly canister-signed sender_info, plus the combined read_only_sessions module described above.
• System test (requests_with_sender_info_permissions in rs/tests/crypto/ingress_verification_test.rs) demonstrating attribute enforcement against a real replica across all /call API versions.

Related

• feat: delegations can require calls to carry a signed sender_info #10452 — base of this stack (sender_info presence requirement).
• feat: reject update calls for delegations with queries-only permissions #10449 — alternative explored in parallel: carrying the permission semantics in the delegation itself.
• Internet Identity and interface-spec changes (checkbox → read_only → attribute issuance / delegation bit) are prepared as patches pending repo access.

cargo test -p ic-validator -p ic-validator-ingress-message -p ic-types passes on the stack, clippy is clean, and the system test binary compiles. Bazel was not available in the development container, so CI should confirm the Bazel build.

https://claude.ai/code/session_01BQNgPJKgxWohrJ6owwJBzz

[Copilot]

Pull request overview

This PR introduces a protocol-level restriction on sender_info for update calls: if a canister-signed sender_info.info decodes as an ICRC-3 map with implicit:permissions = "queries", the replica rejects /call requests during ingress validation (while leaving query/read_state validation behavior unchanged).

Changes:

• Add Candid-decoding of sender_info.info in ic-validator to extract implicit:permissions and reject update calls when it equals "queries".
• Introduce a new validation error UpdateCallNotPermittedBySenderInfo and plumb it through ic-validator-ingress-message.
• Add unit + integration tests and update Cargo/Bazel dependencies needed for Candid decoding in the validator and for encoding test payloads.

Reviewed changes

Copilot reviewed 9 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
rs/validator/src/ingress_validation.rs	Add permission extraction/decision logic and new validation error for update calls.
rs/validator/src/ingress_validation/tests.rs	Add unit tests covering permission extraction and fail-open behavior.
rs/validator/ingress_message/tests/validate_request.rs	Add end-to-end tests verifying update rejection vs query acceptance with permissions.
rs/validator/ingress_message/src/lib.rs	Add new public error variant and Display message in the ingress-message wrapper crate.
rs/validator/ingress_message/src/internal/mod.rs	Map the new ic_validator error into the wrapper crate error.
rs/validator/ingress_message/Cargo.toml	Add candid dev-dependency for encoding test payloads.
rs/validator/ingress_message/BUILD.bazel	Add Bazel test dependency on candid.
rs/validator/Cargo.toml	Add candid, serde, and serde_bytes dependencies needed for decoding in validator.
rs/validator/BUILD.bazel	Add Bazel deps for candid, serde, and serde_bytes to the validator library.
Cargo.lock	Record new dependency edges for candid/serde_bytes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[aterga]

Note to reviewer.

If you dislike adding candid as a dependency here, we can provide a non-candid endpoint in II to serve a different encoding of sender_info - please indicate your preferred encoding to keep this thread actionable.

[aterga]

Closing in favor of the more lightweight approach in #10449 (delegations carry the queries/all permissions directly), which is fully green and consolidates this POC. The sender_info-attribute checking explored here remains documented in this PR's history should the certified-attributes route be revisited.

---

Generated by Claude Code